Economics of Prototyping with Iridium

This post is the first in a two part series that will explain how Iridium service plans typically work. After speaking with a few individuals that plan to use Iridium for their hobbyist or professional projects, I’ve concluded that how Iridium and third-party service providers bill can be confusing.

 

b_ant-154380_424x325

The RockBlock

For the sake of this post, we will take a closer look at one service provider, Rock 7. They sell the RockBlock, which is basically an Iridium 9602 provided in a convenient USB-power assembly (board-only or ruggedized). They also have done a nice job of simplifying some of the archaic looking documentation that other Iridium service providers have put together.

We’ll talk about the hardware in some other posts. I’d like to get to my point on the pricing structure.  Looking at the fees per byte, this scheme is actually pretty reasonable.  Compared to alternative service providers, this structure favors hobbyists or engineers on smaller projects. However, there is an important thing to note:

YOU WILL USE 1 CREDIT, EVEN IF 0 BYTES OF DATA ARE TRANSFERRED IN THE SBD SESSION.

That’s right. Even if no data is sent to or from your mode, you will still be charged. Many hobbyists/engineers pick up the modem, expecting that they can poll with frequency SBD sessions, only to find that they burn up their credits quickly. Another fact, which isn’t quite clear, is an SBD session that transfer a single byte will also consume 1 credit. It might be better if Rock7 adjusted their language to say, “The minimum billable byte count for each SBD session is 50 characters (1 credit).”

How does Iridium/Rock 7 justify this pricing structure?

In actuality, this pricing structure is somewhat legit. Some developers have the misconception that they have not taxed the system if no data has been passed to or from their modem. In actuality, each and every transaction consumes precious satellite bandwidth, even if no payload data in transferred. The modems/satellites have to do things like negotiate TDMA slots, acknowledge packets, and talk all the way up the network stack just to check for messages. So the bandwidth consumed for no data is very comparable to the bandwidth consumed for a full-length packet.

How expensive will my M2M gadget/widget/project cost to operate?

Let’s assume we have some widget mounted on a truck.

sbd-map

We want the widget to report position every five minutes, and check for incoming commands from a control center every minute. It would behoove us to reduce the data in standard NMEA GPS strings to some binary or otherwise reduced format, so we fall below the 50 byte threshold and minimize the credits per outgoing report. Also, it is worth noting, that when an SBD session occurs, it will automatically check for incoming messages. So, if we align our outgoing GPS message to our command polling interval, we can avoid an extra SBD session. In this scenario, we’re looking at a 1-credit SBD session every minute if no commands are sent from the control center to the modem. This translates to about $4.80/hr – not so bad. But if you consider that many of these system go through significant duration test as command and control system are developed, or use multiple devices this can really add up – especially for hobbyist projects.

So, how can we avoid some of these costs?

Drop the polling architecture, use SBD Ring

If you perform an SBDREG when you initialize the modem, the Iridium system will keep tabs on your units position and status. Also, when a new message arrives on the ground station segment, an “SBD Ring” signal will be sent to the modem. This produces a pulse on the digital Ring output, and also a string output on the serial port. At which point, the MCU/processor connected to the modem would perform an SBD session.

It is worth noting, the SBD Ring has not been 100% reliable in my experience. Also, from what I’ve been told (but no observed myself), is the SBD Ring can be inserted anywhere in the UART output of the modem, even if it is in the process of responding to AT commands. So, it is still a good idea for to poll, albeit at lower frequencies.

Don’t poll for data, just check when you have outgoing messages.

Pretty simple. Since every transaction involves both transmission and reception anyway, the Iridium system is nice enough to downlink any pending messages while we are uplinking our own. If you have a mobile that is consistently sending messages, you may not need schedule additional SBD sessions to receive.

Use my Iridium 9602 Emulator

At least, this works in the prototyping phase. If you’re working to developed some microctronoller code to talk to the modem, or the “server-side” system to work with your M2M system, you can leverage the free and efficient bandwidth of the internet. My emulates the AT command parser on the 9602, and will send/receive properly formatted messages via email. You can find more information about my emulator here.

 

 

Categories: comms, iridium