Device with OTAA fails 50 % of RX windows

Setup and configuration
1

Hi all, I have set up a ChirpStack OS on a RaspberryPI, which I operate in the AU_915 0-7 + 64.
The OTAA works perfectly and all the values look good to me. I’m using a RAK 813 and the end device is a Draguino LT - 33222-L, I also have tried a RAK 5205 and it’s behaving in a similar way with error 96 which is Timeout reached waiting for a packet in the LoRa RX2 Window. The server is set up with its defaults unchanged.

Joint Accept Delay 1 5000
Joint Accept Delay 2 6000
Receive Delay 1 1000
Receive Delay 2 2000
RX2 Window Data Rate 8
Rx2 Window Frequency 92330000

This is what I see on my end device output

***** UpLinkCounter= 569 *****
TX on freq 915.200 MHz at DR 5
RX on freq 923.300 MHz at DR 8
txDone
RX on freq 923.300 MHz at DR 13
RX on freq 923.300 MHz at DR 8
rxTimeOut

On the device I have channel 0-7 +64, 8-15 +65 enabled

On the Chirpstack server, I see about 50% of the packets arriving and I can decrypt these packets.
I don’t understand the first-second RX on freq 923.300 MHz at DR 13, I was under the impression that in OTAA the values of the RX window and frequency are passed from the Gateway to the end device.

Any help would be greatly appreciated.

2

It’s not clear that there’s anything going wrong here.

Most LoRaWAN uplink packets should not receive any downlink response. Yet the node has to briefly check for the start of a packet in each of the RX windows, because the server could send a downlink there. So most of the time, you should be seeing both RX windows time out.

It looks like the data rates in your RX windows are proper - uplink and downlink data rates are numbered differently, but if you look you’ll probably see that downlink DR13 is the same spreading factor as uplink DR5, conforming with the usual rule (absent an offset) that the RX1 downlink would use the same spreading factor as the triggering uplink, and the RX2 would use the fixed spreading factor configured.