[Date Prev][Date Next][Thread Prev][Thread Next] - [Date Index][Thread Index][Author Index]
Flight Computers - the MIPS FLOPS POPS and HOPS fad
A point for thought. Lots of people bring up the issues of cpu obsolescence.
The claims are: why use an old and slow X86, NEX V5X when we have the mega
super duper new processors which can simulate nuclear cold fusion in half a
picoseconds?
Well, in these discussions, I always ask the participants to hold on for a
second. The new wave of processors are driven by multimedia. True, they are
being designed for high performance to power ratio. Also true that they also
cross the fuzzy line between a CPU and a DSP when they support the MAC
instructions.
If we get back to the world of Spacecraft On Board Computers, why do we need
the speed for housekeeping capability? Spacecraft on orbit management, has
not changed much in probably 10-20 years. All in all, the duties of a
OBC/IHU/C&DH unit are:
1. Listen to ground command - do something funky when command received
2. Maintain power budget
3. Run some sort of scheduler for "tasks". Don't confuse tasks with
multitasking. Spacecraft tasks are usually associated with turn device A on
for x minutes, turn device B off if A is on, switch between receivers and so
on.
Now, some of you might be saying: well, lets add lots of MIPS to the OBC and
do AODC, several Kalman filters, and some FFT for the audio uplink, and then
a DFFT for the uplink - add a pretty brick filter and audio processing, so
the audio will come down with 1e-5 THD into a $50 Radioshack receiver (with
10% THD) :-)
Well, that's all nice, and for a while it was a hot item. But then everyone
found out that when a mega MIPS OBC has to run housekeeping tasks plus a
number of other complex tasks, it becomes really difficult to schedule, much
less reliable, and alsmost impossible to manage.
So the latest evolution stands are the concept of distributed computing,
i.e.:
1. Build a slow and RELIABLE OBC. It could be slow, but it would run a well
written bulletproof task to manage the spacecraft. Use an older CPU which is
built using larger gate size, and thus more reliable.
2. Add a funky high tech cpu which will enable you to run all the payload
computation you need. Bugs in this payload software wont affect spacecraft
management and will be done independently of it.
This approach will make the operators life easier, and the experimenters
life easier.
For instance, at present, RUDAK's independence allows the RUDAK operator to
upload and test different code regardless of housekeeping tasks. He is
assigned time and power and cannot do any harm to the OBC even if he wanted
to. This kind of independence makes things simple. So I think the bottom
line is that an OBC needs to be a simple, reliable CPU which could be
obsolete as far as the industry is concerned, yet perfect as far as the
satellite builder is concerned.
Assi 4x1kx/kk7kx
***************************
Assi Friedman
email: 4x1kx@iarc.org
http://www.iarc.org/~4x1kx
**************************
----
Via the amsat-bb mailing list at AMSAT.ORG courtesy of AMSAT-NA.
To unsubscribe, send "unsubscribe amsat-bb" to Majordomo@amsat.org
AMSAT Home