AEP receiving Packets Up but not seen by Node-RED

[William Laing]

Good Day.

We’re using various xDot end nodes to send LoRa packets to a MultiConnect Conduit (MTCDT-LVW2-246A::F/W 1.4.14).

In certain circumstances, we are seeing packets received by the gateway but not by Node-RED. We know the gateway is receiving packets, because the value in Status&Logs->Statistics->LoRa->Pkts_Up increments.

But only some of the packets are showing up in Node-RED. We are using one simple Node-RED Function Block that merely logs the message payload and passes it along to a Debug Node:

node.log(“\ntimestamp: ” + msg.time);
node.log(“payload: ” + msg.payload + “\n”);
return msg;

Has any one seen this? Any ideas? We need all the LoRa packets received by the Conduit to be processed by Node-RED.

Thank you in advance for your assistance.

Regards,
Bill

[Jason Reiss]

Do you see the missing packets in the table on LoRaWAN > Packets page?

An MQTT input node could be used to check if there are packets reported to the lora/+/up topic. This should match what is reported by the lora-in node.

[Antonio Muñoz]

Hi
I have this problem too.
The received packets stop arriving at the node-RED application, and the solution I have taken is to restart the conduit when a certain time passes without the node-RED app receiving any packet.
It happens to me with the previous version (1.4.3), and I thought it had been fixed in version 1.4.14.
This does not happen very often, but it should never happen.

Regards.

[William Laing]

Thanks for the response, Jason.

Yes, we saw all the packets on LoRaWAN->Packets->Recent Rx Packets. However, we were only seeing about half of them in Node-RED using a simple .

It looks like we found a solution by modifying our xDot sleep/wake sequence.

After we configure, AT+JOIN and AT+RS:

Old sequence: sleep->wake->AT+RS->AT+SEND->sleep
New sequence: sleep->wake->AT+RS->AT+SEND->AT+SS->sleep

With the new sequence we are now seeing all the packets in Node-RED.

We haven’t had time to read and understand why yet.

Thanks!
Bill

PS Can you tell us what format/units are used for time in the LoRaWAN->Packets->Recent Rx Packets table? We tried epoch time in seconds and milliseconds, and that doesn’t work. The page in the AEP manual just says: Time packet was received.

[Jason Reiss]

It’s a MTAC card internal clock time in microseconds.

There are some message field definitions at the bottom of this page. They should be consistent with lora-query output.

MQTT Messages

[William Laing]

Thanks again for the help, Jason.

We looked at that page. For the LoRa packet timestamp value it says:

tmst | number | Internal timestamp of “RX finished” event (32b unsigned)

How do we translate that into a meaning date and time?

For example, here is one of our packets:
1371445316 913.100 SF8BW125 OK 8.8 -37 51 UpCnf gFLkywEAdQQBXjJfHK…

How do we translate the timestamp of 1371445316 into a usable format?

Thanks,
Bill

[Jason Reiss]

It doesn’t translate to a time. There should be a time field in the packets received by node red.
The recent packets table is a list of packets received by the radio.
Since the may be garbage CRC error packets no processing is done at the network server to add a timestamp. The packet forwarder may attach a timestamp in some configurations with GPS, then it will be included.

The packets table at the top has datetime for authenticated packets. The tmst is included with packets at this table. It could be cross referenced to get the tmst -> time conversion in an app.

[Author]

Posts