The Strings of Cellular IoT

Title Photo by Sagar Dani on Unsplash

I’ve spent the last decade of my career working on software and hardware tools for developers. Tools designed to foster collaboration, and lower the learning-curve of complex technologies so that teams and companies can solve problems faster. Every product I’ve worked on – from web UI tools and mobile app dev services, to developer-biased IoT tools – was created to help developers get something done, faster. And every product was focused on untangling all of the complexity associated with building solutions in that space.

In the IoT, we have more than our share of complexity. We get all of the complexity of the software world, mixed-in with a healthy dose from the physical world around us.

In cellular IoT, I like to refer to this complexity as “the strings of cellular IoT.” They are the things that developers often cannot control about building IoT solutions, or which exist by pure inertia. They are things that slow developers down, cut off choice, or provide unnecessary duplication of effort. They are things that lead us to search for alternatives that may be less than ideal, but which feel worth the tradeoff in our frantic efforts to reduce friction.

And while there are many such strings in the cellular space, these are the ones I tend to see most often:

• Difficult-to-program modems.
• Developer Guardrails.
• Device lifecycle management pitfalls.
• Security not included.
• The meandering path from prototype to scale.

Difficult-to-program modems

If you’ve ever had to work directly with a cellular or Wi-Fi modem, you’re no doubt familiar with the Hayes command set. This command set – often referred to as the “AT command set” because many of the commands start with the string “AT” – was developed by Dennis Hayes in 1981 as a standard command set for interfacing with dial-up modems. It’s terse, and was created in a time when instruction sets were designed to save space. As a result, it’s about as developer-friendly as machine code.

It’s also still in use on many modems, including most cellular IoT devices.

For those unfamiliar with the AT command set, here’s a brief example of the commands needed to turn on a cellular IoT module, set its APN, configure an LTE band, and start scanning for towers:

For many developers, myself included, AT commands are cryptic and inaccessible. They are non-intuitive, and differ from one module to the next. It’s a painful way to add a connectivity module to your application, and yet it’s still the way of the modern world if you’re looking to integrate a cellular modem into your IoT solution.

Developer Guardrails

The challenge of working with cellular IoT modems is well-known, and solutions do exist to create developer-friendly abstractions on top. The problem is that these abstractions often come with guardrails that do too much, or too little, to help accelerate building a connected solution.

Some vendors create narrow guardrails and abstract away the complexity into developer-friendly APIs. The problem is, they also force you to adopt their Host microcontroller, their RTOS, and even a particular programming language. As nice as it is to abstract away the AT command set, cutting off developer choice in the rest of the stack is a steep price to pay, in exchange.

Other vendors give you wide guardrails. They sell you only a SIM or a piece of hardware that requires you to furnish your own SIM and plan. This approach has certainly brought down the cost of IoT and M2M data plans, but it swings too far into the other direction. Developers get cheaper connectivity, but are left to build up the rest of their solution stack themselves. As a result, the developer ends up with the equivalent of “writer’s block” or “blank page syndrome” because there is so much to choose.

The either-or nature of the guardrails in place today leaves developers with a difficult selection: accept too much restriction, or forge ahead with too little guidance?

Device lifecycle management pitfalls

How do you design a real world IoT device when the cost model isn’t built to account for real world use?

Beyond cryptic interfaces and guardrails, developers must also contend with the cost of managing devices and data, much of which is hidden from view. Every device has a price, but some have multiple: the price you pay up-front, the price you pay for data, and the price you pay for a device to change its state, for instance when activated or deactivated.

When a device has multiple price components, or shadow costs, it can be hard to know exactly what your IoT solution is going to cost you. Especially since the reality is that IoT products don’t follow a happy path where they fly off the shelf, are deployed into the field immediately, and are used forever and ever without end.

Instead, most IoT devices tend to go through a pretty consistent lifecycle:

• A inventory and distribution stage where they sit idle.
• Activation when they are first used.
• A period where they fall into less than regular use, but the device is still “online” and accruing fees.
• A period of temporary breakage, and it can often take months before the issue is identified and fixed.
• Re-commissioning after the device is fixed.
• A period where the device is decommissioned permanently.

The typical device lifecycle

Now imagine that, for every one of these stages, you’re paying the same monthly data fee, regardless of actual use, as well as charges for activation, re-commissioning, and decommissioning. The challenge in the cellular IoT space is that each of these phases in the device lifecycle come with carrier fees and transaction costs that can be difficult to plan and budget for. As a result, when most developers look at an IoT device, they don’t know what its true cost is.

How do you design a real world IoT device when the cost model isn’t built to account for real world use?

Security not included

There’s also the string of security, a topic that developers are ever conscious of, but which many providers don’t bake into their products. Key and certificate management is an essential part of every IoT solution. And with all major IoT cloud services now requiring TLS, in the absence of baked-in security, developers are forced to store keys and certificates in firmware in order to connect their devices to cloud services.

With keys and certs in firmware, your IoT devices become yet another sensitive vector that an attacker can use to get the (literal) keys to your kingdom.

The meandering path from prototype to scale

Finally, there’s the string of the disconnect between prototype and production solutions, even as developer-friendly tools abound. As developers, we should consider ourselves fortunate that prototyping is as accessible as it is today, thanks to companies like Arduino, Adafruit, SparkFun, and the Raspberry Pi Foundation. But because much attention has been paid to how “maker friendly” these devices are, they are often dismissed as not production ready. IoT engineers will gladly use these accessible tools to prove an idea at the prototype stage, but throw those prototypes away and start over when it comes time to build a “real” solution.

But if these tools are good enough for the Mars Ingenuity helicopter, they should be good enough for our solutions. And IoT solution vendors can absolutely do more to minimize the throwaway mindset with tools that make prototyping easy from the start, and which level-up to pilot and production scale just as seamlessly.

Complexity Kills

When taken together, the strings of cellular IoT create a developer-hostile environment where complexity rules. From the start, the path of selecting a board to building a prototype to deploying and scaling a pilot is filled with hurdles and roadblocks that make it hard for many initiatives to succeed.

When I think about complexity, I think of a quote from our Founder and CEO, Ray Ozzie. It’s something that he said long before setting out to start Blues Wireless, but which applies very much to the IoT of the present.

Complexity kills. It sucks the life out of developers, it makes products difficult to plan, build, and test. - Ray Ozzie

Introducing the Notecard

It should come as no surprise that Ray was motivated to start Blues Wireless after experiencing the pain and complexity of building an IoT solution himself. As Ray detailed in his recent post, that journey started with the Fukushima Daiichi nuclear disaster and led to the Notecard.

The Notecard is a developer-friendly, production-ready cellular IoT device. It was built by developers, for developers, to address every one of the strings of cellular IoT. The Notecard:

• Is easy to program, with a built-in developer-friendly API.
• Let’s you set your own guardrails with your own host MCU or SBC.
• Has no hidden fees, and a built-in 10-year data plan (with no fees) bundled into the cost of the device.
• Includes baked-in keys and a secure connection to our Notehub.io cloud service.
• And is built on a form-factor that’s ready to move to a pilot or deployment in a snap.

The Notecard is an uncomplicated cellular IoT device. It comes with 500 MB of data and a ten-year plan built-in, and starts at $49. If you’re evaluating cellular IoT solutions, you should check it out, and you can learn more at blues.io, our Developer Portal, or our Shop.

With the Notecard, we aim to cut the strings of cellular and allow the next generation of IoT solutions to be truly wireless.