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.
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.
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.
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.
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.
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!
29 thoughts on “Finding The Goldilocks Cell Module”
why is hologram not on this list? https://hologram.io
great pricing, and their nova USB module with python library is SO EASY to use https://hologram.io/nova/
(fyi i don’t work for this, just genuinely like their stuff!)
No particular reason. The last time I did this research I was only looking for solderable-modules and they didn’t have any, so I didn’t research any further. This is definitely not an exhaustive list!
Another option is always USB cell modem sticks. You can get a 3G stick for $10.
For Sims, the cheapest option I have found for IOT is airvoicewireless. Get the $10 pay as you go plan with 90 day expiration. That gives you 105MB of data spread over three months for $3.33/mth. They take $1 mth out of the $10 to keep the line active so you get $7 to spend on data. They are AT&T reseller.
Airvoice is $1/mth plus 6.6c per MB, compared to Hologram at $1/mth plus 38c per MB.
…and imp is $0.05/MB, with 5MB included, it’s pooled between all devices and it rolls over…
I had not looked at Imp recently. It has a $2.50-$3.00/mth base fee per device which is cheaper than the $3.33 of airvoicewireless. On the other hand, I can use $10 usb cell modems with airvoicewireless and IMPs cost between $40-85. The usb cell modems are plug and play on Linux, just plug them in and they work.
Look on Ebay, there are 100s of 3G modems for $10 or even $5. Some of the companies selling there are bulk wholesalers and can supply 1,000+ identical devices.
In the US FreedomPop (https://www.freedompop.com/) might work as a data plan for you. 250MB of cell data for “free” (I get a $0.01 charge every month). Be sure to cancel all the extra add-ons and be wary of their upsells.
You may be able to get multiple SIMs from them.
Long but worth reading if you’re new to FP: http://www.cranialborborygmus.com/freedompop-for-dummies.htm
Wow. I don’t think I understand their business model at all. Though now I’m interested in getting a SIM!
The idea is to give you a basic ‘free’ connection with continuously changing, confusing rules. The confusing rules make it easy to blow past the free plan and into a paid one. The ‘free’ stuff is just a gimmick to get your to sign up. Their paid plans are not unreasonable, but they are not the cheapest either.
Interesting! I figured it was something advertising related. I’m surprised that model works for them.
That “Innocent Palm Tree” would turn a few heads if it were in a Minnesota cornfield or North Dakota pasture!
They are available in other species: https://www.atlasobscura.com/articles/take-a-look-at-americas-least-convincing-cell-phone-tower-trees
One small town was in negotiations with a cell company over a permit for a tower and said they had serious concerns about the appearance. The cell company was afraid they would have to spend a lot to disguise the tower, then the city representative said “We hate the look of the towers disguised as trees, could you just put in a tower?”
This article should be tagged “US only”. And probably also as “really confused” – sugar here, sugar there, over complicating what is fundamentally straight forward: buy a SIM which has data service capability, and interface to the modem device following the datasheet/manufacturer’s instructions. There’s no mystique once the basic terminology is clearly explained (which this article doesn’t help with at all), and it also doesn’t help anyone to make it look more complex than it is.
And I’ve *never* seen (or ever heard second hand) of a network operator kick a device off a network.
Why US only? Most of this applies world-wide.
On banning – you’ve not been exposed to many carriers, then. Carriers do ban IMEIs from their network, especially Verizon. There’s pretty much no recourse to that state, either. Some carriers, eg T-Mobile, are a lot more accepting but you shouldn’t think that all of them are. This also applies in Europe, I’ve personally seen Orange FR and O2 UK ban devices.
Also, the cell modules vary hugely in bugginess of firmware especially if you use the built-in TCP stack that many offer. For example, one vendor who shall remain nameless doesn’t randomize their source ports, so a rebooted module will use the same source port for outbound connects and hence cause packets to be dropped (because the remote server thinks a previous session is continuing). Many of them publish power numbers which are absolute fantasy. Almost all of them will get into nasty states – invariably when they are deployed in the field – and need a good kicking to recover.
Most cell modems are a huge pile of steaming software, it turns out.
^^THIS^^ I have dealt with several vendors and their modems, and even gone through PTCRB a couple times and multiple carrier certifications. Buggy firmware AND drivers are my biggest pet peaves with cell modems! A lot of times, they will just randomly crash for unknown reasons, rendering the control interface useless. This has made it, absolutely necessary to be able to control all flow of power to the device in several designs order to fully reset it. This also includes making sure no power (i.e. pull-ups) are present on the IO lines as well. Some of them require elaborate power-up and down sequences too. We dealt with one vendor who had such a piss poor hardware implementation inside, that we had to add the ability to completely disconnect ALL the UART/IO lines from the modem to insure the device would reset properly because of some kind of power bleed inside the module!
Don’t even get me started about poor data sheets and documentation, as well as Firmware updating.
As for device getting kicked off of networks, it happens! We have had devices get kicked for various reasons, so don’t let anybody tell you it doesn’t happen, and it is completely up to the carrier! Like was mentioned, you pretty much have no say in the matter.
I feel your pain.
We only found a major bug in our module because the carrier’s nbiot network went down over a weekend, and we just happened to check the battery voltage logs on one device on Monday morning. Turned out that if the module was sent to sleep without a valid network connection, it would silently power back up four minutes later and try again… and then get stuck, and drain the battery for an hour or more, which our system CANNOT tolerate.
I think the vendor also silently pushed out a firmware update over the network on Christmas Day, which has subsequently bricked all but two of the modules that happened to be running on test over the break. Good job, fellas!
A lot of the modules mentioned are multiband and will handle most worldwide standards for the technology they advertise and the ones that operate their own MVNO’s can handle most of the world. I have looked at Particle and Hologram specifically and they advertise as worldwide.
As for carriers kicking devices off, you must have not worked with large volumes of devices with cellular carriers.
I have worked with the ILEC here for a number of projects spanning several technologies and it seems to be regular practice to “clear the books” and purge the registered device lists forcing devices to reregister to the network.
This is irrelevant if you have a ‘normal’ cellphone or aircard-like device, but for integrated or specialty networked devices this can cause lots of problems.
Especially when this is automated to occur at midnight or 1am, and all of the logging and reporting interfaces go offline and half the network map goes red screaming tickets and pages into the night to wake up all of the oncall techs.
It was not fun times…
I’ve playing on-and-off using a dev board with a SIM5320 (https://simcom.ee/modules/wcdma-hspa/sim5320/). It’s ok for hobbyist-level use. Works over UART using AT-commands. Has a GPS receiver and can run Lua scripts directly on the module. Docs at https://simcom.ee/documents/?dir=SIM5320
Adafruit has breakout board (called FONA 3G) for ~$80 https://www.adafruit.com/product/2687 or there are Chinese sellers with their version available on ebay/aliexpress for about $35.
The Chinese dev boards don’t have GPIO pins broken out, but you can solder some 30 AWG wire to the unconnected module pins.
Make sure you buy the right version for your location (Europe/America/Japan?)
Even cheaper is the older SIM900 ($10 breakout boards) but it’s GPRS-only so may not work in many regions or carriers (in US might still work on T-Mobile).
If you want cheap GPRS connecticity for your Arduinos you might want to have a look at Boards with a Simcom SIM800l chips. I got two from Ali for ~$2.20 each.
So far i just managed to send die HTTP requests via AT commands. But i have some Arduino libraries that seem to reduce complexity. But no experience with them yet. But $2.20 sounds like a Deal! And there are iot tageting MNOs that sell Roaming enabled SIMs with reasonable rates per MB Data usage, too…
Looking at the graph of ease of use explains why medical companies I deal
With use multitech modems – just to make the process as difficult as possible – oh your SIM card has failed you need to send your device back so we can configure the new card in the system..
The AT command set is *awful* as a communication interface. It was fine in the days when you just sent a few hardcoded commands to a modem before initiating a connection using a more sensible protocol, but now you have to write whole parsers and complex state machines to use it just to get IP packets in and out of the damn thing.
I spent a significant chunk of last year writing a robust library to deal with it, and I hope I never have to do that again.
Any pointers to your code, if it is available? I’ve also been trying to write an AT-command parser/state machine, but I’m not 100% sure that I properly understand how the transitions are permitted to happen.
Unfortunately it was done for my job, so the code is proprietary.
I can say that using Ragel to generate the response parser made the job much easier, though. Hand coding state machines is a recipe for pain.
I hate that you can’t really send commands without a 500ms delay in data transmission. Some modems have two uarts for this but that is not very elegant at all.
Not that it’s any better complexity wise, but one can initiate a PPP connection with the cell modem after initial configuration via AT commands. PPP isn’t great, but at least it’s designed to send and receive packets.
I think making a 2G modem from scratch would not be that difficult. A few manmonths or so. But it will be difficult to compete with qualcomm, yes :)
Anyone know of a device that provides a raw socket interface? For reasons, the master controller contains the TCP/IP-stack and handles all that. If I get to choose, it’d be at least 3G and multiband too.
. (forgot to enable notifications)
Please be kind and respectful to help make the comments section excellent. (Comment Policy)