RX_WINDOW2 - rxTimeout

Devices
1

Hi everyone,

My setup is a based on the raspbian solution with an IMST concentrator and two end nodes with the Murata CMWX1ZZABZ chip.

I have calculated the values for [SystemMaxRxError] and [MinRxSymbols] according to the pdf document from Semtech: https://www.semtech.com/uploads/documents/an1200.24.pdf

I quote below the output of one EndNode after the JOIN procedure, when transmitting:

[19:25:38:265] ␍*** seqTx= 102 *****␊
[19:25:38:271] ␍TX on freq 868300000 Hz at DR 5␊
[19:25:38:271] ␍txDone␊
[19:25:38:343] ␍RX on freq 868300000 Hz at DR 5␊
[19:25:39:301] ␍rxDone␊
[19:25:39:390] ␍<break>
[19:25:48:280] SEND REQUEST␊
[19:25:48:282] ␍␊
[19:25:48:287] ␍*** seqTx= 103 *****␊
[19:25:48:287] ␍TX on freq 868300000 Hz at DR 5␊
[19:25:48:296] ␍txDone␊
[19:25:48:362] ␍RX on freq 868300000 Hz at DR 5␊
[19:25:49:315] ␍rxTimeOut␊
[19:25:49:400] ␍RX on freq 869525000 Hz at DR 0␊
[19:25:50:405] ␍rxTimeOut␊
[19:25:50:567] ␍␊
[19:25:55:493] ␍*** seqTx= 103 *****␊
[19:25:55:498] ␍TX on freq 868100000 Hz at DR 5␊
[19:25:55:505] ␍txDone␊
[19:25:55:567] ␍RX on freq 868100000 Hz at DR 5␊
[19:25:56:528] ␍rxTimeOut␊
[19:25:56:614] ␍RX on freq 869525000 Hz at DR 0␊
[19:25:57:621] ␍rxTimeOut␊
[19:25:57:780] ␍SEND REQUEST␊
[19:25:58:284] ␍␊
[19:26:02:706] ␍*** seqTx= 103 *****␊
[19:26:02:711] ␍TX on freq 868500000 Hz at DR 4␊
[19:26:02:719] ␍txDone␊
[19:26:02:840] ␍RX on freq 868500000 Hz at DR 4␊
[19:26:03:804] ␍rxTimeOut␊
[19:26:03:893] ␍RX on freq 869525000 Hz at DR 0␊
[19:26:04:891] ␍rxTimeOut␊
[19:26:05:053] ␍SEND REQUEST␊
[19:26:08:285] ␍␊
[19:26:16:125] ␍*** seqTx= 103 *****␊
[19:26:16:125] ␍TX on freq 868100000 Hz at DR 4␊
[19:26:16:125] ␍txDone␊
[19:26:16:254] ␍RX on freq 868100000 Hz at DR 4␊
[19:26:17:218] ␍rxTimeOut␊
[19:26:17:307] ␍SEND REQUEST␊
[19:26:18:287] ␍RX on freq 869525000 Hz at DR 0␊
[19:26:18:308] ␍rxTimeOut␊
[19:26:18:479] ␍SEND REQUEST␊
[19:26:28:288] ␍␊
[19:26:29:539] ␍*** seqTx= 103 *****␊
[19:26:29:539] ␍TX on freq 868500000 Hz at DR 3␊
[19:26:29:539] ␍txDone␊
[19:26:29:781] ␍RX on freq 868500000 Hz at DR 3␊
[19:26:30:756] ␍rxTimeOut␊
[19:26:30:845] ␍RX on freq 869525000 Hz at DR 0␊
[19:26:31:832] ␍rxTimeOut␊
[19:26:31:994] ␍SEND REQUEST␊
[19:26:38:290] ␍SEND REQUEST␊
[19:26:48:292] ␍␊
[19:26:54:245] ␍*** seqTx= 103 *****␊
[19:26:54:250] ␍TX on freq 868100000 Hz at DR 3␊
[19:26:54:250] ␍txDone␊
[19:26:54:492] ␍RX on freq 868100000 Hz at DR 3␊
[19:26:55:463] ␍rxDone␊
[19:26:55:661] ␍SEND REQUEST␊
[19:26:58:295] ␍<break>
[19:27:08:298] SEND REQUEST␊
[19:27:08:299] ␍<break>
[19:27:18:302] SEND REQUEST␊
[19:27:18:303] ␍<break>
[19:27:28:317] SEND REQUEST␊
[19:27:28:333] ␍␊
[19:27:28:333] ␍*** seqTx= 104 *****␊
[19:27:28:333] ␍TX on freq 868500000 Hz at DR 5␊
[19:27:28:333] ␍txDone␊
[19:27:28:395] ␍RX on freq 868500000 Hz at DR 5␊
[19:27:29:352] ␍rxDone␊
[19:27:29:444] ␍<break>
[19:27:38:334] SEND REQUEST␊
[19:27:38:338] ␍␊
[19:27:38:338] ␍*** seqTx= 105 *****␊
[19:27:38:338] ␍TX on freq 868100000 Hz at DR 5␊
[19:27:38:347] ␍txDone␊
[19:27:38:409] ␍RX on freq 868100000 Hz at DR 5␊
[19:27:39:373] ␍rxDone␊
[19:27:39:453] ␍<break>
[19:27:48:350] SEND REQUEST␊

As we can see the algorithm for ADR works fine as it increments and decrements the datarate according to the signal quality.

But, when a rxTimeout occurs in the RX1 slot then the RX2 slot is always unable to receive the data in DR 0.

As mentioned in Lorawan Specification 1.0.2:

3.3.2 Second receive window channel, data rate, and start
The second receive window RX2 uses a fixed configurable frequency and data rate and
opens RECEIVE_DELAY2 1 seconds (+/- 20 microseconds) after the end of the uplink
modulation. The frequency and data rate used can be modified through MAC commands
(see Section 5).The default frequency and data rate to use are region specific and detailed
in the LoRaWAN Regional Parameters document [PARAMS].

the default data rate, as found in RegionEU868.h

/*!
 * Default datarate used by the node
 */
#define EU868_DEFAULT_DATARATE                      DR_0

As a result to this problem is that if the RX1 fails more than 2 times and RX2 is unable to receive in DR0, the ADR procedure starts and takes long time (3-5 minutes) till the next successful reception.

Please, if someone can guide me where to start searching, it would really be appreciated.

Thank you in advance

2

Hi to all again…

this morning I tested the nodes with another loraserver. With the same hardware I redirected the packet-forwarder to a cloud loraserver.

I realized that the end nodes were able to receive in the RX2 window with DR_0 (EU868_DEFAULT_DATARATE). The program in the end nodes is exactly the same.

Is there any possibility that the problem is in loraserver. Something like a configuration that I am missing out?

The loraserver version is 0.26.3 and the lora-gateway-server version is 2.4.1.

Thank you in advance for helping

3

Please note that LoRa Server uses RX1 only currently. Only in case of Class C RX2 is used.

4

Hi @brocaar,

does this happen to the latest version 2.0.1 of lora server also?

5

Is there a reason for this? Are there plans for using RX2 eventually?

6

I noticed that working with semtech’s loraserver, when for some reason RX1 window fail to receive the data, the RX2 window comes with DR0 and saves the day.

So no re-transmission and ADR negotiation is needed.

7

Please note that this requires the gateway to transmit the frame twice. This not only costs more airtime, but during the transmission, the gateway is unable to receive data from other devices (most gateways). In larger networks with many devices, this is not ideal.

It is better to recover from packet-loss on the application layer.