LORA Packet not received by Node-Red, on a conduit power cycle.

[Ajay K]

We have hit a scenario where the Node-Red input node, doesn’t receive the LORA packet that was sent by the MDot, on a conduit power cycle.

Just to explain the sequence, the mdot goes to sleep for period of a minute.

1) Before the mdot wakes up, turn the power of to the conduit, so the send from the mdot fails on a wake up.
2) The mdot goes to sleep again for a minute and while the mdot is in deep sleep mode, I power on the conduit.
3) Eventually once the conduit is up and powered on the packet is resent from the mdot on a wake cycle and it is ack-ed by the conduit as a successful receipt, since the mdot requires an ack from the conduit.
4) However this packet is never handed out to the Node-Red input node for processing and we have lost a packet at this point. This gets worse if we have more than one packet to transmit.

Looking at the logs of the conduit and node-red logs, the Node-Red seems to take almost 3-5 minutes to get completely initialize and the LORA WAN network servicer/service is already up and running. Although the LORA WAN server is up and running, it doesn’t seem like it hands it over to the LORA input node or may be there is an attempt and since node-red is still not completely initialized yet, there is a loss of packet? Is there anything we can do to prevent the loss of the packet(s)?

Thanks,
Ajay

[Lawrence Griffiths]

Ajay, I’ve seen this the LoRa server still working receiving packets but LoRa-in node not processing them. One thing that seemed to upset things was connecting to external MQTT broker which would drop connections. This seemed to upset the LoRa-in node!

And yes I always wait at least 3 mins for node-red to boot. The LoRa network server has grater priority. We won’t see any improvement until new hardware.

[Roman Ploskon]

Hi,

Would you please be able to provide any update on this? I am unable to reproduce the issue seen at customer site:
1. Nodes successfully join the network.
2. Messages are being received by gateway and forwarded to our server.
3. Gateway is power cycled.
4. Several nodes seems to be no longer sending any messages (or at least our server is no longer getting forwarded messages from those nodes).

Re-joining the network seems to help.
Could you please give us any information how re-joining the network could help? This should not be related to “lease time”.

Thank you!

[Ajay K]

Roman,

I have reproduced this every time. When an MDot is connected previously to a network and the conduit is power-cycled, the only way the mdot can send a packet successfully is when you rejoin the network. In my case I have acks enabled, so I would get continuous ack failures, even after the conduit is up and running and the mdot api getNetworkJoinStatus() will return true, even though the conduit has been power cycled . I am not sure why the re-join helps, may be the multi-tech team can shed some light on it.

Thanks,
Ajay

[Jason Reiss]

1. Device Joins Conduit via RF
2. Session is saved to DB in RAM on Conduit
3. DB is periodically backed up to FLASH (1 hour interval)
4. DB on shutdown is backed up to FLASH
5. On power-up DB is restored in RAM from FLASH

When the power is pulled the DB is not backed up to flash. The restored database on power-up does not have a record of the session.

Even when joined the session counters between Conduit and end-device may be lost on power-loss. If the downlink counter on the Dot is ahead of the Conduit then downlink packets will be rejected as repeats until the counter catches up.

On Dot the getNetworkJoinStatus() returns the local state of the network session. It does not query the Conduit of session information.

Work-arounds:
1. UPS + GPIO card to gracefully shutdown gateway before UPS battery runs out.
2. Detect loss of session at end-device via lack of ACK from gateway and re-join. Periodic link check is also available to detect loss.

See setLinkCheckCount and setLinkCheckThreshold in mDot.h.
See Ensuring Network Connectivity section of http://www.multitech.net/developer/software/mdot-software/at-command-firmware-user-guide/

BR,
Jason

[Lawrence Griffiths]

Work-arounds:
1. UPS + GPIO card to gracefully shutdown gateway before UPS battery runs out.

Assume this standard linux shutdown cmd? or is something else.

Thanks
Lawrence

[Jason Reiss]

Standard command
# shutdown -h now

[Author]

Posts