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:

  1. 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.
  2. 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.
  3. 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:

  1. 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.
  2. 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.
  3. 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 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
cd virtual_iridium/python
python -d /dev/ttyUSB0 -u -your_password -i -o -r -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.