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
]]>
- Global Position and Status Reporting with Iridium Communications
- Two-Way Communications, with legacy support for APRS transmitters
- Support for a variety of sensors – GPS, temperature, preasure, battery-sense and more
The long term goal of this project is to make it easy for people to get up and running quickly if they are beginners, or customize both the hardware and software to meet the needs of their mission if the are intermediate of advanced ballooners. With this, we hope to open the doors for more people to experiment with high-altitude balloons in a meaningful and novel way.
Initial Progress
We assembled an initial prototype and have functional software that provides basic payload functionality. On the payload side, we decided to use Arduino for its ease-of-use and ubiquity. The Arduino interfaces to a few sensors, including a MAX7Q GPS, a couple of temperature sensors, and of course the Iridium modem. Over time, we hope to add support for a long list of sensors and a variety of embedded targets – both larger (ARM/Linux based) and smaller (for low-power/light-weight missions). For now though, this is a happy medium to get everyone off the ground (pun intended).
On the ground side, a Python script interfaces to an email server through SMTP and IMAP. This is how we exchange messages between our application layer (where we product commands and process incoming data), and the payload. This Python application should be fairly easy to modify, if your mission needs . Over time we will post tutorials on how to a modify this ground station software, and the payload software to your liking. In essence, this is a GUI or command-line application that will allow you to control your balloon from anywhere in the world.
We have tagged an initial release of the software (admittedly, without much documentation). You can find the code here:
https://github.com/jmalsbury/
Also, here is a picture of the prototype:
We plan to get everything packed up and experiment with some launches in the coming months.
More Information, Feature Requests, and Volunteers
If you are interested in helping out with this project, submitting feature requests, or have any general questions, please contact John Malsbury, [email protected].
]]>Iridium Integration Challenges
As mentioned in our previous posts, we are beginning to develop more sophisticated payloads. One of the features that we are adding is two-way global communications with Iridium. As payloads become more complex a number of issues pop up. First, the total labor required to design, program, and test the payloads. But the increase in effort is non-linear. Every interface, every additional programmer, and every additional component adds new challenges. In other words, the integration work for this payload is going to be greater than the sum of its parts.
Starting on Iridium development, several issues became apparent:
- It would be useful to enable multiple developers to develop with system that are effected by the Iridium modem, or GSS-side functionality – but we can’t afford to purchase hardware for each and every person.
- The integrated of the antenna on the Rockblock makes it difficult to develop anything indoors. The margin of the 9602 already appears to be pretty low, and simply won’t work unless the unit is outside with the antenna pointed up.
- Last but not least, my misunderstanding of the Rockblock fee structure . Some ambiguity in their language could lead someone to believe that you are charged a “credit” every time you send a message with SBDIX. In actuality, I thought we would be charged by bytes transferred.. but its much worse than that. With the Rockblock, you are charged for EVERY SBD session, even if you do not send or receive a message.
One solution to item (3) is to look into having the modem switched to service from N.A.L., but to be honest I’m not sure that will be much less expensive. It’s also possible that some contract prevents using a Rockblock modem on N.A.L. Service.
Iridium System Emulator
All of these factors motivated me to write an emulator for the Rockblock (Iridium 9602). Prior to doing so, I did a search on the web, and was very surprised to find that such a solution did not exist. This emulator, written in Python, does several things:
- Emulates the serial communications behavior of the 9602. Currently, most of the AT commands are implemented, so you can run through the process of writing message and completing SBD sessions (i.e. ‘at+sbdix’). It even uses a virtual coin-toss to simulate the frequency session failures.
- Will read and write correctly formatted e-mail messages to a e-mail account specified for the modem. In this way, whole thing emulates the GSS. You can send e-mails to the test address just like you would send them to the Iridium SBD address, and this virtual modem will receive those messages on a successful SBD session.
- And more stuff that’s not as important.
Let me show some illustrations on why this is useful. Looking at the real-world communications architecture will add some insight:
In the diagram above, all of the software/embedded components we are interested in develop are painted a light-blue color. To properly develop and test these software components across the operational envelop, we simply need to send a lot of test messages. These test messages can be actual, costly SBD sessions with the real hardware. Or these test messages can now be produced with this 9602 emulator. In other words, our development system now looks like this:
There’s a little humor in there for the open source junkies. Anyway, with this system, we can vet a good portion of our system design before we ever send any data over the Iridium system, or incur costs from Rock7Mobile. Of course, we will be doing some testing with the hardware as we go through the process as well. For certain portions of our validation campaign, there’s just not replacement for the real thing.
Where can you get the emulator?
Another benefit to developing this emulator, is that people can experiment with the overall communications concept (SBD ↔ E-mail), before buying hardware. In principle, this means we could expand our development team without needing to send more hardware. Of course, you are free to use this for other projects that are unrelated to high-altitude ballooning. My hope is that this will save some other people some time, frustration and money.
If you are interested in running the code, please see http://github.com/jmalsbury/virtual_iridium to download the code and find some limited documentation. This emulator requires Pyserial to be installed. I’ve only tested it on Linux, but I did what I could to keep in OS-agnostic.
Here’s a short snippet of how to download and install the software:
git clone https://github.com/jmalsbury/virtual_iridium cd virtual_iridium/python python Iridium9602.py -d /dev/ttyUSB0 -u [email protected] -your_password -i imap.gmail.com -o smtp.gmail.com -r [email protected] -m EMAIL |
Of course, you need to adjust the parameters to your liking. You ‘-d’ specifies the serial port to use. This can be a virtual serial port that connects the emulator to another application on the PC.
This is a work in progress. I am likely to put more effort into documentation, bug-fixes, and functional refinements if more people are going to use it. [email protected].
Cheers!
]]>
Upload APRS Frames to APRS-IS – Part I – Learn how to get access to APRS-IS
Uploading APRS Frames to APRS-IS – Part II – Python application that uploads frames…
]]>
I will be helping the group with some payload and communication system design. I also thought that a better website and a comprehensive marketing strategy would help this group with their mission. We’ve got some pretty ambitious things planned, and I think it will excite a lot of spectatres.
Anyway, here’s what the site currently looks like:
]]>
