Currently, the sketch is really dumb: Every 15 minutes, it submits a packet to the LMIC library. Then it waits for a fixed amount of time for the packet to be transmitted. If not TXCOMPLETE event is received, it treats this as a timeout, cancels the packet and waits for another 15 minutes.
If If this is the first packet, this will automatically trigger a join. Normally, this join completes quickly and the packet can be sent quickly too. However, when the join does not complete, it will be retried. Because of the duty cycle limits (which are lower then normal for joining, at least in this version of LoRaWAN), most of the TX timeout will be spent on waiting for airtime to become available for retry join packets.
Things to improve:
When waiting for airtime to become available, we should sleep. This timing is not critical (unlike the time between TX and RX), so sleeping is possible. This holds for joining as well as normal TX, though the latter should never occur currently (but does once the datarate is no longer fixed at SF9, see #1).
When the node powers on, it should start joining right away, in parallel with reading the GPS and before queuing the first packet.
When joining is not complete, the node might need to wake up within the 15 minute cycle when airtime becomes available, to complete the join ASAP.
When joining fails (e.g. it has retried according to the spec, lowering the datarate all the way to SF12), the node should probably not retry joining immediately again. Perhaps it should sleep for 24h or so and then retry again? Another join attempt should probably start at SF12, to not waste too much time and energy?
One challenge here is that the LMIC radio library does note conveniently expose information about what it is waiting for and for how long. It even does not really know right now, since some of this information is implicitly encoded in the timing of the tasks. This might require some changes to LMIC to really implement properly.
Currently, the sketch is really dumb: Every 15 minutes, it submits a packet to the LMIC library. Then it waits for a fixed amount of time for the packet to be transmitted. If not TXCOMPLETE event is received, it treats this as a timeout, cancels the packet and waits for another 15 minutes.
If If this is the first packet, this will automatically trigger a join. Normally, this join completes quickly and the packet can be sent quickly too. However, when the join does not complete, it will be retried. Because of the duty cycle limits (which are lower then normal for joining, at least in this version of LoRaWAN), most of the TX timeout will be spent on waiting for airtime to become available for retry join packets.
Things to improve:
One challenge here is that the LMIC radio library does note conveniently expose information about what it is waiting for and for how long. It even does not really know right now, since some of this information is implicitly encoded in the timing of the tasks. This might require some changes to LMIC to really implement properly.