ADR after join - starting at lower data rates instead of highest to be able to work better with Chirpstack ADR Algo

[Cloolalang]

Is your feature request related to a problem? Please describe. I have tested my LMIC device with Chirpstack, after power up and join at the highest data rate, chirpstack ADR engine can only adjust TX-power, (not data rate) This means that if a LMIC device starts up and joins far away from the gateway, it can struggle to adapt properly via ADR should the SNR be close to the noise floor limit. Chirpstack uses derivation of the SEMtech recommended ADR Algorithm for ADR processing. It works great for high SNR control as it can command an end-device up and down in TX power and up in data-rate,

BUT; Because the ADR cannot step the end-device downwards in data rate, and LMIC starts up at the highest data rate, the ADR is only effective at the high SNR end of the scale (nearby devices).

IF, we could have the option to start up our LMIC device in a lower data rate, then we would get the benefit of the chirpstack ADR control.

Lmic: 3.2.0 EU868, lorawan 1,0.3 A Chirpstack -3.10.0

P

[terrillmoore]

Hi @Cloolalang -- I am not a fan of the Chirpstack approach. They also initially set up multiple repeats, etc, which is very wasteful. Other network servers I've used (TTN, Actility, etc) seem to take a more reasonable approach for real-world applications.

You can experimentally work around this by manually setting the data rate after the join. In the MCCI BSPs, we have support for selecting the target network, and we could potentially set an LMIC_CONFIG_... variable that controls the post-join behavior. But we can't change the default behavior of the LMIC at this time.

[Cloolalang]

Hi Terry, Arr, that's very interesting. Its indeed fascinating to discover these "gray areas" of the Lorwan project!

When you mention multiple repeats, do you mean the NbRep ? . I ask because in my testing I have also seen duplicated LinkADRReq commands from chirpstack identical TX_power and DR settings,,quite strange...

I see cases/arguments for both ADR starting points:

https://www.thethingsnetwork.org/forum/t/start-otaa-join-on-sf7bw125-or-sf12bw125-eu-868mhz/15189/19

I will check with Chirpstack on the ADR implentation, or perhaps look to try another Algorithm.

Thanks for your quick response! p

[Cloolalang]

I had a poke around:

It looks like TTN like to get end-devices joined at SF8 in (EU868) for their ADR for be working:

https://github.com/TheThingsNetwork/ttn/blob/develop/core/networkserver/adr_test.go

[Cloolalang]

https://github.com/brocaar/chirpstack-application-server/issues/558

[tealbrains]

Hi @Cloolalang

Background [AU915, ESP32, SX1276, Chirpstack 3.0]

I am on the same boat here. I use Chirpstack and I have been facing the following:

• Join set to use SF10
• Join works, Join accept (therefore downlinks ok)
• After the join, the device starts transmitting but I can see a Downlink on the server after every Uplink. LMIC says that RX1 window is missed, and RX2 is also missed. These links are using SF12, as if the node was using SF12 as the safest approach before getting ADR confirmation from the server?

  1189684: [Event] TXCOMPLETE
  1189841: engineUpdate, opmode=0x900
  1603074: engineUpdate, opmode=0x908
  1603100: [Event] TXSTART
  1603126: TXMODE, freq=917200000, len=17, SF=12, BW=125, CR=4/5, IH=0
  Packet queued
  Temp: 18.500002 TTN_CayenneLPP: 1 67 00B9
  1747072: setupRx1 txrxFlags 0x20 --> 01
  start single rx: now-rxtime: 2
  1747700: RXMODE_SINGLE, freq=924500000, SF=12, BW=500, CR=4/5, IH=0
  1766648: Invalid downlink, window=RX1
  1809322: setupRx2 txrxFlags 0x1 --> 02
  start single rx: now-rxtime: 2
  1809950: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
  rxtimeout: entry: 1814572 rxtime: 1809946 entry-rxtime: 4626 now-entry: 64 rxtime-txend: 124376
  1814646: processRx2DnData txrxFlags 0x2 --> 00
  1814731: processDnData_norx txrxFlags 00 --> 20
  1814997: [Event] TXCOMPLETE

• My guess is these Downlinks must be ADR related requests. After many packets transmitted, the node is de-registered. Perhaps too many ADR fails?
• If I place the following under EV_JOINED (as @terrillmoore suggested) then I don't get the automatic Downlinks anymore after each Uplink, and I can actually schedule Downlinks manually and the node does receive the payload

  LMIC_setAdrMode(0);
  LMIC_setDrTxpow(AU915_DR_SF10, 14);

  It would be nice to be able to use ADR.

[tealbrains]

I had to set the Maximum and Minimum DR on Chirpstack.

• Join is done at SF12
• After around 10 exchanges things are settled between the node and Chirpstack.
• Chirpstack essentially keeps increasing the TX power on each iteration, even though it's receiving the Uplink. (Perhaps some kind of repetition as mentioned by @terrillmoore )
• Uplinks are sent with SF7

I will now be able to confirm @Cloolalang 's observations. I will also try to start the join procedure with the node placed further hoping it will use a higher SF after joining succesfully.

[Cloolalang]

I gave up with Chirpstack ADR and ended up turning it off on both network and device ends. For the time being I am setting up everything "manually". I did not see any way to change or set NBRep in LMIC either.