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”
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.
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.
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?
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?
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.
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
@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
2 Likes
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"
}
}
}
},
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:
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!
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.
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!
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?
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"
}
}
}
}```It can happen that the first join fails sometimes. Try a second join attempt without rebooting the device.
Nothing Change…
11:35:36.244 -> AT+VER=RUI_4.2.1_RAK3172-E
11:35:36.244 -> OK
11:35:46.871 -> AT+APPKEY=C34A6E1556D0A1F2A5DA6B8513C84791
11:35:46.871 -> OK
11:35:50.727 -> OK
11:35:58.418 -> +EVT:JOIN_FAILED_RX_TIMEOUT
11:36:07.090 -> OK
11:36:14.770 -> +EVT:JOIN_FAILED_RX_TIMEOUT
11:36:32.504 -> +EVT:JOIN_FAILED_RX_TIMEOUT
11:36:50.232 -> +EVT:JOIN_FAILED_RX_TIMEOUT
11:36:58.829 -> OK
11:37:06.494 -> +EVT:JOIN_FAILED_RX_TIMEOUT
11:37:24.247 -> +EVT:JOIN_FAILED_RX_TIMEOUT
And here’s another funny thing: now, when I upload the sketch, it gives me an RX error, even though the gateway receives the Join Request and accepts it.
11:41:04.486 -> RAKwireless RUI3 Node
11:41:04.486 -> -----------------------------------------[SETUP] Confirmed enabled
11:41:04.542 -> [SETUP] Retry = 1
11:41:04.640 -> [SETUP] DR = 0
11:41:04.738 -> Current Work Mode: LoRaWAN.
11:41:14.599 -> AT+VER=RUI_4.2.1_RAK3172-E
11:41:14.599 -> OK
11:41:16.884 -> AT+APPKEY=C34A6E1556D0A1F2A5DA6B8513C84791
11:41:16.917 -> OK
11:41:22.227 -> AT+DEVEUI=AC1F09FFFE111264
11:41:22.227 -> OK
11:41:29.246 -> AT+APPEUI=0000000000000000
11:41:29.246 -> OK
11:41:34.721 -> AT+BAND=4
11:41:34.721 -> OK
11:41:39.242 -> OK
11:41:46.910 -> +EVT:JOIN_FAILED_RX_TIMEOUT
11:41:47.074 -> [JOIN-CB] LoRaWan OTAA - join fail!
11:41:47.074 ->
11:42:04.655 -> +EVT:JOIN_FAILED_RX_TIMEOUT
11:42:04.752 -> [JOIN-CB] LoRaWan OTAA - join fail!
There any other test I can try? Or could be hw failure?
If it works with AT commands, then there is no hardware problem.
Plenty of examples in the RUI3-Best-Practices repo and the BSP itself has as well examples.
No, now even with AT cmd, the join fails in RX.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.