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.
USRP N2xx For ISEE-3 Uplink and Downlink
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.
Rotary feed at Arecibo Observatory.
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:
This plot shows the clock (green), random data (blue), and the FSK/AM sub-carrier (red). Note, do to small deviation relatively to sub-carrier frequency, FSK modulation is not immediately apparent, but it is clear that clock is AM modulated onto the sub-carrier.
The subcarrier signal shown above drives a phase modulator. If the signal was only FSK modulated, the sub-carrier would be a continuous and the signal output from the PM would move around the unit circle with a constant radio(envelope) . However, the AM modulation from the clock produces some instantaneous changes in the sub-carrier, and in turn fluctuations in the envelop of the PM signal.
This is the spectrum of the uplink signal.
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:
Uplink flowgraph used to communicate with ISEE-3.
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 → [email protected].
Other Pictures, Resources, and More!
My Personal Album from Arecibo Observatory
]]>
For those of you who are not familiar with the work… I developed a GNU Radio library called pre-cog in this past Fall. This was originally prepared for a tutorial on cognitive radio at DySPAN 2012. The pre-cog framework was built as a demonstration of a few capabilities of GNU Radio and the Ettus Research USRP. Some of these capabilities:
Software-Based Packet Radio with GNU Radio, gr-extras, and my framework, “pre-cog”
- USRP Timed-commands and tuning functionality (useful for things like frequency hopping)
- Timed-streaming with
- GNU Radio – Stream-tags
- GNU Radio – Python blocks
- GNU Radio – Async. Message Passing
In short, I was trying to show that it is possible to implement both PHY and MAC functions within GNU Radio, while taking advantage of advanced driver features of the USRP family. Some would argue that MAC functions don’t belong in GNU Radio. On some occasions I might agree. However, I still think there is some value to integrating this in GNU Radio, and in-turn, GNU Radio Companion. The main appeal is the ability to modify things in a graphical environment, which makes it easy for students and tinkerers to experiment with different access schemes (CSMA, TDMA, FHSS, etc), physical layer designs, and MAC-layer functions. Essentially, I’d like to create PHY/MAC “Legos”.
What it looks like now…
I did my best to modularize my blocks, but include enough functionality in each block to create clean and easy-to-understand applications. The simplest example is a half-duplex, single-carrier CSMA radio with ARQ. This can be seen in this video:
There are also blocks available to implement TDMA and FHSS. These PHY blocks can replace the CSMA PHY. The same is true for the MAC layer blocks. Currently there is only the “Simple MAC” block.
Next Steps and What I’d Like to Accomplish
After proving the basic idea through this simple framework, and talking to a few people, I’ve decided that it may be worth more effort. The community has provided some indication that a more thorough implementation would be valuable. Here’s an obvious list of improvements/changes:
- Update the blocks to use new PDUs in GNU Radio
- Re-write blocks in C++
- Come up with a cleaner mechanism to pass meta-data around.
- Improve documentation and examples. Make some tutorials.
My ultimate goal here is to spend my time producing something valuable for the community. Thus, I’ve typed up this post to solicit feedback from any students, professors or hackers using the framework. What should change from an architectural standpoint? What blocks and functions are most useful for you? In general, what should I be doing differently?
Also, most importantly… pre-cog is an awful name.. What should I call the official project once I’ve kicked it off?
You can connect with me through my social media links (to the right), or at [email protected].
]]>