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

Re: Flight Computers

On Wed, 01 May 2002 15:06:55  
 Phil Karn wrote:

>Whenever somebody says they need "real time support", I'm always
>curious to know just what they mean. Obviously, if you don't have
>enough total cycles to run all your applications, you need a faster
>CPU, not a real-time OS.
>Sometimes the desire for "real time" comes from the need to avoid
>losing some incoming data (e.g., an A/D sample), as opposed to a need
>to actually act on it in some significant way before some short
>deadline. This particular problem can often be solved with good
>hardware and device driver design, e.g., hardware buffering and an
>interrupt handler that quickly empties or fills it.

Phil, et al

I was very interested about your comments on the need for real time.  I worked on a launch vehicle controller a couple of years back and here is what I did.

We used an Analog Devices 20161 to control the entire bird.  Here is the software that we used.


We had a reference mission in ROM and then used inputs from sensors to verify that profile and then command the engine thrust vectoring to keep us on vector.

Engine Control

The software sensed the state of the engine and controlled the sequence of valve openings to actually run the pressure fed engine.   

Communications and Telemetry

Controlled the packetizing of data from the on board sensors and other telemetry and then transmitting it to the ground, including error correction

This was all accomplished by a 50 millisecond timer that set off a sequence that was a task switch that went through all of the above software.  

The SHARC had so much horsepower that our analysis of the processor bandwidth loading is that with all of the above running we used about 15% of the processor bandwidth.  Most of the time was spent waiting for the next task switch.

This is a reason that I am a very strong advocate of doing whatever it takes in radiation shielding to protect the processors.  This brings so much greater reliability to the system than trying to use the last ounce of power from an ancient processor.

The software development environments are much nicer and reliable as well.

Oh the SHARC has a good compiler and lots of source code.  It is extensively used in communications systems and would support an AMSAT on orbit software radio.  That is a radical thought.


Via the amsat-bb mailing list at AMSAT.ORG courtesy of AMSAT-NA.
To unsubscribe, send "unsubscribe amsat-bb" to Majordomo@amsat.org