Multitech Conduit 1.4 update command payload appear

[carole jacquinot]

Hello,

I made a communication between Multitech Conduit, Lora, Node-Red and a RN2483 module from Microchip.

Since I update to the 1.4.1 version and 1.4.3 version,
I start by making a transmission with RN2483, and it will send another frame that I didn’t ask to it.
I supposed it is a command frame, but this frame is not accepted by the Gateway as command and I can see it printed on the Node-Red.

Information from this mysterious frame:
-Acknowledge another frame that the RN2483 not received as received message
-correct header
-correct appeui and deveui
-no opt indicated
-the payload is [7, 3] ; 0703 which I don’t understand what it means because with LoRaWAN communication only one command answer from the end-device could answer with payload-2-bytes and the information doesn’t match with this mysterious payload.

Also, during the communication another frame appears with this time the [3 ; 7] payload.

Those frames didn’t appear with the 1.3.2 and 1.3.3 AEP firmware version.

So, perhaps the new version send specific command, but if it is why those frames appear, it should be take in account before passed on the Node-Red debug?

Otherwise, Is anyone have a track to understand where those frames come from? what it means? and how avoid or correct it?

Regards,
Carole

[Jason Reiss]

What channel plan are you using?
I will assume EU868

Are you using 1.4.1 or 1.4.3 or both act the same?

Both look like mac command answers
0703 is a new channel request answer
0307 is an adr command answer

The updated network server sends down a packet in the first downlink to define channels for DR6 and DR7

What port is the packet being received on from the end-device?
If the FOpts is empty and the payload contains MAC commands it should be received on port 0.
Packets sent using port 0 should not be forwarded to the application.

How is your application receiving packets in node-red? MQTT node or LoRa-IN node? Can you post an example of the json received.

[carole jacquinot]

Ok,
Thank you for your answers, that’s really help me

I use the EU868 channel plan.

At start, I tried on 1.4.1 and then I passed on the 1.4.3 and I saw the same problem.

Yes, in fact all those command frames are on the port 0:
{ “ack”: true, “adr”: true, “appeui”: “fe-dc-ba-98-76-54-32-10”, “chan”: 4, “cls”: 0, “codr”: “4/5”, “datr”: “SF12BW125”, “deveui”: “00-00-00-00-00-20-03-9c”, “freq”: “867.3”, “lsnr”: “7.8”, “mhdr”: “409c032000a00100”, “modu”: “LORA”, “opts”: “”, “port”: 0, “rfch”: 1, “rssi”: -67, “seqn”: 1, “size”: 4, “timestamp”: “2018-01-09T14:49:33.925661Z”, “tmst”: 567051324, “payload”: [ 7, 3 ], “eui”: “00-00-00-00-00-20-03-9c”, “_msgid”: “ab4abc30.54b54” }

The ACK frame too:
{ “ack”: true, “adr”: true, “appeui”: “fe-dc-ba-98-76-54-32-10”, “chan”: 1, “cls”: 0, “codr”: “4/5”, “data”: “”, “datr”: “SF12BW125”, “deveui”: “00-00-00-00-00-20-03-9c”, “freq”: “868.3”, “lsnr”: “8.5”, “mhdr”: “409c032000a00200”, “modu”: “LORA”, “opts”: “”, “port”: 0, “rfch”: 0, “rssi”: -65, “seqn”: 2, “size”: 0, “timestamp”: “2018-01-09T14:49:38.657740Z”, “tmst”: 571780068, “eui”: “00-00-00-00-00-20-03-9c”, “_msgid”: “a4620411.5b9df8” }

My application receive and transmit packets in node-red with lora input/output nodes.

So, it seems that the command answers are bring to node-red application.

• This reply was modified 6 years, 3 months ago by carole jacquinot.

[Jason Reiss]

It’s interesting that they send the answer in the payload instead of using the FOpts field.

Since the application is allowed to send packets using port 0 it may make sense to also forward port 0 packets to it?
It is an uplink from the end-device, same as an empty uplink packet is forwarded to the application.

The application can easily filter packets on the “port” field.

[carole jacquinot]

Yes, it makes sense,
I will filter those packets.
Thank you.

[Author]

Posts