4 ms·

One thing that I found counter-intuitive is that building a device that periodically receives data wirelessly is generally more expensive on the battery than a

One thing that I found counter-intuitive is that building a device that periodically receives data wirelessly is generally more expensive on the battery than a device which periodically transmits. Naively, I assumed that it must take more power to transmit than to receive, which is true on an instantaneous basis, but false on an average basis. A device that wakes up every so often, transmits, then goes to sleep can use very little average power as compared to a device that must constantly have the receiver powered up to listen.

FirmwareBurner 3y ago
>compared to a device that must constantly have the receiver powered up to listen But there's no need for the receiver to constantly stay awake to listen or poll the transmitter like in wired network systems. Low power wireless protocols use time slots since forever, where receivers wake up only in their dedicated time slots to check if any messages are addressed to them, and if so, then they wake up the entire CPU block and start processing the payload and reply to the message, but if not, then they put the receiver back to sleep till their next time slot. Simple and very energy efficient. Therefore receivers are more efficient than transmitters as transmitters are constantly operating as beacons for every time slot which is what you want when the base station can be powered on AC, while the IoT receivers are usually battery powered and need to last for years. The only tricky part is building a self compensation mechanism in firmware for the receiver wake-up time jitter as all receivers inevitably start to drift in time as per the drift of their oscillators, including the transmitter which also drifts, especially when using low-cost oscillators with horrible drift.
- eggfriedrice 3y ago
  I do a lot with LoRaWAN, and I like the simplicity of its approach for class A devices, which is to wake up and transmit and then listen for a reply in two defined time windows. These are shortly after the transmission, so clock drift is less of an issue with cheap oscillators.
- petsfed 3y ago
  I think this understates the complexity of getting the time slots right, since you have to factor in drift from the firmware, drift from the hardware (which varies based on temperature), and also the propagation time of the radio signals. Essentially, you want the timeslot to be much larger than the sum of all the jitters, while also making sure there are enough timeslots per system cycle to account for all of the devices, at the data rate you want. Not to say its impossible to solve (although infinite precision synchronicity in distributed systems is impossible to solve), just that the more devices you throw at the system, the trickier it gets, in a way that does not scale linearly with the system size.
  - FirmwareBurner 3y ago
    >I think this understates the complexity of getting the time slots right It's tricky, but not impossible to solve by any half decent firmware engineer with low level understanding and some battle scars in the industry. >Essentially, you want the timeslot to be much larger than the sum of all the jitters Not really. Drift is inevitable but it's not so bad that you get huge fluctuations so quickly that you need to take such wide margins. Just sync all your receivers to the drift of the transmitter every few minutes/hours or so and you'll be fine. Depends on environmental conditions of course which you should know up front when designing you product. >just that the more devices you throw at the system, the trickier it gets, in a way that does not scale linearly with the system size Not really, you just sync all receivers to the drift of the base station via the same drift compensation algo. If it works on one device it will work the same on all. Of course you will reach a number of devices limit based on the max time slots you can have which is based on the amount of bandwidth you have and the access time you want for rach device slot. We got a couple of thousand device on one base station lasting ~1-2 years on one button cell so it was good enough.
- marcosdumay 3y ago
  In theory, you don't need the time slots. If you make the addressing in AM, you can use just the radio waves to power a decider that can wake-up your device, and then you do the actual communication in FM. But the wave can't be too faint, so I guess you co always need a bit more power at one side.
- jsmith45 3y ago
  I'm not sure if a sensible timeslot based system could get down as low as the battery usage that something like zigbee battery powered sensors can get. Those are transmitters running on battery, usually with the radio fully powered down, only powering them up to transmit if they need to report a changed value, or to report in at least once a day, so the hub knows they haven't died. Something like a magnetic Reed switch door/winodw sensor would wake up the mcu via a level sensitive interrupt, so obviously the "sensor" portion for some sensor types can have negligible power draw. How could any battery powered receiver possibly get power usage that low? Like even timeslots of only once a minute would seem likely to use considerably more power, and is likely too much latency for many purposes. But surely more frequent timeslots would only increase power drain?
taeric 3y ago
I'd assume the problem with receiving data on a periodic basis is that you still have to establish the link with the towers. Such that you are always "polling" from the perspective of the device. That is, treat the times that you wake up to receive information the same way as the ones where you wake up to send, and I'd expect them to be roughly the same? That not the case?
- sokoloff 3y ago
  There are many connectionless RF protocols. (Don't think only of WiFi or cell/LTE.)
  - taeric 3y ago
    Fair. You'd still have to synchronize the signal to receive data, though? As such, I don't think that changes too much of my question?
    - FirmwareBurner 3y ago
      For battery powered IoT devices, time-slot protocols are the answer. See my comment above.
      - taeric 3y ago
        Right, I'm assuming the device still has to look at and "find" the data in the received signal? As such, if you are just "spraying the data out there," you can do that with less thought and just transmit. But the point was still that, if you are checking your time-slot at a greater rate than you would have been waking up to send data, then it makes sense that it would take more battery power. In essence, you are still "polling" based on your timeslot and not transmitting data at a presumably lower pace. Is that not close?
        FirmwareBurner 3y ago
        There's no need to "find" the data when the receiving powered IoT devices are in perfect sync with the transmitting base station, because then they can be addressed directly. Let's say, for example, that you have 256 time slots of 0.1 seconds length, with 256 devices present in each time slot. Each of those 256 IoT devices wake up simultaneously in their respective time slot in sync with the base station beacon and listen if the base station is trying to address one of them specifically, then the rest who aren't being addressed go back to sleep.
Gibbon1 3y ago
Think in terms of energy per symbol and it makes sense. When waiting in rcv mode you're paying energy for zero symbols. The other is transmitting short packets at high power/data rate is a win vs low power low data rate long packets because your energy per symbol is lower with the former. And people that show know better seem to make that mistake a lot.
tesseract 3y ago
> Naively, I assumed that it must take more power to transmit than to receive, which is true on an instantaneous basis, but false on an average basis. Even that is not necessarily always the case in low-power systems, since often receive amplifiers need to be run at a fairly high current to achieve a low noise floor, and power saving tricks like envelope tracking power supplies are harder to implement on the receive side. For example, I've seen several Bluetooth LE radios where the instantaneous supply current is higher during receive than during transmit.

FirmwareBurner 3y ago

>compared to a device that must constantly have the receiver powered up to listen But there's no need for the receiver to constantly stay awake to listen or poll the transmitter like in wired network systems. Low power wireless protocols use time slots since forever, where receivers wake up only in their dedicated time slots to check if any messages are addressed to them, and if so, then they wake up the entire CPU block and start processing the payload and reply to the message, but if not, then they put the receiver back to sleep till their next time slot. Simple and very energy efficient. Therefore receivers are more efficient than transmitters as transmitters are constantly operating as beacons for every time slot which is what you want when the base station can be powered on AC, while the IoT receivers are usually battery powered and need to last for years. The only tricky part is building a self compensation mechanism in firmware for the receiver wake-up time jitter as all receivers inevitably start to drift in time as per the drift of their oscillators, including the transmitter which also drifts, especially when using low-cost oscillators with horrible drift.

eggfriedrice 3y ago
I do a lot with LoRaWAN, and I like the simplicity of its approach for class A devices, which is to wake up and transmit and then listen for a reply in two defined time windows. These are shortly after the transmission, so clock drift is less of an issue with cheap oscillators.
petsfed 3y ago
I think this understates the complexity of getting the time slots right, since you have to factor in drift from the firmware, drift from the hardware (which varies based on temperature), and also the propagation time of the radio signals. Essentially, you want the timeslot to be much larger than the sum of all the jitters, while also making sure there are enough timeslots per system cycle to account for all of the devices, at the data rate you want. Not to say its impossible to solve (although infinite precision synchronicity in distributed systems is impossible to solve), just that the more devices you throw at the system, the trickier it gets, in a way that does not scale linearly with the system size.
- FirmwareBurner 3y ago
  >I think this understates the complexity of getting the time slots right It's tricky, but not impossible to solve by any half decent firmware engineer with low level understanding and some battle scars in the industry. >Essentially, you want the timeslot to be much larger than the sum of all the jitters Not really. Drift is inevitable but it's not so bad that you get huge fluctuations so quickly that you need to take such wide margins. Just sync all your receivers to the drift of the transmitter every few minutes/hours or so and you'll be fine. Depends on environmental conditions of course which you should know up front when designing you product. >just that the more devices you throw at the system, the trickier it gets, in a way that does not scale linearly with the system size Not really, you just sync all receivers to the drift of the base station via the same drift compensation algo. If it works on one device it will work the same on all. Of course you will reach a number of devices limit based on the max time slots you can have which is based on the amount of bandwidth you have and the access time you want for rach device slot. We got a couple of thousand device on one base station lasting ~1-2 years on one button cell so it was good enough.
marcosdumay 3y ago
In theory, you don't need the time slots. If you make the addressing in AM, you can use just the radio waves to power a decider that can wake-up your device, and then you do the actual communication in FM. But the wave can't be too faint, so I guess you co always need a bit more power at one side.
jsmith45 3y ago
I'm not sure if a sensible timeslot based system could get down as low as the battery usage that something like zigbee battery powered sensors can get. Those are transmitters running on battery, usually with the radio fully powered down, only powering them up to transmit if they need to report a changed value, or to report in at least once a day, so the hub knows they haven't died. Something like a magnetic Reed switch door/winodw sensor would wake up the mcu via a level sensitive interrupt, so obviously the "sensor" portion for some sensor types can have negligible power draw. How could any battery powered receiver possibly get power usage that low? Like even timeslots of only once a minute would seem likely to use considerably more power, and is likely too much latency for many purposes. But surely more frequent timeslots would only increase power drain?

taeric 3y ago

I'd assume the problem with receiving data on a periodic basis is that you still have to establish the link with the towers. Such that you are always "polling" from the perspective of the device. That is, treat the times that you wake up to receive information the same way as the ones where you wake up to send, and I'd expect them to be roughly the same? That not the case?

sokoloff 3y ago
There are many connectionless RF protocols. (Don't think only of WiFi or cell/LTE.)
- taeric 3y ago
  Fair. You'd still have to synchronize the signal to receive data, though? As such, I don't think that changes too much of my question?
  - FirmwareBurner 3y ago
    For battery powered IoT devices, time-slot protocols are the answer. See my comment above.
    - taeric 3y ago
      Right, I'm assuming the device still has to look at and "find" the data in the received signal? As such, if you are just "spraying the data out there," you can do that with less thought and just transmit. But the point was still that, if you are checking your time-slot at a greater rate than you would have been waking up to send data, then it makes sense that it would take more battery power. In essence, you are still "polling" based on your timeslot and not transmitting data at a presumably lower pace. Is that not close?
      - FirmwareBurner 3y ago
        There's no need to "find" the data when the receiving powered IoT devices are in perfect sync with the transmitting base station, because then they can be addressed directly. Let's say, for example, that you have 256 time slots of 0.1 seconds length, with 256 devices present in each time slot. Each of those 256 IoT devices wake up simultaneously in their respective time slot in sync with the base station beacon and listen if the base station is trying to address one of them specifically, then the rest who aren't being addressed go back to sleep.

Gibbon1 3y ago

Think in terms of energy per symbol and it makes sense. When waiting in rcv mode you're paying energy for zero symbols. The other is transmitting short packets at high power/data rate is a win vs low power low data rate long packets because your energy per symbol is lower with the former. And people that show know better seem to make that mistake a lot.

tesseract 3y ago

> Naively, I assumed that it must take more power to transmit than to receive, which is true on an instantaneous basis, but false on an average basis. Even that is not necessarily always the case in low-power systems, since often receive amplifiers need to be run at a fairly high current to achieve a low noise floor, and power saving tricks like envelope tracking power supplies are harder to implement on the receive side. For example, I've seen several Bluetooth LE radios where the instantaneous supply current is higher during receive than during transmit.