Electronics > RF, Microwave, Ham Radio

Lowest energy wireless protocol for specific wireless sensor node

(1/3) > >>

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. 

Navigation

[0] Message Index

[#] Next page