Downlink message queue during OTAA join
-
Is there any way to receive downlink messages that have been sent to the network server before an OTAA join? Only downlink messages that are sent after an OTAA join seem to remain in the LoPy's message buffer.
When a LoPy4 joins by OTAA it empties the server's downlink message queue but the received data is not printed (using any of the online OTAA code samples). The server shows that the messages have been delivered but these is no way of telling whether they were really delivered or delivered and discarded by the LoPy.
-
@31warren could you clarify which example you are referring to? The LoRaWAN with OTAA sample in the docs does indeed send before receiving.
In LoRaWAN class A devices contrary to raw LoRa you cannot receive any downlink unless there’s an uplink anyway (downlinks are sent in specific time windows after an uplink).
-
@robert-hh and jcaron : Thank you for your replies. I was hoping to use a downlink message to send a configuration message to the device when it first joined the network but it seems that this is not possible without some additional code on the application server side. This is not a problem as I can respond to the first uplink message instead. Unfortunately the example programs online all include reading a downlink message immediately after a network join, which gives the impression that this should work when it looks like it doesn't (unless the network parameters have been previously saved). Thanks again for your advice.
-
@31warren Like @jcaron said, joining happens or is required ideally only once in the lifetime of a device. Lora works without connections. It is based on datagrams. The other property which may important: Lora class A device like the LoPy can receive messages only in a short RX Window following a message being sent. Any message transferred outside that window are lost, like messages with wrong device ID's or sequence numbers, even within the proper time window. OTAA join changes the device ID, device keys and message sequence numbers.
You may use ABP join, where you can manually set keys and device ID's, and keep them static, but at the current LoPy Lora stack there is no method to set the sequence number or to discard out-of-order sequence numbers. Since ABP join only set local values, you can run that multiple times.
In any case, use lora.nvram_save() and lora.nvram_restore() to maintain the LoRa status, including keys, device-id and sequence numbers.
-
@31warren the normal behaviour is to join only once, and do a new join only in some edge cases (configuration was lost, reset, etc.).
A join resets a lot of things, including frame counters, MAC state (channels, data rates, RX window settings, unacknowledged frames, etc.), so it would seem bizarre to be able to send a downlink before a join and have the LoPy receive it after the join.
Is there any reason you are joining again? Re-joining will reduce performance, increase battery use, make statistics quite useless...
