LoRaWAN: 7.0.0 only uses 3 channels on EU868

[MortenGuldager]

After upgrading to radiolib 7.0.0 my lorawan device only uses the 3 default channels. Same when running the lorawan_starter example.

A screenshot from the LNS (chirpstack)

I upgraded around the 17th (7.0.0 release day)

Setup is:

• RFM95
• ESP32
• platformio
• chirpstack

[StevenCellist]

Very interesting. Can you enable the protocol-debug flag, and show us the output of a join cycle?

[MortenGuldager]

Here you go. join/accept and the next two uplink/downlink pairs

Setup ... 
Initialise the radio
Join ('login') the LoRaWAN Network
RLB_PRO: Setting up dynamic channels
RLB_PRO: UL:   0 1 868.100 (0 - 5) | DL:   0 1 868.100 (0 - 5)
RLB_PRO: UL:   1 1 868.300 (0 - 5) | DL:   1 1 868.300 (0 - 5)
RLB_PRO: UL:   2 1 868.500 (0 - 5) | DL:   2 1 868.500 (0 - 5)
RLB_PRO: [MAC] 0x03
RLB_PRO: 00000000: 20                                                                 
RLB_PRO: LinkAdrReq: dataRate = 2, txSteps = 0, nbTrans = 0
RLB_PRO: LinkAdrAns: 07
RLB_PRO: [MAC] 0x04
RLB_PRO: 00000000: 07                                               .                 
RLB_PRO: DutyCycleReq: max duty cycle = 1/2^7
RLB_PRO: [MAC] 0x05
RLB_PRO: 00000000: 00 d2 ad 84                                      ....              
RLB_PRO: RXParamSetupReq: Rx1DrOffset = 0, rx2DataRate = 0, freq = 869.525
RLB_PRO: [MAC] 0x08
RLB_PRO: 00000000: 01                                               .                 
RLB_PRO: RXTimingSetupReq: delay = 1 sec
RLB_PRO: [MAC] 0x09
RLB_PRO: 00000000: 05                                               .                 
RLB_PRO: [MAC] 0x0c
RLB_PRO: 00000000: 65                                               e                 
RLB_PRO: ADRParamSetupReq: limitExp = 6, delayExp = 5
RLB_PRO: [MAC] 0x0f
RLB_PRO: 00000000: fa                                               .                 
RLB_PRO: RejoinParamSetupReq: maxTime = 15, maxCount = 10
RLB_PRO: 
RLB_PRO: PHY:  Frequency UL = 868.100 MHz
RLB_PRO: LoRa: SF = 10, TX = 16 dBm, BW = 125.0 kHz, CR = 4/5
RLB_PRO: JoinRequest sent (DevNonce = 0) <-- Rx Delay start
RLB_PRO: 00000000: 00 00 00 00 00 00 00 00 00 eb be be ba fe ca ad  ................
RLB_PRO: 00000010: de 00 00 fe 68 9c ac                             ....h..           
RLB_PRO: 
RLB_PRO: PHY:  Frequency DL = 868.100 MHz
RLB_PRO: LoRa: SF = 10, TX = 16 dBm, BW = 125.0 kHz, CR = 4/5
RLB_PRO: Opening Rx1 window (232 ms timeout)... <-- Rx Delay end 
RLB_PRO: Closing Rx1 window
RLB_PRO: JoinAccept (JoinNonce = 3, previously 0):
RLB_PRO: 00000000: 20 03 00 00 00 00 00 10 de e3 01 80 01 a3 9e 0b   ...............
RLB_PRO: 00000010: 4c                                               L                 
RLB_PRO: LoRaWAN revision: 1.1
RLB_PRO: Setting up dynamic channels
RLB_PRO: UL:   0 1 868.100 (0 - 5) | DL:   0 1 868.100 (0 - 5)
RLB_PRO: UL:   1 1 868.300 (0 - 5) | DL:   1 1 868.300 (0 - 5)
RLB_PRO: UL:   2 1 868.500 (0 - 5) | DL:   2 1 868.500 (0 - 5)
RLB_PRO: [MAC] 0x05
RLB_PRO: 00000000: 00 d2 ad 84                                      ....              
RLB_PRO: RXParamSetupReq: Rx1DrOffset = 0, rx2DataRate = 0, freq = 869.525
RLB_PRO: [MAC] 0x08
RLB_PRO: 00000000: 01                                               .                 
RLB_PRO: RXTimingSetupReq: delay = 1 sec
Ready!

Sending uplink
RLB_PRO: Uplink MAC payload:
RLB_PRO: 00000000: 0b 01                                            ..                
RLB_PRO: Uplink (FCntUp = 0) decoded:
RLB_PRO: 00000000: 00 89 78 56 3c 22 c9 3f 7b 10 00 00 a4 f6 c8 3f  ..xV<".?{......?
RLB_PRO: 00000010: 40 10 de e3 01 82 00 00 10 5c 01 b5 a3 6c 20 20  @........\...l  
RLB_PRO: 00000020: 20 20                                                              
RLB_PRO: 
RLB_PRO: PHY:  Frequency UL = 868.500 MHz
RLB_PRO: LoRa: SF = 10, TX = 16 dBm, BW = 125.0 kHz, CR = 4/5
RLB_PRO: Uplink sent <-- Rx Delay start
RLB_PRO: 
RLB_PRO: PHY:  Frequency DL = 868.500 MHz
RLB_PRO: LoRa: SF = 10, TX = 16 dBm, BW = 125.0 kHz, CR = 4/5
RLB_PRO: Opening Rx1 window (232 ms timeout)... <-- Rx Delay end 
RLB_PRO: Closing Rx1 window
RLB_PRO: Downlink (NFCntDown = 0) encoded:
RLB_PRO: 00000000: 49 00 00 00 00 01 10 de e3 01 00 00 00 00 00 23  I..............#
RLB_PRO: 00000010: 60 10 de e3 01 80 00 00 00 af 76 69 ea 3b 33 e9  `.........vi.;3.
RLB_PRO: 00000020: f7 4b d2 a4 a3 6c 10 a7 2c b0 f8 5d 8e 19 2a 68  .K...l..,..]..*h
RLB_PRO: 00000030: 27 b9 d1 12 04 db e5                             '......           
RLB_PRO: [MAC] 0x0b
RLB_PRO: 00000000: 01                                               .                 
RLB_PRO: RekeyConf: server version = 1.1
RLB_PRO: [MAC] 0x07
RLB_PRO: 00000000: 03 18 4f 84 70                                   ..O.p             
RLB_PRO: [MAC] 0x07
RLB_PRO: 00000000: 04 e8 56 84 70                                   ..V.p             
RLB_PRO: [MAC] 0x07
RLB_PRO: 00000000: 05 b8 5e 84 70                                   ..^.p             
RLB_PRO: [MAC] 0x06
RLB_PRO: DevStatusAns: status = 0xff0d
RLB_PRO: [MAC] 0x05
RLB_PRO: 00000000: 00 00 00 00                                      ....              
RLB_PRO: RXParamSetupReq: Rx1DrOffset = 0, rx2DataRate = 0, freq =   0.000
Received a downlink
Next uplink in 60 seconds

Sending uplink
RLB_PRO: Uplink MAC payload:
RLB_PRO: 00000000: 07 01 07 01 07 01 06 ff 0d 05 06                 ...........       
RLB_PRO: Uplink (FCntUp = 1) decoded:
RLB_PRO: 00000000: 9b 89 78 56 70 22 c9 3f 47 10 00 00 a4 f6 c8 3f  ..xVp".?G......?
RLB_PRO: 00000010: 40 10 de e3 01 8b 01 00 67 f0 a9 fd b5 49 df 81  @.......g....I..
RLB_PRO: 00000020: e3 d3 dc 01 c5 9e 1e a7 2c b0 f8                 ........,..       
RLB_PRO: 
RLB_PRO: PHY:  Frequency UL = 868.100 MHz
RLB_PRO: LoRa: SF = 10, TX = 16 dBm, BW = 125.0 kHz, CR = 4/5
RLB_PRO: Uplink sent <-- Rx Delay start
RLB_PRO: 
RLB_PRO: PHY:  Frequency DL = 868.100 MHz
RLB_PRO: LoRa: SF = 10, TX = 16 dBm, BW = 125.0 kHz, CR = 4/5
RLB_PRO: Opening Rx1 window (232 ms timeout)... <-- Rx Delay end 
RLB_PRO: Closing Rx1 window
RLB_PRO: Downlink (NFCntDown = 1) encoded:
RLB_PRO: 00000000: 49 00 00 00 00 01 10 de e3 01 01 00 00 00 00 12  I...............
RLB_PRO: 00000010: 60 10 de e3 01 8a 01 00 c0 49 b0 db 70 78 b5 7f  `........I..px..
RLB_PRO: 00000020: e5 d0 07 b2 3e bd                                ....>.            
RLB_PRO: [MAC] 0x03
RLB_PRO: 00000000: 53 07 00 00 00 00 00 00 00 00 00 00 00 01        S.............    
RLB_PRO: LinkAdrReq: dataRate = 5, txSteps = 3, nbTrans = 1
RLB_PRO: UL:   0 1 868.100 (0 - 5) | DL:   0 1 868.100 (0 - 5)
RLB_PRO: UL:   1 1 868.300 (0 - 5) | DL:   1 1 868.300 (0 - 5)
RLB_PRO: UL:   2 1 868.500 (0 - 5) | DL:   2 1 868.500 (0 - 5)
RLB_PRO: LinkAdrAns: 07
RLB_PRO: [MAC] 0x05
RLB_PRO: 00000000: 00 00 00 00                                      ....              
RLB_PRO: RXParamSetupReq: Rx1DrOffset = 0, rx2DataRate = 0, freq =   0.000
Received a downlink
Next uplink in 60 seconds

[StevenCellist]

It appears you are using custom channels (as they are configured through downlink, not CFList) which are rejected. What channel plan did you define on Chirpstack? Please dump the whole of it

[StevenCellist]

Actually, I see that I can 'translate' it from the logs - your channel plan allows all additional channels to use datarate 0 through 7. Three things to note about datarate 7:

1. datarate 7 uses FSK modulation instead of LoRa,
2. gateways can only listen to one FSK frequency, not five at the same time,
3. RadioLib's LoRaWAN stack is not (yet) able to switch to FSK.

The third point is the reason why these channels are rejected (RadioLib 6.x would accept them, but that's not meant to happen as the device can't use the whole range of datarates). To solve this problem, you'll have to improve your Chirpstack channel plan by removing datarate 7 from the normal channels.
We're working on adding support for switching to different modulations on-the-go, but until then datarate 7 is not supported (besides gateways only being able to listen to one FSK channel).

[HeadBoffin]

As irritating as this statement will be, the gold standard we work to is TTN. The Chirpstack I use for testing (a whole range of things, but particularly RadioLib) is as is out the box, nothing special setup. Depending on your setup, it's always worth testing either against TTN or swap your Chirpstack over to a minimally configured one - I do this with an SD Card swap at present but I'm looking at scripting that.

[MortenGuldager]

Unfortunately I dont have shell access to the server. I have asked the sysadmin for the chirpstack-network-server.toml file.
I found this in the gui, which might answer the question:

I will spin up my own chirpstack and try it there and on TTN while I wait for the sysamin to get back to me with the file.

[StevenCellist]

No need for the toml - the screenshot tells the same story. This is such a screwed setup, I already noticed a bit in the logs, but see that Rx2 frequency... Wrong on so many levels!!
But as noted from the logs and now confirmed with the screenshot, the configured datarate 7 is not acknowledged by RadioLib and thus should be modified. As well as being plain incorrect as gateways can 'physically' only listen to one channel for DR7.

[MortenGuldager]

Thanks @StevenCellist and @HeadBoffin

Now I can add some substance to the discussions I'm going to have...

[MortenGuldager]

Quickly spun up a chirpstack and now I see channel allocation work as expected, 8 channels get an even usage.
Simply used the default eu868 region definition from the chirpstack distribution. Now it looks like:

Do you see anything that should cause concern?

[StevenCellist]

This looks all good! Datarates 0-5 are pretty standard, DR6 non-standard but just as good (still LoRa but double bandwidth). It's the DR7 that's causing issues on the 'real' setup, as well as disabling Rx2 which is so against the spec, and may lead to very much undefined behaviour at the device side.