Downlink problems with new R11e-LR8G (not occur with R11e-LR8)

Hardware MikroTik IoT hardware
1

We operate a private LoRa network inside buildings, where we have a few dozen GW RBwAPR-2nD&R11e-LR8. We have now purchased several new RBwAPR-2nD&R11e-LR8G devices. After putting them into operation, we immediately noticed problems with downlink delivery (ACK) for confirmed uplinks.

The problem is that end devices often do not receive ACK for confirmed uplinks (they probably do not arrive in the expected RX1/RX2 window). This results in a significant number of retries because, from the end device's perspective, the ACK does not arrive and a retry occurs.

Environment
Region: EU868
Network server: ChirpStack (common for all devices)
Protocol: UDP (Smtech UDP packet-forwarder)
End devices: Class A, confirmed uplinks requiring ACK

I did experiments with different GWs under the same conditions (same network, same lorawan devices, same network server, mikrotiks set up identically, including NTP and iot/lora section settings). Tested with RouterOS 7.21.3 and 7.22rc1.

  • RBwAPR-2nD&R11e-LR8 (Semtech SX1301 chip): no problems
  • RBwAPR-2nD&R11e-LR8G (Semtech SX1302 chip): delivery problem

To eliminate the possibility of compatibility issues between the end device modem and the Semtech SX1302 chip, I also tested the GW SenseCAP M2 (with a Semtech SX1302 chip) under the same conditions and found no problems.

Several wAPs LR8G were tested to rule out a possible defect in a specific unit. This indicates that the problem is specific to the R11e-LR8G.

Can anyone confirm the same problem with downlinks, or whether their device with R11e-LR8G behaves normally?

Thanks

2

This also happens on the RBLtAP-2HnD&R11e-LTE&LR8G (the original model with LR8 works without issues).

The region setting on the ChirpStack Network Server (version 4.14) is at the default configuration. I tried changing the rx_window setting (RX1/RX2, RX1 only), but without success.

# RX window (Class-A).
#
# Set this to:
# 0: RX1 / RX2
# 1: RX1 only
# 2: RX2 only
rx_window=1

The RX1 delay is set to the default value of 1.

# RX1 delay (1 - 15 seconds).
rx1_delay=1

# RX1 data-rate offset
rx1_dr_offset=0
3

I did another tests. I installed a separate instance with latest version of the Chirpstack network server and registered 17 test devices to it. The error appeared again with LR8G. I tried increasing rx1_delay to 2s and 3s but without significant effect.

This leads me to believe that there is some bug related to LR8G.

4

Is LBT enabled in your case? Also is it private or public network?

5

LBT is disabled. Our end devices are Class A and operate in private indoor networks within the EU868 duty-cycle limits. Band interference is probably not the problem, analysis using SDR receiver does not indicate any interference in the area (it is not exact, just indikative).

Print from one of gws attached below.

/iot lora print detail
Flags: X - disabled
0   status="Active" firmware-id="0426c248" version="1.4.4" rx-packets=3018
tx-packets=0 tx-toa=0 name="loragw" gateway-id="04F41CFFFF0B31B4"
servers=NS (UDP) channel-plan=eu-868 antenna-gain=2dBi
forward=crc-validation,dev-addr-validation network=public lbt-enabled=no
listen-time=5000us rssi-threshold=-65dBm band=863-870 antenna=uFL

/iot lora channel print detail
Flags: X - disabled
0   name="loragw" type=MSF radio=radio1 freq-off=-400000 bandwidth=125_kHz freq=868.1
1   name="loragw" type=MSF radio=radio1 freq-off=-200000 bandwidth=125_kHz freq=868.3
2   name="loragw" type=MSF radio=radio1 freq-off=0 bandwidth=125_kHz freq=868.5
3   name="loragw" type=MSF radio=radio0 freq-off=-400000 bandwidth=125_kHz freq=867.1
4   name="loragw" type=MSF radio=radio0 freq-off=-200000 bandwidth=125_kHz freq=867.3
5   name="loragw" type=MSF radio=radio0 freq-off=0 bandwidth=125_kHz freq=867.5
6   name="loragw" type=MSF radio=radio0 freq-off=200000 bandwidth=125_kHz freq=867.7
7   name="loragw" type=MSF radio=radio0 freq-off=400000 bandwidth=125_kHz freq=867.9
8   name="loragw" type=LoRa radio=radio1 freq-off=-200000 bandwidth=250_kHz freq=868.3 spread-factor=SF7
9   name="loragw" type=FSK radio=radio1 freq-off=300000 bandwidth=125_kHz freq=868.8 datarate=50000

/iot lora radios print detail
Flags: X - disabled
0   name="loragw" type=SX1250 center-freq=867500000 tx-freq-min=863000000 tx-freq-max=870000000 rssi-off=-215.4 tx-enabled=yes
1   name="loragw" type=SX1250 center-freq=868500000 tx-freq-min=0 tx-freq-max=0 rssi-off=-215.4 tx-enabled=no

/iot lora servers print detail
0 name="TTS Cloud (eu1)" address="eu1.cloud.thethings.industries" up-port=1700 down-port=1700 protocol=UDP netid="" joineui=""
1 name="TTS Cloud (nam1)" address="nam1.cloud.thethings.industries" up-port=1700 down-port=1700 protocol=UDP netid="" joineui=""
2 name="TTS Cloud (au1)" address="au1.cloud.thethings.industries" up-port=1700 down-port=1700 protocol=UDP netid="" joineui=""
3 name="TTN V3 (eu1)" address="eu1.cloud.thethings.network" up-port=1700 down-port=1700 protocol=UDP netid="" joineui=""
4 name="TTN V3 (nam1)" address="nam1.cloud.thethings.network" up-port=1700 down-port=1700 protocol=UDP netid="" joineui=""
5 name="TTN V3 (au1)" address="au1.cloud.thethings.network" up-port=1700 down-port=1700 protocol=UDP netid="" joineui=""
6 name="NS (UDP)" address="udp........com" up-port=1700 down-port=1700 protocol=UDP netid="" joineui=""
6

Iā€™m a bit confused. Is it private or public network? Your print clearly says public.

7

Private means that we do not provide services publicly. The network itself has the setting network=public which should indicate SyncWord 0x34 which is for LoraWAN. The setting SyncWord private (0x12) should be for communication without a LoraWAN stack. If I understand this setting correctly.

I contacted support and attached some debug logs and supout.rif. Hopefully we can identify the problem.

1 Like