When is channel mask sent to end devices?

Home Forums Lora Network Server When is channel mask sent to end devices?

Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
    Posts
  • #27233
    EG
    Participant

    I 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!

    #27234
    Jason Reiss
    Keymaster

    The 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.

    #27235
    EG
    Participant

    Hmm. 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!

    #27236
    Jason Reiss
    Keymaster

    Yes 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.

    #27240
    EG
    Participant

    The 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!

    #27241
    EG
    Participant

    I 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.

    #27244
    EG
    Participant

    Jason – 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 5 years, 1 month ago by EG.
    #27247
    Jason Reiss
    Keymaster

    Looks 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 1

    See page 23 and 24
    https://lora-alliance.org/sites/default/files/2018-07/lorawan_regional_parameters_v1.0.3reva_0.pdf

    #27255
    EG
    Participant

    Thanks. I’ll give that a try.

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