2 ms·

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?

by taeric 3y ago

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
        Sorry, I didn't mean you had to do that in your code, necessarily. I meant that the receiving hardware has to do it. That said, the main contention was on timelines, still. My assumption being if you use the same sleep/active cycles between transmit or receive, then you should see similar battery life? Is that not the case?
        FirmwareBurner 3y ago
        >My assumption being if you use the same sleep/active cycles between transmit or receive, then you should see similar battery life? Is that not the case? I don't get your question. Use the same sleep/active cycles for what? If you're asleep you use almost no power. If you do CPU processing in that time you will sue more power. But do CPU processing for what? Most battery powered IOT widgets don't usually do any CPU heavy application, they just collect regular sensor data and forward it to a base station which forwards it to some cloud service. And any way, any modern ARM core consumes much less power in operation than a RF recover or transmitter which are the big gas guzzlers in this case.
        taeric 3y ago
        The opening assertion that got me in this thread was that sending data was cheaper than receiving data. Opening post said that they were surprised to find that is the case in the work they did. To that end, I was asserting that the problem the poster was seeing was that they were too aggressive in how they "listen" for data.

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?

by 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
        Sorry, I didn't mean you had to do that in your code, necessarily. I meant that the receiving hardware has to do it. That said, the main contention was on timelines, still. My assumption being if you use the same sleep/active cycles between transmit or receive, then you should see similar battery life? Is that not the case?
        FirmwareBurner 3y ago
        >My assumption being if you use the same sleep/active cycles between transmit or receive, then you should see similar battery life? Is that not the case? I don't get your question. Use the same sleep/active cycles for what? If you're asleep you use almost no power. If you do CPU processing in that time you will sue more power. But do CPU processing for what? Most battery powered IOT widgets don't usually do any CPU heavy application, they just collect regular sensor data and forward it to a base station which forwards it to some cloud service. And any way, any modern ARM core consumes much less power in operation than a RF recover or transmitter which are the big gas guzzlers in this case.
        taeric 3y ago
        The opening assertion that got me in this thread was that sending data was cheaper than receiving data. Opening post said that they were surprised to find that is the case in the work they did. To that end, I was asserting that the problem the poster was seeing was that they were too aggressive in how they "listen" for data.