Imagine you’re the manufacturer of industrial equipment — perhaps you supply power generators to war zones, or monster excavators to mining projects, or perhaps you make sensors for monitoring pipelines.

The equipment that you produce is inherently big and complex — which means that it’ll be packed with gizmos and sensors to monitor its health, performance and to detect faults/errors.

If a sensor fails in the forest, and nobody is around, does it make a sound?

Herein lies the problem. Your equipment isn’t around the corner — you can’t just pop over to check it’s ok. If it’s truly remotely deployed, it may require several days travel and a helicopter to check!

Clearly this isn’t a sustainable or practical solution — so what about remote monitoring? It’s unlikely that you’ll be within cellular coverage, and if you are it’s likely to be patchy and unreliable (it’s like that even in the middle of London sometimes)!

In this instance, the only viable option you have for remotely monitoring your equipment is via satellite. Today, there’s a multitude of satellite operators and terminals available, each with their respective pros/cons in respect of physical size, operating cost, power requirements, communication speed and bandwidth etc.

For our hypothetical scenario, let’s assume we make monster excavators used to extract lithium from remote Australian mines. They’re super-computers on wheels and are packed with sensors, measuring things like: temperature, pressure, vibration, movement and location. There’s a ready supply of power but physical space is limited. Being able to monitor this data in real-time is invaluable for things like performance and safety monitoring.

Introducing Ground Control’s RockREMOTE

The RockREMOTE is an Iridium Certus IoT terminal, providing both IP connectivity and IMT-based messaging from anywhere on the planet. Its IoT Gateway enables easy integration with other equipment and applications through the lingua-franca of the IoT industry — MQTT.

How do we connect the RockREMOTE to a monster excavator?

In our scenario, we’ve got an onboard network connecting all the sensors to a central data logger which stores the sensor readings. The sensors themselves speak to the data-logger via the industry-standard CAN bus protocol as is commonly used in the automotive industry.

The data logger is simply connected to the RockREMOTE via Ethernet cable.

Yes that’s a child’s toy — no expense spared artist’s impression showing the system end-to-end

Data Logger > MQTT > RockREMOTE (IoT Gateway)

So we’ve got our readings gleaned from the onboard sensors; they’re currently stored in a simple database on our data-logger. This is a proprietary system developed in-house, so we’ll need some developer-smarts to send the data to the IoT Gateway on the RockREMOTE.

Side note: it’s at this point that everyone’s system will vary. In the event that you’re not already utilising MQTT, some development work will be unavoidable. Fear not: due to the ubiquity of MQTT, it’s very widely supported and there’s established libraries for most platforms and programming languages.

Our data-logger runs Linux so we have a multitude of tools at our disposal; the simplest and easiest being a basic Python script (as shown below):

import time
import paho.mqtt.client as mqtt

 time.sleep(60) #Sleep for 60 seconds

This snippet will diligently send the sensor readings to the IoT Gateway every 60 seconds. That’s it — pretty cool 😎

What do you mean that’s it — we’ve not even mentioned Satellites?

This is where the RockREMOTE IoT Gateway comes into its own!

RockREMOTE x IoT Gateway

So let’s pop the proverbial hood and let’s see what’s actually going on here.

On the surface, IoT Gateway exposes a standard MQTT broker — nothing special or proprietary — this means any existing MQTT client/library can connect and publish messages.

Security specialists: on this interface it utilises basic username/password authentication; so there’s no certificate authentication with which to concern yourself. No one wants to charter a helicopter to update an expired certificate, and if the monster excavator is physically compromised – well, you’ve got bigger problems to worry about…

There’s no restriction to the message payload that you publish — you can send text or binary; anything you like — most popular for IoT applications is JSON or Protobufs. The only limitation is that the total message size must not exceed 100 Kb — more on this in a second.

Not sure what MQTT is?

It’s pretty straightforward. MQTT is an industry standard which describes a simple Pub-Sub protocol whereby: clients connect to a broker and PUBLISH messages — other clients connect to said broker and SUBSCRIBE to receive the messages when published — that’s pretty much it!

To keep things organised it utilises the concept of TOPICS — whereby a message is published to a named topic — typically these take the form of a directory structure (e.g. /site01/sensor10/temperature) but you can use anything you like.

It does a few other things, but that’s all you need to know for now!

In the same way there’s no restriction to the message payloads, there’s also no restriction to the topics that you use. This is super convenient if you’re migrating from an existing MQTT solution — no need to change your topics!

So to recap: you can use any MQTT client/library, send any message payload to any topic you like. It’s almost as if Ground Control have taken a monster excavator to any possible barriers or hurdles to using this!

C’mon — what about the satellites?

So we’ve PUBLISH’d our inaugural “Hello World” message to IoT Gateway — what happens next? How do I get hold of these beautiful ones and zeros?

It’s magic. Or it may as well be, we don’t actually need to do anything more — the IoT Gateway takes care of all the heavy lifting. But since you’ve come this far — let’s dig into the wizardry…

The RockREMOTE is an Iridium Certus 100 IoT terminal. This means that it can talk to the Iridium satellite network to send/receive data. It has truly global coverage and works anywhere on the planet at any time of the day.

Zeroing in further, the IoT Gateway makes use of the brand new Iridium Message Transport (IMT) service. Read the deep-dive into how IMT works and how it differs from other IP Connection-based services.

In essence, this is a message-based service for sending/receiving messages up to 100 Kb. You’re only charged for the data you successfully transmit, so you’re not charged for protocol overhead, handshaking or bloat 😎

Sending the Message

Anything you PUBLISH will be automatically packaged and sent to space. IoT Gateway takes care of managing the connection, message queuing, retries etc — truly fire-and-forget!

Thud!

That’s the sound of your “Hello World” message landing down to earth.

This time instead of being in a remote Australian lithium mine; it’s in sunny Tempe, Arizona (where Iridium’s ground station resides). From here it’s whisked to Ground Control’s omnipresent platform, Cloudloop.

Your message, still cold from its brief stint in space, is reconstituted and published to their secure cloud-based MQTT broker (not to be confused, with the broker mentioned earlier, that resides on the RockREMOTE).

Again, this completely standard MQTT interface can be securely connected to with any MQTT client or library, allowing your cloud-application to consume the messages published from IoT Gateway.

Back to the monster excavator…

Recap: we’ve used a Python script running on our data-logger to relay sensor data (via MQTT) to the IoT Gateway every 60 seconds. For the alert readers, you’ll recall this data was published to the lithium/truck01 topic. The data has gone via satellite and has now been re-published to the MQTT broker residing in Cloudloop.

We’d now like to present the sensor data in real-time on a dashboard screen we’ve got setup in the office. For this, we’ll need to SUBSCRIBE to the relevant topics to get this information automatically pushed to it.

We’ve got two options — use an existing IoT Dashboard (e.g. Thingsboard) or create something ourselves. We’ll take a look at how we might get the data ourselves here.

To consume the messages from Cloudloop MQTT:

import paho.mqtt.client as mqtt

client.loop_forever()

Side note: the message was technically published to iot/ACCOUNT-ID/lithium/truck01 — this is because it’s a multi-tenanted environment and the prefixing nicely provides account-segregation.

In this scenario, we’ve been working with a single excavator — but there’s nothing stopping this working with multiple. You can easily see by changing the topic name (e.g. cobalt/truck32) we could support multiple sites and multiple excavators 😎

What about sending messages to the monster excavator?

So far, we’ve only spoken about data originating from the monster excavators (Mobile Originated in satcom parlance) — but what about sending messages to the excavator (i.e. Mobile Terminated)?

No problem, it works in exactly the same way — just in reverse.

Simply PUBLISH a message to Cloudloop MQTT and it will be sent via space and picked up by the IoT Gateway; the data-logger would just need to SUBSCRIBE to that particular topic to receive the message.

Iridium Messaging Transport (IMT) was launched on 21st December 2022, and in Iridium’s own words, it’s:

…a two-way cloud-native networked data service optimized for use over Iridium Certus® and designed to make it easier to add satellite connections to existing or new IoT solutions. IMT provides an IP data transport service unique to the Iridium® network, designed for small-to-moderate-sized messages supporting satellite IoT applications.

So what does this mean for the often overlooked, but nonetheless critical world of small-to-moderate-sized IoT messages?

For those of you wanting to reliably send/receive small amounts of data from anywhere on the planet, the only truly tried and tested solution is Iridium Short Burst Data (SBD) that enables you to send/receive messages up to around 300 bytes (yes, bytes)!

In general, describing anything as being small-to-moderately sized is not something to shout about. But in the world of IoT and M2M it’s not how big your payload is, it’s what you do with it…

Constraint breeds innovation — if you’ve only got 300 bytes to play with, you start to think creatively and use all sorts of tricks and techniques to cram as much information in as you can! There’s countless companies using SBD to do incredibly cool things (hello, ybtracking.com).

However there’s a limit — no matter how much you try, you cannot squeeze a photograph into an SBD message; nor can you squish in a whole weather GRIB file (trust me, I’ve spent the last 10 years trying)!

We’re gonna need a bigger boat…. enter stage left: Iridium Certus.

The Iridium Certus 100 service is the next-size-up for people looking to send/receive larger volumes of data via satellite. There are differences beyond speed and data limitations: Certus 100 provides a full-blown IP-connection and SBD is Message-based; not to mention the larger form-factor and antenna requirements, and cost etc.

What’s a satellite IP connection anyway? Simply put, it’s a full-on (albeit very slow) Internet connection, just like the one you’re using right now. Except instead of being a super-fast, fibre-optic, giga-bit connection, it’s a measly 88 Kbps — yes, there’s our old friend bytes again.

(Faster Iridium Certus service classes are available, up to a heady 700 Kbps using Certus 700 — but the entry-level Certus 100 service is best suited for IoT applications).

And Message-based? To save on words, it’s essentially an SMS text message you’d send from your mobile phone. You want to send “Hello World” and that’s all you send — there’s no superfluous headers, handshakes or protocol bloat (I’m looking at you, Mr IP Connection).

Analogy: Message-based communications is like calling up a friend and leaving a message on their answerphone; once they’ve listened to your message; to reply they call you back and leave you an answerphone message.

While this could be considered a crude form of two-way communication; it lacks the dynamism, flexibility and spontaneity of a telephone call — where both parties can freely communicate, interrupt without delay (i.e. IP Connection-based).

So to recap: Iridium Certus is faster and capable of sending loads more data (compared to the minuscule 300 bytes that SBD offers) — the kicker however is you have to contend with talking proper big-boy TCP/IP; this means latency, two-way handshakes, retries and failed transmissions.

One thing that you can be certain of: if you’re sending data from the middle-of-nowhere, up into space, to a satellite, back down to earth and then onto the Internet; and back again — there’s going to be latency and packet-loss. This is true of the Internet connection you’re using now, but this all happens in the background and you never notice anything — however, when you’re on a very slow connection (and you’re paying for every byte you send and how long you’re connected) — you’ll soon notice!

So the solution? Use a Message-based service, where you just pay for the actual payload that you send and only when it’s successfully transmitted. Er, what, like SBD? Yes exactly.

Enter stage right: Iridium Certus Message Transport (IMT).

IMT is the best of both worlds — Message-based service utilising Iridium Certus 100 to facilitate, drum-roll please… sending/receiving messages up to:

One-hundred-thousand-bytes (yes, 100,000 bytes)!

(Finally, something about which those with a small-to-moderate-sized payload can rejoice)!

This is a massive increase in message size, finally making it feasible to send larger amounts of data from anywhere on the planet. You’re not going to be able to browse the Internet or stream Netflix — but your remotely deployed IoT application, monitoring some hypothetical oil and gas pipeline will now be able to send more data. Which in turn might facilitate additional sensor readings, greater data resolution or even low-res photographs if it detects suspicious activity — the sky’s the limit!

IMT is pretty cost-effective, you’re only charged for the data you send: price plans start from 25 USD/month, and typical data usage costs 10 USD/MB.

From SBD to IMT

The pathway to IMT for existing SBD applications (that use something like Ground Control’s RockBLOCK) is pretty straightforward.

As mentioned earlier, SBD and Certus 100 are not like-for-like comparable — Certus 100 is bigger, more expensive, requires more power and a bulkier antenna compared to its short-burst brethren (although both are still considered microscopic compared something like VSAT).

So if you’re building an autonomous-flying plane for delivering medicine across Africa (hello, Zipline) — you’ll probably want to stick with SBD. However, if your remote IoT application is not as constrained, IMT might just be the thing you’ve always longed for.

Engineers integrate with SBD by sending simple AT commands via a serial interface — however, in contrast, IMT is not directly exposed by default on Certus 100 terminals. It’s up to the individual terminal manufacturers to decide if/how they want to expose it.

At time of writing, only two manufacturers had IMT solutions ready for their terminals. And Ground Control is one of them: both the original RockREMOTE and the new RockREMOTE Rugged are IMT-ready.

RockREMOTE, utilising our IoT Gateway, exposes IMT messaging through the lingua-franca of the IoT industry – MQTT. The proposition is simple: talk MQTT in the field (e.g. from your microprocessor, PLC, Arduino or RPi) to the RockREMOTE and your message will be magically whisked off (via space) and arrive at their Cloud MQTT broker ready to be consumed by your application/ dashboard — effectively end-to-end MQTT.

So from an integration perspective, while it’s not quite a drop-in for SBD — it’s not far from it. By using an industry standard MQTT interface, it’s possible to send/receive messages with just a few lines of code.

Let’s just replace all existing IP connections with IMT — simple, right?!

Alas, it’s not necessarily that straightforward.

Imagine you’re coming at IMT from an existing IP connection-based solution; maybe you’re already using Inmarsat BGAN M2M or maybe you’re moving to Satellite IoT from the world of Cellular IoT.

The good news is, if you’re already using MQTT, the move is likely to be a piece-of-cake with a device like the RockREMOTE. All you’ll need to do is update the destination of your MQTT broker to point to the RockREMOTE.

If you’re using something like HTTP GET/POST or FTP — it’s pretty simple to take the data you would have sent via these means and package it up to send via MQTT instead. One of the great things about MQTT is that there’s no prescribed message format — send Text, Binary, JSON or Protobufs etc.

Finally, what about if you’re doing something more complex, for example using another application or protocol that expects an interactive two-way IP connection (e.g. SSH, SFTP, TCP/IP sockets, Web browsing etc)?

In short, IMT isn’t going to work for you. Message-based communication is perfect for asynchronous communication – fire-and-forget — it isn’t suitable for scenarios that require synchronous communication — (see again the answerphone analogy).

Unfortunately, if you have to use this type of synchronous communication; your only option will be to continue to use an IP Connection.

But there’s a glimmer of hope. Some devices, like the RockREMOTE, are able to support both message-based communication (using IMT) as well as IP connection — so you have the flexibility to use either methods (or indeed, both), depending on the type of communication you want to undertake.