Downlink msg fail after join

Home Forums Lora Network Server Downlink msg fail after join

Viewing 18 posts - 1 through 18 (of 18 total)
  • Author
    Posts
  • #21729
    luis santos
    Participant

    Hi,
    I have a conduit mlinux gateway with a lora module.
    I build a network with 100 nodes with laird rm186 modules.
    The nodes wake up at 6 and 6 hours, and do OTA join. After join success they send data to the gateway, and the gateway response back with some node cfg.
    All the uplink msg are revived by the gateway. But the first dowwlink gateway response never arrived to the node. The node must send again the data. After the 2 try the node received the gateway msg.
    I have read all the logs from the lora-network-server, lora_pkg_fwd. I a don’t find any problem.

    The gw is running the last lora server and pkg fwd version.

    Any suggestion is welcome.

    cumps,

    Luís Santos

    #21730
    Jason Reiss
    Keymaster

    The first downlink contains MAC commands to setup additional channels or the channel mask.

    #21737
    luis santos
    Participant

    Tks for the quick response. So it’s not possible to send data on the first downlink?

    #21745
    Jason Reiss
    Keymaster

    Data queued for downlink will need to wait for next packet.
    The first downlink is sent on port 0 with payload of MAC commands.

    #21757
    luis santos
    Participant

    Ok, I was not aware of that. So after doing a join, the node need to send 2 packets (uplink) before received the first gateway payload?
    For a battery powered device this kinda sucks.

    tks,

    #21758
    Jason Reiss
    Keymaster

    How often does the device need to join? Is the session info being saved?

    #21768
    luis santos
    Participant

    Well. The device do ota join, send data, receive data, deep sleep 6h, wake-up do ota join, …, sleep 6h.
    The reason i do a ota join every time the device wake-up is because i put the laird rm186 in deep sleep, and from what i’m aware this module when go in deep sleep lose the session info.

    • This reply was modified 6 years, 5 months ago by Jason Reiss.
    #21769
    Jason Reiss
    Keymaster
    #21770
    Jason Reiss
    Keymaster

    To stop the network server from sending the first downlink, clear the queue on joined event or when the first uplink is received. Then queue your downlink packet.

    Send MQTT message with topic
    lora/<DEV-EUI>/clear

    • This reply was modified 6 years, 5 months ago by Jason Reiss.
    • This reply was modified 6 years, 5 months ago by Jason Reiss.
    #21824
    luis santos
    Participant

    Hi,

    After talking with Laird. They respond this.

    “Unfortunately because all communication is terminated when the module goes into deep sleep to conserve power, you will always need to rejoin when the module wakes. The only way to prevent needing a new join request would be to keep your module in standby doze mode rather than deep sleep.”

    #21827
    Jason Reiss
    Keymaster

    Have you looked at the xDot module? 1.8 uA sleep with RAM retained so rejoin on every wakeup is not necessary.

    It also allows saving session to flash for full power down.

    #21828
    luis santos
    Participant

    Cool, for the next project I will suggest the xDot.
    I have one question about the xDot. Is possible used the xDot as class C lora?

    #21830
    Jason Reiss
    Keymaster

    Class C is supported.

    The xDot module is fully programmable using os.mbed.com online compiler or offline sdk.

    #21837
    luis santos
    Participant

    To stop the network server from sending the first downlink, clear the queue on joined event or when the first uplink is received. Then queue your downlink packet.

    Send MQTT message with topic
    lora/<DEV-EUI>/clear

    Your tip help. Now the lora node receive the first dowwlink.
    But I not happy with this kind of solution. But for now, this must do.

    Tks,

    • This reply was modified 6 years, 5 months ago by luis santos.
    #21874
    Jason Reiss
    Keymaster

    What do you propose as a better solution?

    Adding a configuration option to not queue the downlink? Your application is already able to override the default behavior. What more is desired?

    Additional information for OTA nodes is required to be sent in the first downlink.

    Otherwise the device may assume it can use unavailable channels.

    #21876
    luis santos
    Participant

    For me the better solution, is to change the Laird lora module that i’m using now, for a new one that don’t need to make a lora join every time e wakeup from a deep sleep.

    tks,

    #21878
    Jason Reiss
    Keymaster

    Sounds good. Just wondering if there was something you still needed from the server side.

    Cheers.

    #21879
    luis santos
    Participant

    No.
    I’m very happy with the conduit gateway.

    Cheers,

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