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.
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?
>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.
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?
> We appear to be in fairly solid agreement on why a receiving device uses more battery. Has nothing to do with one being more battery per byte sent/received. Has everything to do with whiffing on many more receives than you do on sends. And is in complete control of the person building/operating the device.
Ah I misunderstood your previous comment; yes we agree on all of this.
What you are proposing only works if you have a device that only receives replies. That is not always the case.
Think of it this way: the postal carrier arrives at your house at whatever schedule the post office decides. You don't have control over that. The only way to get your mail is to continuously check your mailbox to see if anything new has arrived. It only takes 3 minutes to check your mailbox. For the sake of this analogy assume if the carrier arrives the next day and finds something in your mailbox they return it to the sender.
Conversely sending mail is different. If you haven't written a letter or packed a box there is by your choice nothing to do. That situation can persist for days, weeks, months, or even years if you have nothing to send outbound. When you have something to send it takes you over an hour to drive to the post office, wait in line, mail the package, and return... but there are no consequences if you don't go to the post office other than delaying your outbound mail.
Yes sending a package is expensive but it doesn't happen often and you can decide to wait until multiple packages have piled up to be sent making your trip more efficient.
Conversely you're paying 3 minutes to check your mailbox every day whether anyone sent you mail or not. If you don't pay the 3 minute price critical mail may be lost forever.
If you send a package once per month that cost 60 minutes but checking the mail an average of 27 days per month costs 81 minutes. Receiving mail cost you more time overall despite each receive attempt being 20x cheaper than each send attempt.
If I was finding that I am spending too much energy checking my mail for a letter, I don't presume that it takes me more energy to check mail than it does for me to send it. Rather, I presume that I'm choosing to go check my mailbox too often. That is literally all I am saying here.
Your logic on why that is, is effectively my assertion on why someone would find that transmitting devices are easier on the battery. People build the device thinking "the message could come at any time, so we always have to check." Stop doing that, and you go easier on the battery.
That is all to say, yes? We appear to be in fairly solid agreement on why a receiving device uses more battery. Has nothing to do with one being more battery per byte sent/received. Has everything to do with whiffing on many more receives than you do on sends. And is in complete control of the person building/operating the device.
>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.
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.
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.