search

mcci-catena / arduino-lmic

LoraWAN-MAC-in-C library, adapted to run under the Arduino environment
https://forum.mcci.io/c/device-software/arduino-lmic/
MIT License
633 stars 209 forks source link

With TTN V3, much longer delay until EV_TXCOMPLETE given #698

Closed pomplesiegel closed 3 years ago

pomplesiegel commented 3 years ago

Hello Everyone,

Thank you for your hard work. LMIC is amazing.

I have noticed an issue, which may be LMIC-related or more of an integration issue with TTN V3. Or perhaps it's literally just a TTN V3 thing, but I didn't see anything on the forums.

I'm seeing that for every uplink, there is a MUCH longer delay until we receive the EV_TXCOMPLETE when using TTN v3 vs TTN v2. See logs below (each '.' is a second)

Total measurement duration millis: 4418
4967633
: 
EV_TXSTART
.
.
.
.
.
.
.
5352567
: 
EV_TXCOMPLETE (includes waiting for RX windows)
Duration we've been awake since last sleep (ms): 11580

This is what i'm seeing upon every uplink: about 7 seconds (exclude our measurement time from 11.58s) until the EV_TXCOMPLETE is given. In TTN v2, this usually happens in about 2 seconds, so this is a significantly more battery usage.

Notes

Environment

Thank you all very much!

terrillmoore commented 3 years ago

Not a bug.... or an illusion...

This is because TTN v3 sends a downlink that changes the RX window to 5 seconds. If you chase this, you'll find it was announced as part of The Things Conference TTN v3 rollout, I believe.

Yeah, it's a a real thing, and there's nothing we can do about it apart from possibly coming up with a way to sleep in between. If you're not transmitting very often, it's not generally a huge power difference; the RX is off, and you're not transmitting; these are number 2 and number 1 power draws, respectively, in my testing.

Best regards, --Terry

pomplesiegel commented 3 years ago

@terrillmoore, wow that is crazy!

Even though it's potentially not a game-changing difference in power, it definitely would be noticeable for devices that are anywhere 'on the edge' with their current battery solution. When our micro (ATSAMD21G18) is on and not sleeping, we're consuming about 15mA from the battery, so that's about 0.15 * 5 = .075 coulombs per transmit that were not previously budgeted for. When sleeping we are consuming about 10uA, so the difference is quite notable with this change.

Any ideas what it would be like to try to sleep during this period? I imagine other folks are running into this as well.

And of course - feel free to change this from a bug to whatever you think is appropriate. Thank you!

terrillmoore commented 3 years ago

We would have to add an API that lets you find out how long you can safely sleep. You can sort of do that now: ask "can I sleep for one second", then do so if you can; 5 micro bursts of wake up are probably acceptable. But you have to make sure millis() stay in sync with real time (we can tolerate errors in micros over the long pause of 5 seconds, but millis() need to stay in sync).

I don't know if I have a "feature" tag... what I'll do is make this a "discussion item".