[Date Prev][Date Next][Thread Prev][Thread Next] - [Date Index][Thread Index][Author Index]

Re: Longevity-sat proposal

Emily Clarke wrote:

> At 03:54 AM 10/28/2003 -0800, Cathryn Mataga wrote:

>> 1.  No batteries.  Design from the start to live off of power
>> from the solar cells.  This means the satellite could live beyond the
>> life of existing batteries
> You really would need batteries if you want the satellite to work during 
> eclipses.  You could run the transponder off the panels only but you 
> should have minimal battery power to keep alive some critical systems.  
> Also, you may need some battery power to cushion the blow of high 
> powered signals coming into the transponder.  If you listen to AO-7 you 
> can tell when the solar panels are not providing adequate power because 
> it will FM.  But certainly higher efficiency solar cells and 
> un/under-stressed batteries would contribute to longevity.

The no-battery thing is just part of the concept.  And that
means when it's dark, it just goes off.  As far as 'critical
systems' just don't have any.  And with a little planning,
it'd be possible to make it go down a little more gracefully
than AO7 does that starts to wig out.  As far as how the system
behaves with high power signals, seems to me easiest just to make
an AGC that can handle it.  I don't see why this requires a battery.

>> 2.  No microprocessor.  Do all the logic with chips with great big
>> fat gates that can survive a long time.  Or maybe use transistors.
> Discrete transistors alone would not guarantee immunity to radiation 
> damage and would probably cause the weight and power budget to balloon.  
> For that matter eliminating the microprocessor doesn't really improve 
> survivability though having a backup would.  However it's true that the 
> more simple the design the more survivable it will be.  By eliminating 
> complexity you improve your chances of survivability.
>  From what I can gather out of AMSAT records, the reasons satellites go 
> SK are varied but batteries lead the way.
>  8 De-Orbits
> 14 Battery failures
>  7 Computer failures
>  5 Transponder or receiver failure
>  1 Temperature failure
>  1 Radiation related failure
>  8 For unknown reasons
>  3 Other reasons

Those are interesting numbers.  Both the battery and computer are the cause
of quite a few failures, looks like.

>> 3.  Only provide the simplest control.  Transponder On and OFF. That's 
>> it.
> That's pretty simple.  However once you provide controls for one action, 
> adding additional controls is relatively easy.

Though my thought was that with the bigger gates, transistor or otherwise,
it'd be trickier to build and use more power, so to compensate for that
just limit control to the ultra-bare minimum.  Only a single on/off
switch and make that extra redundant.

>> 5.  Omni antennas.  Assume tumbling and prepare for that in
>> advance.  Design it so if it tumbles it's still okay.
> Good idea but this would mean more tx power.  If the satellite is 
> tumbling it might run into a situation where the antenna gets partially 
> or completely shadowed by the satellite body.  Spin stabilization would 
> be much better.

Do you get spin for free as part of the launch?  I'm just thinking long
term here.  And if the goal is a satellite design life of 30 years,
is it reasonable to expect it to stay spinning all that time?  The philosophy
here is to dump everything that won't last forever.  So, if it won't stay
spinning, then the only option is to make it tumble and to deal with that.
High gain antennas would be better, but like, then if it ends up tumbling,
that's not so good.

Simply, can we make a satellite that our grandchildren could use?  It seems
to me, if we planned for a super-mega-long lifetime of these things.  And,
say we launched 1 every 3 years or so, then in 21 years, there'd be like
7 of them up there.   AO7 has proven the concept, by accident.  There'd
be some huge compromises, I guess I'm trying to figure out if there's
an intersection between the compromises and something actually useful.
and fun.
Sent via amsat-bb@amsat.org. Opinions expressed are those of the author.
Not an AMSAT member? Join now to support the amateur satellite program!
To unsubscribe, send "unsubscribe amsat-bb" to Majordomo@amsat.org