Digital Signal Processing (DSP) is an important issue in every project involving data transfer and Mission 2004 is no exception. A regular data transmission from Mars to Earth usually includes 20-40% noise, which means that one or two bits out of every five transmitted are lost. As a consequence, about one-third of the data will be unreliable. A more thorough discussion of the problem may be found in Appendix A.

 
Concerns

 
For our particular mission, we wanted to choose hardware and an error-control code for all transmitting equipment (e.g. satellites, rovers, LMRs, space suits) with the following characteristics:

• Able to remove up to 50% noise from any transmission;
• Simple enough to run everywhere in real-time, eliminating signal delay;
• Efficient with respect to the computational power used for a single transmission; and
• Reliably effective.

We considered the  the following error-control codes [2]:

• Single-error-correcting (SEC) Hamming codes,
• Reed-Muller (RM) codes,
• Bose-Chaudhuri-Hocquenghem (BCH) codes, and finally,
• Reed-Solomon (RS) codes.

In the end, several characteristics recommended adoption of the RS codes for Mission 2004. The RS error-correction method has been available since the mid-1960’s and has been used in most, if not all, applications in which when extreme reliability is needed. For example, the RS codes can remove up to 50-60% noise from any transmission, resulting in a loss of1 bit of data out of 10 million transmitted, on average. The algorithm used is quite simple and can easily be run on almost every processor in real time. For example, an RS system is able to process up to 1Mbps data on 40 MHz PowerPC (around 1MFLOPS) processor in real time. Even if a 16Mhz 386 processor is used, around 100Kbps could be processed in real time. Most importantly, NASA has used RS codes for numerous missions, proving its reliability.

 
Mission Integration

 
After deciding on the error-control code, we turned our attention to its implimentation. Since our mission involves so many different environments that have to run DSP, they were divided into two groups:

• Equipment capable of running DSP software with its own CPU (e.g., satellites, base station, big rovers), and
• Equipment incapable of doing so (e.g., LMRs, space suits) because of limited computational power.

Two entirely different protocols are needed for the two environments. Implimenting the software on DSP-capable equipment is straightforward, but the next problem is a bit more complex. For its solution we have to build a "black box", capable of:

• Getting a digital signal on input,
• Processing it in real time and converting it into analog, and
• Sending the signal to the antenna through the output.

In addition, the instrument has to be energy efficient because the equipment has very low power resources. Building the actual "box" is not that difficult, since there are companies doing so already [3], but we need to customize it for our mission. In terms of power efficiency, we require a processor that will use as little power as possible and still be able to deal with all our data. It has been suggested by Transmeta Corporation that CPU power consumption will have decreased enough by our launch date that it will be possible to run a  1GHz processor at 100MFLOPS, processing up to 10Mbps, with as little power as 4 W [4] , This is far in excess of our requirements, since satellite-to-satellite communication invoves only up to 4Mbps [5].

 
DSP “Black Box” Specifications (roughly estimated)

Output: Analog radio signal to an X-band or Ka-band antenna. 
 
 

Appendix A

This series of images illustrates the need for high-quality noise reduction codes. Each frame is the same photo of the Mars Pathfinder rover (Sojourner) with different amounts of noise: 0% (upper left), 5% (upper right), 20% (lower left), and 40% (upper right). Even 5% noise represents significant signal degradation, but typical "uncorrected" signals from Mars contain upward of 20% noise and 40% noise is sometimes encountered. With  good noise-reduction routines, like Reed-Solomon codes, we can  "remove" about 50% of the noise from any data transmitted, with an expectation of losing about one bit out of10,000.

Appendix B

Serial Port	Max Data Transfer Rate	Max Number of Operating Devices	CPU needed	Power supply needed
RS-485	10Mbps	32	6 MFLOPS	<1W
USB	40Mbps	127	20 MFLOPS	1-2W
Firewire	400Mbps	64	200 MFLOPS	4-10W

References

Author: Jordan Brayanov (jordan12@mit.edu)