Hmmmm, key difference here is that you have told the LMIC to schedule the task to run at some point in the future which is up to LMIC. And if it’s been frozen in time, it may take some time to get to a point where it thinks it’s time to send.
Whereas I tell the LMIC to transmit, which as long as you haven’t contravened it’s algorithm for duty limits, will do a transmit via it’s own internal threaded system. And, as you can see from the table below, it’s reasonably consistent.
I’d set LMIC_DEBUG_LEVEL to 1 in config.h in the library so you can see far more detail on the serial port as to what is going on under the hood.
Here’s the last 10 records from the Production office temperature device. The code has to turn on the IO & ADC, then each sensors is turned on, some settle time, a reading (or more to iron out noise) and then turn off. One sensor is a DHT and the other is a DS18B20, both of which have to be re-initialised. There’s also a 4 second extra as a rounding error on the set interval of 300 seconds. It’s not optimised and I’ve never timed it as I’ve no particular need for an Arduino + RFM95 node as I don’t deploy them for production, just as Canarys (end to end monitor) or as give-aways.
Timestamp | Difference | Diff from Ave |
---|---|---|
03/12/2020 19:40:00 | 5m 34s 526ms | -0m 0s 652ms |
03/12/2020 19:45:34 | 5m 34s 730ms | -0m 0s 856ms |
03/12/2020 19:51:08 | 5m 33s 389ms | 0m 0s 485ms |
03/12/2020 19:56:41 | 5m 32s 876ms | 0m 0s 998ms |
03/12/2020 20:02:14 | 5m 33s 6ms | 0m 0s 868ms |
03/12/2020 20:07:48 | 5m 34s 15ms | -0m 0s 141ms |
03/12/2020 20:13:22 | 5m 34s 563ms | -0m 0s 689ms |
03/12/2020 20:18:56 | 5m 33s 403ms | 0m 0s 470ms |
03/12/2020 20:24:30 | 5m 34s 231ms | -0m 0s 357ms |
03/12/2020 20:30:04 | 5m 34s 1ms | -0m 0s 127ms |
Given I’ve never really looked at my Arduino implementation at this level of detail, I’m reasonably happy but my interest is peaked so I’ll instrument a copy of the device at some point over the holidays.