New Page 1

Communication and Software
DSP and Error Control

Abstract

Digital Signal Processing (DSP) is a big issue in every project dealing with some king of data transfer. Since our mission is mainly dealing with collecting, processing and transmitting valuable information from the surface of Mars to the Earth the need of a good DSP was considered as vital for our success. A regular data transmission from Mars to Earth usually gets around 20-40% noise, which means one or two bits out of every five transmitted are lost and therefore about 1/3 of the data will be unreliable. For a better understanding and some visual examples of the problem see Appendix A.

Concerns

For our particular mission there are several concerns taken into account while choosing the best error-control code and hardware to be used for the DSP. Since we want to have a DSP running on all the transmitting equipment (e.g. satellites, rovers, LMRs, space suits) we need a code which:

Will be able to remove up to 50% noise from any transmission,
Is simple enough to run everywhere in real-time, so we do not get a signal delay,
Is power efficient, in terms of the computational power used for a single transmission,
Has been tested before and has proven its effectiveness.

All of the following codes were considered throughout the process of finding the most appropriate one [2]:

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

After careful examination and research done, the RS codes were decided to be the most appropriate for our mission, because of their characteristics. The RS error-correction has been around since mid-1960’s and has been used in most, if not all, of the cases when extreme reliability has been needed, because it is able to remove up to 50-60% noise from any transmission with a chance of losing 1 bit of data out of 10 million transmitted. And the algorithm used is quite simple and can easily run on almost every processor in real time. A reasonable estimation about its speed is that a RS system is able to process up to 1Mbps data on 40 MHz PowerPC (around 1MFLOPS) processor in real time. And even if a 16Mhz 386 processor is used, around 100Kbps could be processed in real-time. And the best part of it is that NASA had used RS codes in all their missions and had proven that it actually works.

Mission Integration

After deciding what should be used we had to decide how are we going to use it. And since in our mission there are so many different environments that have to run DSP, they were divided into two sub-sections:

Equipment capable of running DSP software on its own CPU (e.g. satellite, base station, big rovers), and
Equipment incapable of doing so (e.g. LMRs, space suits) because it does not have that much computational power installed.

Because of those two problems, two entirely different solutions are needed. The software solution is pretty easy and intuitive. We just have to run DSP software on the main computers of the given equipment and it will take care of everything. 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 at the input,
Processing it in real time and converting it into analog,
Sending the signal to the antenna through the output, and
Not wasting the whole power of the equipment running it (e.g. an LMR).

Building the actual “box” is not that difficult, since there are companies doing it [3], but we need to customize is, so that it will be the most appropriate one for our mission. In terms of power efficiency we have to use a processor that will use as less power as possible and still be able to deal with all our data. According to [4] the new company Transmeta corp. shows that by the day we actually have to run our mission the CPU power consumption will be decreased so much, that on 4W we will probably be able to run a 1GHz processor, doing 100MFLOPS and process up to 10Mbps, which is far more than we will be able to use (since a satellite-to-satellite communication cab be up to 4Mbps [5].

DSP “Black Box” Specifications (roughly estimated)

Dimensions: from 7cm x 10cm x 3cm to 15cm x 20cm x 10cm, depending on the power supply and the data transfer rate supported.

Weight: from 0.3kg to 5kg, again depending on the power supply and data transfer rate.

Input: digital signal from digital cameras, computers, analytic devices through a serial port (e.g. RS-485, USB, or Firewire), depending on the data transfer rate. For better understanding -- see Appendix B.

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

Appendix A

What you can see on those four pictures is a photo of the Mars Pathfinder. The first picture is the actual one and then there are 3 others with 5%, 20% and 40% noise on them. As you can see even 5% noise is bad enough for any research purposes. And a regular transmission from Mars usually gets about 20% noise (pic #3). And sometimes we can even get a picture with 40%-50% noise on it (depending on distance/time/other stuff). Using a good noise-protection, like Reed-Solomon codes we can "remove" about 50% noise from any data transmitted, with a chance of losing one bit out of 10000.

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

[1] Lee, L., “Error-Control Block Codes for Communication Engineers”

[2] Co-Optic Inc., http://www.co-optic.com/reedsolm.htm

[3] MacInfo, “Processor Power Consumption”

[4] Broniatowski, D, "Sattelites and antennas"

Author: Jordan Brayanov

A printer-friendly version (PDF) could be found here.