just to be clear, i’m pretty new to the Library and i have no idea whats going on in the background for the most part. I was just wondering if it was possible to decouple the enqueueing of the DeviceTimeReq mac command from the actual receiving of the Time.
I have a setup in which a ESP32 (class a) goes into deepsleep most of the time. When the mcu wakes up it is supposed to read some sensors send an uplink and go back to sleep. What i am trying to achieve is that the esp adds the maccommand to an uplink (every tenth uplink or something) and go back to sleep. The next time the esp wakes up the downlink with the requested time arrives. At this point the callback isn’t triggered of course because there was a deepsleep in between.
Should this be achieveable at this point? Or am i totally missing something? Or is there some workaround?
I would like to avoid staying awake between two uplinks because the interval might be very long and power is limited.
Another way if thought of would be to send a empty dummy Payload after the initial mac command. but thats also kinda wasteful.
Hope someone can point me in the right direction.
thanks
The downlink has to happen as part of the class A exchange (which a fixed time after the uplink carrying the time). The time sent is referenced to that uplink, and can only be interpreted based on the timing of the class A exchange.
So you CAN’T sleep for any appreciable time before the downlink; that’s just not how this works. You can, of course, sleep during the delay to the RX window, but that is a bit complex and doesn’t save much power. But it simply is not LoRaWAN – the downlink can’t be sent except in response to an uplink. So what I understand you to be describing won’t work.
If you ran a Class B device, you can get the time from the beacon; but Class B support is unstable in the current version of the LMIC, unfortunately.
Hey! Thanks for the reply. I think i didn’t describe the problem well enough.
U = Uplink
D = Downlink
S = Sleep
T = LMIC_getNetworkTimeReference
TD = Downlink carrying the networktime
This is what i would like to do:
U | S | U | S | U+T | S | U | TD | S
This is what i do right now:
U | S | U | S | U+T | S | U + T | TD(From the previous cycle) | S | U | TD (This is kind of wasted)
What would be the intended way?
Sending a second uplink right after the one carrying the timeflag? I dont get the time on the very next downlink from TTN. Thats my problem.
The network doesn’t have to send the time (according to the LoRaWAN spec); the device requests, but the network only makes a best effort. I suspect that TTN deliberately delays. .
Your diagram is a bit confusing to me; we should add another letter (“r”) for downlink slots that are not use. Your “what I do now” is probably actually:
U r1 r2 | S | U r1 r2 | S | U+T r1 r2 | S | U+T r1(TD) | S | U r1(TD) | S
FWIW I’m getting the DeviceTimeAns in the downlink associated with my DeviceTimeReq every time, on the free ThingsStack.
What I couldn’t get from the spec was if the server is obliged to answer the time request then, or if the answer can come in a later downlink and the node has to remember when it sent the request. Or if the server can just ignore the request altogether.
The reply, if it comes, has to come in the same Class A transaction. The network server might omit it; or the gateway might have a conflict (already something scheduled at that time for something else, e.g. a class B beacon); or the gateway might not have bandwidth available (in EU regions) for doing a downlink at that time. I don’t think the network is allowed to get an uplink time request from Uplink N, and then put the response in the downlink to Uplink N+1. (If Uplink N+1 also contains a time request, then the time response is interpreted as being in response to Uplink n+1.)