Multitech Conduit 1.4 update command payload appear

Home › Forums › Lora Network Server › Multitech Conduit 1.4 update command payload appear

Tagged: , , ,

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
    Posts
  • January 9, 2018 at 7:00 am #22274
    carole jacquinot
    Participant

    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

    January 9, 2018 at 8:09 am #22280
    Jason Reiss
    Keymaster

    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.

    January 9, 2018 at 9:03 am #22281
    carole jacquinot
    Participant

    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.

    January 9, 2018 at 9:22 am #22282
    Jason Reiss
    Keymaster

    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.

    January 9, 2018 at 9:27 am #22284
    carole jacquinot
    Participant

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

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