When is channel mask sent to end devices?
Home › Forums › Lora Network Server › When is channel mask sent to end devices?
- This topic has 8 replies, 2 voices, and was last updated 6 years, 1 month ago by
EG.
-
AuthorPosts
-
February 12, 2019 at 12:43 pm #27233
EG
ParticipantI have the subband and channel mask configured for my AEP gateway. When my nodes join, they get the channel mask and are constrained to that channel. All is good.
However, if I power cycle the gateway, I suspect it’s sending a message to the end devices to use all channels (I can see them start to hop on the spectrum analyzer). Does the network server send any commands to end devices at startup to use all channels?
What I’m trying to accomplish is to be able to change subbands in the field. The end devices are running without any configured subband and I was hoping to rely on the channel mask being sent after join to constrain to the subband supported by the gateway.
Thanks!
February 12, 2019 at 12:49 pm #27234Jason Reiss
KeymasterThe full channel mask is sent in the first downlink.
If the end-device is reusing all channels, perhaps ADR has dropped to lowest datarate and enabled all channels again. The network is not aware of the channel mask change accept for join.
Only part of the channel mask will be set by ADR as only 16 channels can be changed in a single command and only one command is sent to adjust DR or TXP.
The application can send ADR commands on port 0 to end-devices to change channel mask.
February 12, 2019 at 7:23 pm #27235EG
ParticipantHmm. OK. I’ve seen that code in the stack, but I didn’t think it was being hit here. I’ll investigate further.
Regarding “The application can send ADR commands on port 0 to end-devices to change channel mask” – Can you please explain this? Do you mean an application running on the gateway using mqtt?
My issue is this – assume I boot up my end-devices and the gateway. How do they negotiate a shared subband when they don’t know which subband to use, and then be able to change subbands at will.
My plan was to bring up my end devices without constraining the channels. They hop on all channels until they find the gateway and join, then hop again sending an init message until they find the gateway again, at which point the gateway will send the channel mask down in the receive window and the channels will be constrained to the single subband. If I want to switch subbands, I remotely change the subband and channel mask of the gateway, save, and restart the network server, and my end devices will go back to join after realizing they cannot reach the gateway for a while, repeating the process until they are on the new subband.
I’m sure this has come up before, do you have a recommendation for best practice for this?
Thanks!
February 13, 2019 at 6:53 am #27236Jason Reiss
KeymasterYes an application on the gateway can send a MAC command in a payload through the network server.
The end-device has only on operation when it is not joined. It can only send join requests. No information can be received from the network until it is joined.
Once the device is joined you will know that the network is available on the successful sub-band used for the join request/accept messages. There is no need to hop across sub-bands after the join is successful. Send an uplink using the same sub-band and the network will send down the correct channel mask for the available channels.
To change sub-bands will be tricky as the device will be stranded if the gateway changes first. The application on the device will need to detect and fallback to the join procedure.
Likewise if the end-device is changed first then the uplinks will be lost until the gateway is also changed.
February 14, 2019 at 7:52 am #27240EG
ParticipantThe stack does not expose the channel/subband that was used for the join request. I would use it if I could. The second round of hopping is a waste of time, power, & bandwidth. I may have to modify it to pull it out.
Yes, it’s tricky. That’s why I have my end-devices go back to join after they detect no communication for a while, so they’ll hop until they find it. It sounds like aside from optimizing out the second round of hopping there’s really no better way.
Oh, so you’re saying to send a normal downlink but with the payload formatted to contain a MAC command (port=0, formatted as a link ADR req). Ah, thanks, I didn’t think of that!
February 14, 2019 at 8:00 am #27241EG
ParticipantI have a question regarding the mac command to change the channel mask. Do you know if that is supposed to (according to spec) set the channel mask to the new mask or if it masks it – I’ve seen some code in the stack where it &’s it, which would just turn off disabled channels but not turn on enabled ones, but the stack can be hard to follow in places. I’m trying to determine if I need to first send a command to open up all channels, then send the channel mask.
At join time, all channels are active. so it doesn’t matter with the one the gateway sends.
February 14, 2019 at 3:18 pm #27244EG
ParticipantJason – sorry for one more question. How do I send a message and specify the port? I don’t see anything here that allows that: http://www.multitech.net/developer/software/lora/lora-network-server/mqtt-messages. I only specify the application payload as in “down JSON fields”.
I would have to do it through the AEP API as documented here?
http://www.multitech.net/developer/software/aep/conduit-aep-api/collection-endpoints-conduit/lora-packets/
I’m not sure how to format it.Thanks!
-
This reply was modified 6 years, 1 month ago by
EG.
February 14, 2019 at 3:27 pm #27247Jason Reiss
KeymasterLooks like “port” wasn’t listed, I added it to the mqtt-messages page.
AEP doc
http://www.multitech.net/developer/software/aep/lorawan-aep/downlink-queue/LinkADRReq ex. 0300FFFF01
CMD DR/PWR MASK CTRL/REP
03 0 0 FFFF 0 1See page 23 and 24
https://lora-alliance.org/sites/default/files/2018-07/lorawan_regional_parameters_v1.0.3reva_0.pdfFebruary 15, 2019 at 7:34 am #27255EG
ParticipantThanks. I’ll give that a try.
-
This reply was modified 6 years, 1 month ago by
-
AuthorPosts
- You must be logged in to reply to this topic.