Skip to main content
surumadurum
surumadurum
Associate III
May 13, 2024
Question

CubeWL RX delays incorrect?

  • May 13, 2024
  • 6 replies
  • 2058 views

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

This topic has been closed for replies.

6 replies

surumadurum
surumadurumAuthor
Associate III
May 13, 2024

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
surumadurumAuthor
Associate III
May 13, 2024

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

STTwo-32
STTwo-32
ST Technical Moderator
May 14, 2024

Hello @surumadurum 

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

Best Regards.

STTwo-32

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
surumadurum
surumadurumAuthor
Associate III
May 24, 2024

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.

surumadurum_0-1716553187660.png

Heres the first UnconfirmedDataDown

surumadurum_1-1716553239941.png

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?)

surumadurum_2-1716553786319.png

Strangely ChirpStack settings also tell me 1s RxDelay

surumadurum_3-1716554045258.png

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
surumadurumAuthor
Associate III
May 24, 2024

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
surumadurum_0-1716555774179.png


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



Terms & ConditionsAccessibility statement