LoPy4: sending LoRa datagram to TTN V3 Stack after restore LoRa nvsram failure

[Teus Hagen]

Use of LoPy4, firmware 1.20.2.rc10 (jan 2021)
Issue with sending LoRa datagram to TTN V3 Stack after restore LoRa nvsram.

Migrating LoPy4 from V2 to V3 The Things Network Stack went ok after power off LoPy4, reset LoRa nvsram, power on.
First join went OK.
Rejoin after power cycle went ok.
If no LoRa nvsram dump/restore is used sending to TTN V3 Stack works OK.

The issue: those LoPy4's which use a restore of LoRa nvsram (so no rejoin) for sending the next datagram the LoRaWan package is not received by TTN.
So the deepsleep/reuse of LoRa state seems not to work with V3.
With TTN V2/deepsleep there was no LoRa state restore problem.
V3 is using a strickter LoRa implementation. E.g DevID use.
Is this a firmware issue or a use of LoRa state software issue?

[Teus Hagen]

@Teus-Hagen
The code has something like:

• send off LoRa package
• dump LoRa state
• deepsleep / wakeup from deepsleep
• restore LoRa state
  Say the LoRa datagram was sent but deepsleep is done before LoRa state was updated.
  The frame count in this case was not updated and next datagram sent will be discarded and will arrive at destination. As well next datagrams will be discarded.
  Work around: Need to try to give LoRa part time to update status before the deepsleep?

[d.alvrzx]

@Teus-Hagen Can you verify if TTN V3 is compatible with LoRaWAN 1.0.2? I saw Pycom release a firmware version compatible with LoRaWAN 1.0.3, which might be compatible with TTN V3. You could try that out.

[Teus Hagen]

@d-alvrzx The same code ok if no deepsleep and no LoRa nvsram dump/restore actions are taking place.
Stil the problem maybe at user Python code in relation with the port/socket binding done when deepsleep has taken place. Debugging those parts with deepsleeps is complex.
So have ordered a LoRa gateway with some debugging so it becomes easier to look at e.g. frame counts.

[Teus Hagen]

@Teus-Hagen Playing with some basic code with LoRa nvram restore/save and deepsleep we could not reproduce the problem. Ie that part is working. For now let us close this issue.
So now we have to dig into what LoRa nvram restore and save actually is doing with the state. Eg after a LoRa nvram restore() is there an argument to follow that imediately with a save? As well to make sure that a power cycle differs from a deepsleep for this: a power cycle should cause a join.