[Namaste-dev] Re: Software Defined Radio - Mars Lander daily software changes

Phil Karn karn at ka9q.net
Fri Jun 13 23:06:19 PDT 2008


grayg ralphsnyder wrote:

> The data relay satellite orbiting Mars has a 'safe mode' that it goes 
> into when some fault occurs or by other causes such as excessive 
> radiation.  It stops what is was doing until it receives new 
> instructions.  Do all satellites have this feature ? 

Safe mode is a very common feature on spacecraft, especially 
interplanetary research probes. They tend to be complex and nearly 
unique so there are many ways to get into trouble. The distance to earth 
and the path losses are so high that some autonomy is needed. The 
spacecraft must have some basic protective instincts such as the ability 
to maintain a positive power budget and establish some sort of link with 
earth. This usually involves acquiring the sun, pointing solar panels at 
it, and then using the sun and other attitude references (e.g., star 
trackers) to point a high gain antenna at the earth.

If this isn't possible the spacecraft can switch to an omni directional 
antenna and a very low data rate. I've seen emergency rates as low as 5 bps.

The first amateur spacecraft to have an onboard computer and thereby be 
heavily software dependent was AMSAT Phase-IIIA, lost in the Ariane L02 
launch failure in May 1980. A near copy, Phase-IIIB, was launched as 
Oscar-10 in 1983. Both spacecraft used an RCA 1802 computer to control 
the entire spacecraft operating state. The command receiver fed a 400 
bps BPSK demodulator that in turn fed a computer input port read by the 
operating system. Without the computer running, there was no way to 
command the spacecraft.

In case the 1802 crashed, a hardware sequence detector continually 
monitored the command demodulator output for a special reset sequence. 
Special hardware loaded a block of uplink data into RAM and reset the 
computer to execute it. There was no ROM.

The RAM used a simple (12,8) binary Hamming ECC to protect against 
single bit RAM errors. An XOR ladder generated the four parity bits as 
each byte of data was written to RAM, and hardware also corrected read 
errors. A software "wash" routine ran in the background on the computer. 
It simply read each byte of RAM and wrote it back, causing the ECC 
hardware to detect and correct any errors. This was necessary to reduce 
the chances of any single RAM location containing two or more bit 
errors, which would have been uncorrectable.


More information about the Namaste-dev mailing list