Great, thanks for confirming.
I see two LinkADRReq’s in the downlink message. Is the first one for 8-channel upstream (LoRa 500 KHz BW at DR4) and the second request for 64-channel upstream (125 KHz BW varying from DR0 to DR3)?
These two command are processed in order and are used to efficiently configure the channel plan on the device. Typically this pair is used to configure an 8 channel plan.
Just to make sure my understanding is correct. Using the example above, the first request:
LinkADRReq [DR=4 Pwr=2 ChnlMsk=0100 ChnlCntl=7 NbTrans=1]
is for 8-ch upstream (@ 500 KHz BW) and it can only be operated at DR4.
The second request in the same downlink message:
LinkADRReq [DR=3 Pwr=5 ChnlMsk=FF00 ChnlCntl=0 NbTrans=1]
is for 64-ch plan (@ 125 KHz BW) since the DR can only vary from 0 to 3.
And the end-device can only be operated in either 8-ch or 64-ch plan but not both at the same time.
Is that correct? Please advise.
As documented in the LoRaWAN specification, the first command disables all channels and enabled the 500kHz channels present in the mask (in this case the first channel), the only valid datarate is DR4 for such a command. The next command is to enable 8 channels from the first bank of 16, set the DR to 3 and set TxPower to 20dbm. The result is both the 125khz and 500 khz channel for the first bank is enabled, and the final DR is 3.
There are many combinations of channels that are valid for an end device all the way from 1 (500kHz) channel to all 64 125kHz + 8 500 kHz. The device as only a single channel plan at any given time.
Ok, thanks for clarifying.
Hi Dave,
I have a device (Dev Address: 1200849D) which it can no longer join network for some reasons. The last join was on 4/20 and both AppEui ( 00250C0000010001) and AppKey (661EC15004405CE03D855185E25DD2E2) are set up correctly to the best of my knowledge.
Can you help?
Thanks,
Charlie
Hello Charlie,
We can see that your device is attempting to join but is failing due to an incorrect appKey. A review of your devices shows the appKey provided belongs to a different device that is registered in your portal account. If you log into your portal account and Edit the Device there is an option to review the OTAA keys.
Please let us know if you require some additional assistance
Regards,
Mike
Thanks Mike. It’s working now.
Charlie
Hi Charlie,
Great! I was just typing a response as I noticed the device just successfully joined. Please let us know if you have any additional questions.
regards,
Mike
Mike,
I can see my end-device sending uplink data as expected.
One thing I notice is that it seems to skip the first 3 Seq No (0,1,2) and starts at 3. Do you have any idea?
Charlie
Hello Charlie,
The gateway that the device is communicating through is an 8 channel gateway. If your device is configured as recommended to initially attempt to join the network across the full 64 channels, then the first three lost packets are likely due to the fact that these uplinks were transmitted on channels that the Conduit gateway was not listening on. The device should transmit the first uplink from the same channel bank as the Join Request.
Regards,
Mike
Hi Mike,
So the join request channels show up on the portal are only the ones that the gateway listens to and forwards to the network server, right? Any join request sent outside of these 8 channels would not be received by the gateway.
Charlie
Hello Charlie,
Yes, that is correct.
As your device testing is leveraging a Conduit, this gateway only operates on the first bank of 8 channels by default. Any communication from the device outside of those channels will not be received by the gateway. By default the device is to attempt to join the network across each bank of 8 channels until successful. The initial uplink from the device is to Tx on the same channel band as the Join Accept was received. From there, the NWK server will direct the device to operate on the proper channel plan, data rate, and Tx power through ADR.
Regards,
Mike
Hi Mike,
Thanks for confirming.
I’ve seen several attempts for join request from my end-device but it’s not shown in the portal. This would explain why I’m seeing this.
Regards,
Charlie
Hi Charlie,
Yes, that would be the explanation.
Please continue to follow up with any additional questions.
Regards,
Mike
Mike,
My device hasn’t been able to join the network in the last couple days or so. I have tried several times but still without success.
Prior to this, it was working consistently without any issue. Do you have any idea?
Charlie
your gateway is no longer connected.
Just found out our network is down. Thanks for your help.
Hi,
I have a question about DevNonce during join request. From LoRaWAN specification, the DevNonce should be incremented for each join request. From my test, it is acting more like randomized number instead (see attachment). Can you comment on that?
Thanks!
