Confirming Packet sent successfully to mdot.

Home › Forums › Conduit: AEP Model › Confirming Packet sent successfully to mdot.

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
    Posts
  • August 29, 2016 at 10:25 am #14642
    Ajay K
    Participant

    Using the LORA Send/Output node, is it possible to determine if the packet was sent successfully to the mdot. The LORA send node in the class A scenario I am assuming is just queued to be sent until the next uplink occurs. How would I be able to determine if a packet was sent successfully to the mdot in this case?

    Thanks,
    Ajay

    August 29, 2016 at 10:38 am #14643
    Jason Reiss
    Keymaster

    You will need an MQTT node

    MQTT Messages

    August 29, 2016 at 1:30 pm #14644
    Lawrence Griffiths
    Participant

    Ajay, remember you can use the (single level wild card) lora/+/packet_sent in you topic to see all down link messages. http://www.hivemq.com/blog/mqtt-essentials-part-5-mqtt-topics-best-practices

    @Jason is the “Request an ACK for downstream packets from the end-device?” a LoRaWAN or mDot feature? e.g if my customer is using a Microchip RN2483 can I use this feature?

    August 30, 2016 at 11:07 am #14660
    Ajay K
    Participant

    Thanks Jason and Lawrence for taking the time to respond.

    Packet sent – a packet has been sent to the radio to be transmitted
    lora/<DEV-EUI>/packet_sent

    would the above MQTT output topic indicate that the message was sent successfully or is it more a pre-send notification.

    Also as Lawrence called out, if I am right the LORA output node, has a checkbox to receive acks on transmission, does this require the MDot to turn on acks on its end as well? Is this checkbox for the LORA output node to internally figure out if the message was transmitted successfully and would it throw an exception which can be handled by the catch node?

    Thanks,
    Ajay.

    August 30, 2016 at 11:14 am #14661
    Jason Reiss
    Keymaster

    If you require ACK on the lora-out node then the network server will hold the packet in the queue until ACK is received from the device. If the ACK is not received on the next uplink then the same packet will be sent down to the device, include the same sequence number.

    This is separate from the ACK required for an uplink sent to the server where the server will send the ACK in a downlink if the device has ACK enabled.

    @Lawrence uplink/downlink ACK is a LoRaWAN feature

    August 30, 2016 at 12:53 pm #14664
    Ajay K
    Participant

    Thanks Jason for your quick response. Some follow up questions.

    1) How many times will it retry sending the same packet if the Ack is not received.
    2) You talked about a sequence number, is it possible to read this value in the node-red flow?

    3) Also since there is a fixed limit to the queue per mdot/end device connected to the conduit, how does the lora output node handle the queue max size being hit?

    4) One last question, the mqtt request_sent topic what kind of information does it provide, other than the packet being sent via the radio? Does it provide any additional information.

    August 30, 2016 at 1:23 pm #14666
    Jason Reiss
    Keymaster

    1) it will stay in the queue until network server is reset or empty command is sent to queue

    2) the downlink seq no should be in the packet_sent event

    3) it does not handle the event

    4) it contains all information sent to the radio via the packet forwarder i.e. freq, datr, modu, …
    See
    https://github.com/Lora-net/packet_forwarder/blob/master/PROTOCOL.TXT

    April 21, 2017 at 11:08 am #18484
    Michele Ferrari
    Participant

    Hi,
    I have a similar problem. I have a class C actuator device.
    I have done a nodered flow in which I send a turn On command, with “ack” flag set on true.
    I think that the packet ACK was lost, and I continue to receive duplicated messages from the actuator.
    This is the slice of the log.

    13:46:2:896|DEBUG| Received packet
================================
000   80 03 00 00 00 80 d9 01
008   7d 5e 1a 44 b8 ce 8c 3e
010   23 50 ed 36 e0

13:46:2:896|DEBUG| Rx on 868300000, rssi: -93 snr: 70
13:46:2:896|DEBUG| Received frame: type: Confirmed Up
13:46:2:897|DEBUG| Packet received from Node 00:00:00:03  GW 00:80:00:00:a0:00:05:8d  (127.0.0.1)  Seq# 1d9
13:46:2:898|DEBUG| Expecting packet SeqNo: 000001d9
13:46:2:898|DEBUG| Check for dup: 01d9 == 01d9
13:46:2:899|DEBUG| MIC Check: 50ed36e0 == 50ed36e0
13:46:2:899|INFO| SeqNo: 0009474c PrevSeqNo: 000001d9 Duplicate: yes

    I can’t understand
    13:46:2:899|INFO| SeqNo: 0009474c PrevSeqNo: 000001d9 Duplicate: yes

    Watching packet bytes sequence nr is 01d9, and the expected one is 01d9.
    I can’t understand 0009474c.

    I’ve tried to rejoin the device, sequence number restart from 0, but always the message 0009474c is displayed.

    I’ve tried to restart both network server and mosquitto, but nothing change.
    I’ve also tried to send a mosquitto_pub -n -t /lora/<actuator EUI>/clear, but nothing change.

    I’ve searched inside .db file, but I cannot find 0009474c anywhere.

    To fix it, I have to unregister and register again the device.

    Can someone help me with this strange issue?

    Michele

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