Using Satellite for IoT

If you are involved in building Internet of Things solutions for industry, you are probably familiar with radio technologies that connect IoT sensors to the Internet: WiFi, cellular, LoRa, etc. What about satellite connectivity? Wifi or cellular connectivity may not be available where you need to deploy a solution. Perhaps you are monitoring sensors on an ocean vessel or a remote oil well. With many aspiring entrants in the satellite IoT space (no pun intended), it’s time to get serious about comparing not only the costs, but how these systems actually perform.

Using satellite connectivity is becoming a more viable option as new solutions like Swarm come to market. This article compares Swarm’s offering to the well-established Iridium Short Burst Data (SBD) service. This isn’t just a comparison of the features and costs — I’ve run experiments with Swarm and Iridium modems to compare the latency and performance of each system so that you can make decisions based on actual data. By just looking at the sizes of the satellites, we can see that this is a David vs. Goliath story!

I know you are probably wondering about costs, right? The Costs section below gives the cost details, but the quick summary is that Swarm is cheaper than Iridium both in terms of CapEx and OpEx. That’s capital expenditures and operation expenses for you non-CFOs. But cost is not the only concern, so you might find the cost differences immaterial given the actual operational characteristics that you need. So let’s get into how these two satellite IoT solutions actually work and how I measured their capabilities.

Swarm

Swarm Technologies (acquired by SpaceX in 2021) has launched (as of this writing) approximately 175 small “SpaceBEE” satellites about the size of a piece of bread. They are about 2.8cm thick, so more like Texas toast. According to CelesTrak, they are near polar orbits (I think they are sun-synchronous orbits) providing coverage at all latitudes and are in several orbital planes at a variety of LEO altitudes. Here’s a snapshot of the orbits using a tool that I made to help me see where things are. Swarm also provides a pass checker tool which probably takes into account which satellites are actually operational.

To communicate with the Swarm satellite network, I bought the Swarm evaluation kit in fall of 2021. It came with a tripod, solar panel, antenna, and circuit board with the Swarm modem and all required power management circuitry. It came with a FeatherS2 development board with pre-loaded firmware for communicating with the modem. The FeatherS2 has an Adafruit OLED display. This is a very nice kit that has everything you need to start communicating right away.

Note that this version of the eval kit has their first generation “Tile” modem, which has been superseded by their new M138 modem. I don’t know if the performance of the new modem is better, but as we will see, the ability to send messages has much more to do with satellite coverage than the modem hardware. It’s obvious in the orbit image above that there are significant gaps in coverage between orbital planes, and this has a huge effect on the time it takes to successfully deliver a message.

The goal of the experiments is to measure how long it takes to deliver messages from the modem to the Internet. Sending messages using the Swarm modem is easy. As a developer, you just send NMEA-like sentences over a serial connection to the modem. Messages are queued in the modem until the modem can successfully uplink it to a passing Swarm satellite. The modem can hold up to 1000 messages that it will continually try to uplink, so as a developer, it’s like a fire-and-forget approach. Nice.

Whichever Swarm satellite received the message will downlink the message to a ground station. Messages that have been delivered to Earth show up on the online site Swarm Hive. Hive can also deliver the message to your own infrastructure using a webhook (I had my messages delivered to a Node-RED endpoint). This article is not going to get into all the code details of how I performed the experiments, but the source code is linked in the Resources section below.

In order to assess the characteristics of the network, there are two things we want to measure: the time it takes for a message to be received by a satellite and the time it takes to be downlinked to a ground station and made available in the Hive.

time to uplink + time to downlink and deliver = total time

Measuring these is a bit tricky. After handing a message to the modem using the $TD command, the modem responds with a unique identifier for that message. Eventually when the message is uplinked, the modem provides an unsolicited message $TD SENT with the unique identifier. My firmware keeps track of how long this process took and saves all of the information in a .csv file on the FeatherS2 filesystem. On the receiving side, I deployed a Node-RED endpoint to serve as a webhook to which the Hive could deliver my messages. The problem is that the delivered message does not contain the unique identifier known to the modem, so there is no way to correlate what the modem knows with what the Hive knows. To solve this, I included my own unique identifier in the payload of the message. This way I could match up the uplink measurements performed on the FeatherS2 code with the received messages in my Node-RED code.

I ran my experiement to send a message every 15 minutes for 8 hours. For each message I was able to determine how long it took for the modem to uplink it to a satellite, and then how long it took for that satellite to deliver the message to my Internet endpoint. The detailed results are in the Experimental Results section below. In summary, Swarm messages can take up to several hours to be uplinked if your ground station is under a gap in the orbital planes. Sometimes there were a dozen messages queued up in the modem. But eventually, when there are satellites overhead, the messages will get uplinked, sometimes 5 at a time. Once uplinked, the downlink/delivery time is usually pretty short.

It’s worth noting that messages will not necessarily be uplinked in the order they were sent, so “queue” is not the right word for what the modem is doing. I also observed several cases where the modem reported the uplink of a message after the message had already been delivered to Earth. Sometimes this happened several hours after terrestrial delivery. I don’t know if that’s a bug or if it’s just a design characteristic of the way the network acknowledges receipt of a message to the modem. I have omitted those few anomalies from the statistics below.

Bottom line? Swarm makes it easy to send messages from an embedded microcontroller IoT solution. The messages may get uplinked and delivered right away if you are lucky, or you may wait several hours. But they do get delivered! In all of my experimentation I have never lost a message.

Iridium

Iridium is the decades-old 800 pound gorilla in the commercial space communications industry. Literally, their Iridium NEXT satellites weigh significantly more than 800 pounds each (a lot more). This doesn’t mean that their satellites are old and obsolete. The current generation is quite new, and don’t forget that these satellites are used for satellite telephone conversations. Iridium satellites communicate with one another using microwave links with nearby satellites in order to create a real-time communication link capable of maintaining a telephone conversation. That’s nothing short of incredible, in my opinion. IoT messages should be a piece of cake, and from what I can tell, it is. The Iridium constellation is 66 satellites in polar orbits at the somewhat high altitude of 781 km giving them global coverage.

For IoT using small messages, Iridium offers the Small Data Burst (SBD) service. I’m using the Ground Control (formerly Rock Seven Communications) RockBLOCK 9603 modem. You can also buy it from SparkFun.

For my experiments I used a simple development board that I had built for a project called Iridium satellite communication. It incorporates the modem with a GPS receiver because the Iridium modem does not have integrated GPS like the Swarm modem. GPS is important for knowing what time it is, not where we are.

Here is my ground station. The dev board is in a plastic box in case it rains. I’m using an external antenna (also available from SparkFun), and power is provided by a large battery with solar charger.

Just as I did with Swarm, I ran the experiement for 8 hours, sending a message every 15 minutes. Using the Iridium modem is quite different than Swarm, though. The Iridium modem can only handle one message at a time, so there’s no fire-and-forget model. The embedded software on the microcontroller needs to interact with the modem to wait for the successful uplink and cannot send any other messages until the uplink succeeds, times out, or is canceled. From a development perspective, it’s much more hands-on, but luckily there is an excellent Arduino library, Mikal Hart’s Iridium SBD library, that makes this as painless as possible.

After successful uplink, the message will be downlinked to an Iridium ground station somewhere — possibly being passed between other Iridium satellites! — and delivered to the Ground Control online management console similar to Swarm’s Hive site. Ground Control will also deliver the message to a webhook, so I am also having the data sent to a Node-RED endpoint for analysis.

Measurement of the uplink time and downlink time is easier with Iridium than with Swarm. The data delivered to the management console and my webhook tells me when the message was received by an Iridium satellite. I know when I sent the message because I include a timestamp in the payload itself. So at the Internet endpoint, I know when I attempted to send the message, when it was actually received by a satellite, and when it was delivered to Earth. Full results are below, but the bottom line is that Iridium’s global coverage and microwave interconnects provides fast and predictable delivery of IoT messages. Sometimes it takes 10 minutes, but usually only a few minutes, and sometimes almost instantly.

Experimental Results

Ok, it’s finally time to review the results. Below are tables showing the minimum, maximum and average measured times for the uplink, downlink, and total latency. You can see clearly that Swarm messages can take hours to deliver (one took almost 2 hours). If Swarm satellites are overhead, though, it can only take a couple of minutes. On average, over an 8 hour experiment sending a message every 15 minutes, Swarm delivered the messages in 39 minutes, 44 seconds.
 

Swarm message delivery statistics

	min	max	average
time to uplink	00:00:30	01:56:45	00:32:47
time to downlink	00:00:07	00:35:22	00:07:31
total time	00:02:32	01:58:37	00:39:44

 
Iridium, on the other hand, is much faster. It can take up to 15 minutes for an uplink to succeed, but on average only takes 3:11. Once uplinked, the Iridium network delivers messages to the ground very quickly with an average of only 12 seconds! Remember that Iridium satellites can talk to one another, so this can really speed things up. Average end-to-end delivery time for Iridium was only 3 minutes, 22 seconds.
 

Iridium message delivery statistics

	min	max	average
time to uplink	00:00:04	00:15:47	00:03:11
time to downlink	00:00:05	00:01:06	00:00:12
total time	00:00:10	00:15:53	00:03:22

 

Costs

How much does all this cost? First let’s talk about hardware (CapEx). I bought the $500 Swarm evaluation kit, but for an actual IoT deployment, the newer Swarm M138 modem on a breakout board is available from SparkFun for $150, including an antenna and ground plane. An Iridium ROCKBlock modem module can also be bought from SparkFun for $267. If you want the external antenna, that will cost another $70. Overall, an Iridium hardware solution will cost you more.

Also note that since Iridium uses a much higher frequency (1626 MHz), it can get by with a patch antenna or the small GPS-like antenna. The Swarm system uses lower frequencies: downlink 137-138 MHz / uplink 148-149.95 MHz. This requires a larger antenna which is 8 inches or 20cm and a square 8×8 inch ground plane. That will affect the size of your deployed package.

Operational costs are also much lower for Swarm than Iridium. For a $60/year subscription, you can send 750 messages per month, or about 24 per day. That’s a lot of messages. For my Iridium integration, I am using Ground Control (formerly Rock Seven) which is a British company. Their pricing is in GBP, but I’ll convert to USD for comparison. There is a monthly “line rental” fee for about $15 per device. Messages are paid for with “credits” which cost about $0.15 per credit. A message of 50 bytes or less uses one credit. Longer messages will use 2 credits.

To compare apples to apples, let’s say we wanted to send 750 messages per month for one year with Iridium + Ground Control. First line rental would be $15 x 12 = $180. At 15 cents per message, we would spend $1350 for credits, for a yearly total of $1530. Swarm would cost $60 for the same amount of messaging. That’s a big difference. But that’s assuming you are using all of your alloted message capacity with Swarm, and you may not need to send nearly that many messages. So, it really depends on how many messages you need to send. The fewer it is, the less difference there is between both solutions.

Does this cost difference really matter? If you are a hobbyist, yes, money matters. But what if you are a large company using IoT to monitor assets in the field? Maybe your infrastructure is worth millions of dollars. A few thousand dollars here and there for monitoring may not matter at all. But if you are a company deploying thousands of devices? Then Swarm will probably be cheaper. As always, “it depends”.

Summary

Both Swarm and Iridum can be used to create satellite-connected IoT solutions. Swarm is easy to use and lower cost, but the latency for message delivery is significantly longer, potentially several hours. This might be fine for your application.

Iridium is more expensive, but offers much lower latency delivery of messages and can generally be integrated into a smaller hardware package. If you need to monitor expensive infrastructure and want to know about problems as soon as possible, Iridium might be for you. If there is a leak or a fire or anything that needs attention, you’ll want to know in a few minutes, not a few hours.

As is usually the case in engineering, there is no one-size-fits-all answer and as an IoT professional you have some things to consider. I hope this article and the actual experimental results presented is useful. With the rapid proliferation of commercial space ventures, the coming years will bring many new options to the satellite IoT solution space, and we will be watching closely and experimenting as much as we can!

nootropic design, LLC provides custom electronics and IoT solutions for industry.
You can contact us at nootropicdesign [at] gmail.com

Resources

Swarm

SparkFun: Satellite Transceiver Breakout – Swarm M138

Ground Control

SparkFun: Iridium ROCKBlock 9603N – Iridium SatComm Module

Iridium SBD library for Arduino

Swarm Satellite Arduino Library

GitHub repository containing the source code used to perform the experiements. This is provided for reference only and is not intended to help you replicate the experiements. There is significant setup required on the Swarm Hive and Ground Control management console sites, and I deployed Node-RED endpoints as webhooks to receive messages. Much of the analysis was manual file manipulation and was not automated.