LinkAdrReq how to get join response with channel config?

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:

  1. 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:

1.0.2 Join Accept

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 and for EU868 in ADR problems - node of the same type have different ADR behaviour.

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