Intermittent TX_TIMEOUT on RAK3172/3272S – No JoinRequest received by ChirpStac

ELVIS_WINE · June 23, 2025, 5:48pm

Hi everyone,

I’m experiencing an intermittent issue with a RAK3272S module (RUI3 firmware, using Arduino IDE). The OTAA parameters are set correctly, and in some cases the device joins the network and works fine, but most of the time the join fails with this log:

DevEUI: AC1F09FFFE111264
AppEUI: 0000000000000000
AppKey: C34A6E1556D0A1F2A5DA6B8513C84791
AppEUI set successfully
AppKey set successfully
DevEUI set successfully
Join started successfully
Attempting to join...
+EVT:JOIN_FAILED_TX_TIMEOUT

Other devices with the same code and configuration (only different DevEUI) can join without any problem through the same gateway (ChirpStack on Raspberry Pi with Semtech concentrator).

When the join fails, no JoinRequest is seen in ChirpStack – not even in the gateway logs. It looks like the packet is never transmitted.

There are any other setting to get a more granular view on what’s going on in the tx process?

carlrowan · June 24, 2025, 12:43am

Hi @ELVIS_WINE ,

On joining issues where no join uplink was received by the LNS and no logs on the gateway, the issue can be on the device. Maybe a problem related to RF transmission, bug on the fw, module hw issue, etc.

Some ideas:

Since it is intermittent and sometimes joins, are the RSSI and SNR readings ok and not too low/marginal when you have successful uplinks?
Have you check if there’s anything wrong on the antenna?
How about reuploading the FW? Even having full chip erase then reupload the hex file.
Also maybe you can test it in LoRa P2P just to get idea how the module’s internal RF section is behaving.

ELVIS_WINE · June 24, 2025, 5:27am

Hi @carlrowan,

Thanks for the suggestions. Here’s what I’ve tried so far and some additional observations:

Reflashing firmware
I’ve performed a full chip erase and reuploaded the .hex for both the RAK3272S final and the RAK3172 final firmwares, but the intermittent join issue persists. Sometimes it succeeds, but more often it times out without any JoinRequest seen on the gateway.
RSSI/SNR readings before join
While waiting for a successful join, if I query the module with:

AT+RSSI

it returns 0, and similarly AT+SNR returns 0. I understand that before a join actually happens there is no packet to measure, so those zeroes likely just reflect “no packet received.”
However, when uplinks do eventually get through and the gateway logs them, I see values like:

RSSI: around –62 dBm (sometimes –55 dBm)
SNR: around 11 to 12 dB
These are good link metrics, so when the module does manage to transmit, the link budget appears sufficient.

Antenna swap
I swapped in a known-good antenna from another RAK module, but the behavior is unchanged: intermittent join, most attempts time out without the JoinRequest ever appearing at the gateway.

Alternative tests to verify antenna transmission without P2P
Since I can’t free another module for a P2P test right now, are there other ways to confirm that the antenna (and RF chain) is actually transmitting on-air?

beegee · June 24, 2025, 5:38am

Jumping in here with a maybe stupid question, as we have two RAK3172 variants, one with a “simple” crystal and one with a TCXO. And the firmware for the two modules are not the same.
A breakout board should never have a RAK3172-T with TCXO, but who knows. And the TX problems somehow point to a mismatch with either the module or the firmware.

What is on the label of the RAK3172 breakout board. Is there somewhere a (T), (TI) or (TP) printed?
It should not be, but please check.

What does AT+VER return?
It should be something like AT+VER=RUI_4.2.1_RAK3172-E
If you get something with a -T, like AT+VER=RUI_4.2.1_RAK3172-T then the firmware is for the TCXO version.

ELVIS_WINE · June 24, 2025, 6:17am

Hi @beegee,

Thanks for the insight. Here are the details from my module:

AT+VER
AT+VER=RUI_4.2.1_RAK3272-SiP
OK

Board labeling:
- One side is marked “RAK3172 (P)”
- The opposite side reads “RAK3272S VER C 8261007X”

beegee · June 24, 2025, 6:29am

Which module is on the breakout board?

If it is the left one, you have the wrong firmware.

If it is the right one, you should have the correct firmware, but that is the RAK3272-SiP breakout board, not the RAK3272 breakout board.

ELVIS_WINE · June 24, 2025, 6:35am

Thx! It is the left one!. So I tried: “RAK3172-E_latest_final.hex”, it is the right one?
Btw, I get always the same " +EVT:JOIN_FAILED_TX_TIMEOUT" and no evidence on the gateway log.

beegee · June 24, 2025, 6:55am

RAK3172-E_latest_final.hex is the correct firmware for the RAK3272 breakout board.

After flashing the correct firmware, did you double check that LoRaWAN region, DevEUI, AppEUI, AppKey and subband are still correct.

Just flashing the firmware should keep the old values, but better to double check.

And last check (I don’t think that is the case, but again …)
The RP-SMA connector has it’s pin and your antenna connector has a hole for that pin?

ELVIS_WINE · June 24, 2025, 8:23am

I redefine in the script LoRaWAN region, DevEUI, AppEUI (all zeros), AppKey in at the beginning of the script:

#define OTAA_PERIOD   (8000)

/** Definizione OTAA credentials **/
uint8_t OTAA_DEVEUI [8]  = { 0xAC, 0x1F, 0x09, 0xFF, 0xFE, 0x11, 0x12, 0x64 };
uint8_t OTAA_APPEUI [8]  = { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 };
uint8_t OTAA_APPKEY [16] = { 0xC3, 0x4A, 0x6E, 0x15, 0x56, 0xD0, 0xA1, 0xF2, 0xA5, 0xDA, 0x6B, 0x85, 0x13, 0xC8, 0x47, 0x91 };

/** Definizione dei pin per Relè (se non usati, possono restare ma non sono nel payload) **/
#define RELAY1_PIN        PA7
#define RELAY2_PIN        PA6

/*************************************
   Impostazione della banda LoRaWAN:
     RAK_REGION_EU433
     RAK_REGION_CN470
     RAK_REGION_RU864
     RAK_REGION_IN865
     RAK_REGION_EU868
     RAK_REGION_US915
     RAK_REGION_AU915
     RAK_REGION_KR920
     RAK_REGION_AS923
*************************************/
#define OTAA_BAND     (RAK_REGION_EU868)

/** Inclusione delle librerie necessarie **/
#include <Wire.h>
#include <Adafruit_ADS1X15.h>
#include <ctype.h>  // per controllo caratteri stampabili

Adafruit_ADS1115 ads;

void recvCallback(SERVICE_LORA_RECEIVE_T * data)
{
    if (data->BufferSize > 0) {
        Serial.print("hellow form Gateway: ");
        for (int i = 0; i < data->BufferSize; i++) {
            uint8_t b = data->Buffer[i];
            char c = (char)b;
            if (c >= 32 && c <= 126) {
                Serial.print(c);
            } else {
                Serial.printf("%02X ", b);
            }
        }
        Serial.println();
    }
}

void joinCallback(int32_t status)
{
    Serial.printf("Stato di join: %d\r\n", status);
}

void sendCallback(int32_t status)
{
    if (status == RAK_LORAMAC_STATUS_OK) {
        Serial.println("Inviato con successo");
    } else {
        Serial.println("Invio fallito");
    }
}

void setup()
{
    Serial.begin(115200, RAK_AT_MODE);
    delay(2000);

    Serial.println("------------------------------------------------------");

  

    
    if (api.lorawan.nwm.get() != 1)
    {
        Serial.printf("Imposta modalità di lavoro dispositivo Node %s\r\n",
            api.lorawan.nwm.set() ? "Successo" : "Fallimento");
        api.system.reboot();
    }

    // Stampa le credenziali per verifica
    Serial.print("DevEUI: ");
    for (int i = 0; i < 8; i++) {
        Serial.printf("%02X", OTAA_DEVEUI[i]);
    }
    Serial.println();
    Serial.print("AppEUI: ");
    for (int i = 0; i < 8; i++) {
        Serial.printf("%02X", OTAA_APPEUI[i]);
    }
    Serial.println();
    Serial.print("AppKey: ");
    for (int i = 0; i < 16; i++) {
        Serial.printf("%02X", OTAA_APPKEY[i]);
    }
    Serial.println();

    // Imposta le credenziali LoRaWAN direttamente
    if (!api.lorawan.appeui.set(OTAA_APPEUI, 8)) {
        Serial.println("Errore nell'impostazione dell'AppEUI");
    } else {
        Serial.println("AppEUI impostato correttamente");
    }
    if (!api.lorawan.appkey.set(OTAA_APPKEY, 16)) {
        Serial.println("Errore nell'impostazione dell'AppKey");
    } else {
        Serial.println("AppKey impostato correttamente");
    }
    if (!api.lorawan.deui.set(OTAA_DEVEUI, 8)) {
        Serial.println("Errore nell'impostazione del DevEUI");
    } else {
        Serial.println("DevEUI impostato correttamente");
    }

    if (!api.lorawan.band.set(OTAA_BAND)) {
        Serial.printf("LoRaWan OTAA - impostazione banda errata! \r\n");
        return;
    }
    if (!api.lorawan.deviceClass.set(RAK_LORA_CLASS_C)) {
        Serial.printf("LoRaWan OTAA - impostazione classe dispositivo errata! \r\n");
        return;
    }
    if (!api.lorawan.njm.set(RAK_LORA_OTAA)) {
        Serial.printf("LoRaWan OTAA - impostazione modalità di join rete errata! \r\n");
        return;
    }

    // Avvia il processo di join
    if (!api.lorawan.join()) {
        Serial.println("Tentativo di join avviato");
    } else {
        Serial.println("Join avviato con successo");
    }

    // Attendi il successo del Join
    while (api.lorawan.njs.get() == 0) {
        Serial.println("Tentativo di join in corso...");
        api.lorawan.join();
        delay(5000);
    }
    Serial.println("Join completato con successo");

    if (!api.lorawan.adr.set(true)) {
        Serial.printf("LoRaWan OTAA - impostazione adaptive data rate errata! \r\n");
        return;
    }
    if (!api.lorawan.rety.set(1)) {
        Serial.printf("LoRaWan OTAA - impostazione tentativi di ritrasmissione errata! \r\n");
        return;
    }
    if (!api.lorawan.cfm.set(1)) {
        Serial.printf("LoRaWan OTAA - impostazione modalità conferma errata! \r\n");
        return;
    }

    Serial.printf("Duty cycle è %s\r\n", api.lorawan.dcs.get()? "ATTIVO" : "DISATTIVO");
    Serial.printf("Il pacchetto è %s\r\n", api.lorawan.cfm.get()? "CONFERMATO" : "NON CONFERMATO");
    uint8_t assigned_dev_addr[4] = { 0 };
    api.lorawan.daddr.get(assigned_dev_addr, 4);
    Serial.printf("Indirizzo dispositivo assegnato è %02X%02X%02X%02X\r\n",
                  assigned_dev_addr[0], assigned_dev_addr[1], assigned_dev_addr[2], assigned_dev_addr[3]);
    Serial.printf("Periodo di uplink è %ums\r\n", OTAA_PERIOD);
    Serial.println();
    api.lorawan.registerRecvCallback(recvCallback);
    api.lorawan.registerJoinCallback(joinCallback);
    api.lorawan.registerSendCallback(sendCallback);
}

void uplink_routine()
{
    const char msg[] = "Hellow from RAK";
    uint8_t data_len = sizeof(msg) - 1; // senza il terminatore '\0'
    Serial.print("Invio payload: ");
    Serial.println(msg);
    if (api.lorawan.send(data_len, (uint8_t *)msg, 2, true, 1)) {
        Serial.println("Invio richiesto");
    } else {
        Serial.println("Invio fallito");
    }
}

void loop()
{
    static uint64_t last = 0;
    uint64_t elapsed;
    if ((elapsed = millis() - last) > OTAA_PERIOD) {
        uplink_routine();
        last = millis();
    }
    api.system.sleep.all(OTAA_PERIOD);
}

But no way I always get “+EVT:JOIN_FAILED_TX_TIMEOUT”.

The RP-SMA connector looks the same in your pic. Can I test the antenna with an ohmeter in some way?

carlrowan · June 24, 2025, 1:26pm

RF signal appears to be ok whenever you have a successful connection. This means the RF frontend path is ok.

When you said on your first post that other devices are ok, are these devices also RAK3172? These devices have common APPEUI and APPKEY but different DEVEUI right?

Maybe you can try to flash erase again and try the default FW. But this time, do not upload any custom FW but use AT commands to test join. Just to see if AT commands will work ok.

I am running out of ideas. Maybe @beegee has another look on this as well.

ELVIS_WINE · June 24, 2025, 5:30pm

Thanks for the support!

I’ve tried a full flash erase and used only AT commands as suggested — and yes, in that case the OTAA join works correctly. So the RF frontend and configuration seem fine.

What’s puzzling is that I’m quite sure I managed to join successfully using the same script before (with the same DevEUI/AppEUI/AppKey), so I suspect something may have changed or been corrupted along the way.

That said, to eliminate any doubts and avoid further inconsistencies, could anyone share a minimal working example for Class C uplink/downlink communication using the RAK3172 and the official RUI3 framework (not just AT commands)? I’d like to rewrite my script from a clean reference.

Thanks again for the help

beegee · June 25, 2025, 1:52am

@ELVIS_WINE
Not sure if it is “minimal” enough, but in the RUI3-Best-Practices repo on Github we have an example for Class C and downlinks RUI3-Relay-Class-C

ELVIS_WINE · June 26, 2025, 5:02am

Thanks for your help so far. I’ve double-checked by reflashing the RAK3172 with the AT-firmware and issuing these commands over UART:

AT+DEVEUI=AC1F09FFFE111264  
OK  
AT+APPKEY=C34A6E1556D0A1F2A5DA6B8513C84791  
OK  
AT+JOIN

…and in ChirpStack I can clearly see the JoinRequest followed a few seconds later by a JoinAccept (see attached log).

However, as soon as I flash the example sketch you provided—without touching it—the module starts spitting out AT_COMMAND_NOT_FOUND and eventually:

21:41:28.751 -> -----------------------------------------[SETUP] Confirmed enabled
21:41:28.819 -> [SETUP] Retry = 1
21:41:28.916 -> [SETUP] DR = 0
21:41:29.047 -> Current Work Mode: LoRaWAN.
21:42:04.352 -> AT+DEVEUI=AC1F09FFFE111264
21:42:04.352 -> OK
21:42:11.471 -> AT+APPKEY=C34A6E1556D0A1F2A5DA6B8513C84791
21:42:11.471 -> OK
21:42:31.266 -> AT_COMMAND_NOT_FOUND
21:43:17.244 -> AT_COMMAND_NOT_FOUND
21:43:19.561 -> AT_COMMAND_NOT_FOUND
21:43:24.465 -> OK
21:43:28.418 -> +EVT:JOIN_FAILED_TX_TIMEOUT
21:43:28.547 -> [JOIN-CB] LoRaWan OTAA - join fail! 
21:43:28.547 -> 
21:43:42.420 -> +EVT:JOIN_FAILED_TX_TIMEOUT
21:43:42.486 -> [JOIN-CB] LoRaWan OTAA - join fail!

That’s expected, because once you upload a custom sketch, the built-in AT interpreter is replaced. The example code runs in “bare-metal” mode (API mode), so AT commands no longer work. It also means the OTAA parameters you set via AT are discarded on flash—by default the sketch will use zeros for AppEUI/DevEUI/AppKey, which of course makes the join fail.

JSON.LOG:

{
        "phy_payload": {
            "mhdr": {
                "m_type": "JoinAccept",
                "major": "LoRaWANR1"
            },
            "mic": [
                74,
                15,
                98,
                16
            ],
            "payload": "3aa521cf91518bbfb3fcb818d1477c4f2d2a2dcd2cb2e10ff2f9ae6c"
        },
        "tx_info": {
            "context": "ShxIhw==",
            "frequency": 868300000,
            "modulation": {
                "lora": {
                    "bandwidth": 125000,
                    "codeRate": "CR_4_5",
                    "polarizationInversion": true,
                    "spreadingFactor": 12
                }
            },
            "power": 16,
            "timing": {
                "delay": {
                    "delay": "5s"
                }
            }
        }
    },
    {
        "phy_payload": {
            "mhdr": {
                "m_type": "JoinRequest",
                "major": "LoRaWANR1"
            },
            "mic": [
                70,
                2,
                6,
                121
            ],
            "payload": {
                "dev_eui": "ac1f09fffe111264",
                "dev_nonce": 659,
                "join_eui": "0000000000000000"
            }
        },
        "rx_info": [
            {
                "channel": 1,
                "context": "ShxIhw==",
                "crcStatus": "CRC_OK",
                "gatewayId": "0016c001ff1f1170",
                "location": {},
                "metadata": {
                    "region_common_name": "EU868",
                    "region_config_id": "eu868"
                },
                "nsTime": "2025-06-25T19:49:26.947619578+00:00",
                "rfChain": 1,
                "rssi": -48,
                "snr": 6.75,
                "uplinkId": 392945578
            }
        ],
        "tx_info": {
            "frequency": 868300000,
            "modulation": {
                "lora": {
                    "bandwidth": 125000,
                    "codeRate": "CR_4_5",
                    "spreadingFactor": 12
                }
            }
        }
    },
    {
        "phy_payload": {
            "mhdr": {
                "m_type": "JoinAccept",
                "major": "LoRaWANR1"
            },
            "mic": [
                5,
                25,
                200,
                191
            ],
            "payload": "cdc8d524b30510e54958a2dfe80447662b880bd4c93de514a73a817d"
        },
        "tx_info": {
            "context": "R/x3Fw==",
            "frequency": 868500000,
            "modulation": {
                "lora": {
                    "bandwidth": 125000,
                    "codeRate": "CR_4_5",
                    "polarizationInversion": true,
                    "spreadingFactor": 12
                }
            },
            "power": 16,
            "timing": {
                "delay": {
                    "delay": "5s"
                }
            }
        }
    },
    {
        "phy_payload": {
            "mhdr": {
                "m_type": "JoinRequest",
                "major": "LoRaWANR1"
            },
            "mic": [
                107,
                62,
                71,
                110
            ],
            "payload": {
                "dev_eui": "ac1f09fffe111264",
                "dev_nonce": 658,
                "join_eui": "0000000000000000"
            }
        },
        "rx_info": [
            {
                "channel": 2,
                "context": "R/x3Fw==",
                "crcStatus": "CRC_OK",
                "gatewayId": "0016c001ff1f1170",
                "location": {},
                "metadata": {
                    "region_common_name": "EU868",
                    "region_config_id": "eu868"
                },
                "nsTime": "2025-06-25T19:48:51.304477515+00:00",
                "rfChain": 1,
                "rssi": -48,
                "snr": 6.75,
                "uplinkId": 1324381653
            }
        ],
        "tx_info": {
            "frequency": 868500000,
            "modulation": {
                "lora": {
                    "bandwidth": 125000,
                    "codeRate": "CR_4_5",
                    "spreadingFactor": 12
                }
            }
        }
    },
    {
        "phy_payload": {
            "mhdr": {
                "m_type": "JoinAccept",
                "major": "LoRaWANR1"
            },
            "mic": [
                245,
                251,
                134,
                99
            ],
            "payload": "37e8fde6a6f7fb8e7c644437a9befc05e0730f90b0c7c14a542d9cda"
        },
        "tx_info": {
            "context": "RuS1rg==",
            "frequency": 868500000,
            "modulation": {
                "lora": {
                    "bandwidth": 125000,
                    "codeRate": "CR_4_5",
                    "polarizationInversion": true,
                    "spreadingFactor": 12
                }
            },
            "power": 16,
            "timing": {
                "delay": {
                    "delay": "5s"
                }
            }
        }
    },

beegee · June 26, 2025, 5:51am

Not really, unless you changed how the Serial is initialized. In my code the AT command interpreter is still running, even if you use a custom application.
My code is initializing the Serial with

// Start Serial|
Serial.begin(115200);

which leaves the AT command interpreter active.

Default mode is RAK_AT_MODE.

Here is a screenshot from a test I am running right now. It shows the debug output and I can send AT commands at any time:

ELVIS_WINE · June 26, 2025, 3:13pm

I’m puzzled: if I reset the RAK3172 back to the AT firmware and issue the OTAA commands over UART:

17:15:04.344 -> 
17:15:04.540 -> RAKwireless RAK3172-E
17:15:04.540 -> ------------------------------------------------------
17:15:04.540 -> Version: RUI_4.2.1_RAK3172-E
17:15:04.540 -> Current Work Mode: LoRaWAN.
17:15:06.644 -> 
17:15:06.840 -> RAKwireless RAK3172-E
17:15:06.840 -> ------------------------------------------------------
17:15:06.840 -> Version: RUI_4.2.1_RAK3172-E
17:15:06.840 -> Current Work Mode: LoRaWAN.
17:15:17.843 -> AT+DEVEUI=AC1F09FFFE111264
17:15:17.843 -> OK
17:15:25.688 -> AT+APPKEY=C34A6E1556D0A1F2A5DA6B8513C84791
17:15:25.688 -> OK
17:15:33.804 -> OK
17:15:42.091 -> +EVT:JOINED

the join completes successfully. However, when I flash the exact example sketch you provided—without changing a single line—I immediately get:

17:05:12.856 -> RAKwireless RUI3 Node
17:05:12.856 -> ------------------------------------------------------
17:05:12.856 -> Setup the device with WisToolBox or AT commands before using it
17:05:12.856 -> Version RUI3-Relay-V1.0.1
17:05:12.856 -> ------------------------------------------------------
17:05:12.856 -> [AT_CMD] Got flag: AA
17:05:12.955 -> [AT_CMD] Got send interval: 00000000
17:05:13.088 -> [AT_CMD] Send interval found 0
17:05:14.176 -> [SETUP] Confirmed enabled
17:05:14.274 -> [SETUP] Retry = 1
17:05:14.373 -> [SETUP] DR = 0
17:05:14.471 -> Current Work Mode: LoRaWAN.
17:05:48.472 -> AT+DEVEUI=AC1F09FFFE111264
17:05:57.009 -> AT+APPEUI=0000000000000000
17:05:57.009 -> OK
17:06:05.173 -> AT_COMMAND_NOT_FOUND
17:06:13.499 -> AT+APPKEY=C34A6E1556D0A1F2A5DA6B8513C84791
17:06:13.499 -> OK
17:06:21.860 -> AT+VER=RUI_4.2.1_RAK3172-T
17:06:21.860 -> OK
(here I entered AT+JOIN, not printed on Serial)
17:06:29.511 -> OK
**17:06:33.460 -> +EVT:JOIN_FAILED_TX_TIMEOUT**
**17:06:33.525 -> [JOIN-CB] LoRaWan OTAA - join fail!**

I don’t understand why. In both cases I’m starting from a clean device, and the example still calls Serial.begin(115200);, so the AT interpreter should remain active in RAK_AT_MODE. What could be causing a TX timeout only when the sketch is loaded?

Could there be a corrupted or mismatched library on my system that’s interfering?
What other tests or diagnostics would you recommend I run to narrow down the root cause?

Thanks for any insight!

beegee · June 27, 2025, 1:53am

Seems you select the wrong board when you compile the application.
You flashed RUI_4.2.1_RAK3172- E and it works.

But you compile for RUI_4.2.1_RAK3172- T which is a different module. It has a TCXO and its setup is different.

Use the WisDuo RAK3172 Evaluation Board when you compile your code.

ELVIS_WINE · June 27, 2025, 7:04am

Unfortunately, even with the RAK3172-E firmware, I still get:

08:53:16.228 -> -----------------------------------------RAKwireless RUI3 Node
09:02:02.103 -> -----------------------------------------[SETUP] Confirmed enabled
09:02:02.156 -> [SETUP] Retry = 1
09:02:02.255 -> [SETUP] DR = 0
09:02:02.353 -> Current Work Mode: LoRaWAN.
09:02:27.229 -> AT+VER=RUI_4.2.1_RAK3172-E
09:02:27.229 -> OK
09:02:42.185 -> OK
09:02:46.145 -> +EVT:JOIN_FAILED_TX_TIMEOUT
09:02:46.211 -> [JOIN-CB] LoRaWan OTAA - join fail! 
09:02:46.211 ->

I’ve uninstalled all RAK board packages from the Arduino IDE, reinstalled the WisDUO STM32 package, and selected “Evaluation Board,” but nothing changes—TX_TIMEOUT is still happening. I’m at a loss for what else to try!

Also, is there any difference in how AT+JOIN behaves when the sketch is loaded versus when you’re just on the stock AT firmware? At this point the only place left to look must be there!

beegee · June 27, 2025, 7:21am

AT+JOIN and api.lorawan.join are using the same LoRaWAN functions to initialize the join procedure.

After you reflashed the device, are the DevEUI, AppEUI, AppKey, LoRaWan region still correct?

ELVIS_WINE · June 27, 2025, 7:33am

Ok, here it starts to get twisted:


09:28:28.865 -> AT+VER=RUI_4.2.1_RAK3172-E

09:28:28.865 -> OK

09:28:32.057 -> AT+DEVEUI=AC1F09FFFE111264

09:28:32.057 -> OK

09:28:34.627 -> AT+APPKEY=C34A6E1556D0A1F2A5DA6B8513C84791

09:28:34.627 -> OK

09:28:45.379 -> AT+CLASS=C

09:28:45.379 -> OK

09:29:04.389 -> AT+BAND=4

09:29:04.389 -> OK

09:30:08.539 -> AT+DCS=1

09:30:08.539 -> OK

09:30:19.479 -> AT+DR=0

09:30:19.479 -> OK

09:30:48.586 -> AT+RX2FQ=869525000

09:30:48.586 -> OK

09:31:41.205 -> AT+APPEUI=0000000000000000

09:31:41.205 -> OK

09:31:46.147 -> OK

09:31:53.838 -> +EVT:JOIN_FAILED_RX_TIMEOUT

09:32:11.552 -> +EVT:JOIN_FAILED_RX_TIMEOUT

Now flashing again, it gives to me RX-TIMEOUT!

But on Chripstack, the join is accepted:

{
    "phy_payload": {
        "mhdr": {
            "m_type": "JoinAccept",
            "major": "LoRaWANR1"
        },
        "mic": [
            122,
            218,
            120,
            90
        ],
        "payload": "9b50fd6d29d6133b900e1bed6bbdf4eebc63022cba3260b6e35d4033"
    },
    "tx_info": {
        "context": "RU+HzQ==",
        "frequency": 868100000,
        "modulation": {
            "lora": {
                "bandwidth": 125000,
                "codeRate": "CR_4_5",
                "polarizationInversion": true,
                "spreadingFactor": 12
            }
        },
        "power": 16,
        "timing": {
            "delay": {
                "delay": "5s"
            }
        }
    }
}```

beegee · June 27, 2025, 8:51am

It can happen that the first join fails sometimes. Try a second join attempt without rebooting the device.