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

Home › Forums › Conduit: AEP Model › LORA Packet not received by Node-Red, on a conduit power cycle.

Tagged: , ,

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
    Posts
  • April 3, 2017 at 10:46 am #18126
    Ajay K
    Participant

    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

    April 7, 2017 at 4:36 am #18195
    Lawrence Griffiths
    Participant

    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.

    April 26, 2017 at 10:50 am #18679
    Roman Ploskon
    Participant

    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!

    April 26, 2017 at 11:45 pm #18768
    Ajay K
    Participant

    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

    April 27, 2017 at 8:09 am #18769
    Jason Reiss
    Keymaster

    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

    June 28, 2017 at 8:49 am #19740
    Lawrence Griffiths
    Participant

    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

    June 28, 2017 at 8:54 am #19742
    Jason Reiss
    Keymaster

    Standard command
    # shutdown -h now

  • Author
    Posts
Viewing 7 posts - 1 through 7 (of 7 total)
  • You must be logged in to reply to this topic.