If adding a cell modem is dealing with a drama queen of a hardware component, then choosing from among the many types of modules available turns the designer into an electronics Goldilocks. There are endless options for packaging and features all designed to make your life easier (or not!) so you-the-designer needs to have a clear understanding of the forces at work to come to a reasonable decision. How else will Widget D’lux® finally ship? You are still working on Widget D’lux®, aren’t you?

OK, quick recap from last time. Cell modems can be used to add that great feature known as The Internet to your product, which is a necessary part of the Internet of Things, and thus Good. So you’re adding a cell modem! But “adding a cell modem” can mean almost anything. Are you aiming to be Qualcomm and sue Apple build modems from scratch? Probably not. What about sticking a Particle Electron inside to bolt something together quickly? Or talk to Telit and put a bare modem on a board? Unless you’re expecting to need extremely high volume and have a healthy appetite for certification glee, I bet you’ve chosen to get a modem with as many existing certifications as possible, which takes us to where we are today. Go read the previous post if you want a much more elaborate discussion of your modem-packaging options and some of the trade offs involved.

The Cell Module Spectrum

A cursory web search turns up an unhelpful number of options for cell modem modules. What parameters matter? Why would you choose one over another? A little market survey can place most cell modules on a spectrum of choices, which is the subject of this post. It’s worth noting there’s one more discussion about cell technologies that we haven’t had yet, but that will come another day. For now we’ll presuppose that all of these options meet our needs. With that caveat out of the way, here we go!

Why did I choose that X axis? Well the spectrum really comes down to how many layers of sugar a vendor wraps around the network connection. It is my experience that every method of networking devices together fundamentally sucks, but the precise way in which they suck is what varies between technologies. Cell modems are no different, but like WiFi and ZigBee and Bluetooth and everything else each provider packages the relevant APIs in different ways. So in that sense the spectrum is sort of from “easy to develop” to “hard to develop”.

How Do Networks Work?

Cell modems have one extra layer that some of those other technologies avoid or intermediate; a cell modem connects to The Internet. To be clear that’s quite a simplification, as a modem doesn’t actually quiiiite connect directly to The Internet. What? Confused yet? Modems connect to a cell carrier which in turn internally routes data that can sometimes connect to the Internet. That’s true of, say, an ESP8266 too, but in that case the ESP connects to your home WiFi, your WiFi connects to a modem which is screwed into a coax connection that eventually leads to your ISP. You pay your ISP to provide Internet to that modem on that cable, the WiFi has an Internet connection, done. The difference here is subtle but important. In the ESP example, the relationship between your widget and the Internet is the same as your laptop and the Internet. Comcast doesn’t care what you plug in and in fact they can’t see what’s connected. Not so with a cell modem.

The cell modem is connected to the carrier directly. This relationship is governed by the SIM card inserted into the device. The cell modem only knows how to connect to the carrier tied to the inserted SIM card and its network connection is completely governed by that carrier. There are some configurations where the modem’s network connection actually won’t terminate in the public Internet. I swear the specificity of this digression will be relevant in a bit, so bear with me.

Anyway, there is another implication of this relationship, and that’s that every cell modem will be connected to a network. So paragraphs ago when we mentioned the vendor can provide a nice candy coating around the network related APIs? That can wrap all the around past the hardware and encompass the other end of the connection too in someone else’s computer the cloud. The spectrum goes from “do everything yourself” to “you send some data and it magically appears on a webhook in our cloud.”

An Aside on SIM Pricing and Plans

Before we break down what the elements of the spectrum mean we should take a moment and talk about cell plans. For small devices like these the plans available are designed for what is referred to as “machine to machine” messaging. Even if the modems have the bandwidth capabilities to stream 8K HDR cooking shows the carriers expect them to send, say, one message an hour, or one message a day. Instead of having deep data, text, and voice allowances M2M plans tend to have low per-device maintenance and registration costs with tiny data allowances. The expectation is that the purchaser is managing a fleet of thousands/tens of thousands/hundreds of thousands of devices but that each one sends and receives very little data, and plans are priced accordingly. DigiKey resells M2M data SIMs recently so you can use their pricing as a guideline, though I find it to be significantly different from agreements I’ve seen for shipping products. For another reference point, NimbeLink lists prices too. Like all things this is a negotiable element and scale helps.

A final note; you can always use a normal consumer cell data SIM instead of a specific M2M SIM. If you’re building just one of something this is probably a fine option if you can find a plan with cheap overhead. There are a few US carriers who have relatively low per-SIM costs and work well. I’ve used US Mobile in the past, and if you’re a Google Fi customer their data-only SIMs may work though obviously without SMSs.

Other Considerations

Vendors selling cell modules expect them to be deployed en mass to a large fleet of end devices — this goes with the expected use cases for those M2M SIM cards we just talked about. Some vendors will package and sell “fleet management” capabilities with their solutions even if they don’t provide much additional sugar. Typical fleet management tools will let you see basic telemetry for each node such as which devices are active, connection quality, and modem version. Some will also let you track resource consumption per-device to help manage spend. This telemetry is typically separate from any data your application may report. Fleet management tools may expose this bulk metadata via APIs so that they can be plugged into your application level data stores to include in other health metrics.

In the previous post we made an offhand comment about keeping your modem up to date, but that was no joke. Every carrier will want you to keep your modems up to date or they may evict you from the network. This is a protective measure to make sure that buggy devices don’t ruin things for everyone but it means that your device must provide it. Some vendors provide this as a remote OTA capability as part of their fleet management solution. If that’s not an option your user firmware may need to download and apply modem updates itself. This can be especially complex because, as with all OTAs, if there is a problem your device may be knocked off the network permanently. To reiterate, this OTA is separate from the ability to update user firmware remotely and one does not necessarily imply the other.

Breaking Down the Modem Spectrum

Whew! Caveats done, it’s finally time to talk through the spectrum in more detail. For that I’ve prepared… yet another table! Keep in mind that this is not an exhaustive list, and not meant to be interpreted as an endorsement of any particular choice. It’s merely a representative selection of the market as it stands at time of writing.

Whole Fat

In the “whole fat” category we have offerings that take care of nearly everything. These are the vendors who will sell you a cell plan, wrap every network API, and make sending and receiving data as easy as possible. Often that means the on-device APIs look something like “message.send()” and data will magically appear in the backend wholly formed. No complex network state error handling to write. No framing and unframing to debug. And their infrastructure just begs to have some of your server code running in it. Two exemplars here are Particle and Electric Imp. Both of these companies sell products on basically the same premise: “building network connected hardware is hard, so use our products to make it easy.”

Unsurprisingly solutions in this segment of the market tend to be on the expensive side in exchange for ease of use. But even the pricing is easier, they may abstract the cell plan out entirely so the developer never has to talk to carrier or any other organization. You get a single entity to deal with one pricing model.

Obviously these can be great choices for getting a new project out the door quickly but they also involve more platform lock in. You’re buying everything in one place, from cloud infrastructure to fleet management to electrical interfaces to a vendor relationship. Nothing carries over if you try to pull out, even plan pricing will need to be negotiated from scratch. It’s a great deal for the vendor but might end up being pretty expensive in the long run for you the hardware manufacturer, depending on what your business model is.

There’s also an exchange of control and visibility for an SLA. If an internal component of a full fat vendor’s infrastructure goes down, becomes unreliable, or changes substantially talking to a Field Application Engineer may be the only recourse. And if things really go down hill and you want to leave, refer to the previous point about lock in.

2%

Ahh wonderful 2%, the great taste of full fat without the serving of guilt that comes along with it. The 2% “medium fat” option sits in a sweet spot between “too many batteries included” and “make it from sticks on a deserted island”. Here there is a more gentle interface to the underlying hardware than the fat-free choices below but substantially less hand holding the full fats. There are two main areas where the medium fat options differ from the others, included network infrastructure and on device APIs.

Each of the full fat vendors would prefer if you buy the entire stack from modem hardware through cloud services from them. That arrangement is really the way their offerings are designed to work, that’s the special sauce. Though it might be possible to use the full fat modules without the entire backend by making web requests directly on the device, it would negate much of the benefit of the higher cost. The medium fat vendors mostly don’t offer that choice; they give you a modem that can open a socket and it’s up to the developer to do the rest. What they do add is fleet management. Both of my favorite examples, LinkLabs and Digi offer interfaces for commissioning and managing large groups of devices, and both support remote modem OTA.

A momentary aside about the LinkLabs offering. Remember I bent over backwards to describe how a cell modem talks to the carrier to mediate its network connection? The LinkLabs module routes all of its traffic this way and provides no other choices. To interface with the Internet all traffic goes through Verizon’s infrastructure then through LinkLabs’ before it hits the public network.

The other benefit to going medium fat is nicer device side network APIs. If you dig deep enough most modems speak ye’ olde AT commands under the hood. With a fat-free option the developer needs to write code that interacts with the modem directly themselves. This is certainly possible, after all AT commands aren’t terribly complex, but it does force the developer to spend some quality time with an ugly modem data sheet and it doesn’t insulate the main firmware from the quirks of a particular modem. The medium fat options include the same benefit as the full fat options in the form of a friendly neighborhood coprocessor which does all the messy modem support itself, ideally hiding behind a UART and a vendor-provided C library.

Another aside, this time about the Digi modules. Digi might be a familiar name because they make the ubiquitous and often confused pentagonal XBee modules. Their cell modules fit in exactly the same form factor and use the same pinout. It’s possible to swap one of their WiFi or ZigBee modules out for cell and continue using it with no code changes, except for the APIs that don’t make sense anymore.

Fat Free

If all of those options were the complex ones, fat-free isn’t. Fat free is simple! Do you want a cell modem? Do you want nothing else? Great! Choose a fat free cell module! Though even here the lines can be a little blurry.

The fattier cell modules above usually gain their nice features by adding a second microcontroller to the package instead of just providing a modem in a PCBA. This lets them include whatever shims and padding are required to make the software and electrical interfaces more palatable. But even without this ride-along micro some electrical and mechanical cross compatibility is present in these modems.

Both our example fat-free module vendors Nimbelink and Multitech sell modules that are footprint-compatible with other options in the range, but they aren’t quite as universal as something like Digi’s XBee line. Here it’s more like electrical comparability than software, meaning things like power pins at the same locations, level shifters on IOs, and UART TX/RX pairs on the same pins. Definitely an improvement over redesigning a board from scratch for a new cell modem, but also still requiring the firmware to adapt.

What Now?

So where does all that leave us? The right choice is all about expectations. (And money, it’s always about money.) How many of your project or product do you expect to make? How many other people or employees do you expect to be able to staff on the project? Are you able to pass recurring costs on to a customer? Do you expect to sell and support the product for a long time? Internationally? (We haven’t even taken that can of worms down off the shelf!)

If you’re making a few of something, or may not be able to staff a large team, or want to launch quickly, or can pass the cost to your customers, then a full fat option might be right for you! If you want the absolute lowest cost and most control, maybe fat-free is the way to go. And if you want a little sugar, but not too much, and can stomach a slightly higher price point for a nicer experience overall, then the 2% camp is where it’s at.

Thanks to [Yoo Yoo] for noticing DigiKey’s cell plan options!