With TTN V3, much longer delay until EV_TXCOMPLETE given

[pomplesiegel]

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

• Issue persists whether or not we enabled ADR or Linkcheck
• Same exact gateway in both situations (Dragino LG308)
• I didn't see anything that jumped out at me in the TTN logs, for either the device or gateway

Environment

• LMIC = v.3.3
• Arduino IDE 1.8.13
• TTN v3 (community hosted) - North America
• US915
• Adafruit Feather M0 LORA

Thank you all very much!

[terrillmoore]

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]

@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]

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".

[pomplesiegel]

Understood. I think the better option is for TTN v3 to allow the RX1 window to be configurable, which I believe they could? I have asked the question here: https://www.thethingsnetwork.org/forum/t/rx1-delay-setting-in-v3-console/43749/6

[terrillmoore]

BTW: you ought to be able to do better with the SAMD21G18 by looking more closely at which peripherals are being clocked. We used the M0 LoRa a lot, and although we could never get down to 10 uA in sleep -- great work there -- , we were seeing only 9 or 10 mA in run. I suspect something is running in the CPU that could be turned off. Just doing a __WFE() or __WFI() to wait for the next systick would probably make a big difference.

[pomplesiegel]

Got it, thank you!