As many of you have probably read, the ISEE-3 Reboot Project was able to successfully send uplink commands to the space craft. This was accomplished through a lot of team work and generous support from the community at large.
Balint Seeber and I were fortunate enough to work on the communications for this project. When you tell most people that you designed a deep-space uplink modulator in a couple of days, there is a good chance that they will be fairly impressed. In reality though, products like the Ettus Research USRP, the open source SDR framework GNU Radio have made this exceedingly easy. We’re just building off the work of many people before us!
Let’s talk about how this “magic” works!
Design Approach – Leverage SDR!
In order to meet the aggressive schedule and budget requirements of this project, we elected to use software-defined radio to implement the uplink. There’s basically one place people go to build an affordable SDR-based systems – and that would be Ettus Research, maker of the USRP product line. And typically when people use a USRP, they use it with GNU Radio.
For the readers who are not familiar with SDR, the USRP, or GNU Radio, I’d explain it like this: SDR allows you to implement functions that had been previously implemented in specific, tuned RF circuits in software. This in turn provides some awesome capabilities, such as:
Flexibility – Using the same piece of hardware to operate over multiple standards. For example, you can use the same USRP and laptop to implement the vintage uplink modulator discussed in this article or something more sophisticated like a modern satellite broadcast transmitter.
Rapid prototyping and debugging – Let’s face it, we all make mistakes, especially when it comes to the ‘black magic’ of wireless system design. SDRs like the USRP allow you to iterate on designs until the do just what we need, all for very low cost.
Community – Really, the community that has grown around the USRP and GNU Radio is enormous and grows every day. This allowed me to get in touch with experts and peers to vet implementations very quickly. Remember, there was no reference hardware we could “truth” against, so access to peer review was very important to make sure we interpreted and implemented things correctly.
Hardware and System
As you can see from many pictures posted by Balint Seeber, the hardware configuration is actually quite simple. It is an affordable, but very capable USRP N200 which contains an SBX motherboard. The N200 is connected to a laptop via Gigabit Ethernet. The output of the USRP (~ 2.05 GHz) is transferred to the transmitter room in the Gregorian dome of the dish via an RF-over-Fiber system. The signal drives a 400 W S-band amplifier, whose output is finally transmitted off the dish.
We’ll touch on the feed at Arecibo in a different article. It’s quite flexible and impressive, and the staff at the observatory were extremely accommodating as they helped us put things into the right configuration for this project.
The Uplink Specification
Actually, one of the most difficult parts of this project was sifting through hundreds and hundreds of pages of specifications from NASA. They covered everything from the antenna designs, to the specifics of the modulation scheme, to the layout of the communications system of the ground segment! After some digging into sometimes contradictory specifications, we did converge on a modulation spec. The uplink uses PCM/FSK/AM/PM. Here’s how it works:
If you have a command you would like to send up, you generate the appropriate command sequence, which is basically 60 bits in length. These bits are fed into an FSK modulator with a center frequency of 8.25 kHz and deviation of 750 Hz. Narrow-band FSK like this is pretty standard, but that isn’t the end of the modulator chain.
In these early days of deep space communication, the designers wanted to make the receiver on the spacecraft as simple as possible. Instead of designing clock recovery circuits on the spacecraft receiver, they decide to include the clock on the uplink signal. This is accomplish by AM modulating the FSK sub-carrier with the clock signal. Thus, there is now sub-carrier where frequency represents data, and amplitude represents clock. This FSK/AM modulated sub-carrier then phase modules the RF carrier (2.05 GHz). This scheme is generally not considered to be bandwidth or power efficient. But its easy to trade power efficiency for simplicity on the spacecraft. Here’s some screenshots of what things look like at various places in the modulator chain:
Originally, all of this was implemented in hardware, with calibrated circuits fulfilling each of the modulator functions. Fortunately, technology has been marching along for the past 30 years, and we have a much easier task than some of the original designers.
Modulator Implementation in GNU Radio
As I said, digging through the specifications, and confirming our own understanding of how the modulator should work was the challenging part of this project. Most of the functions of the modulator can be implemented with blocks from the standard in-tree modules. Truth be told, this modulator can be built in a matter of hours by someone who is relatively new to GNU Radio. Here’s the flowgraph we put together:
Starting from the left, there are a few blocks that help us get data into the flowgraph from an external application. The Socket PDUinterface is just that, a TCP/IP socket that outputs data in frames called “PDUs”. There is one more block called “binary_to_pdu” which helps collect bits and then pass them along to the modulator in a contiguous frame.
After being converted to a stream of bits (that are represented by bytes), the data is frequency modulated at baseband (I/Q), multiplied by a complex cosine to shift to sub-carrier frequency, as well as the magnitude driven by the clock (from vector source). This AM+FSK modulated sub-carrier phase modulator, which has a pretty loose modulation index specification. Finally, the signal is re-sampled and output to the USRP through the USRP sink. Just prior to these, we apply on last step of frequency correction for doppler and clock uncertainty. The I/Q stream is then sent to a USRP tuned to the uplink frequency.
An XMLRPC client allows us to change many parameters like offset frequency and data polarity at runtime. With this, the same external application that generates the commands can also tweak parameters. We’ll discuss how this for our transmission strategy soon.
Transmission Technique – Command/Modulator Parameter Search
Now that we had a system that was capable of transmitting correct commands to ISEE-3, we had a little bit of guess work to do. There were a number uncertainties about the behavior of the space craft receiver. Ambiguous specifications on items like receive lock range, phase modulation index, and mark/space tones, left us with some uncertainties to deal with. Also, a rough link budget showed that we should have about 5 dB of margin under ideal circumstances. If we had any significant pointing errors, or there were other factors we hadn’t accounted for, there was a decent chance that we were operation near the best sensitivity of the space craft receiver. This meant we could have a marginal link with frequent bit errors.
So while we had our “best guess” at the proper command and modulation parameters, we decided to write a script to automate the transmission and modulation parameter adjustments. This allowed us to try many commands and many modulator configurations in the short contact period on our final day at Arecibo.
In the end, this strategy worked out for us. We were able to turn the modulation on on the first day we were permitted to transmit. With telemetry enabled we can begin to decode data and assess the health of the spacecraft.
Working on the Downlink
The team will continue to collect data from the downlink and assess the health of the satellite. For more updates on this effort, please see the official ISEE-3 project page.
Access to Source Code
GNU Radio is an open source community, and we are all about sharing. Sometime in the not-to-distant future, we may release a portion of our implementation. In the meantime, if you have any questions, feel free to contact me → firstname.lastname@example.org.
Other Pictures, Resources, and More!