I’m making a US915 device and I need to get LinkAdrReq response from a join to correctly set the channel mapping. Even is ADR is activated, I do not get any specific response from TTN with the channel configuration.
Can you help me to find how to get this LinkAdrReq response from the network server ?
Paul
Don’t you get it right after the join? Or is it ABP?
https://www.thethingsnetwork.org/docs/lorawan/adr.html explains:
There are a several moments when an ADR request is scheduled or sent:
The initial ADR Request (for US915 and AU915). This is sent immediately after join and is mainly used to set the channel mask of the device. This one is a bit tricky, because we don’t have enough measurements for setting an accurate data rate. To avoid silencing the device, we use an extra “buffer” of a few dB here. This request is only needed with pre-LoRaWAN 1.1 on our v2 stack. With LoRaWAN 1.1 devices on our v3 stack, we can set the channel mask in the JoinAccept message. ABP devices pre-LoRaWAN 1.1 will only get this message once, if they reset after that, they won’t get the message again; this issue is also solved by LoRaWAN 1.1.
…
That is not clear. I get the ADR message only during the next communication and not during Join Procedure.
Joining LoRaWan
Join OK
…
Send LoRaWan
Proceed RegionUS915LinkAdrReq
Disable all Channels
Change channel chan[0] with FF00
That makes sense: this really is a workaround for the flaw in the 1.0.2 specifications that for US915 do not include the CFList with network settings in the Join Accept. A Join Accept message does not have the option to include additional MAC commands, so an additional downlink is needed, which can only be sent after receiving another uplink:
As for the first revision of your post in which you thought the actual ADR message was not okay: if you still have doubts then see an example for AU915 in LMIC Library Always Does Unwanted Downlink - #10 by arjanvanb and for EU868 in ADR problems - node of the same type have different ADR behaviour - #11 by arjanvanb.
1 Like
Thank for the response. I have no doubt, I changed my post after confirming it was Ok and I mis interpreted the result.
The part about the CFList in the JoinAccept message is unclear to me: The link you gave and the table show the CFList. I do not understand why this setting is not proceeded by my device. I’m 1.0.2 LoRaWan stack so I should process it isn’t it ?
Basically I’m not looking for ADR but for Channel configuration…
Unfortunately, like explained in LMIC Library Always Does Unwanted Downlink - #12 by arjanvanb for AU915, you also won’t get channel configuration in the Join Accept in LoRaWAN 1.0.2 for US915:
2.2.4 US902-928 JoinAccept CFList
The US902-928 LoRaWAN does not support the use of the optional CFlist appended to the JoinAccept message. If the CFlist is not empty it is ignored by the end-device.
1 Like
OK
Currently I’m not using LMIC but Semtech LoRaNode stack.
My question was more, does TheThingsNetwork send the CFList field or doesn’t it ?
Paul
How could The Things Network (spaces in its name!) do that? The community network of TTN implements LoRaWAN 1.0.2 which, like linked to above, simply does not define the contents of CFList for US915 nor AU915.
Peeking in 1.0.3 or 1.1 you’ll see that the definition of the US915 CFList is not the same as, e.g., the definition of the EU868 CFList. As a workaround, TTN implemented the initial ADR for AU915 and US915, which an OTAA device will get when its first uplink was received by TTN. That could take a while when the device randomly selects an unsupported channel for its first uplink(s).
1 Like
OK, that’s clear … I did not noticed the 1.0.2 do not defined the CFList field for US915 … LOL
Thank you for the help. Now I’m clear with all of this.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.