Downlink msg fail after join
Home › Forums › Lora Network Server › Downlink msg fail after join
- This topic has 17 replies, 2 voices, and was last updated 7 years, 4 months ago by
luis santos.
-
AuthorPosts
-
November 13, 2017 at 10:48 am #21729
luis santos
ParticipantHi,
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
November 13, 2017 at 10:55 am #21730Jason Reiss
KeymasterThe first downlink contains MAC commands to setup additional channels or the channel mask.
November 14, 2017 at 2:43 am #21737luis santos
ParticipantTks for the quick response. So it’s not possible to send data on the first downlink?
November 14, 2017 at 9:45 am #21745Jason Reiss
KeymasterData queued for downlink will need to wait for next packet.
The first downlink is sent on port 0 with payload of MAC commands.November 15, 2017 at 10:47 am #21757luis santos
ParticipantOk, 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,
November 15, 2017 at 1:27 pm #21758Jason Reiss
KeymasterHow often does the device need to join? Is the session info being saved?
November 16, 2017 at 2:42 am #21768luis santos
ParticipantWell. 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 7 years, 4 months ago by
Jason Reiss.
November 16, 2017 at 6:09 am #21769Jason Reiss
KeymasterLooks like your module may have 4Mb flash?
November 16, 2017 at 6:44 am #21770Jason Reiss
KeymasterTo 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 7 years, 4 months ago by
Jason Reiss.
-
This reply was modified 7 years, 4 months ago by
Jason Reiss.
November 20, 2017 at 5:54 am #21824luis santos
ParticipantHi,
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.”
November 20, 2017 at 7:34 am #21827Jason Reiss
KeymasterHave 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.
November 20, 2017 at 9:00 am #21828luis santos
ParticipantCool, 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?November 20, 2017 at 9:13 am #21830Jason Reiss
KeymasterClass C is supported.
The xDot module is fully programmable using os.mbed.com online compiler or offline sdk.
November 21, 2017 at 3:34 am #21837luis santos
ParticipantTo 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>/clearYour 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 7 years, 4 months ago by
luis santos.
November 21, 2017 at 6:06 pm #21874Jason Reiss
KeymasterWhat 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.
November 22, 2017 at 2:26 am #21876luis santos
ParticipantFor 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,
November 22, 2017 at 8:59 am #21878Jason Reiss
KeymasterSounds good. Just wondering if there was something you still needed from the server side.
Cheers.
November 22, 2017 at 9:03 am #21879luis santos
ParticipantNo.
I’m very happy with the conduit gateway.Cheers,
-
This reply was modified 7 years, 4 months ago by
-
AuthorPosts
- You must be logged in to reply to this topic.