4 ms·

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"

by 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.
        taeric 3y ago
        I'm assuming you have to inspect the signal to confirm the opening frame of data. Mainly to guard against clock drift. But, I'm also assuming that the person that talked of waking and sending data was not doing so as often as you would in this scheme. Which is the thrust of my assertion. Granted, I'd assume waking every 25ish seconds is probably fine? My gut was more that the person seeing bad battery life on receiving data was polling in the sub second timeframe. But was waking to send data in the seconds time timeframe. If both are done in the 25ish seconds timeframe, I'd have expected them to both take roughly the same power. Transmitting more if you are having to send distances?
        FirmwareBurner 3y ago
        >I'm assuming you have to inspect the signal to confirm the opening frame of data. There's not need for manual inspection. The analog receiver front ends of modern 2.4GHz microcontrollers of past ~15 years are smart enough that they have programable logic that can handle low-level packet inspection of the RF preamble and sync word to check if they're the ones being addressed, after which that will trigger full CPU wakeup where your code can start execution and process the message payload. Check out this old application note from TI/ChipCon: https://www.ti.com/lit/ug/swru237/swru237.pdf https://www.ti.com/lit/ug/swru237/swru237.pdf
        taeric 3y ago

by taeric 3y ago

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.
      - taeric 3y ago
        I'm assuming you have to inspect the signal to confirm the opening frame of data. Mainly to guard against clock drift. But, I'm also assuming that the person that talked of waking and sending data was not doing so as often as you would in this scheme. Which is the thrust of my assertion. Granted, I'd assume waking every 25ish seconds is probably fine? My gut was more that the person seeing bad battery life on receiving data was polling in the sub second timeframe. But was waking to send data in the seconds time timeframe. If both are done in the 25ish seconds timeframe, I'd have expected them to both take roughly the same power. Transmitting more if you are having to send distances?
        FirmwareBurner 3y ago
        >I'm assuming you have to inspect the signal to confirm the opening frame of data. There's not need for manual inspection. The analog receiver front ends of modern 2.4GHz microcontrollers of past ~15 years are smart enough that they have programable logic that can handle low-level packet inspection of the RF preamble and sync word to check if they're the ones being addressed, after which that will trigger full CPU wakeup where your code can start execution and process the message payload. Check out this old application note from TI/ChipCon: https://www.ti.com/lit/ug/swru237/swru237.pdf https://www.ti.com/lit/ug/swru237/swru237.pdf
        taeric 3y ago