Im using a RAK 7258 (Semtech 1301 Lora demodulator)
I am testing the ADR on my Chirpstack (V 3.10.0) EU868 Lorawan 1.0.3
I see that if I reduce the path loss (and therefor increase the SNR at the GW), Chirpstack adapts the data rate as expected.
However when I then increase the path loss a few dB’s to stimulate ADR to reduce the DR (and or increase TX power), it doesnt really work well, and before it works, I get a lot of CRC_Errors at the GW.
Im currently using a low installation margin (4db) to try to get to to be more active. This works well at the very low path loss situations.
I see from a little digging that the ADR engine is using an SNR table:
// SpreadFactorToRequiredSNRTable contains the required SNR to demodulate a
// LoRa frame for the given spreadfactor.
// These values are taken from the SX1276 datasheet. (page 27)
var SpreadFactorToRequiredSNRTable = map[int]float64{
6: -5,
7: -7.5,
8: -10,
9: -12.5,
10: -15,
11: -17.5,
12: -20,
}
The first thing I notice is that this chip is not a Gateway IC.
My Questions:
Can I change this table to better suit my GW radio spec?
Is the table actually correct for the SM 1301 radio?
Is there a bias towards ADR pushing DR up more than down in steps?
Im using LMIC, (MCCI version) and yes, it starts OTAA join at DR5 (SF7), so if the end-device is far away (SNR should dictate an ADR command to reduce DR), my LMIC end-node seems to flounder and never really get sorted out by the chirpstack ADR engine!
Service Profile ADR Max DR = 5, Min DR=0
Installation margin = 10dB
I can work around this:
Before starting and OTAA joining my end-device, I set the service profile to MAX&MIN DR=0 (SF12).
Turn on the end-device, when it does get a join (at what ever DR gets a join (LMIC steps down in DR during join until success) )Chirpstack immediately commands it to DR0 (as per the service profile).
Then I change the service profile back to Max=5, Min=0.
I can watch the end-device get ADR commands over the next few frames get its DR increased to a state within correct setting range.
So, can I assume that Chirpstack ADR assumes most end-devices well join initially at DR0, and so get stepped up to the correct level?
If Lmic works the other way round and joins at DR5, Chirpstack ADR will not really work as well as it will have to command from DR5 stepping downwards?
For some reason, I have never seen chirpstack ADR command a DR reduction even after reducing the end-device SNR by more than margin?