Lowest energy wireless protocol for specific wireless sensor node

[JacobJ]

There are so many options for low-power wireless communication these days. BLE is everywhere, and many other manufacturers try to push their protocols as well. LoRa, Dust, Zigbee, Thread, Sigfox, etc., the list is long. What I think is lacking is a good way to compare the total energy consumption. Data rate and transmit power are easy, but there are so many other variables that make it difficult to compare.

What is interesting is the lowest possible energy consumption for a transmission period, and thereby the longest possible lifespan, but obviously also for the sensor node to function in the environment it is designed for.

This question would be much too broad without some constraints, so these are listed below.

Q: Which is the most low energy wireless protocol?

Constraints:
•   Industrial enviroment (WiFi present, but not crowded 2.4 GHz like residential areas)
•   Data packages of 10 kB (kilobytes)
•   Range up to 150 m inside steel structure with some steel obstacles
•   Transmission period 1/week
•   Network of potentially 1000 nodes
•   Highly predictable lifespan if supplied from primary battery
•   It is allowed for a power manager to disable the voltage supply to the wireless subsystem, though some protocols are designed to be always powered and have a low power keep-alive communication going (Dust comes to mind)

[janekm]

Your requirements are almost unique compared to typical sensor network / IoT applications, in particular the need for sending 10kB in a single transmission once per week. "IoT" protocols like the ones you mentioned (especially LoRa and Sigfox) are not designed for such large transmissions (they're designed for sending a few bytes of data, not kBs).

If it wasn't for the 150m range requirement (with steel present) I would have just recommended wifi, if you just need to transmit once per week then you'll get great battery life. Zigbee won't really cut it for 150m range in that environment.

You didn't mention your reliability requirements... does it matter if the transmission isn't received? Though realistically a 10kB transmission will need some flow control & retransmission anyway.

You might have some luck with a custom protocol based around something like the TI CC1125: (your range is obviously going to be severely degraded compared to this kind of ideal case scenario)

With 1000 nodes you need to be concerned about collisions, the easiest would be to allocate fixed time slots to each node and implement a simple time synchronisation for the nodes.

Also you didn't mention your network topology, I assumed star since otherwise turning the radio off would be an issue...

[JacobJ]

That's a good point about the intended use of various protocols. What I'd really like to see is a series of benchmarks like what we see for graphics cards and the like, subjecting various protocols to a series of use cases for easy comparison. I'm just hoping I won't have to do it all myself with the number of competing protocols available Though I do plan to pick a handful of the most promising ones and run field tests.

The transmissions must go through, and retransmissions will be a drain on the battery, but there will of course be some retransmissions. The roboustness of the transmission is also a factor in the total energy consumption, so everything really depends on the big picture - the total power used per cycle. I think a finished solution where flow control etc. is handled by a readymade module would be a big benefit in terms of low-energy, as higher integration almost always has that effect in my experience.

Time slots, yes, that was my thought too.

Star would probably be preferable to mesh in terms of more even load on the nodes, and thereby more predictable battery life. Dust, which is mesh, does claim to be very low-power despite constant network self maintenance going on, with the advantage of everything already being set up and ready to go when a node wants to transmit, ie. no long, energy draining startup sequence.

CC1125 is certainly a candidate. Have you any experience with that one?

I pity the guy in the video who forgot his sunscreen though

[janekm]

The thing is that your scenario is really different from typical "IoT" scenarios (where you're usually talking sending a few bytes of actual data (temperature, energy consumption, location, ...) anywhere between every few seconds to several times per day, so any existing benchmark (the ones I've seen have been to try and pitch one protocol over another, so not perhaps that useful anyway) so would not be applicable to your scenario.

If you're only transmitting once per week then any kind of mesh network is a disaster for the battery life of your nodes as they either need to be listening all the time (obviously very expensive!) or keep a tight time synchronisation for a common wakeup schedule so either way you're wasting a lot of energy to maintain the network. That's why I would suggest looking at a protocol that has sufficient range to cover your scenario without needing any relay nodes. If a single receiver doesn't cut it (perhaps you need to place some nodes in the shadow of some giant metal object) then I would look at multiple "base stations" next, much like for wifi (btw wifi may be a suitable protocol for your scenario, as the cost of association won't be too huge once a week with a decent amount of data to be sent).

I don't have personal experience with the CC1125 just suggested it as a thought experiment... a transceiver with a very high link budget like that can cope with a lot of troublesome environments.

[mikeselectricstuff]

The most critical part you've not specified is the receiver - will this be mains powered ? if so, then if you're only sending once a week, the power draw of the radio is pretty much irrelevant as it's a tiny duty cycle. It's all down to standby power ( your data collection).

A bigger issue is going to be peak power delivery capability over time - offhand I'd guess you'd be looking at somewhere in the tens of milliwatts tx power, and due to obstructions 900MHZ ( 868/915) is probably a good bet.

You need to take a long hard look at battery type, and what you may need to do to suppliment its current-delivery capability, e.g. supercaps. Note that some battery types suffer form passivation effects, i.e if you only draw a tiny current for a long period, their internal resistance increases so they struggle to deliver high currents when needed. I think Lithium Thionyl Chloride can suffer this - look at manufacturer datasheets. 

[JacobJ]

janejm,

Dust uses something like 5-10 uA IIRC to keep the network alive and healthy, and remember that the whole network could be switched off, or parts of it selectively, when not in use. Maybe the whole mesh network would only be powered an hour per week. So mesh isn't necessarily a huge battery drain, but it does make battery life somewhat unpredictable, since some nodes would take a higher load than others, even with the network trying to distribute load evenly. Mesh will also have some advantages, possibly resulting in lower total energy, and that's the kind of thing I'm trying to get suggestions for.

WiFi is an interesting idea. WiFi is already available in parts of the structure. I'm sure it would require multiple base stations to cover the entire area, all to be mains powered, and that would require extensive cabling, which I would like to avoid.

mikeselecticstuff,

Yes, the base station is mains powered with no special requirements.

Actually, since the radios can be powered down when not in use, I would say that the standby power could be the least important factor, if it turns out to be most advantageous to do (and it probably will I think). And regardless of how low energy the various solutions are, and how low my duty cycle is, it will always be a good thing to save money on a smaller battery by achieving the very lowest energy consumption possible. A possibility I haven't mentioned is also to run off vibration harvested energy. I didn't want to muddle the question with that, since the benefit of lower energy consumption is the same (lower cost), and the power delivery requirement challenges are similar, but low power is even more important for vibration harvested energy (cost of the harvester). I have examined that extensively.

The power vs. energy trade-off is a very good point, and I have been thinking about that myself. I have designed a combined battery/harvesting systems before, where I used supercaps for the harvesting, and where the primary battery used could handle the radio (Wireless M-Bus) current draw when running on battery. I think it was 40 mA. Power/current delivery shouldn't be a problem, but passivation might indeed. That will have to be analyzed by a battery manufacturer.

[mikeselectricstuff]

mikeselecticstuff,

Yes, the base station is mains powered with no special requirements.

Actually, since the radios can be powered down when not in use, I would say that the standby power could be the least important factor, if it turns out to be most advantageous to do (and it probably will I think).

Powering off the radio is a no-brainer. And probably worth external switching rather than using its own sleep mode. The standby/measurement power of your stuff will dominate, a lot of which will be the power needed to keep a wake-up timer running. You should easily ba able to get this down to well under 5uA, and maybe 1uA if you really try.

[JacobJ]

By powering off, I do mean removing power from the subciruits. Yes, sub-uA is achievable. I might use a Cortex-M0 for power management and power everything else off. I have that part well covered, and what concerns me is finding the lowest energy wireless solution.

[mikeselectricstuff]

By powering off, I do mean removing power from the subciruits. Yes, sub-uA is achievable. I might use a Cortex-M0 for power management and power everything else off. I have that part well covered, and what concerns me is finding the lowest energy wireless solution.

Like I said, the power for your wireless stuff is just not an issue  as you're transmitting so infrequently. The only issue is finding a long-life battery that can deliver enough current when you do decide to send data.

[JacobJ]

And like I said, I disagree, since a smaller energy requirement will mean a smaller battery or energy harvester, which in turn will mean a cheaper product.

But your point is noted.

[janekm]

I am showing my biases when it comes to mesh solutions... While Dust may advertise a 5-10uA current consumption to maintain the mesh (sounds optimistic but let's take their word for it); when it comes time to send your 10kB through the mesh things are going to start looking pretty ugly pretty quick... Each node has a certain set of time slots allocated to it for communication; It will have to request additional slots to send the sudden much higher amount of data, and the repeater node is going to be in a really rough spot with potentially several other nodes trying to push 10kB through it on top of what it's already trying to send itself. It's pretty much the opposite of a predictable power consumption scenario. Another question is what is the overhead of maintaining the network for 1000 nodes... Also, what if 500 of your nodes have to relay through a single battery-powered relay node?

Let's look at the most optimal (but unrealistic) case for the lowest possible power consumption at the battery-powered nodes:
Each node is using a very low power but high data rate radio (something like Nordic NRF52 in raw radio mode), resulting in a tiny cost in Joules per bit to transmit only the data, and the receiver acknowledges a set of n packets at a time (where n is chosen to optimise the ratio between repeated packets / acknowledgement packets), and each node has a separate large timeslot (could be 1 hour given your dutycycle!) to avoid collisions.

The problem is that a high data rate radio has a limited range, so you'll have to accept some reduction in data rate for a higher link budget, and the calculation here is entirely dependent on your environment for the installation (i.e., going from 2mbps to 1mbps roughly doubles the time the radio transmitter and receiver need to be powered on, at 7-100mA depending on radio)... The aim is to find the sweet spot where the cost per packet is balanced against the number of retransmissions to get each packet through. Protocols like LoRa or Sigfox achieve amazing link budgets, but at tiny data rates, and would likely be the wrong tradeoff in your scenario.

If you have the option to install extra base stations, or powered relays, you can reduce the energy consumption of your edge nodes by installing extra relay / base station nodes in spot with spotty reception. But the cost of that (in terms of installation cost) is likely to outweigh the cost of a slightly larger battery.

BTW you'll probably want to look at something like the Tadiran TRR batteries: http://www.tadiran.com/index.php/tadiran-rapid-response-trr-series though they're not exactly cheap. A pair of Energizer Lithium AAs should also give you a good 10 years or more life in the scenario you laid out:

Assuming 100kb/s data rate, 10kB could be transmitted in 0.8s, allowing for protocol overhead and retransmissions let's call it 3s. Assuming a 100mA power consumption of the radio (generous) that's an average of only 0.5uA if transmitting once per week. If that was all you were drawing then the self-discharge of any battery would dominate (though the pulse load would be problematic, obviously).

[janekm]

In other words, what mike said... With your duty cycle (assuming a sensible radio implementation, even with wifi) finding a good long-life power source is the main issue.

[JacobJ]

A Tadiran battery will handle the long-life without issue.

I have done the math, and the wireless transmission will take up around 90% of the total energy.

So I still think finding the absolutely most low-energy wireless solution is the key challenge.

I guess there was just not much input to be had for that, so I will do the tests.