In a previously published article (New Electronics, 9 March), we proposed that building the right kind of connected device is a lot like preparing a six-course dinner, in that each course needs to be considered, but they all need to work well together if you want to impress. And decisions taken early in the IoT development process will inevitably restrict your choices later on.
The Connectivity Course – the radio you use to connect to the Cloud – is fundamental to every IoT project so it’s worth understanding the kinds of questions we need to answer to get this course just right.
An example scenario
Let us imagine we have a vending machine that dispenses hot coffee and another drink, which is supposed to taste like tea! The machine requires regular maintenance visits from a service technician, but senior management have run the numbers and have concluded there is a business case to upgrade the system to be “Internet connected”.
Perhaps there’s a need to increase service intervals through fault detection or predictive maintenance. Or to obtain better insights into customers’ buying behaviours.
The question is: how do we get data from this device to a backend server (which invariably lives in the Cloud) when it’s possible to use a personal-, local- or wide-area network to achieve this.
The Personal Area Network
Personal Area Networks (or PANs) are formed in the vicinity of an individual, and assuming we only want to consider wireless connections (ignoring, say, USB) then the most common example of this would be using Bluetooth. As with all radio systems, our IoT device needs another radio as a ‘gateway’ to talk to, and for a PAN that gateway is most likely to be someone’s smartphone.
On the plus side this approach does not cost us anything, either for the smartphone itself (the user just installs an App) or for the data transfer (using the owner’s LTE connection or their Wi-Fi connection). But the flip-side, however, is that the gateway device doesn’t belong to us – the user could just un-install the App, reset or upgrade their phone. Also, the phone’s owner must go through the rigmarole of Bluetooth pairing so the IoT device knows which phone to connect to and can do so securely.
Users also have an annoying habit of moving around, taking our gateway device in and out of range at unpredictable times. Maintaining the App on multiple platforms (Android, iOS) is an added cost, and it requires the lifetime of the IoT device to align with the obsolescence cycle of the phone’s operating system, which could be a problem.
The Local Area Network
Wi-Fi is probably the best example of a Local Area Network, but there is also Zigbee and Thread (or Matter) in this category too – even if they are technically labelled as PANs. The key feature here is that the gateway is not a smartphone that comes and goes, but a dedicated appliance we can rely on such as a Zigbee hub or a Wi-Fi network.
The main issue that can arise though is around device enrolment. For example, what happens when your designated Wi-Fi Access Point goes down, or if the code (or ‘PSK’) for the Wi-Fi network changes? Does your device keep trying to reconnect forever? Or does it give up and start a built-in Wi-Fi Access Point for configuration purposes?
Of course, rolling out your own gateway devices can help solve these sorts of problems, but where do those gateway devices get their Internet connection from? And will you have the time and permissions required to install them around the building, and to maintain them too?
The Wide Area Network
The final option to consider is simply to bypass any local infrastructure and to talk directly to some globally (or at least nationally) available network – typically an LTE cellular network. But you could also consider Low-Earth Orbit satellite systems here (starting with Iridium or next-gen LEO services, such as Starlink), if it’s outdoors, as well as wide-area non-LTE systems like LoRa or Sigfox.
The benefits here are that someone else has already installed a network of satellites or cell towers but it is going to cost you to access them. And your radio will have to shout a little louder (and hence use more power) to be heard over the greater distances involved.
Using one of the new narrow-band LTE-based standards, such as LTE-M or NB-IoT, would be a good choice of radio in this category. These offer considerable power savings over older 2G and 3G technology, and trade lower bandwidth and higher latencies for much improved range compared with other LTE categories (like the one your phone uses to let you watch YouTube on the train).
NB-IoT has probably slightly better range, but it can’t currently perform network roaming which might limit your options on network providers in the future.
Either way, you’ll need a SIM card (whether it’s a physical one, an e-SIM chip, or integrated into the silicon die of your modem) and then you’ll be on the hook for a monthly charge from your network operator.
It’s also worth thinking about getting some SIMs locked-down for your specific use case – you may have heard about SIM cards being stolen from over 400 sets of IoT-enabled traffic lights in South Africa and then being illicitly used in smartphones.
What is the best solution then?
Well … it depends!
If you don’t need your connected coffee machine to provide real-time reporting and analysis, and are regularly servicing it anyway, then you could just issue each service technician with a smartphone and use Bluetooth. As soon as the technician arrives, the coffee machine can connect and start uploading its reports. The same smartphone can also be used to log the service and any issues that occur.
If you do want real-time data (or at least in near-real-time), then Wi-Fi would work assuming the buildings the machines are installed in have available networks – ideally one dedicated to small IoT devices so that it doesn’t get swamped when someone fires up Netflix on their lunchbreak.
But if your coffee machines can only be installed in locations with unreliable Wi-Fi, then maybe a swap-in communications module that you can switch between Wi-Fi and cellular variants would be a good choice. From an application point of view, you still have an Internet connection (to send IP packets) and you can then fit the right radio at installation time.
If you have a lot of coffee machines, for example in a large office block or a stadium, then it would pay to roll out your own Wi-Fi or Thread network and to install your own gateway devices in various locations.
That approach would allow you to fit the more expensive cellular modems and SIM cards to those few gateway devices, rather than to every single coffee machine.
As in all design projects though, multiple conflicting factors must be traded off against each other to find the right balance.
But hopefully walking through some of the areas to consider in terms of connectivity will have given you food for thought.
Author details: Jonathan Pallant is a senior embedded systems consultant at 42 Technology
