Troubleshooting potential Conduit Transmit packet loss.

[Ajay K]

We have about 50 MDots deployed in the field and have custom firmware on the mdot. we are sending the same set of 3 down link packets to all the nodes from the gateway. However Every time we are testing this, a couple of the MDot’s don’t receive 1 or 2 of the three downlink packets. It is pretty consistent. I have increased the logging for the lora network server and upped the logging for the node-red.

So based on the node-red logs, I can confirm the packets were queued successfully via the LORA o/p node. However beyond that I have no way to troubleshoot if the packets were sent to a specific MDot. Also we do have tracing turned on the MDots, so we can figure it out from there too, but these are located miles apart from the Conduit and would be very hard to find out which MDot didnt receive the packets, as the MDots that don’t receive the packets are pretty random each time we resend the three downlink packets.

So In short what tools can I use on the conduit to troubleshoot which packets to which mdots were sent successfully and were queued but were failed to be transmitted to the mdot?

Thanks,
Ajay

[Ajay K]

This is what I got from the lorawan-servers logs and not sure how to interpret this?

Would the log below indicate that an uplink?

Apr 11 21:07:39 mtcdt user.info lora-network-server: Check response size: 0000001d sf: 7 bw: 2 dur: 17 < tm: 20 wnd: 1
Apr 11 21:07:39 mtcdt user.info lora-network-server: TransmitQueue canIncreaseDuration 22767364 20 0
Apr 11 21:07:39 mtcdt user.info lora-network-server: Transmit UDP message to Gateway 184 bytes
Apr 11 21:07:40 mtcdt user.info lora-network-server: Parsing 1 rx packets
Apr 11 21:07:40 mtcdt user.info lora-network-server: SeqNo: 000000fc PrevSeqNo: 000000fb Duplicate: no^M
Apr 11 21:07:40 mtcdt user.info lora-network-server: Addr: 00:00:00:04 MIC Check: passed
Apr 11 21:07:40 mtcdt user.info lora-network-server: Packet accepted from Node 00:00:00:04  GW 00:80:00:00:00:00:00:79  (127.0.0.1)  Seq# fc  ADR enabled SF7BW125

Would the log below indicate that an downlink of a queued packet occurred here?

Apr 11 21:07:40 mtcdt user.info lora-network-server: Schedule TX Time on air: 17 ms
Apr 11 21:07:41 mtcdt user.info lora-network-server: Frame transmitted to 00:00:00:04 via GW (00:80:00:00:00:00:00:79 Chan FC1 127.0.0.1:58905)  Seq# 149

Thanks,
Ajay

[Peter Ferland]

Your interpretation of the logs is correct.

Is it always the same mDots? There may be something related to the location they’re at that is degrading reception.

It is not unexpected to lose some packets at random in any wireless system. You might consider transmitting several times to reduce the probability of all of your dots missing the message or some method for the mDots to know that they missed a message when they next check in.

[Ajay K]

Thanks Peter. Is there a way to figure out the payload that was transmitted during the downlink, for future troubleshooting. One of the issues we discovered was that we were on an older version of the conduit firmware 1.2.2. Once we upgraded this to 1.3.3 and it is working mostly. we will wait and see if a packet loss occurs again. However your point is taken that a re-transmit may be required.

Thanks,
Ajay

[Peter Ferland]

You could subscribe to the lora/+/down topic to see the payload of the packets when queued. You’d have to correlate them with the other log using the SeqNo.

(the mosqutto command line tools aren’t installed by default on an AEP conduit, but can be installed using opkg install mosquitto-clients)

[Ajay K]

Thanks Peter for the response. I am new to the MQTT concept. I am assuming if I subscribe to that topic, then I would receive that message in the node-red flow, but this won’t in any way effect the packet being downlinked correct? As any MQTT subscriber to this topic would receive a copy of this message?

Thanks,
Ajay

[Author]

Posts