Custom IoT design — the why and how

Ray Keefe, Managing Director of Successful Endeavours, examines the issue of when and how to go for a custom IoT solution. Successful Endeavours focuses on the design of smart electronics products that are made in Australia.

IoT has been growing in hype and volume since 2016 and is seen as a core enabling technology for nearly all industry sectors, some examples being:

• Personal health
• Industry 4.0 (a whole topic on its own)
• Transport and logistics
• Smart cities, homes, buildings
• Energy, water and waste metering and monitoring
   

And there are catalogues out there full of devices. So surely you can just get, off the shelf, anything you want in sensors, edge computing, gateways and web services?

Turns out it isn’t as simple as that. There are a lot of needs (use cases is another term for this) that can’t be met by any product in the catalogue. The reasons vary but some examples are:

• Has to be battery operated but the power consumption is too high
• Needs power but it costs too much to run power or the solar panel would be huge
• Locked in web services that you can’t integrate into your system or which cost too much
• Using cellular communications but the SIM card costs are too expensive at one per sensor node
• Can’t be customised, so they nearly do what you want but aren’t close enough
• Can’t be supported in the field through device management or over-the-air firmware upgrades
   

At this point you either compromise on what you can achieve, don’t go ahead at all or you have the option to go for a custom solution. This article is following this last path and exploring what that can look like.

Now you are considering a custom IoT solution, a whole new set of considerations arise. For the rest of the article, I will focus on a specific use case that is very difficult and give two examples of products we developed:

• Battery operated and either tiny solar panel or primary cell (non-rechargeable battery)
• Multiple and complex sensor readings
• Web service providing device management, firmware upgrade in the field and API integration into other systems

arcHUB

The first example is a smart cities sensor device called the arcHUB (Figure 1). This is a compact solar-powered device that measures PM2.5 (smoke) and PM10 (dust) particulate levels and optionally you can add wind speed, temperature, pressure, humidity and ambient light levels to get a complete air quality and micro-climate sensor all in one. It takes readings at a fixed time interval and uploads them using cellular connectivity.

Figure 1.

If you are familiar with particulate sensors, you will be aware that they are very power hungry, typically 100 mA at a 5 VDC level of power consumption. So clearly we are turning lots of things off at every chance we get. Let’s look at some of the design decisions we made in order for this to work:

• CAT-M1 for cellular communications — lowest power option even compared to NB-IoT
• ATSAML21 MCU — 35 µA/MIP running, 1.7 µA in sleepwalking mode
• Buck converter instead of LDO — BQ25570 has 93% efficiency at very light load
• MPPT solar charging — BQ25570 has MPPT boost converter so uses <2 V solar cells
• High side switch for all sensors plus modem, so quiescent = 0 µA when shut down
• Optimised sampling interval of 15 min and upload every hour rather than every reading
• Web service is API based — passed on to customers so they get the data into their existing systems in an agreed format
   

The result is a system that can run from 0.5 W of solar cells, taking readings every 15 min, with hourly upload as a self-contained system. Sleepwalking mode means that peripherals such as timers can run while the main processor is asleep, providing a power saving as shown in Figure 2.

Figure 2.

You can read more about the arcHUB and what it does at https://blog.successful.com.au/archub-smart-cities-case-study/.

The arcHUB was a finalist for the 2018 IoT Innovation Award for Australia and the Agilent Award for Innovation in Analytical Science 2017, and was listed in the Anthill Smart 100 2018.

Waterlink SmartMESH

This is a primary cell-powered device that is used for water metering of up to six pulse probe output water meters. It is an indoor device and uses the Wirepas Massive mesh networking protocol to allow the devices to create their own network and then use a cellular gateway to communicate to a web service. Sounds simple enough?

Let’s look at the complications:

• Pulse counting models with one, two, four or six inputs
• Primary cell battery operated with 10+ year battery life
• Water volume, minimum flow and maximum flow in each reporting interval
• Default hourly reporting
• Plug pack powered gateway, so power conservation was not required there
   

If we use a 19 A h Li/SOCl₂ primary cell then that has a very high series resistance, so that means we have to add a supercapacitor to support it, but this has to be a low-leakage supercapacitor. So to run for 10 years we need an average power consumption of 19 / (10 * 365.25 * 24) = 200 µA rounded down, and of course you never get the whole of the battery charge as the terminal voltage eventually falls too far. And we are mesh networking with the radio running Wirepas Massive all the time.

This was achieved with the following selections:

• ATSAML21 MCU — 35 µA/MIP running, 1.7 µA in sleepwalking mode
• Buck converter instead of LDO — TPS62740 has 90% efficiency at very light load
• Wirepas Massive mesh network operating in low-power/high-latency mode
• DGH105Q5R5 supercapacitor with µA level leakage
• u-blox NINA-B112 2.4 GHz radio module which runs the protocol stack and the entire application
   

The light load efficient buck converter makes a huge difference here, as shown in Figure 3, and the PCB looks pretty sparse even for the six-channel version (Figure 4).

Figure 3.

Figure 4.

The product met the power consumption requirements and was awarded the Environmental Solution of the Year at the 2020 Endeavour Awards run by Manufacturers Monthly.

The web services also publish to other services to support integration into existing systems, as well as providing their own dashboard and water usage analytics.

You can read more about this at https://blog.successful.com.au/environmental-solution-of-the-year/.

Summary

You have seen two examples of custom IoT development and the hardware design side of the equation. There is also both embedded software written in C and web services written in Python to support all this. And best of all, from my perspective, all made in Australia.

Top image credit: ©stock.adobe.com/au/Blue Planet Studio