Join Failed - RADIOLIB_ERR_NO_JOIN_ACCEPT (-1116) on TTGO LoRa32 V1 on AU915

[ElectronicallyE]

Hello,

I'm been trying to get my TTGO LoRa32 connected to an AU915 V3 instance of The Things Network following this guide:
https://planb.nicecupoftea.org/2024/04/29/a-lora-lora-laughs/

I can confirm the gateway is configured for V3.

I can't seem to get the LoRa32 to acknowledge/receive the downlink.

I'm getting the error (-1116), which I understand means "No JoinAccept was received - check your keys, or otherwise likely a range issue!". This means the serial never says it is "Ready!". I have never had the LoRa32 connect.

LoRa32 located inside, about 300 metres from a Tektelic gateway mounted on the roof of an approximately 2-story building with a mast. Almost direct line of sight from out of the window.

Given my RSSI in the -90s (see metadata later on), I don't think I'm "overwhelming" the device, but I'll leave that to the experts to make the call.

You may see I have included a line into try and force SF12. I haven't got around to verifying if it is working correctly as it appears transmissions are still occurring at SF10. Even before this line was added, the same issue was occurring.

Source: https://jgromes.github.io/RadioLib/group__status__codes.html

Here is my code:

LoRaWAN_Starter.ino

/*
  RadioLib LoRaWAN Starter Example

  ! Please refer to the included notes to get started !

  This example joins a LoRaWAN network and will send
  uplink packets. Before you start, you will have to
  register your device at https://www.thethingsnetwork.org/
  After your device is registered, you can run this example.
  The device will join the network and start uploading data.

  Running this examples REQUIRES you to check "Resets DevNonces"
  on your LoRaWAN dashboard. Refer to the network's 
  documentation on how to do this.

  For default module settings, see the wiki page
  https://github.com/jgromes/RadioLib/wiki/Default-configuration

  For full API reference, see the GitHub Pages
  https://jgromes.github.io/RadioLib/

  For LoRaWAN details, see the wiki page
  https://github.com/jgromes/RadioLib/wiki/LoRaWAN

*/

#include "config.h"

void setup() {
  Serial.begin(115200);
  while(!Serial);
  delay(5000);  // Give time to switch to the serial monitor
  Serial.println(F("\nSetup ... "));

  Serial.println(F("Initialise the radio"));
  int16_t state = radio.begin();
  debug(state != RADIOLIB_ERR_NONE, F("Initialise radio failed"), state, true);

  // Set spreading factor to SF12
  radio.setSpreadingFactor(12);
  
  // Setup the OTAA session information
  state = node.beginOTAA(joinEUI, devEUI, nwkKey, appKey);
  debug(state != RADIOLIB_ERR_NONE, F("Initialise node failed"), state, true);
  Serial.println(F("Join ('login') the LoRaWAN Network"));
  state = node.activateOTAA();
  debug(state != RADIOLIB_LORAWAN_NEW_SESSION, F("Join failed"), state, true);

  Serial.println(F("Ready!\n"));
}

void loop() {
  Serial.println(F("Sending uplink"));

  // This is the place to gather the sensor inputs
  // Instead of reading any real sensor, we just generate some random numbers as example
  uint8_t value1 = radio.random(100);
  uint16_t value2 = radio.random(2000);

  // Build payload byte array
  uint8_t uplinkPayload[3];
  uplinkPayload[0] = value1;
  uplinkPayload[1] = highByte(value2);   // See notes for high/lowByte functions
  uplinkPayload[2] = lowByte(value2);
  
  // Perform an uplink
  int16_t state = node.sendReceive(uplinkPayload, sizeof(uplinkPayload));    
  debug(state < RADIOLIB_ERR_NONE, F("Error in sendReceive"), state, false);

  // Check if a downlink was received 
  // (state 0 = no downlink, state 1/2 = downlink in window Rx1/Rx2)
  if(state > 0) {
    Serial.println(F("Received a downlink"));
  } else {
    Serial.println(F("No downlink received"));
  }

  Serial.print(F("Next uplink in "));
  Serial.print(uplinkIntervalSeconds);
  Serial.println(F(" seconds\n"));
  
  // Wait until next uplink - observing legal & TTN FUP constraints
  delay(uplinkIntervalSeconds * 1000UL);  // delay needs milli-seconds
}

config.h

#ifndef _RADIOLIB_EX_LORAWAN_CONFIG_H
#define _RADIOLIB_EX_LORAWAN_CONFIG_H
#define ARDUINO_TTGO_LORA32_V1

#include <RadioLib.h>

// first you have to set your radio model and pin configuration
// this is provided just as a default example
SX1276 radio = new Module(18, 26, 14, 33);

// if you have RadioBoards (https://github.com/radiolib-org/RadioBoards)
// and are using one of the supported boards, you can do the following:
/*
#define RADIO_BOARD_AUTO
#include <RadioBoards.h>

Radio radio = new RadioModule();
*/

// how often to send an uplink - consider legal & FUP constraints - see notes
const uint32_t uplinkIntervalSeconds = 5UL * 60UL;    // minutes x seconds

// joinEUI - previous versions of LoRaWAN called this AppEUI
// for development purposes you can use all zeros - see wiki for details
#define RADIOLIB_LORAWAN_JOIN_EUI  0x0000000000000000

// the Device EUI & two keys can be generated on the TTN console 
#ifndef RADIOLIB_LORAWAN_DEV_EUI   // Replace with your Device EUI
#define RADIOLIB_LORAWAN_DEV_EUI   0x70B3D57ED006F85A
#endif
#ifndef RADIOLIB_LORAWAN_APP_KEY   // Replace with your App Key 
#define RADIOLIB_LORAWAN_APP_KEY   0x11, 0x25, 0x4E, 0x23, 0x83, 0xD5, 0x85, 0x39, 0x87, 0xC4, 0xDA, 0x5B, 0x68, 0xA6, 0x67, 0xA8
#endif
#ifndef RADIOLIB_LORAWAN_NWK_KEY   // Put your Nwk Key here
#define RADIOLIB_LORAWAN_NWK_KEY   0xDC, 0xEC, 0x04, 0x77, 0xB0, 0x90, 0x2C, 0x60, 0xF2, 0xA3, 0x40, 0x66, 0x44, 0x4A, 0x91, 0xFB
#endif

// for the curious, the #ifndef blocks allow for automated testing &/or you can
// put your EUI & keys in to your platformio.ini - see wiki for more tips

// regional choices: EU868, US915, AU915, AS923, AS923_2, AS923_3, AS923_4, IN865, KR920, CN500
const LoRaWANBand_t Region = AU915;
const uint8_t subBand = 2;  // For US915, change this to 2, otherwise leave on 0

// ============================================================================
// Below is to support the sketch - only make changes if the notes say so ...

// copy over the EUI's & keys in to the something that will not compile if incorrectly formatted
uint64_t joinEUI =   RADIOLIB_LORAWAN_JOIN_EUI;
uint64_t devEUI  =   RADIOLIB_LORAWAN_DEV_EUI;
uint8_t appKey[] = { RADIOLIB_LORAWAN_APP_KEY };
uint8_t nwkKey[] = { RADIOLIB_LORAWAN_NWK_KEY };

// create the LoRaWAN node
LoRaWANNode node(&radio, &Region, subBand);

// result code to text - these are error codes that can be raised when using LoRaWAN
// however, RadioLib has many more - see https://jgromes.github.io/RadioLib/group__status__codes.html for a complete list
String stateDecode(const int16_t result) {
  switch (result) {
  case RADIOLIB_ERR_NONE:
    return "ERR_NONE";
  case RADIOLIB_ERR_CHIP_NOT_FOUND:
    return "ERR_CHIP_NOT_FOUND";
  case RADIOLIB_ERR_PACKET_TOO_LONG:
    return "ERR_PACKET_TOO_LONG";
  case RADIOLIB_ERR_RX_TIMEOUT:
    return "ERR_RX_TIMEOUT";
  case RADIOLIB_ERR_CRC_MISMATCH:
    return "ERR_CRC_MISMATCH";
  case RADIOLIB_ERR_INVALID_BANDWIDTH:
    return "ERR_INVALID_BANDWIDTH";
  case RADIOLIB_ERR_INVALID_SPREADING_FACTOR:
    return "ERR_INVALID_SPREADING_FACTOR";
  case RADIOLIB_ERR_INVALID_CODING_RATE:
    return "ERR_INVALID_CODING_RATE";
  case RADIOLIB_ERR_INVALID_FREQUENCY:
    return "ERR_INVALID_FREQUENCY";
  case RADIOLIB_ERR_INVALID_OUTPUT_POWER:
    return "ERR_INVALID_OUTPUT_POWER";
  case RADIOLIB_ERR_NETWORK_NOT_JOINED:
	  return "RADIOLIB_ERR_NETWORK_NOT_JOINED";
  case RADIOLIB_ERR_DOWNLINK_MALFORMED:
    return "RADIOLIB_ERR_DOWNLINK_MALFORMED";
  case RADIOLIB_ERR_INVALID_REVISION:
    return "RADIOLIB_ERR_INVALID_REVISION";
  case RADIOLIB_ERR_INVALID_PORT:
    return "RADIOLIB_ERR_INVALID_PORT";
  case RADIOLIB_ERR_NO_RX_WINDOW:
    return "RADIOLIB_ERR_NO_RX_WINDOW";
  case RADIOLIB_ERR_INVALID_CID:
    return "RADIOLIB_ERR_INVALID_CID";
  case RADIOLIB_ERR_UPLINK_UNAVAILABLE:
    return "RADIOLIB_ERR_UPLINK_UNAVAILABLE";
  case RADIOLIB_ERR_COMMAND_QUEUE_FULL:
    return "RADIOLIB_ERR_COMMAND_QUEUE_FULL";
  case RADIOLIB_ERR_COMMAND_QUEUE_ITEM_NOT_FOUND:
    return "RADIOLIB_ERR_COMMAND_QUEUE_ITEM_NOT_FOUND";
  case RADIOLIB_ERR_JOIN_NONCE_INVALID:
    return "RADIOLIB_ERR_JOIN_NONCE_INVALID";
  case RADIOLIB_ERR_N_FCNT_DOWN_INVALID:
    return "RADIOLIB_ERR_N_FCNT_DOWN_INVALID";
  case RADIOLIB_ERR_A_FCNT_DOWN_INVALID:
    return "RADIOLIB_ERR_A_FCNT_DOWN_INVALID";
  case RADIOLIB_ERR_DWELL_TIME_EXCEEDED:
    return "RADIOLIB_ERR_DWELL_TIME_EXCEEDED";
  case RADIOLIB_ERR_CHECKSUM_MISMATCH:
    return "RADIOLIB_ERR_CHECKSUM_MISMATCH";
  case RADIOLIB_ERR_NO_JOIN_ACCEPT:
    return "RADIOLIB_ERR_NO_JOIN_ACCEPT";
  case RADIOLIB_LORAWAN_SESSION_RESTORED:
    return "RADIOLIB_LORAWAN_SESSION_RESTORED";
  case RADIOLIB_LORAWAN_NEW_SESSION:
    return "RADIOLIB_LORAWAN_NEW_SESSION";
  case RADIOLIB_ERR_NONCES_DISCARDED:
    return "RADIOLIB_ERR_NONCES_DISCARDED";
  case RADIOLIB_ERR_SESSION_DISCARDED:
    return "RADIOLIB_ERR_SESSION_DISCARDED";
  }
  return "See https://jgromes.github.io/RadioLib/group__status__codes.html";
}

// helper function to display any issues
void debug(bool failed, const __FlashStringHelper* message, int state, bool halt) {
  if(failed) {
    Serial.print(message);
    Serial.print(" - ");
    Serial.print(stateDecode(state));
    Serial.print(" (");
    Serial.print(state);
    Serial.println(")");
    while(halt) { delay(1); }
  }
}

// helper function to display a byte array
void arrayDump(uint8_t *buffer, uint16_t len) {
  for(uint16_t c = 0; c < len; c++) {
    char b = buffer[c];
    if(b < 0x10) { Serial.print('0'); }
    Serial.print(b, HEX);
  }
  Serial.println();
}

#endif

I consistently get the following output on my serial:

21:09:09.481 -> Setup ... 
21:09:09.482 -> Initialise the radio
21:09:09.482 -> Join ('login') the LoRaWAN Network
21:09:19.514 -> Join failed - RADIOLIB_ERR_NO_JOIN_ACCEPT (-1116)

The output in serial monitor are as follows:

21:10:07.349 -> Setup ... 
21:10:07.349 -> Initialise the radio
21:10:07.349 -> Join ('login') the LoRaWAN Network
21:10:17.404 -> Join failed - RADIOLIB_ERR_NO_JOIN_ACCEPT (-1116)

The Things Network console shows the following. I'm particularly confused by "Receive join-accept message", because it appears like the LoRa32 can receive a message from the gateway":

Here are the settings for the device in The Things Network console:

Details from "Receive join-request":

{
  "name": "ns.up.join.receive",
  "time": "2025-03-30T10:40:07.903606591Z",
  "identifiers": [
    {
      "device_ids": {
        "device_id": "test-device",
        "application_ids": {
          "application_id": "ttgo-lora32-sx1276-electronicallye"
        },
        "dev_eui": "70B3D57ED006F85A",
        "join_eui": "0000000000000000"
      }
    }
  ],
  "data": {
    "@type": "type.googleapis.com/ttn.lorawan.v3.UplinkMessage",
    "raw_payload": "AAAAAAAAAAAAWvgG0H7Vs3AAAPbhU5E=",
    "payload": {
      "m_hdr": {},
      "mic": "9uFTkQ==",
      "join_request_payload": {
        "join_eui": "0000000000000000",
        "dev_eui": "70B3D57ED006F85A",
        "dev_nonce": "0000"
      }
    },
    "settings": {
      "data_rate": {
        "lora": {
          "bandwidth": 125000,
          "spreading_factor": 10,
          "coding_rate": "4/5"
        }
      },
      "frequency": "917800000",
      "timestamp": 3141377716,
      "time": "2025-03-30T10:40:07.755Z"
    },
    "rx_metadata": [
      {
        "gateway_ids": {
          "gateway_id": "eui-647fdafffe00b437",
          "eui": "647FDAFFFE00B437"
        },
        "time": "2025-03-30T10:40:07.755Z",
        "timestamp": 3141377716,
        "rssi": -95,
        "channel_rssi": -95,
        "snr": 8.8,
        "location": {
          "latitude": -34.770833066481295,
          "longitude": 138.719783330873,
          "source": "SOURCE_REGISTRY"
        },
        "uplink_token": "CiIKIAoUZXVpLTY0N2ZkYWZmZmUwMGI0MzcSCGR/2v/+ALQ3ELS99tkLGgwIh7+kvwYQ+MivrAMgoN7PxbbACSoMCIe/pL8GEMDFgegC",
        "channel_index": 15,
        "gps_time": "2025-03-30T10:40:07.755Z",
        "received_at": "2025-03-30T10:40:07.842044590Z"
      }
    ],
    "received_at": "2025-03-30T10:40:07.899964099Z",
    "correlation_ids": [
      "gs:uplink:01JQKA6APVM4FEYZT20D6SA64A"
    ],
    "device_channel_index": 13,
    "consumed_airtime": "0.370688s"
  },
  "correlation_ids": [
    "gs:uplink:01JQKA6APVM4FEYZT20D6SA64A"
  ],
  "origin": "ip-10-102-7-79.ap-southeast-2.compute.internal",
  "context": {
    "tenant-id": "CgN0dG4="
  },
  "visibility": {
    "rights": [
      "RIGHT_APPLICATION_TRAFFIC_READ"
    ]
  },
  "unique_id": "01JQKA6APZ61B8E7FA6CBXWKBG"
}

Following the information in README.md in the LoRaWAN_Starter example folder, I tried 1.0.4 and set the NwkKey to NULL. I get a "MIC mismatch" error and the same -1116 error in serial. This happens on 1.0.2 as well.

Additional Info:

• MCU: TTGO LoRa32 SX1276 V1
• Link to Arduino core: esp32 by Espressif Systems https://github.com/espressif/arduino-esp32 (Board: TTGO LoRa32-OLED)
• Wireless module type: SX1267
• Arduino IDE version: 2.3.4
• Library version: 7.1.2

Any help would be much appreciated. This has got me beat!

Also, I acknowledge I have shared my IDs, but just doing some testing, so will be deleting the application later.

[StevenCellist]

Hi @ElectronicallyE, great report with lots of crucial info! As far as I scanned the details now, it looks pretty solid. I think we'll need to see the protocol debug log of your device to confirm whether your device is correctly listening at the right moments for the JoinAccept. You can check the wiki how to enable (protocol) debug output. Please enable timestamps in your terminal: they're the most important part of the log!

Oh.. and LoRaWAN overrides all calls to radio functions such as your setSpreadingFactor(12). The right way to do this would be node.activateOTAA(0) (this uses datarates, not spreading factor), however, on AU915 dwelltime limitations are in place, and the specification forces JoinRequests to be sent at DR2 = SF10, so that trick won't work!

[ElectronicallyE]

Hi @StevenCellist,

Thank you for your quick reply and positivity. It's refreshing to have positive feedback!

I have enabled RADIOLIB_DEBUG_PROTOCOL in BuildOptUser.h as per https://github.com/jgromes/RadioLib/wiki/Debug-mode.

This was tested with LoRaWAN Specification 1.1.0 and RP002 Regional Parameters 1.0.4. Using the code above, with the spreading factor line removed.

Arduino serial monitor output:

13:59:34.910 -> RLB_PRO: RXTimingSetupReq: delay = 1 sec
13:59:34.942 -> RLB_PRO: [MAC] 0x09
13:59:34.942 -> RLB_PRO: 00000000: 1d                                               .                 
13:59:34.942 -> RLB_PRO: TxParamSetupReq: dlDwell = 0, ulDwell = 1, maxEirp = 30 dBm
13:59:34.942 -> RLB_PRO: [MAC] 0x0c
13:59:34.942 -> RLB_PRO: 00000000: 65                                               e                 
13:59:34.974 -> RLB_PRO: ADRParamSetupReq: limitExp = 6, delayExp = 5
13:59:34.974 -> RLB_PRO: [MAC] 0x0f
13:59:34.974 -> RLB_PRO: 00000000: fa                                               .                 
13:59:35.014 -> RLB_PRO: RejoinParamSetupReq: maxTime = 15, maxCount = 10
13:59:35.047 -> RLB_PRO: 
13:59:35.047 -> RLB_PRO: PHY:  Frequency = 918.200 MHz, TX = 30 dBm
13:59:35.092 -> RLB_PRO: LoRa: SF = 10, BW = 125.0 kHz, CR = 4/5, IQ: U
13:59:35.453 -> RLB_PRO: JoinRequest sent (DevNonce = 0) <-- Rx Delay start
13:59:35.453 -> RLB_PRO: 00000000: 00 00 00 00 00 00 00 00 00 5a f8 06 d0 7e d5 b3  .........Z...~..
13:59:35.453 -> RLB_PRO: 00000010: 70 00 00 f6 e1 53 91                             p....S.           
13:59:35.499 -> RLB_PRO: 
13:59:35.499 -> RLB_PRO: PHY:  Frequency = 927.500 MHz, TX = 30 dBm
13:59:35.499 -> RLB_PRO: LoRa: SF = 10, BW = 500.0 kHz, CR = 4/5, IQ: D
13:59:43.108 -> RLB_PRO: Opening Rx1 window (77 ms timeout)... <-- Rx Delay end 
13:59:43.225 -> RLB_PRO: Closing Rx1 window
13:59:43.271 -> RLB_PRO: 
13:59:43.271 -> RLB_PRO: PHY:  Frequency = 923.300 MHz, TX = 30 dBm
13:59:43.271 -> RLB_PRO: LoRa: SF = 12, BW = 500.0 kHz, CR = 4/5, IQ: D
13:59:44.684 -> RLB_PRO: Opening Rx2 window (191 ms timeout)... <-- Rx Delay end 
13:59:44.948 -> RLB_PRO: Closing Rx2 window
13:59:44.948 -> Join failed - RADIOLIB_ERR_NO_JOIN_ACCEPT (-1116)

Here is a screenshot from the TTN Console.

According to https://www.thethingsnetwork.org/docs/lorawan/regional-parameters/ it states:
_Default Settings for All Regions
There are a few recommended default settings available that can be applied to all the regions.

RX1 Delay: 1s
RX2 Delay: 2s (RX1 Delay + 1s)
Join Accept 1 Delay: 5s
Join Accept 2 Delay: 6s

Looking at the timestamps in the serial monitor:

• RX1 (join accept) delay start (13:59:35:047) -> RX1 (join accept) delay end (13:59:43.108) = 8.061 seconds (approximately 3 seconds too late)
• RX1 (join accept) delay end (13:59:43.108) to RX2 (joint accept) delay end (13:59:44.684) = 1.576 seconds (half a second too late)

Out of curiosity and following a bit of testing that has done by alistair23 in issue #1145, I wrote a basic delay script:

void setup() {
    Serial.begin(115200); // Start serial communication at 115200 baud
}

void loop() {
    Serial.println("1 second"); // Print message to serial
    delay(1000); // Wait for 1 second
}

Here is the serial output:

14:42:00.035 -> 1 second
14:42:01.604 -> 1 second
14:42:03.153 -> 1 second
14:42:04.659 -> 1 second
14:42:06.229 -> 1 second
14:42:07.728 -> 1 second
14:42:09.312 -> 1 second
14:42:10.805 -> 1 second
14:42:12.342 -> 1 second
14:42:13.880 -> 1 second
14:42:15.421 -> 1 second
14:42:16.960 -> 1 second
14:42:18.497 -> 1 second

It looks like the board's clock is nearly out by half a second per second average (50%)! Far out, it must be on vacation!

Here is another board with the same result:

Given the system clock can't be trusted, I need to be able to compensate for it. The challenge is the time difference can vary by up to 100 milliseconds for each second. Can this be done via software or is an RTC a requirement?

[StevenCellist]

Wow, this is wild, I've never seen an ESP32 perform so badly. I guess Australia is warmer than the Netherlands but 50% off is insane. Do you by any chance have some normal ESP32 boards around, just to confirm that they run more normally?

RadioLib offers a method for clock drift compensation but its intended to fix (stable) drifts in the order of 10s of milliseconds per second - this issue must be fixed in another way. As I have never seen anything like this, I wouldn't have a clue how to resolve it.

[ElectronicallyE]

AND WE HAVE SUCCESS!

Thanks for another quick reply @StevenCellist.

I've just tried the same delay sketch on an ESP-WROOOM32 which appears to work fine (using ESP32 Dev Module as the board). Looks like it doesn't face the same problem

16:01:22.344 -> 1 second
16:01:23.360 -> 1 second
16:01:24.344 -> 1 second
16:01:25.381 -> 1 second
16:01:26.363 -> 1 second
16:01:27.370 -> 1 second
16:01:28.388 -> 1 second
16:01:29.389 -> 1 second

I've tried a third TTGO LoRa32 V1 which has the same amount of drift of 1.5 seconds for every second.

The ESP32 chip on the TTGO LoRa32 V1 is a ESP32 DOWDQ6.

In order to read the serial monitor, I have been setting the baud rate to 74880, even though in the script it is 115200. My understanding is because the chip uses a 26 MHz crystal, instead of a 40 MHz crystal ((26/40) * 115200 = 74880). 115200/74880 = 1.538, which is close enough to the drift. I didn't think until now that this would mean this would also affect the chips time (obvious now given it affects the baud rate)!

https://docs.espressif.com/projects/esp-idf/en/v5.1.2/esp32c2/get-started/establish-serial-connection.html
The default console baud rate on ESP32-C2 is 115200 when a 40 MHz XTAL is used, or 74880 when a 26 MHz XTAL is used.

Here's a few links describing a similar problem:
espressif/arduino-esp32#9837 <- This is an issue called out about the board library and calls out "Heltec Lora boards" which are very similar to mine.
https://forum.arduino.cc/t/baudrate-changes-after-boot/1337352
https://www.esp32.com/viewtopic.php?t=43788
sparkfun/ESP32_Thing_Plus#7
https://community.sparkfun.com/t/sparkfun-esp32-thing-issue-with-espressif-version-3-0-0-core-clock-incorrect-frequency/47531

Downgrading the esp32 by Espressif Systems board library to 2.0.17 seems to work a treat!

I reupload the following code:

void setup() {
    Serial.begin(115200); // Start serial communication at 115200 baud
}

void loop() {
    Serial.println("1 second"); // Print message to serial
    delay(1000); // Wait for 1 second
}

Please see the latest results below. Can you confirm if the variation will cause any connection issues (how much leniency is there)?

Tried reuploading the code and I'm in business! You little ripper! (From the Australian classic movie The Castle)

Screenshot from the console (might have to zoom in):

Output from serial monitor:

17:27:05.646 -> ets Jun  8 2016 00:22:57
17:27:05.646 -> 
17:27:05.646 -> rst:0x1 (POWERON_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT)
17:27:05.646 -> configsip: 0, SPIWP:0xee
17:27:05.646 -> clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
17:27:05.646 -> mode:DIO, clock div:1
17:27:05.646 -> load:0x3fff0030,len:1184
17:27:05.646 -> load:0x40078000,len:13260
17:27:05.691 -> load:0x40080400,len:3028
17:27:05.691 -> entry 0x400805e4
17:27:10.804 -> 
17:27:10.804 -> Setup ... 
17:27:10.804 -> Initialise the radio
17:27:10.804 -> Join ('login') the LoRaWAN Network
17:27:10.836 -> RLB_PRO: Setting up fixed channels (subband 2)
17:27:10.836 -> RLB_PRO: UL:   8 1 916.800 (0 - 5) | DL:   0 0   0.000 (0 - 0)
17:27:10.836 -> RLB_PRO: UL:   9 1 917.000 (0 - 5) | DL:   0 0   0.000 (0 - 0)
17:27:10.836 -> RLB_PRO: UL:  10 1 917.200 (0 - 5) | DL:   0 0   0.000 (0 - 0)
17:27:10.836 -> RLB_PRO: UL:  11 1 917.400 (0 - 5) | DL:   0 0   0.000 (0 - 0)
17:27:10.836 -> RLB_PRO: UL:  12 1 917.600 (0 - 5) | DL:   0 0   0.000 (0 - 0)
17:27:10.877 -> RLB_PRO: UL:  13 1 917.800 (0 - 5) | DL:   0 0   0.000 (0 - 0)
17:27:10.877 -> RLB_PRO: UL:  14 1 918.000 (0 - 5) | DL:   0 0   0.000 (0 - 0)
17:27:10.877 -> RLB_PRO: UL:  15 1 918.200 (0 - 5) | DL:   0 0   0.000 (0 - 0)
17:27:10.909 -> RLB_PRO: [MAC] 0x03
17:27:10.909 -> RLB_PRO: 00000000: 20                                                                 
17:27:10.909 -> RLB_PRO: LinkAdrReq: dataRate = 2, txSteps = 0, nbTrans = 0
17:27:10.909 -> RLB_PRO: LinkAdrAns: 07
17:27:10.909 -> RLB_PRO: [MAC] 0x04
17:27:10.909 -> RLB_PRO: 00000000: 00                                               .                 
17:27:10.941 -> RLB_PRO: DutyCycleReq: max duty cycle = 1/2^0
17:27:10.941 -> RLB_PRO: [MAC] 0x05
17:27:10.941 -> RLB_PRO: 00000000: 08 68 e2 8c                                      .h..              
17:27:10.941 -> RLB_PRO: RXParamSetupReq: Rx1DrOffset = 0, rx2DataRate = 8, freq = 923.300
17:27:10.941 -> RLB_PRO: [MAC] 0x08
17:27:10.941 -> RLB_PRO: 00000000: 01                                               .                 
17:27:10.973 -> RLB_PRO: RXTimingSetupReq: delay = 1 sec
17:27:10.973 -> RLB_PRO: [MAC] 0x09
17:27:10.973 -> RLB_PRO: 00000000: 1d                                               .                 
17:27:10.973 -> RLB_PRO: TxParamSetupReq: dlDwell = 0, ulDwell = 1, maxEirp = 30 dBm
17:27:10.973 -> RLB_PRO: [MAC] 0x0c
17:27:10.973 -> RLB_PRO: 00000000: 65                                               e                 
17:27:10.973 -> RLB_PRO: ADRParamSetupReq: limitExp = 6, delayExp = 5
17:27:11.015 -> RLB_PRO: [MAC] 0x0f
17:27:11.015 -> RLB_PRO: 00000000: fa                                               .                 
17:27:11.015 -> RLB_PRO: RejoinParamSetupReq: maxTime = 15, maxCount = 10
17:27:11.062 -> RLB_PRO: 
17:27:11.062 -> RLB_PRO: PHY:  Frequency = 917.600 MHz, TX = 30 dBm
17:27:11.062 -> RLB_PRO: LoRa: SF = 10, BW = 125.0 kHz, CR = 4/5, IQ: U
17:27:11.404 -> RLB_PRO: JoinRequest sent (DevNonce = 0) <-- Rx Delay start
17:27:11.451 -> RLB_PRO: 00000000: 00 00 00 00 00 00 00 00 00 5a f8 06 d0 7e d5 b3  .........Z...~..
17:27:11.451 -> RLB_PRO: 00000010: 70 00 00 f6 e1 53 91                             p....S.           
17:27:11.451 -> RLB_PRO: 
17:27:11.451 -> RLB_PRO: PHY:  Frequency = 925.700 MHz, TX = 30 dBm
17:27:11.451 -> RLB_PRO: LoRa: SF = 10, BW = 500.0 kHz, CR = 4/5, IQ: D
17:27:16.395 -> RLB_PRO: Opening Rx1 window (77 ms timeout)... <-- Rx Delay end 
17:27:16.471 -> RLB_PRO: Closing Rx1 window
17:27:16.548 -> RLB_PRO: JoinAccept (JoinNonce = 23, previously 0):
17:27:16.548 -> RLB_PRO: 00000000: 20 17 00 00 13 00 00 de 0e 0d 26 88 05 00 ff 00   .........&.....
17:27:16.548 -> RLB_PRO: 00000010: 00 00 00 00 00 02 00 00 00 00 00 00 01 da 3d af  ..............=.
17:27:16.548 -> RLB_PRO: 00000020: 71                                               q                 
17:27:16.548 -> RLB_PRO: LoRaWAN revision: 1.1
17:27:16.548 -> RLB_PRO: [MAC] 0x05
17:27:16.580 -> RLB_PRO: 00000000: 08 68 e2 8c                                      .h..              
17:27:16.580 -> RLB_PRO: RXParamSetupReq: Rx1DrOffset = 0, rx2DataRate = 8, freq = 923.300
17:27:16.580 -> RLB_PRO: [MAC] 0x08
17:27:16.580 -> RLB_PRO: 00000000: 05                                               .                 
17:27:16.580 -> RLB_PRO: RXTimingSetupReq: delay = 5 sec
17:27:16.580 -> RLB_PRO: Processing CFList
17:27:16.580 -> RLB_PRO: [MAC] 0x03
17:27:16.580 -> RLB_PRO: 00000000: ff 00 ff 00 00 00 00 00 00 02 00 00 00 00        ..............    
17:27:16.612 -> RLB_PRO: LinkAdrReq: dataRate = 15, txSteps = 15, nbTrans = 0
17:27:16.612 -> RLB_PRO: UL:   8 1 916.800 (0 - 5) | DL:   0 0   0.000 (0 - 0)
17:27:16.612 -> RLB_PRO: UL:   9 1 917.000 (0 - 5) | DL:   0 0   0.000 (0 - 0)
17:27:16.612 -> RLB_PRO: UL:  10 1 917.200 (0 - 5) | DL:   0 0   0.000 (0 - 0)
17:27:16.612 -> RLB_PRO: UL:  11 1 917.400 (0 - 5) | DL:   0 0   0.000 (0 - 0)
17:27:16.644 -> RLB_PRO: UL:  12 1 917.600 (0 - 5) | DL:   0 0   0.000 (0 - 0)
17:27:16.644 -> RLB_PRO: UL:  13 1 917.800 (0 - 5) | DL:   0 0   0.000 (0 - 0)
17:27:16.644 -> RLB_PRO: UL:  14 1 918.000 (0 - 5) | DL:   0 0   0.000 (0 - 0)
17:27:16.644 -> RLB_PRO: UL:  15 1 918.200 (0 - 5) | DL:   0 0   0.000 (0 - 0)
17:27:16.644 -> RLB_PRO: UL:  65 1 917.500 (6 - 6) | DL:   0 0   0.000 (0 - 0)
17:27:16.644 -> RLB_PRO: LinkAdrAns: 07
17:27:16.644 -> Ready!
17:27:16.686 -> 
17:27:16.686 -> Sending uplink
17:27:16.760 -> RLB_PRO: Uplink MAC payload:
17:27:16.760 -> RLB_PRO: 00000000: 0b 01                                            ..                
17:27:16.760 -> RLB_PRO: Uplink (FCntUp = 0) decoded:
17:27:16.792 -> RLB_PRO: 00000000: 01 00 78 56 7c 8d fb 3f 13 00 00 00 34 12 ba ab  ..xV|..?....4...
17:27:16.792 -> RLB_PRO: 00000010: 40 de 0e 0d 26 82 00 00 7e ff 01 68 d4 ec 00 00  @...&...~..h....
17:27:16.792 -> RLB_PRO: 00000020: 14 80                                            ..                
17:27:16.792 -> RLB_PRO: 
17:27:16.792 -> RLB_PRO: PHY:  Frequency = 917.800 MHz, TX = 30 dBm
17:27:16.792 -> RLB_PRO: LoRa: SF = 10, BW = 125.0 kHz, CR = 4/5, IQ: U
17:27:17.119 -> RLB_PRO: Uplink sent <-- Rx Delay start
17:27:17.155 -> RLB_PRO: 
17:27:17.155 -> RLB_PRO: PHY:  Frequency = 926.300 MHz, TX = 30 dBm
17:27:17.155 -> RLB_PRO: LoRa: SF = 10, BW = 500.0 kHz, CR = 4/5, IQ: D
17:27:22.140 -> RLB_PRO: Opening Rx1 window (77 ms timeout)... <-- Rx Delay end 
17:27:22.222 -> RLB_PRO: Closing Rx1 window
17:27:22.222 -> RLB_PRO: Downlink (NFCntDown = 0) encoded:
17:27:22.222 -> RLB_PRO: 00000000: 49 00 00 00 00 01 de 0e 0d 26 00 00 00 00 00 12  I........&......
17:27:22.254 -> RLB_PRO: 00000010: 60 de 0e 0d 26 8a 00 00 4e 3b a7 41 94 1a 11 f8  `...&...N;.A....
17:27:22.254 -> RLB_PRO: 00000020: 8a 8c a7 63 4d 59                                ...cMY            
17:27:22.254 -> RLB_PRO: [MAC] 0x0b
17:27:22.254 -> RLB_PRO: 00000000: 01                                               .                 
17:27:22.254 -> RLB_PRO: RekeyConf: server version = 1.1
17:27:22.254 -> RLB_PRO: [MAC] 0x09
17:27:22.254 -> RLB_PRO: 00000000: 1d                                               .                 
17:27:22.286 -> RLB_PRO: TxParamSetupReq: dlDwell = 0, ulDwell = 1, maxEirp = 30 dBm
17:27:22.286 -> RLB_PRO: [MAC] 0x03
17:27:22.286 -> RLB_PRO: 00000000: 41 00 ff 00 00 00 00 00 00 00 00 00 00 01        A.............    
17:27:22.286 -> RLB_PRO: LinkAdrReq: dataRate = 4, txSteps = 1, nbTrans = 1
17:27:22.286 -> RLB_PRO: UL:   8 1 916.800 (0 - 5) | DL:   0 0   0.000 (0 - 0)
17:27:22.318 -> RLB_PRO: UL:   9 1 917.000 (0 - 5) | DL:   0 0   0.000 (0 - 0)
17:27:22.318 -> RLB_PRO: UL:  10 1 917.200 (0 - 5) | DL:   0 0   0.000 (0 - 0)
17:27:22.318 -> RLB_PRO: UL:  11 1 917.400 (0 - 5) | DL:   0 0   0.000 (0 - 0)
17:27:22.318 -> RLB_PRO: UL:  12 1 917.600 (0 - 5) | DL:   0 0   0.000 (0 - 0)
17:27:22.318 -> RLB_PRO: UL:  13 1 917.800 (0 - 5) | DL:   0 0   0.000 (0 - 0)
17:27:22.318 -> RLB_PRO: UL:  14 1 918.000 (0 - 5) | DL:   0 0   0.000 (0 - 0)
17:27:22.355 -> RLB_PRO: UL:  15 1 918.200 (0 - 5) | DL:   0 0   0.000 (0 - 0)
17:27:22.355 -> RLB_PRO: LinkAdrAns: 07
17:27:22.355 -> RLB_PRO: [MAC] 0x06
17:27:22.355 -> RLB_PRO: DevStatusAns: status = 0xff06
17:27:22.355 -> Received a downlink
17:27:22.355 -> Next uplink in 300 seconds
17:27:22.355 -> 

[StevenCellist]

Great digging! Weird results with the baud rate - in the latest link I see someone having success again on Arduino-ESP32 core v3.0.2, what version were you on?

The clock stability isn't looking particularly wonderful: I see variations of up to 45ms on your table. I recommend you keep your device running for a while and try sending it a few downlinks every now and then to see if it receives all of them.
If not, you may want to increase the value of node.scanGuard (which basically widens the Rx window). See here:

RadioLib/src/protocols/LoRaWAN/LoRaWAN.h

Lines 856 to 868 in ec78500

	/*!
	\brief Rx window padding in milliseconds
	according to the spec, the Rx window must be at least enough time to effectively detect a preamble
	but we pad it a bit on both sides (start and end) to make sure it is wide enough
	The larger this number the more power will be consumed! So be careful about changing it.
	For debugging purposes 50 is a reasonable start, but for production devices it should
	be as low as possible.
	0 is a valid time.
	500 is the **maximum** value, but it is not a good idea to go anywhere near that.
	If you have to go above 50 you probably have a bug somewhere. Check your device timing.
	*/
	RadioLibTime_t scanGuard = 5;

The current value of 5ms is the minimum stable value across a variety of modern boards we've encountered, including a bunch of LoRa32 v2's and v3's - not sure we've had recent reports of v1's. But the same MCU is on the v2 vs the v1, and we haven't seen any stability problems with ESP32. So maybe there's simply a lot of buffering on the UART which makes it look like it is instable, and in reality it works just fine with the 5ms scan guard. Just test a bit for yourself :)

[ElectronicallyE]

You must be following me, jumping from here to the TTN Forums! ;)

Okay, so I blew the fair use policy out the window for testing (so please don't go reporting me).

I configured the code to send confirmed transmissions every 30 seconds:
int16_t state = node.sendReceive(uplinkPayload, sizeof(uplinkPayload),true);

Here are all the downlink reported by the TTN console and the serial monitor:

All the downlinks were received, so should I adjust node.scanGuard?

The TTN console reports a "RX1 Delay" of "5" for all downlinks, even those which aren't "join accept" downlinks that should be 1s for RX1. Do you know why this is the case? Does your library adjust the delay correctly for a "join accept" downlink versus a "normal" downlink?

Does TTN restrict the number of downlinks and is there any logic behind this (which ones it allows versus blocks)?

On another note, I figured out how to do confirmed uplinks via LoRaWAN_Reference.ino. Is this the best source for all the commands and parameters that can be applied or is there a list with descriptions elsewhere?

[StevenCellist]

No reason to change the scanGuard if all went well.

The TTN console reports a "RX1 Delay" of "5" for all downlinks, even those which aren't "join accept" downlinks that should be 1s for RX1. Do you know why this is the case? Does your library adjust the delay correctly for a "join accept" downlink versus a "normal" downlink?

TTN uses a 5 second Rx1 delay which is communicated through the JoinAccept which is parsed by RadioLib. This 5 second delay allows e.g. webhooks to schedule downlinks based on the uplink. With the default 1s delay, it can be pretty hard to schedule a downlink on time.

Does TTN restrict the number of downlinks and is there any logic behind this (which ones it allows versus blocks)?

TTN FUP limits to at most 10 downlinks a day, but you should regard LoRaWAN as uplink-only except for maybe a configuration change every few days or weeks. Or maybe a 'ping' once a day. Any use case that requires regular downlinks isn't fit for (public) LoRaWAN networks. TTN doesn't automatically block downlinks, but if you happen to spike the usage graphs enough for someone at the TTI towers to notice, someone will push a button to terminate your activity. So for testing, best to get a TTS Discovery instance which doesn't limit FUP.

On another note, I figured out how to do confirmed uplinks via LoRaWAN_Reference.ino. Is this the best source for all the commands and parameters that can be applied or is there a list with descriptions elsewhere?

It's surely the most comprehensive, but otherwise there's the API documentation which lists all available functions.

[ElectronicallyE]

Thanks @StevenCellist for your explanations once again.

TTN uses a 5 second Rx1 delay which is communicated through the JoinAccept which is parsed by RadioLib.

If the default RX1 downlink window is 5 seconds (regardless of a "JoinAccept" or not, why do they say it is 1s? Am I missing something?

TTN doesn't automatically block downlinks, but if you happen to spike the usage graphs enough for someone at the TTI towers to notice, someone will push a button to terminate your activity.

So in my case, would you suspect this is was manually capped/restricted? It seemed to allow a couple of downlinks on the reboot without issue.

[StevenCellist]

RP002-1.0.4 recommends Rx1Delay to be 5 seconds, which TTN apparently put in their docs (is that a screenshot from the v2 docs? formatting looks more like v2 than v3 - TTN did use 1s on v2). They use 5s though.

A handful of downlinks doesn't spike the graphs at once - your screenshot didn't show though that you're missing downlinks?

[ElectronicallyE]

RX1 Delay
That screenshot regarding delays is from https://www.thethingsnetwork.org/docs/lorawan/regional-parameters/ which must be for V2. Not sure why they keep this online if it's out of date?

I've found the latest documentation here:
https://www.thethingsindustries.com/docs/getting-started/glossary/

Class A
Class A devices support bi-directional communication between a device and a gateway. Uplink messages (from the device to the server) can be sent at any time (randomly). The device then opens two receive windows at specified times after an uplink transmission. The first receive window (Rx1) is set to 5 seconds and can be modified. The second receive window (Rx2) always comes 1 second after Rx1.
https://www.thethingsnetwork.org/docs/lorawan/classes/#class-a

Missing Downlinks
Correct, no downlinks are being missed, but the code requests confirmed uplinks...

[StevenCellist]

An uplink is confirmed by the LNS by sending a downlink with the Ack bit set. Which, if you inspected the downlink JSON, you would have seen set to true.

[ElectronicallyE]

Correct, however I should have clarified that better.

I meant that every 30 seconds an uplink was being sent requesting it be confirmed. For the bulk of the transmissions, no confirmation downlink was received. The above list were exclusively uplinks with accompanying downlinks. There were a number without one.