CubeWL RX delays incorrect?

[surumadurum]

I have a CubeWL-based, CubeMX-generated LoRaWAN application (868Mhz region) on Helium (LNS tells me RX1 delay is 1s).

OTAA join and confirmed msg downlink reception seemed very unreliable, even with a gateway just in the other room (OTAA ± 5 tries, uplink confirmation received after ± 35 tries).
Now I tried RakWireless RUI3 framework and transmission work as expected, reliable OTAA join on first try as well as reception of uplink confirmations.

LNS shows me JoinAccept frames send "delay: 5s" and UnconfirmedDataDown frames send "delay: 2s" to device.

I tool a closer look at the timings and was wondering:
a) It looks like RX1 window is opening 2s after beginning of TX transmission. Shouldn't it be after the end of the transmission?

b) Why is the RX window increased by the LNS?

1715603464s576:TX on freq 868500000 Hz at DR 0
1715603465s732:MAC txDone
1715603466s575:RX_1 on freq 868500000 Hz at DR 0
1715603467s101:IRQ_RX_TX_TIMEOUT
1715603467s101:MAC rxTimeOut
1715603467s575:RX_2 on freq 869525000 Hz at DR 0
1715603468s101:IRQ_RX_TX_TIMEOUT
1715603468s101:MAC rxTimeOut

BTW, the OTAA join seems to be closer to "5s from end of transmission", and also works a lot more reliable

0s030:TX on freq 868100000 Hz at DR 0
1s488:MAC txDone
6s331:RX_1 on freq 868100000 Hz at DR 0
8s160:MAC rxDone

###### = JOINED = OTAA =====================

[surumadurum]

I increased  

LmHandlerSetSystemMaxRxError( 200 );

in LmHandler.c.
After reverting to 20ms, I see that it moves closer to "Rx delay after end of transmission + RxError window".
Also, receive window opens now 1s after txDone, but LNS sends after 2s...

1715606021s478:TX on freq 867700000 Hz at DR 0
1715606022s634:MAC txDone
1715606023s657:RX_1 on freq 867700000 Hz at DR 0
1715606023s854:IRQ_RX_TX_TIMEOUT
1715606023s854:MAC rxTimeOut
1715606024s657:RX_2 on freq 869525000 Hz at DR 0
1715606024s854:IRQ_RX_TX_TIMEOUT
1715606024s854:MAC rxTimeOut

[surumadurum]

When I lower max. RxError to 10ms, downlink frames seem to be received reliably... Does that make sense?

[STTwo-32]

Hello @surumadurum 

Can you give more details, some screenshots for the different cases ....

Best Regards.

STTwo-32

[surumadurum]

Ok, here's a situation where almost everything worked (OTAA join on first try, downlinks ACKed), but in the first downlink, LNS sets RX delay to 2 seconds, but RX1 is still opened after 1s.

Heres the first UnconfirmedDataDown

Here you can see, OTAA is 5s + 20ms RxError
First downlink is expected 1s + 20ms RxError
Second downlink should be 2s, but is still 1s (strangely MINUS ±20ms RxError?)

Strangely ChirpStack settings also tell me 1s RxDelay

But in general, RX_1 always times out and RX_2 comes to the rescue, but this should not be the standard behavior I guess...

[surumadurum]

And then there are situations where this goes just on and on with NACKs. OTAA most of the times works after some tries. This is with RSSI ±-60 and SNR of 8.8.

This took 11 tries to get an ACK here...

[POR]

1716555016s474:TX on freq 868100000 Hz at DR 0

1716555017s957:MAC txDone

1716555022s980:RX_1 on freq 868100000 Hz at DR 0

1716555023s178:IRQ_RX_TX_TIMEOUT

1716555023s178:MAC rxTimeOut

1716555023s980:RX_2 on freq 869525000 Hz at DR 0

1716555024s178:IRQ_RX_TX_TIMEOUT

1716555024s178:MAC rxTimeOut

###### = JOIN FAILED

###### = RE-TRYING OTAA JOIN

1716555024s184:TX on freq 868300000 Hz at DR 0

1716555025s668:MAC txDone

1716555030s691:RX_1 on freq 868300000 Hz at DR 0

1716555032s456:MAC rxDone

###### = JOINED = OTAA =====================

NVM DATA STORED

1716555052s459:Sending HEARTBEAT...

1716555052s463:TX on freq 868300000 Hz at DR 0

1716555052s465:[INFO] Successfully enqueued uplink...

1716555053s620:MAC txDone

1716555054s643:RX_1 on freq 868300000 Hz at DR 0

1716555054s841:IRQ_RX_TX_TIMEOUT

1716555054s841:MAC rxTimeOut

1716555055s643:RX_2 on freq 869525000 Hz at DR 0

1716555055s841:IRQ_RX_TX_TIMEOUT

1716555055s841:MAC rxTimeOut

###### ========== MCPS-Confirm =============

#Uplink-Counter:0001 | AppPort:20 | DataRate:0 | TxPwr:0 | MSG TYPE:CONFIRMED [NACK]

1716555072s465:Sending HEARTBEAT...

1716555072s469:TX on freq 867900000 Hz at DR 0

1716555072s471:[INFO] Successfully enqueued uplink...

1716555073s626:MAC txDone

1716555074s649:RX_1 on freq 867900000 Hz at DR 0

1716555074s847:IRQ_RX_TX_TIMEOUT

1716555074s847:MAC rxTimeOut

1716555075s649:RX_2 on freq 869525000 Hz at DR 0

1716555075s847:IRQ_RX_TX_TIMEOUT

1716555075s847:MAC rxTimeOut

###### ========== MCPS-Confirm =============

#Uplink-Counter:0002 | AppPort:20 | DataRate:0 | TxPwr:0 | MSG TYPE:CONFIRMED [NACK]

1716555092s471:Sending HEARTBEAT...

1716555092s475:TX on freq 867700000 Hz at DR 0

1716555092s476:[INFO] Successfully enqueued uplink...

1716555093s632:MAC txDone

1716555094s655:RX_1 on freq 867700000 Hz at DR 0

1716555094s852:IRQ_RX_TX_TIMEOUT

1716555094s852:MAC rxTimeOut

1716555095s655:RX_2 on freq 869525000 Hz at DR 0

1716555095s852:IRQ_RX_TX_TIMEOUT

1716555095s852:MAC rxTimeOut

###### ========== MCPS-Confirm =============

#Uplink-Counter:0003 | AppPort:20 | DataRate:0 | TxPwr:0 | MSG TYPE:CONFIRMED [NACK]

1716555112s476:Sending HEARTBEAT...

1716555112s480:TX on freq 867300000 Hz at DR 0

1716555112s482:[INFO] Successfully enqueued uplink...

1716555113s638:MAC txDone

1716555114s661:RX_1 on freq 867300000 Hz at DR 0

1716555114s858:IRQ_RX_TX_TIMEOUT

1716555114s858:MAC rxTimeOut

1716555115s661:RX_2 on freq 869525000 Hz at DR 0

1716555115s858:IRQ_RX_TX_TIMEOUT

1716555115s858:MAC rxTimeOut

###### ========== MCPS-Confirm =============

#Uplink-Counter:0004 | AppPort:20 | DataRate:0 | TxPwr:0 | MSG TYPE:CONFIRMED [NACK]

1716555132s482:Sending HEARTBEAT...

1716555132s486:TX on freq 868300000 Hz at DR 0

1716555132s488:[INFO] Successfully enqueued uplink...

1716555133s643:MAC txDone

1716555134s667:RX_1 on freq 868300000 Hz at DR 0

1716555134s864:IRQ_RX_TX_TIMEOUT

1716555134s864:MAC rxTimeOut

1716555135s667:RX_2 on freq 869525000 Hz at DR 0

1716555135s864:IRQ_RX_TX_TIMEOUT

1716555135s864:MAC rxTimeOut

###### ========== MCPS-Confirm =============

#Uplink-Counter:0005 | AppPort:20 | DataRate:0 | TxPwr:0 | MSG TYPE:CONFIRMED [NACK]

In LNS, all frames are received and ACKed

Is it possible they are not delivered by the gateway because of Duty Cycle restrictions?
When I try with RAK wireless firmware in same setup, everything works out of the box again...

[STTwo-32]

Hello @surumadurum 

I suggest you ensure that your Gateway configurations are fully compatible with the ones in your Nodes.

Best Regards.

STTwo-32