RAK3172 Difficulty joining

I am experiencing difficulties in joining with the RAK3172 modules.
Below I present the log of the Join process.

The first Join Request is sent at:
19:13:03.083 → api.lorawan.join(#0):true

After a little more than 9 seconds, it appears that a Timeout occurred in:
19:13:09.506 → +EVT:JOIN_FAILED_RX_TIMEOUT

However, I saw that afterwards, a reception seems to occur:
19:13:09.506 → Receiving MLME_JOIN

What does “Receiving MLME_JOIN” mean?

The waiting time is 10 seconds, checking the following:
19:13:13.086 → api.lorawan.njs.get():false

After checking that the Join did not work, do the first retry:
19:13:13.086 → api.lorawan.join(#1):true

It only worked in retry #8:
19:14:23.196 → api.lorawan.join(#8):true
19:14:28.638 → +EVT:JOINED

Despite using the LA915 band, I saw that the RX windows are the same as the AU915, with JN1DL = 5 and JN2DL = 6.

On the server side I can see that Join Requests are arriving and Join Replies are being sent.

Are Join Reply messages arriving outside of JN1DL and JN2DL’s reception tolerance?
Or are Join Replys arriving corrupted?

What could be happening?

Best Regards.

====================================== LOG ==================================

19:13:03.083 → api.lorawan.njs.get():false
19:13:03.083 → Frequency:0
19:13:03.083 → Rx1Frequency:0
19:13:03.083 → RxCFrequency:923300000
19:13:03.083 → ChannelsDatarate:2
19:13:03.083 → ChannelsTxPower:5
19:13:03.083 → FCntUp:0
19:13:03.083 → api.lorawan.join(#0):true
19:13:09.506 → +EVT:JOIN_FAILED_RX_TIMEOUT
19:13:09.506 → Receiving MLME_JOIN
19:13:09.506 → DevAddr:00000000
19:13:09.506 → joinCallback:4
19:13:13.086 → api.lorawan.njs.get():false
19:13:13.086 → Frequency:0
19:13:13.086 → Rx1Frequency:0
19:13:13.086 → RxCFrequency:923300000
19:13:13.086 → ChannelsDatarate:6
19:13:13.086 → ChannelsTxPower:5
19:13:13.086 → FCntUp:0
19:13:13.086 → api.lorawan.join(#1):true
19:13:19.178 → +EVT:JOIN_FAILED_RX_TIMEOUT
19:13:19.178 → Receiving MLME_JOIN
19:13:19.223 → DevAddr:00000000
19:13:19.223 → joinCallback:4
19:13:23.125 → api.lorawan.njs.get():false
19:13:23.125 → Frequency:0
19:13:23.125 → Rx1Frequency:0
19:13:23.125 → RxCFrequency:923300000
19:13:23.125 → ChannelsDatarate:2
19:13:23.125 → ChannelsTxPower:5
19:13:23.125 → FCntUp:0
19:13:23.125 → api.lorawan.join(#2):true
19:13:29.541 → +EVT:JOIN_FAILED_RX_TIMEOUT
19:13:29.541 → Receiving MLME_JOIN
19:13:29.541 → DevAddr:00000000
19:13:29.541 → joinCallback:4
19:13:33.119 → api.lorawan.njs.get():false
19:13:33.119 → Frequency:0
19:13:33.119 → Rx1Frequency:0
19:13:33.119 → RxCFrequency:923300000
19:13:33.119 → ChannelsDatarate:6
19:13:33.119 → ChannelsTxPower:5
19:13:33.119 → FCntUp:0
19:13:33.119 → api.lorawan.join(#3):true
19:13:39.209 → +EVT:JOIN_FAILED_RX_TIMEOUT
19:13:39.209 → Receiving MLME_JOIN
19:13:39.256 → DevAddr:00000000
19:13:39.256 → joinCallback:4
19:13:43.158 → api.lorawan.njs.get():false
19:13:43.158 → Frequency:0
19:13:43.158 → Rx1Frequency:0
19:13:43.158 → RxCFrequency:923300000
19:13:43.158 → ChannelsDatarate:2
19:13:43.158 → ChannelsTxPower:5
19:13:43.158 → FCntUp:0
19:13:43.158 → api.lorawan.join(#4):true
19:13:49.581 → +EVT:JOIN_FAILED_RX_TIMEOUT
19:13:49.581 → Receiving MLME_JOIN
19:13:49.581 → DevAddr:00000000
19:13:49.581 → joinCallback:4
19:13:53.169 → api.lorawan.njs.get():false
19:13:53.169 → Frequency:0
19:13:53.169 → Rx1Frequency:0
19:13:53.169 → RxCFrequency:923300000
19:13:53.169 → ChannelsDatarate:6
19:13:53.169 → ChannelsTxPower:5
19:13:53.169 → FCntUp:0
19:13:53.169 → api.lorawan.join(#5):true
19:13:59.216 → +EVT:JOIN_FAILED_RX_TIMEOUT
19:13:59.263 → Receiving MLME_JOIN
19:13:59.263 → DevAddr:00000000
19:13:59.263 → joinCallback:4
19:14:03.172 → api.lorawan.njs.get():false
19:14:03.172 → Frequency:0
19:14:03.172 → Rx1Frequency:0
19:14:03.172 → RxCFrequency:923300000
19:14:03.172 → ChannelsDatarate:2
19:14:03.172 → ChannelsTxPower:5
19:14:03.172 → FCntUp:0
19:14:03.172 → api.lorawan.join(#6):true
19:14:09.602 → +EVT:JOIN_FAILED_RX_TIMEOUT
19:14:09.602 → Receiving MLME_JOIN
19:14:09.602 → DevAddr:00000000
19:14:09.602 → joinCallback:4
19:14:13.187 → api.lorawan.njs.get():false
19:14:13.187 → Frequency:0
19:14:13.187 → Rx1Frequency:0
19:14:13.187 → RxCFrequency:923300000
19:14:13.187 → ChannelsDatarate:6
19:14:13.187 → ChannelsTxPower:5
19:14:13.187 → FCntUp:0
19:14:13.187 → api.lorawan.join(#7):true
19:14:19.285 → +EVT:JOIN_FAILED_RX_TIMEOUT
19:14:19.285 → Receiving MLME_JOIN
19:14:19.285 → DevAddr:00000000
19:14:19.285 → joinCallback:4
19:14:23.196 → api.lorawan.njs.get():false
19:14:23.196 → Frequency:0
19:14:23.196 → Rx1Frequency:0
19:14:23.196 → RxCFrequency:923300000
19:14:23.196 → ChannelsDatarate:2
19:14:23.196 → ChannelsTxPower:5
19:14:23.196 → FCntUp:0
19:14:23.196 → api.lorawan.join(#8):true
19:14:28.638 → +EVT:JOINED
19:14:28.638 → joinCallback:0
19:14:28.638 → Receiving MLME_JOIN
19:14:28.684 → DevAddr:179eb2c6
19:14:33.246 → api.lorawan.njs.get():true
19:14:33.246 → join():8

LA915 is an unofficial LoRaWAN region, implemented in RUI3 on the request of some South American users.

Is your gateway supporting LA915? What gateway are you using?

Is your LoRaWAN server supporting LA915? What LoRaWAN server are you using?

How close are the node and the gateway during the test? If very close, did you try to reduce the TX power on the node?

Hello Bernd, I’m part of that South American team that you mentioned.

Q: Is your gateway supporting LA915? What gateway are you using?

A: The gateway operates on LA915. I don’t know the answer to the brand and model of the gateway. The provider is called EveryNet.

Q: Is your LoRaWAN server supporting LA915? What LoRaWAN server are you using?

A: I think EveryNet servers also support LA915. And I also won’t be able to tell you which server EveryNet uses.

Q: How close are the node and the gateway during the test? If very close, did you try to reduce the TX power on the node?

A: From the EveryNet dashboard I was able to see that there are some gateways around, but none of them are so close to causing problems.
I have the ADR active “AT+ADR=1” and I believe that the Data Rate and TX Power control must be automatically controlled.

What does “Receiving MLME_JOIN” that appears after “+EVT:JOIN_FAILED_RX_TIMEOUT” mean that a join reply message was received?

Best Regards.

My problem is that we have neither gateways nor a LoRaWAN server that supports LA915, so it is difficult to test and check what the problem could be.

+EVT:JOIN_FAILED_RX_TIMEOUT

Means that the device didn’t receive the JOIN accept message from the LNS within the two RX windows.

What you can try is to change the join delay 1 and 2 with the AT commands AT+JN1DL/ AT+JN2DL commands.

The message combination

19:13:19.178 → Receiving MLME_JOIN
19:13:19.223 → DevAddr:00000000

means that the device is in the Join process, but the device address (assigned by the LoRaWAN server) is 0, which should not be.

I will confirm with the R&D team about the complete meaning of that message.