Uplink Packets missing Data sent from the MDot.

Home Forums Conduit: AEP Model Uplink Packets missing Data sent from the MDot.

Tagged: ,

Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
    Posts
  • #29927
    Ajay K
    Participant

    Our firmware on MDot is using 3.1.0 mdot-library and the gateway is on 1.7.4 firmware version. We have about 30 mdot nodes communicating with a single gateway. All the packets transmitted between the gateway and the mdots have ADR and ACK turned on. One of the things we noticed is that we are missing firstly the data part of the packet as shown below and also the ack seems to be true sometimes and false sometimes. Which I don’t understand since we explicitly require ACKs in the MDot code base. In the example packet below the ack attribute is set to false. We were wondering why would no data be sent out in the first place since every packet we send has data. Also does the mdot library have a scenario when we explicitly set an ACK via code, it can be overidden by the MDot library?

    11/21/2019 0:2:25: [DEBUG] Received Uplink Packet with EUI: 00:80:00:00:00:01:57:47, sequence#: 123
    Uplink Packet: {"tmst":3637994484,"chan":6,"rfch":1,"freq":906.7,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":5.8,"rssi":-92,"opts":"","size":0,"fcnt":123,"cls":0,"port":1,"mhdr":"801f8ae001807b00","data":"","appeui":"55-ab-d3-90-e4-c5-a9-0a","deveui":"00-80-00-00-00-01-57-47","ack":false,"adr":true,"gweui":"00-80-00-00-a0-00-41-ca","seqn":123,"time":"2019-11-21T00:02:24.977047Z"}

    #29928
    Ajay K
    Participant

    Just adding the packet, since it seems to be clipped in the previous post.

    11/21/2019 0:2:25: [DEBUG] Received Uplink Packet with EUI: 00:80:00:00:00:01:57:47, sequence#: 123
    Uplink Packet: {“tmst”:3637994484,”chan”:6,”rfch”:1,
    “freq”:906.7,”stat”:1,”modu”:”LORA”,
    “datr”:”SF7BW125″,”codr”:”4/5″,”lsnr”:5.8,
    “rssi”:-92,”opts”:””,”size”:0,”fcnt”:123,”cls”:0,”port”:1,
    “mhdr”:”801f8ae001807b00″,
    “data”:””,
    “appeui”:”55-ab-d3-90-e4-c5-a9-0a”,
    “deveui”:”00-80-00-00-00-01-57-47″,
    “ack”:false,
    “adr”:true,
    “gweui”:”00-80-00-00-a0-00-41-ca”,
    “seqn”:123,”time”:”2019-11-21T00:02:24.977047Z”}

    #29931
    Jason Reiss
    Keymaster

    The ack field means that the packet is an ACK and has the ACK bit set in the FCtrl field of the LoRaWAN header. Other fields are ADR, FPending, AdrAckReq, ClassB, etc. Details can be found in the protocol reference documentation (https://lora-alliance.org/resource-hub/lorawanr-specification-v103)

    The confirmed/unconfirmed bits are in the MType field in the first byte of the LoRaWAN header. In this case 0x80 seen in the “mhdr” field which is a Confirmed Uplink packet.

    I would only expect a packet to have an empty data field if mac commands needed to be sent and could not fit in the packet with the requested payload. The MAC commands would be sent and seen in the “opts” field which is empty.

    You will need to look at the end-device application to see how an empty packet could be sent. The Confirmed Uplink request will not be overridden by the library in any case to answer your question.

    This packet decoder maybe useful, this fake packet shows each field of the packet with an incremented set of numbers. A full LoRaWAN packet from the packet_recv topic would need to be used as input if you wanted to decode a real message.
    https://lorawan-packet-decoder-0ta6puiniaut.runkit.sh/?data=80111111112233334444556666666677777777&nwkskey=&appskey=

    Field definitions found in the MQTT messages are defined.
    https://www.multitech.net/developer/software/lora/lora-network-server/mqtt-messages/

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