To recharge or not to recharge: a battery of IoT questions
To recharge or not to recharge: a battery of IoT questions
Well, we technologists pretty much have that Internets thing solved. That series of tubes works pretty well. So well in fact that the carriers are busying themselves trying to bring Gigabit to everybody, though nobody really knows what they’re going to do with it (but we all want to be in one of those special cities). I think we got bored. And you know what happens when a bunch of technologists gets bored, we look for another hard problem to solve.
Enter IoT, the Internet of Things. We realized that the Internet, with all of its virtual technology and its climate-controlled data centers, still hadn’t conquered what really matters to all of us – the world we interact with every day – the real world. Now, there’s a set of challenges that’ll keep us technologists engaged for at least another decade.
I suggest the primary real-world challenge with the Internet of Things isn’t rooted in inter-networking at all, but with how powering the Things affects inter-networking and software programming, specifically in wireless situations.
What do batteries have to do with IoT?
We see powering in the world of Consumer IoT often in the form of rechargeable batteries. The iPhone charges for a few hours a day and is able to communicate via TCP/IP protocols over Cellular and Wi-Fi. That doesn’t seem to have changed the networking or software programming approaches too drastically. The Fitbit charges for a few minutes a day and communicates via Bluetooth with another mobile device. There we see a more drastic impact on the networking and software programming models.
Daniel Barnes, Director of Product Management, Synapse
But what if I told you the battery had to last for one month without recharge or replacement? How about six months, two years, five years? Well, that’s insane, who would demand a wearable that lasted that long without a recharge?
Consider these very real Industrial IoT applications: monitoring field and pest conditions in almond orchards, monitoring cows for sickness, a factory air compressor retrofit for predictive maintenance, over-the-top services such as crane monitoring, motor performance monitoring, or fire extinguisher monitoring. In each of these cases, the Thing is placed into the environment with the expectation of lasting longer than six months (some cases as long as five years) without service or connected power.
As an aside, the over-the-top services as a business model is quite interesting. These are traditional product companies that make cranes, motors, fire extinguishers, etc. They have decided to make their products smart and connected to gather additional service revenue or to develop closer relationships with their customers. But they want to continue installing their products without interfering with the existing infrastructure. This alone represents a whole category of Things in the Industrial arena that may need to operate with long battery life.
How do you make a battery last that long?
You buy a REALLY big battery.
That certainly is one way, but often not very practical nor is it cost effective. A more engineered approach boils down to three things:
1) Use a low-power processor that has advanced sleep controls.
2) Use a low-power RF technology that allows precise control of TX/RX utilization time.
3) Control the power utilization of sensor and actuator peripherals.
In other words, wake up long enough to read a sensor and send the information and then shut everything back down in as low-power mode as possible. It’s all about managing the power duty-cycle.
What are the tradeoffs?
Of course, the number one rule of engineering is that to get something you want, you have to give something else up. There are always tradeoffs – in this case trading traditional networking and software programming for a long battery life.
Wi-Fi and TCP/IP don’t really help you control the power duty-cycle very well. Wi-Fi takes RF time to lock onto an Access Point. TCP requires a connection handshake before sending data and the overhead of the protocol to make it reliable. All of this costs valuable RF and processor time in the power duty-cycle. It’s time not spent on transmitting data, but on establishing the connection and maintaining reliability. You might consider UDP as an alternative, but it still has excessive overhead and the reliability is now left up to a higher layer where you often lose even more efficiency and introduce more complexity into your application.
Some alternative networking approaches to shortening the “ON” duty-cycle include:
- Fire and forget (if reliability isn’t a big issue, it’s the lowest power option)
- Time synchronized transmit (to avoid collisions)
- A backbone of powered repeaters to relay messages (reliability between battery-operated nodes and powered nodes takes less time)
These and others are all non-traditional networking schemes, meaning that others schemes have to be employed to ensure reliability. The good news is that there are emerging standards at the physical, link and network layers for managing these things, but they can’t be expected to work the same way as the networking that we’ve come to appreciate. There will be additional tools and algorithms necessary to collect data reliably.
Just to add one more level of complexity, traditional OSs don’t support the rapid sleep/wake cycles necessary to conserve this type of power, nor will they work with the limited RAM & flash typical to these constrained processors. The decision-making logic on the Thing will be embedded software and largely event-driven: a programming paradigm traditional IT developers are not familiar with.
So the bottom line here is that Industrial IoT will require a significant portion of Things to have batteries and these batteries will need to last for such a long time that reliable networking and programming will require rare expertise.
The problem isn’t really how to power an IoT Things Platform, but that an IoT Things Platform ought to make it easy to achieve long battery life. Make sense?
This article was produced in partnership with Synapse Wireless
The post To recharge or not to recharge: a battery of IoT questions appeared first on ReadWrite.
(40)
