Originally published on LinkedIn in February 2021; reviewed and updated for this site.
These days everyone is talking about the Internet of Things and connected devices. Smart cities, Industry 4.0, the connected home, the connected car and the connected worker have ushered in an era where things can communicate. Karl Steinbuch, the German computer science pioneer, said: "In a few decades time, computers will be interwoven into almost every industrial product." Most would agree that vision is already a reality, and there is still high potential for further development.
It is also interesting to reflect that IoT is an industry where the research has largely been proven correct — look at the roadmap created by SRI Consulting Business Intelligence in reflection of the 2008 report on Global Trends 2025 by the U.S. National Intelligence Council. Most would agree it has been pretty much spot on.
So as everyone is either starting to embrace IoT in their product development or expanding its scope, here are some of the lessons I have learnt around the building blocks I have used in developing IoT products.
What the IoT is made up of
The IoT can be designed at different scales for different uses. It can start in our homes with simple lighting or appliance control, and expand into factories and industry with automated machines, smart security and central management systems — what is often called Industry 4.0. It scales up again to entire cities: smart parking, smart metering, waste management, fire control, traffic management. Whatever the scale, the backbone remains similar.
The architecture is multi-layered, with delicate components intricately connected to each other. It starts with sensors, the source of the data. Sensors pass data to an edge or gateway device, which converts it into readable digital values and stores it temporarily. When the edge device senses a suitable wireless network or the internet, it pushes that stored data to a cloud server. The data is processed, analysed, stored and forwarded to the end-user device, with context provided by application software. The main design fundamentals and challenges of an IoT product revolve around these layers.
Designing the system
Setting up a complete IoT chain comes with challenges that are best considered at the outset rather than addressed retrospectively. You need to consider business requirements like prolonged battery life and low power consumption, secured network gateways and ruggedised hardware.
Electromagnetic compliance and resistance to electromagnetic interference are also essential. Introducing new devices that can be proved not to interfere with, or be interfered with by, existing systems is one of the most demanding skills in IoT design.
Components like the microcontroller, the sensors and the wireless network are chosen and handled with care for an optimal system design. Based on the scale of the application the design is bound to alter, but while the basics remain the same, attention to detail in the engineering improves a build by leaps and bounds.
Pick the right MCU
The MCU is the central nervous system of the setup. Data collected by sensor nodes is processed there, enabling the system to respond. The MCU is chosen on application-specific requirements — but there is a wide range of vendors, and a wide range of choice within each vendor.
For basic applications with a limited amount of data transmitted each day, an 8-bit MCU will suffice. Large-scale connected systems need 32-bit controllers: bigger RAM and larger flash that can hold a complete network stack alongside the application code, which makes them optimal for embedded systems running RF stacks or complex algorithms.
MCUs with floating-point units ease computation and give precision to long decimal values. That flexibility eliminates overflow checks in the program and is a real advantage in applications like location tracking, or processing measurement data from accelerometers and gyroscopes — anywhere data precision matters.
You also have to consider what you are connecting to, and whether there is a library for that connection. ESP chips have good support for Azure, for example, where some ARM parts have less.
Talking to the rest of the world
How do you want your devices to interact? The major wireless options are Wi-Fi, Bluetooth Low Energy, cellular, LoRa and Zigbee. The criteria that matter when choosing a connectivity module are data throughput, range and speed, power requirement, scalability, robustness and protocol support.
Choose a technology that is — and will continue to be — available, and that will do the job in the place you are deploying. There is no good building a GPRS device for the USA only to find AT&T no longer support it.
Effective point-to-point connectivity depends on two components: the transceiver (a receiver, a transmitter and an antenna) and the network frequency. The receiver sets the threshold for the signal and ensures it is distinguishable from other signals on the same frequency and from ambient noise. A high-quality receiver is imperative, and a lower data rate improves its sensitivity. But the quality of your receiver is irrelevant unless your antenna is good enough.
The transmitter controls output power — how much the transceiver can amplify. A 6 dB gain can double the amplitude of the output signal. Higher transmit power means a stronger signal, but the trade-off is battery life, so the decision depends entirely on the application, the data and the geography.
Choosing a frequency
Frequency determines range and data throughput. For IoT, sub-1 GHz and 2.4 GHz are the most used. Unlike media streaming or voice and video calls, IoT applications deal in small data packets.
Many developers opt for 2.4 GHz because of its popularity in mainstream applications. It offers higher throughput, but with challenges: lower coverage range, poor penetration through obstacles, and heavy traffic from other devices — microwave ovens, Wi-Fi — which creates interference.
Sub-1 GHz offers greater range and sensitivity in exchange for throughput. Distributed infrastructure benefits greatly from those long-range characteristics, and transmission through obstacles is possible. Since IoT sensors generate small amounts of data throughout the day, sub-1 GHz is a good fit for many applications: it consumes far less power and provides connectivity for years on a battery. Systems in agricultural fields or the oil and gas industry share very low-volume data — soil pH, moisture level, gas level — and a sub-1 GHz frequency can cover the whole perimeter on very little power.
Different regions have different bands available, which means either different products or multiband antennas if you want to sell in both the USA and Europe.
On standards: Wi-Fi keeps moving — 802.11ac gave way to ax and beyond — while IEEE 802.15.4 has held its ground as the basis for low-rate IoT networking. There is always the chance that if you wait for the next great thing, someone else gets there first.
Creating a power-efficient system
Batteries in these systems are expected to last up to twenty years without much manual intervention. The uniqueness of IoT design is the ability to sleep when not in use. A scheme where the transceiver wakes only when it is due to transmit, then goes straight back to sleep — leaving the hardware asleep for the vast majority of the time — is the best way to conserve energy.
IoT systems consume power in two modes: dynamic, when the hardware is active, and static, when it is asleep or in standby. Both need to be kept in check, for the MCU and the transceiver alike. A 32-bit MCU can transmit data faster, so its dynamic consumption can be lower overall, and FPU support enhances that further.
If your device needs recharging, that needs considering too. If you have a hundred devices that all need charging at the same time, a hundred plug-top chargers with a hundred micro-USB leads is probably not the right answer.
Software for security
Security is essential to ensure no part of the system — hardware, software or network gateway — is compromised.
There are two main elements: checking the authenticity of the devices talking to each other, and encrypting the data both in motion and at rest. Hiding data in motion with advanced encryption schemes means it cannot be breached while crossing the network, and the data itself should be tested at the application layer to ensure it is clean. Authentication — passwords, biometrics — provides secured access to the components and the data.