Deep Space Network


Deep Space Network logo

NASA's Deep Space Network (DSN) has some very immediate problems

  1. NASA DSN science data is being continuously lost with Voyager I & II missions at the Madrid, Goldstone and Canberra signal intercept sites due to rain fades and decay of reception equipment.
  2. NASA (unlike SETI @ Home) has failed to innovate by using software to decode telemetry from Deep Space Missions -- famous for their very weak signals.
  3. NASA uses hardware (and hardware only) decoding technology. Thus NASA loses DSN data all the time.
  4. DSN @ Home can fix most (but not all) of the Deep Space Network’s problems relating to the Voyager missions -- and New Horizons.
  5. The US economy is operating under difficult conditions caused by the role debt now plats in the economy. Many US science projects will suffer unless radical new ways of thinking about how these projects are run (and in some cases how the core science is done).

 Voyager I & II solar system
                  path versus termination shock

The main goal of this project :

Use the SETI @ Home and Astropulse source codebase (or related open source codebases) to detect and decode Voyager I & II telemetry, and later on or simultaneously the telemetry of the New Horizons Pluto-Charon mission. Once the software codebase for doing so has been perfected move on adapting the codebase to the New Horizons mission that has similar transmission complexities.

The Deep Space Network antennas, especially the 70-m antennas, which provide most of the collecting area, are getting older and are becoming less reliable than desired. Further, it is difficult for the 70-m antennas to provide reliable operation at 32 GHz (Ka-band), where there is a 500-MHz-wide spectrum allocation compared to only 50 MHz at 8 GHz (X-band).

In future there may be a need for support for more deep-space missions, and also a need for increasing data rates from these missions. This means there may be a need for more sensitivity [A/T, where A is antenna effective collecting area and T is system temperature] at both X and Ka space communication bands. Therefore, it may be necessary not only to replace the aging antennas but also to increase the overall sensitivity (A/T) of the DSN.

All you need to know about the Voyager I & II Downlink paths

The High Gain Antenna transmits data to Earth on two frequency channels (the downlink). One, at about 8.4 gigahertz (8,400 million cycles per second), is the X-band channel and contains science and engineering data.
  • The X-band downlink science data rates are as high as 7.2 kilobits per second.
  • The other S-band channel, around 2.3 gigahertz transmits only engineering data on the health and state of the spacecraft at the low rate of 40 bits per second.
  • The S-band transmitter has not been used since the last planetary encounter.

Damaged or malfunctioning downlink systems

In the case of Voyager 2, which began its tour of the outer planets in 1977, a failure in the transponder's phase-locked loop (PLL) capacitor while on its way to Jupiter left the spacecraft extremely sensitive to Doppler dynamics on the uplink, thus jeopardizing the link whenever coherent mode was selected.

To prevent complete loss of telemetry data during critical encounters, Voyager was switched to noncoherent mode prior to the high Doppler dynamics of closest approach (even though the transponder remained locked to the uplink), thus sacrificing the most desirable data, from the standpoint of celestial mechanics researchers, at Saturn, Uranus, and Neptune.

All you need to know about the New Horizons Downlink

The NASA New Horizons spacecraft has been received at X-band by amateur F5PL on 20 April 2006.

Bertrand writes, "Very difficult to lock NH: the antenna must be aimed with a precision better than 0.1° angular. That's compulsory to do precise calibrations on the sun before tracking."

He uses a 3.5 meter dish for the reception of various X-band space probes.

For the time being some amateurs can receive the link, but this margin is fading fast.

How will the DSN software work?

Initial signal intercept parameters (based on ITU CCSDS parameters)

  • Sample rate : 32 kbs, 48 kbs, 64 kbs, 128 kbs.
  • Sampling window : 500 kHz. (SETI uses 2.5 MHz; the wide bandwidth is to cope with Voyager Doppler tracking issues)
  • Work unit frequency overlap : 30% (so no bits are lost due to Doppler shifts)
  • Note 32 kbs sampling may be adequate, as the Voyager "modem" only uses under 14 kHz maximum bandwidth for its high speed mode.
  • The sample rate has yet to be determined, there are a lot of subtle issues here.
  • Sample depth (magnitude) : 16 bits or 24 bits; SETI style 'phase sampling' will probably not be necessary as signal phase can be determined by post processing the signal.
  • It is assumed that 16 bit sampling must be tried initially, but it is also assumed that 24 bit sampling will probably be mandatory due to dynamic range issues.
  • It is unknown if sampling will be unsigned (like the Compact Disc or NICAM), signed, or complex signed (with bits set aside for phase information).
  • Antenna information: A very small amount will be included with the work units, probably in a different file.
  • Probably an open source (open specification) "container" file format like uncompressed WAV will be used with some metadata in the header.

Initial work unit generation parameters

  • Work unit size: 4.02 mb, the 0.02 mb being for the dish or dishes parametric metadata
  • Work unit overlap: 2.25 seconds
  • Work unit sample modes: Single Dish (Probably CISRO Parkes)
  • Work unit sample modes (future implementation) : 2 Dishes Cophased, 3 or 4 Dishes Cophased, VBLI Modes


There are many FFT programs available, and some designed specifically for SETI use. This program can be modified to decode CCSDS compliant telecommunications with the appropriate existing CCSDS decoders added in.

SETI Search was made with specific reasons in mind
  • Open source : much of the code should be re-usable under any Operating System.
  • Modularized : the program can easily be modified for other input - such as external DSP card
  • Separate display : my plans to use a remote telescope for piggy-back SETI, the data processing can be done close to the telescope, and the display can be seen over an internet connection
  • Language : This product is written in c++.
Functionality will become available in planned phases.

Phase 1 - Basic Operation
  • 'AGC' level logging for Radio Astronomy purposes
  • Multiple buffer arrangement to reduce data loss when windowing, this can be modified to increase fault tolerance for distributed computing work...
  • [re] Calculate target position (Right Ascension and Elevation) in near real time
  • Normalize mode, possibly useful if dynamic range issues are present -- albeit may have to be totally disabled and completely rewritten for CCSDS Deep Space Network use...
  • Averaging and Peak detection
  • Logging of 'Hits' would need to be disabled or modified. A "Hit" would be a carrier lock event.
  • Separate display program connects to main program via socket (could be over network / internet)
Phase 2 - Useful Functionality
  • 2 Channel Support (Stereo)
  • Hard programmable response on signal detection - Alarms, aerial movement
Phase 3 - Customizable Response
  • This will have to be determined as screensaver not a dedicated SETI search application.
  • BOINC allows custom features to be controlled via the web, so this feature will have to be tweaked for this.

An illustrated FFT calculation
  • Audio bandwidth from receiver = 20 KHz (DC .. 20KHz)
  • Sample rate =  44.1 KHz
  • Data rate = 88 Kbytes/second (assuming 16 bit samples)
  • Target bin size ~ 10 Hz (to detect carrier)
  • Bin Size = {sample frequency}/{FFT length} = 44100 / 4096 = 10.7666 Hz
  • Number of FFTs per second = sample frequency / FFT length ~ 10.5 FFTs per second.
  • Max time for each FFT cycle ~ 90 ms ... 100 ms

Decoder algorithm (generalized)

Assume that the screensaver and the decoding subsystem are different programs, for increased portability.

It is assumed that multiple FFT window sizes will have to be tried : 1024, 2048, 4096, 8192.

It is assumed that the audio level signal may be digitized in the form of 24 bit signed ints or 32 bit signed single precision floating point floats.

  1. Like with SETI, Find Optimal Functions ...
  2. A low complexity SETI search for the signal will be needed to initially detect the signal and its properties.
  3. Upon completed detection of the telemetry signal (CW_lock = True; Doppler_lock = True; Doppler_drift > 0 hz/sec; etc ...) -- send message back to server on signal characteristics.
  4. Save state.
  5. The signal must be sent thru a "Dedispersion" step : Dedispersion in the time and frequency domains is needed before sending it on for further decoding...
  6. Save state.
  7. Use multiple FFT16 or FFT24, Wavele16 or Wavelet24 decoders to get multiple strings of bits and their probabilities.
  8. Save state.
  9. Update FFT display if screensaver is on, and FFT screen is enabled...
  10. Save state.
  11. At this stage, a signal should exist that would resemble the Voyager modem's output at about 50 AU.
  12. Save state.
  13. DECODE : At this point there should be an output stream of probabilities of bits : Probability_1_time-series {0.4113, ... 0.8321}
  14. Use CCSDS decoder to Voyager's telemetry, storing processed data with XML wrapper, also returning the raw bitstream.
  15. Save state every decoded CCSDS Packet (Voyager) or Frame (New Horizons).
  16. Multiple iterated decoding steps could be done from about step #4 to here, with changes in decoding parameters either pre-programmed or adaptive.
  17. If multi-attempt decoding : The decoded packets and frames could then go on to compared at the bit level, where a voting algorithm (coupled with EEC) votes out the faulty bits -- 3to1 or maybe 5to1 filtering.
  18. If multi-attempt decoding : send all various decoded packets or frames to server for monitoring or separate post processing...
  19. Compare decoded packet data to normalized time series for said data, system telemetry and scientific data being equal here...
  20. Save state.
  21. Display on the screen the scientific data, coupled with the telemetry data.
  22. When no packets are decoded yet, show Voyager / New Horizons current position and or position when the data is recorded.

Astropulse research project's contribution to the codebase

Not only does dedispersion allow us to see the true shape of the signal, but it also reduces the amount of noise that interferes with the signal's visibility. Noise consists of fluctuations that produce a false signal. There could be electrical noise in the telescope, for instance, creating the illusion of a signal where there is none. Because dispersion spreads a signal out to be up to 10,000 times as long, this can cause 10k times as much noise to appear with the signal. (There's a square root factor due to the math, so there's really only 100 times as much noise power, but that's still a lot.)

The amount of dispersion depends on the amount of ISM plasma between the Earth and the source of the pulse. The dispersion measure (DM) tells us how much plasma there is. DM is measured in "parsecs per centimeter cubed", or pc cm^-3.

This phrase "parsecs per centimeter cubed" probably sounds a bit meaningless ... here's the explanation: a parsec is about 3 light years. If a source is 1 parsec away, and the space between the Earth and that source is filled with plasma, with 1 free electron per cubic centimeter, then that's 1 pc cm^-3. To get the DM, multiply the distance in parsecs by the electron density in cm^-3. The density of free electrons in the ISM is about 0.03 per cubic centimeter.

From :

Voyager telemetry intercept at
                  109 AU, carrier wave integrated over 192 seconds

Comments of Voyager and New Horizons downlink decoding

  1. Voyager craft use [ ] as their base downlink modulation format, bandwidth = ; symbol rates = { } ; harmonics = {1st: 2nd}
  2. New Horizons uses [ ] as its base downlink modulation format, bandwidth = ; symbol rates = { } ; harmonics = {1st: 2nd}
  3. At least one of the Voyager craft has a transponder fault, so some noise filtering may have to be replicated in software

Target reception frequencies (f0)

  • both craft have a downward frequency trend
  • there are 2 downlink frequencies for each
  • each craft has 2 downlink transmitters in 2 different CCSDS bands

Voyager I (Craft 31)

  • 8,414,995,272.530 Hz (Titan)
  • 8,414,995,272.376 Hz (Saturn)

Voyager II (Craft 32)

  • 8,420,430,593.447 Hz (Jupiter)
  • 8,420,430,462.000 Hz (Saturn)
  • 8,420,430,456.100 Hz (Uranus)
  • 8,420,430,398.420 Hz (Neptune)
  • 90 AU: (?)

New Horizons

  • 8436.895671 MHz

Bandwidth: 800 Hz, nominal

  • There may already be some deviation from the original f(0)


  • The DSN does not disclose (on any of its websites) current known downlink and uplink frequencies for the Voyager Program. This policy of link frequency secrecy does not help NASA or the DSN.
  • Voyager I's f(0) data is unavailable at the time of posting for other encounters within the solar system. All f0 data here is from occultation experiments.
  • The Voyager craft's carrier wave drifting rate is about  -0.6 > {Hz/second} due to Doppler effects from Earth rotation -- and craft motion.

This software innovation will make it possible to improve the overall reliability of the Deep Space Network, and the deep space science platforms using the Deep Space Network.

This software innovation will allow the Voyager I & II, and any future spacecraft to have downlink data rates that will nearly reach the maximum rates specified by the "Shannon Limit" from information theory and the error correction schemes in place.

  • Download applicable NASA Deep Space Network research documents (ZIPPED PDFs)
  • This document set is subject to revision (and even deletion) and is intended for informational use only.

Other future mission optimizations possible with this research

  • Allowed f_Subcarrier_Frequency values too restrictive : CCSDS%2091011R1/DispForm.aspx?ID=113
  • Some uplinks for flying spacecraft use subcarrier frequencies other than 8000 Hz and 16000 Hz. For example, Voyager I and Voyager II uses 512 Hz and Muses-C uses 4000 Hz. 
  • The DSN Uplink is required to generate subcarriers for commanding over a much wider range of values (from 1 Hz to 16000 Hz), including values that take into account Doppler shifts.
  • Future implementations may require higher subcarrier frequencies.

Dataset Websites

  1. NASA Voyager Mission : (datasets, misc)
  2. Instrument datasets for Voyager (magnetic, plasma) :
  3. Distributed Computing Links :, SETI @ Home, Astropulse
  4. Planetary Society :

Important onward reference points, science and telemetry

Important parts of DSN signal recovery
Important filters and methods that must be used or experimented with
Transforms that must be used or experimented with

Related websites (possible prototypes for a screensaver interface)

Initial version

Current version

Update notes

02 FEB 2000
17 NOV 2020 (some cleanup)
Civilization Reset Initial 0.55