Thanks cslorabox.
I know of the technique where you ask LMIC if it is busy for some amount of time, but need to examine the source more closely to answer the questions below.
I’m on leave ATM and spent the whole of my first day looking into it, so will probably not do any more until next week.
I’ve seen other people are doing the same as us - issuing a LMIC_setTxData2, going into tight loop calling os_runloop_once() based upon a flag, and setting that flag to break from the loop in the TX_COMPLETE event handler, then going to sleep until we next want to measure and send.
So it would be good to get a clear idea of whether this works properly! Perhaps it worked with TTN v2 and v3 doesn’t like it as much, or perhaps it’s fine if the config is all done before TX_COMPLETE is issued, and config answers are queued for the next uplink.
-
Does it take the config reply uplinks into account? Ie are they scheduled as jobs that can be seen by the job queries?
-
Are the config queries handled like the time req where you set a flag and that is included in the next uplink. If so, then #1 doesn’t matter because the answers to the config reqs will be sent on my next uplink.
-
Are the internal state updates requested by the server handled before TX_COMPLETE is issued?
-
Does LMIC want to do anything between issuing a TX_COMPLETE event and the next call to os_runloop_once?
-
If I wake up to do a os_runloop_once(), is that enough to get LMIC doing what it needs to do and in a state I can check to see I need to let it keep going until some defined and visible end state where I can sleep again.