TTGO ESP32 LoRa V1.0 and V1.3 not joining over ABP

Dear TTN-fellows,

I’ve gone carefully through the ESP32 topics:

I’m trying to connect following TTGO boards to TTN using ABP:
http://www.lilygo.cn/prod_view.aspx?TypeId=50003&Id=1136&FId=t3:50003:3
Board versions 1.0 and 1.3.

I’ve previously added a lot of snsors to TTN including the v1.0 version using the no longer maintained LMIC library.

I am now using the arduino-lmic library (newest version):
Using library arduino-lmic-master at version 3.2.0 in folder: C:\Users\bobin\OneDrive\Dokumente\Arduino\libraries\arduino-lmic-master

My pinmapping is correct, I’ve checked it multiple times on the manufacturer website and elsewhere:

const lmic_pinmap lmic_pins = {
    .nss = 18, 
    .rxtx = LMIC_UNUSED_PIN,
    .rst = 14,
    .dio = {/*dio0*/ 26, /*dio1*/ 33, /*dio2*/ 32}
};

I’ve tried using the boards ESP32 dev and TTGO LoRa32-OLED V1. And I’ve contacted already Shramik from myDevices about this issue (very nice and helpul guy):
TTGO LoRa32-OLED V1

I’m getting following output from the Arduino console:

ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x12 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0018,len:4
load:0x3fff001c,len:1044
load:0x40078000,len:8896
load:0x40080400,len:5816
entry 0x400806ac
Starting
11043: EV_TXSTART
Packet queued
141682: EV_TXCOMPLETE (includes waiting for RX windows)
3891703: EV_TXSTART
Packet queued
4022333: EV_TXCOMPLETE (includes waiting for RX windows)
7772354: EV_TXSTART
Packet queued
7902985: EV_TXCOMPLETE (includes waiting for RX windows)
11653005: EV_TXSTART
Packet queued
11783635: EV_TXCOMPLETE (includes waiting for RX windows)
15533656: EV_TXSTART
Packet queued
15664291: EV_TXCOMPLETE (includes waiting for RX windows)
19414310: EV_TXSTART
Packet queued
19544941: EV_TXCOMPLETE (includes waiting for RX windows)
23294961: EV_TXSTART
Packet queued

Please see here my entire code (last digits of the keys were removed), it is the basic ttn_abp example:

/*******************************************************************************
 * Copyright (c) 2015 Thomas Telkamp and Matthijs Kooijman
 * Copyright (c) 2018 Terry Moore, MCCI
 *
 * Permission is hereby granted, free of charge, to anyone
 * obtaining a copy of this document and accompanying files,
 * to do whatever they want with them without any restriction,
 * including, but not limited to, copying, modification and redistribution.
 * NO WARRANTY OF ANY KIND IS PROVIDED.
 *
 * This example sends a valid LoRaWAN packet with payload "Hello,
 * world!", using frequency and encryption settings matching those of
 * the The Things Network.
 *
 * This uses ABP (Activation-by-personalisation), where a DevAddr and
 * Session keys are preconfigured (unlike OTAA, where a DevEUI and
 * application key is configured, while the DevAddr and session keys are
 * assigned/generated in the over-the-air-activation procedure).
 *
 * Note: LoRaWAN per sub-band duty-cycle limitation is enforced (1% in
 * g1, 0.1% in g2), but not the TTN fair usage policy (which is probably
 * violated by this sketch when left running for longer)!
 *
 * To use this sketch, first register your application and device with
 * the things network, to set or generate a DevAddr, NwkSKey and
 * AppSKey. Each device should have their own unique values for these
 * fields.
 *
 * Do not forget to define the radio type correctly in
 * arduino-lmic/project_config/lmic_project_config.h or from your BOARDS.txt.
 *
 *******************************************************************************/

 // References:
 // [feather] adafruit-feather-m0-radio-with-lora-module.pdf

#include <lmic.h>
#include <hal/hal.h>
#include <SPI.h>

//
// For normal use, we require that you edit the sketch to replace FILLMEIN
// with values assigned by the TTN console. However, for regression tests,
// we want to be able to compile these scripts. The regression tests define
// COMPILE_REGRESSION_TEST, and in that case we define FILLMEIN to a non-
// working but innocuous value.
//
#ifdef COMPILE_REGRESSION_TEST
# define FILLMEIN 0
#else
# warning "You must replace the values marked FILLMEIN with real values from the TTN control panel!"
# define FILLMEIN (#dont edit this, edit the lines that use FILLMEIN)
#endif

// LoRaWAN NwkSKey, network session key
// This should be in big-endian (aka msb).
static const PROGMEM u1_t NWKSKEY[16] = { 0xF2, 0xF3, 0x8B, 0x47, 0x43, 0x14, 0x40, 0x8A, 0xCA, 0x95, 0x3B, 0x39, 0x76, 0xXX, 0xXX, 0xXX };

// LoRaWAN AppSKey, application session key
// This should also be in big-endian (aka msb).
static const u1_t PROGMEM APPSKEY[16] = { 0x57, 0xB0, 0x1C, 0x17, 0xC4, 0xB3, 0xB0, 0xA3, 0x6B, 0x60, 0xE7, 0x1D, 0xAD, 0xXX, 0xXX, 0xXX };

// LoRaWAN end-device address (DevAddr)
// See http://thethingsnetwork.org/wiki/AddressSpace
// The library converts the address to network byte order as needed, so this should be in big-endian (aka msb) too.
static const u4_t DEVADDR = 0x2601XXXX ; // <-- Change this address for every node!

// These callbacks are only used in over-the-air activation, so they are
// left empty here (we cannot leave them out completely unless
// DISABLE_JOIN is set in arduino-lmic/project_config/lmic_project_config.h,
// otherwise the linker will complain).
void os_getArtEui (u1_t* buf) { }
void os_getDevEui (u1_t* buf) { }
void os_getDevKey (u1_t* buf) { }

static uint8_t mydata[] = "Hello, world!";
static osjob_t sendjob;

// Schedule TX every this many seconds (might become longer due to duty
// cycle limitations).
const unsigned TX_INTERVAL = 60;

// Pin mapping
// Adapted for Feather M0 per p.10 of [feather]
const lmic_pinmap lmic_pins = {
    .nss = 18, 
    .rxtx = LMIC_UNUSED_PIN,
    .rst = 14,
    .dio = {/*dio0*/ 26, /*dio1*/ 33, /*dio2*/ 32}
};

void onEvent (ev_t ev) {
    Serial.print(os_getTime());
    Serial.print(": ");
    switch(ev) {
        case EV_SCAN_TIMEOUT:
            Serial.println(F("EV_SCAN_TIMEOUT"));
            break;
        case EV_BEACON_FOUND:
            Serial.println(F("EV_BEACON_FOUND"));
            break;
        case EV_BEACON_MISSED:
            Serial.println(F("EV_BEACON_MISSED"));
            break;
        case EV_BEACON_TRACKED:
            Serial.println(F("EV_BEACON_TRACKED"));
            break;
        case EV_JOINING:
            Serial.println(F("EV_JOINING"));
            break;
        case EV_JOINED:
            Serial.println(F("EV_JOINED"));
            break;
        /*
        || This event is defined but not used in the code. No
        || point in wasting codespace on it.
        ||
        || case EV_RFU1:
        ||     Serial.println(F("EV_RFU1"));
        ||     break;
        */
        case EV_JOIN_FAILED:
            Serial.println(F("EV_JOIN_FAILED"));
            break;
        case EV_REJOIN_FAILED:
            Serial.println(F("EV_REJOIN_FAILED"));
            break;
        case EV_TXCOMPLETE:
            Serial.println(F("EV_TXCOMPLETE (includes waiting for RX windows)"));
            if (LMIC.txrxFlags & TXRX_ACK)
              Serial.println(F("Received ack"));
            if (LMIC.dataLen) {
              Serial.println(F("Received "));
              Serial.println(LMIC.dataLen);
              Serial.println(F(" bytes of payload"));
            }
            // Schedule next transmission
            os_setTimedCallback(&sendjob, os_getTime()+sec2osticks(TX_INTERVAL), do_send);
            break;
        case EV_LOST_TSYNC:
            Serial.println(F("EV_LOST_TSYNC"));
            break;
        case EV_RESET:
            Serial.println(F("EV_RESET"));
            break;
        case EV_RXCOMPLETE:
            // data received in ping slot
            Serial.println(F("EV_RXCOMPLETE"));
            break;
        case EV_LINK_DEAD:
            Serial.println(F("EV_LINK_DEAD"));
            break;
        case EV_LINK_ALIVE:
            Serial.println(F("EV_LINK_ALIVE"));
            break;
        /*
        || This event is defined but not used in the code. No
        || point in wasting codespace on it.
        ||
        || case EV_SCAN_FOUND:
        ||    Serial.println(F("EV_SCAN_FOUND"));
        ||    break;
        */
        case EV_TXSTART:
            Serial.println(F("EV_TXSTART"));
            break;
        case EV_TXCANCELED:
            Serial.println(F("EV_TXCANCELED"));
            break;
        case EV_RXSTART:
            /* do not print anything -- it wrecks timing */
            break;
        case EV_JOIN_TXCOMPLETE:
            Serial.println(F("EV_JOIN_TXCOMPLETE: no JoinAccept"));
            break;
        default:
            Serial.print(F("Unknown event: "));
            Serial.println((unsigned) ev);
            break;
    }
}

void do_send(osjob_t* j){
    // Check if there is not a current TX/RX job running
    if (LMIC.opmode & OP_TXRXPEND) {
        Serial.println(F("OP_TXRXPEND, not sending"));
    } else {
        // Prepare upstream data transmission at the next possible time.
        LMIC_setTxData2(1, mydata, sizeof(mydata)-1, 0);
        Serial.println(F("Packet queued"));
    }
    // Next TX is scheduled after TX_COMPLETE event.
}

void setup() {
//    pinMode(13, OUTPUT);
    while (!Serial); // wait for Serial to be initialized
    Serial.begin(115200);
    delay(100);     // per sample code on RF_95 test
    Serial.println(F("Starting"));

    #ifdef VCC_ENABLE
    // For Pinoccio Scout boards
    pinMode(VCC_ENABLE, OUTPUT);
    digitalWrite(VCC_ENABLE, HIGH);
    delay(1000);
    #endif

    // LMIC init
    os_init();
    // Reset the MAC state. Session and pending data transfers will be discarded.
    LMIC_reset();

    // Set static session parameters. Instead of dynamically establishing a session
    // by joining the network, precomputed session parameters are be provided.
    #ifdef PROGMEM
    // On AVR, these values are stored in flash and only copied to RAM
    // once. Copy them to a temporary buffer here, LMIC_setSession will
    // copy them into a buffer of its own again.
    uint8_t appskey[sizeof(APPSKEY)];
    uint8_t nwkskey[sizeof(NWKSKEY)];
    memcpy_P(appskey, APPSKEY, sizeof(APPSKEY));
    memcpy_P(nwkskey, NWKSKEY, sizeof(NWKSKEY));
    LMIC_setSession (0x13, DEVADDR, nwkskey, appskey);
    #else
    // If not running an AVR with PROGMEM, just use the arrays directly
    LMIC_setSession (0x13, DEVADDR, NWKSKEY, APPSKEY);
    #endif

    #if defined(CFG_eu868)
    // Set up the channels used by the Things Network, which corresponds
    // to the defaults of most gateways. Without this, only three base
    // channels from the LoRaWAN specification are used, which certainly
    // works, so it is good for debugging, but can overload those
    // frequencies, so be sure to configure the full frequency range of
    // your network here (unless your network autoconfigures them).
    // Setting up channels should happen after LMIC_setSession, as that
    // configures the minimal channel set. The LMIC doesn't let you change
    // the three basic settings, but we show them here.
    LMIC_setupChannel(0, 868100000, DR_RANGE_MAP(DR_SF12, DR_SF7),  BAND_CENTI);      // g-band
    LMIC_setupChannel(1, 868300000, DR_RANGE_MAP(DR_SF12, DR_SF7B), BAND_CENTI);      // g-band
    LMIC_setupChannel(2, 868500000, DR_RANGE_MAP(DR_SF12, DR_SF7),  BAND_CENTI);      // g-band
    LMIC_setupChannel(3, 867100000, DR_RANGE_MAP(DR_SF12, DR_SF7),  BAND_CENTI);      // g-band
    LMIC_setupChannel(4, 867300000, DR_RANGE_MAP(DR_SF12, DR_SF7),  BAND_CENTI);      // g-band
    LMIC_setupChannel(5, 867500000, DR_RANGE_MAP(DR_SF12, DR_SF7),  BAND_CENTI);      // g-band
    LMIC_setupChannel(6, 867700000, DR_RANGE_MAP(DR_SF12, DR_SF7),  BAND_CENTI);      // g-band
    LMIC_setupChannel(7, 867900000, DR_RANGE_MAP(DR_SF12, DR_SF7),  BAND_CENTI);      // g-band
    LMIC_setupChannel(8, 868800000, DR_RANGE_MAP(DR_FSK,  DR_FSK),  BAND_MILLI);      // g2-band
    // TTN defines an additional channel at 869.525Mhz using SF9 for class B
    // devices' ping slots. LMIC does not have an easy way to define set this
    // frequency and support for class B is spotty and untested, so this
    // frequency is not configured here.
    #elif defined(CFG_us915) || defined(CFG_au915)
    // NA-US and AU channels 0-71 are configured automatically
    // but only one group of 8 should (a subband) should be active
    // TTN recommends the second sub band, 1 in a zero based count.
    // https://github.com/TheThingsNetwork/gateway-conf/blob/master/US-global_conf.json
    LMIC_selectSubBand(1);
    #elif defined(CFG_as923)
    // Set up the channels used in your country. Only two are defined by default,
    // and they cannot be changed.  Use BAND_CENTI to indicate 1% duty cycle.
    // LMIC_setupChannel(0, 923200000, DR_RANGE_MAP(DR_SF12, DR_SF7),  BAND_CENTI);
    // LMIC_setupChannel(1, 923400000, DR_RANGE_MAP(DR_SF12, DR_SF7),  BAND_CENTI);

    // ... extra definitions for channels 2..n here
    #elif defined(CFG_kr920)
    // Set up the channels used in your country. Three are defined by default,
    // and they cannot be changed. Duty cycle doesn't matter, but is conventionally
    // BAND_MILLI.
    // LMIC_setupChannel(0, 922100000, DR_RANGE_MAP(DR_SF12, DR_SF7),  BAND_MILLI);
    // LMIC_setupChannel(1, 922300000, DR_RANGE_MAP(DR_SF12, DR_SF7),  BAND_MILLI);
    // LMIC_setupChannel(2, 922500000, DR_RANGE_MAP(DR_SF12, DR_SF7),  BAND_MILLI);

    // ... extra definitions for channels 3..n here.
    #elif defined(CFG_in866)
    // Set up the channels used in your country. Three are defined by default,
    // and they cannot be changed. Duty cycle doesn't matter, but is conventionally
    // BAND_MILLI.
    // LMIC_setupChannel(0, 865062500, DR_RANGE_MAP(DR_SF12, DR_SF7),  BAND_MILLI);
    // LMIC_setupChannel(1, 865402500, DR_RANGE_MAP(DR_SF12, DR_SF7),  BAND_MILLI);
    // LMIC_setupChannel(2, 865985000, DR_RANGE_MAP(DR_SF12, DR_SF7),  BAND_MILLI);

    // ... extra definitions for channels 3..n here.
    #else
    # error Region not supported
    #endif

    // Disable link check validation
    LMIC_setLinkCheckMode(0);

    // TTN uses SF9 for its RX2 window.
    LMIC.dn2Dr = DR_SF9;

    // Set data rate and transmit power for uplink
    LMIC_setDrTxpow(DR_SF7,14);

    // Start job
    do_send(&sendjob);
}

void loop() {
    unsigned long now;
    now = millis();
    if ((now & 512) != 0) {
      digitalWrite(13, HIGH);
    }
    else {
      digitalWrite(13, LOW);
    }

    os_runloop_once();

}

The console output is good - no complaints from the stack about not being able to talk to the radio, it thinks it’s transmitted, so your pin numbers should be fine.

Do you have a gateway you can check the logs to see if things are arriving but not being processed / rejected.

How far apart is the device from the gateway? Too close and they can overload each other - 10m or behind a brick wall or an substantial computer monitor (iMac in my case).

Just a bit fo terminology, ABP doesn’t join - it just transmits blindly - which can be useful, in other situations like deploying lots of devices, not so much.

Thank you @descartes
I’m using a RAK831 with an RPI3B+, the node is in the same office, I’ve never had issues with too near distances. The gateway is receiving signals from a TTGO T-beam correctly (around 700 today already):

● ttn-gateway.service - The Things Network Gateway
   Loaded: loaded (/lib/systemd/system/ttn-gateway.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2020-11-04 11:05:32 GMT; 3min 16s ago
 Main PID: 5566 (start.sh)
    Tasks: 8 (limit: 4915)
   CGroup: /system.slice/ttn-gateway.service
           ├─5566 /bin/bash /opt/ttn-gateway/packet_forwarder/lora_pkt_fwd/start.sh
           └─5590 ./lora_pkt_fwd

Nov 04 11:08:13 rak-gateway ttn-gateway[5566]: ### [GPS] ###
Nov 04 11:08:13 rak-gateway ttn-gateway[5566]: # Invalid time reference (age: 1604488086 sec)
Nov 04 11:08:13 rak-gateway ttn-gateway[5566]: # no valid GPS coordinates available yet
Nov 04 11:08:13 rak-gateway ttn-gateway[5566]: ##### END #####
Nov 04 11:08:13 rak-gateway ttn-gateway[5566]: JSON up: {"stat":{"time":"2020-11-04 11:08:06 GMT","rxnb":0,"rxok":0,"rxfw":0,"ackr":100.0,"dwnb"
:0,"txnb":0}}
Nov 04 11:08:13 rak-gateway ttn-gateway[5566]: INFO: [up] PUSH_ACK received in 84 ms
Nov 04 11:08:13 rak-gateway ttn-gateway[5566]: WARNING: [gps] could not get GPS time from GPS
Nov 04 11:08:13 rak-gateway ttn-gateway[5566]: INFO: [down] PULL_ACK received in 60 ms
Nov 04 11:08:13 rak-gateway ttn-gateway[5566]: WARNING: [gps] could not get GPS time from GPS
Nov 04 11:08:13 rak-gateway ttn-gateway[5566]: WARNING: [gps] could not get GPS time from GPS

I’m using sudo watch systemctl status ttn-gateway.service
Do you know of a better way to monitor the output?

I’ve also tested my dragino-rpi gateway:

Same here: I receive nothing from the TTGO v1.0/v1.3 boards

As you say, the pinmapping seems fine, if I change the DI0 pin to something ‘wrong’ I receive an error.

Just for completeness, I’ll put my Arduino IDE programming log here:

Using library arduino-lmic-master at version 3.2.0 in folder: C:\Users\bobin\OneDrive\Dokumente\Arduino\libraries\arduino-lmic-master 
Using library SPI at version 1.0 in folder: C:\Users\bobin\AppData\Local\Arduino15\packages\esp32\hardware\esp32\1.0.4\libraries\SPI 
"C:\\Users\\bobin\\AppData\\Local\\Arduino15\\packages\\esp32\\tools\\xtensa-esp32-elf-gcc\\1.22.0-80-g6c4433a-5.2.0/bin/xtensa-esp32-elf-size" -A "C:\\Users\\bobin\\AppData\\Local\\Temp\\arduino_build_596913/ttn-abp.ino.elf"
Sketch uses 233997 bytes (17%) of program storage space. Maximum is 1310720 bytes.
Global variables use 16588 bytes (5%) of dynamic memory, leaving 278324 bytes for local variables. Maximum is 294912 bytes.
C:\Users\bobin\AppData\Local\Arduino15\packages\esp32\tools\esptool_py\2.6.1/esptool.exe --chip esp32 --port COM7 --baud 921600 --before default_reset --after hard_reset write_flash -z --flash_mode dio --flash_freq 80m --flash_size detect 0xe000 C:\Users\bobin\AppData\Local\Arduino15\packages\esp32\hardware\esp32\1.0.4/tools/partitions/boot_app0.bin 0x1000 C:\Users\bobin\AppData\Local\Arduino15\packages\esp32\hardware\esp32\1.0.4/tools/sdk/bin/bootloader_dio_80m.bin 0x10000 C:\Users\bobin\AppData\Local\Temp\arduino_build_596913/ttn-abp.ino.bin 0x8000 C:\Users\bobin\AppData\Local\Temp\arduino_build_596913/ttn-abp.ino.partitions.bin 
esptool.py v2.6
Serial port COM7
Connecting....
Chip is ESP32D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
MAC: f0:08:d1:c8:d9:2c
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 921600
Changed.
Configuring flash size...
Auto-detected Flash size: 4MB
Compressed 8192 bytes to 47...

Writing at 0x0000e000... (100 %)
Wrote 8192 bytes (47 compressed) at 0x0000e000 in 0.0 seconds (effective 4096.0 kbit/s)...
Hash of data verified.
Compressed 15856 bytes to 10276...

Writing at 0x00001000... (100 %)
Wrote 15856 bytes (10276 compressed) at 0x00001000 in 0.1 seconds (effective 893.3 kbit/s)...
Hash of data verified.
Compressed 234112 bytes to 123877...

Writing at 0x00010000... (12 %)
Writing at 0x00014000... (25 %)
Writing at 0x00018000... (37 %)
Writing at 0x0001c000... (50 %)
Writing at 0x00020000... (62 %)
Writing at 0x00024000... (75 %)
Writing at 0x00028000... (87 %)
Writing at 0x0002c000... (100 %)
Wrote 234112 bytes (123877 compressed) at 0x00010000 in 2.6 seconds (effective 729.0 kbit/s)...
Hash of data verified.
Compressed 3072 bytes to 128...

Writing at 0x00008000... (100 %)
Wrote 3072 bytes (128 compressed) at 0x00008000 in 0.0 seconds (effective 1638.4 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...

But maybe now you do, search the forum, it gets mentioned at least once a week and is a very easy thing to try. I’ve already suggested on another thread today.

I know it seems the reverse of being too close, but ensure the antenna is connected - sometimes the pin in the middle can get bent.

If you have a SDR dongle, check to see if there is any RF output.

@descartes thank you! I’ve tried with my 1xV1.0 board and my 2xV1.3 using ABP. I’ve moved around 20-50m away and checked the IPEX connector. I can now verify at least that i am receiving signals and getting a CRC_FAIL 100% error, where you recommended how to fix it already.

I think there might also be a sotware or setting related issue since it’s not working anymore after upgrading from an old lmic library to the newest version of the arduino-lmic library…

I’ve used different SF-settings from 7 to 10. I didn’t touch the frequency setting as I’m living in Germany and the arduino-lmic library defaults to 868MHz. I’m a bit puzzled now.

Great!

Whilst preferable to use more up to date code, it may be worth getting hold of the old software to see if that works, and if it does, then figure out the differences. The one that normally gets me with OTAA is the endian-ness!

@descartes I still haven’t been able to resolve the issue with the new arduino-lmic library. I’ve switched back to my old library that I luckily kept track of:
MCCI_LoRaWAN_LMIC_library-20200619T092138Z-001.zip
Version 2.3.2

Now the four nodes (one ATMEGA1284P custom-built, one V1.0 and two v1.3 TTGO boards) worked very smoothly.

Sadly, I’ve spent like 6-8 hours troubleshooting this problem but I’m not much smarter now besides keeping better track o which versions to use.

Do you think you could help me with the following questions to get a better understanding:

  1. How likely is a CRC_FAIL? Is it often caused by interfering signals having nothing to do with lora signals or: is it mainly corrupted LoRa signals?
  2. The 2.3.2 version library works out of the box for me:
    grafik
    So I thought this cannot be and installed the latest 3.2.0 version again and the packets were not forwarded to TTN. When switching back from 3.2.0 to 2.3.2 with the library manager, the same, no packets for forwarded. Then I manually installed the package that I saved quite some time ago from the github repo (Version 2.3 2018-11-10) and it worked again.

I’m a bit puzzled…at least I can send to TTN again but my understanding of what’s actually going on worries me a bit.

Hah! I lost 10+ man days last summer evaluating Arduino LMIC. We get this fantastically complicated software for free, so we can’t really complain. Hopefully you will answer questions in the future about TTGO ESP32 on this forum!

Not my expertise, I’ll page some people more likely to know. @kersing, @cslorabox, can you comment please

Here’s my offering: GitHub - descartes/Arduino-LMIC-example: Known good Arduino ATmega328 + LoRa chip LoRaWAN node where you will see my comments about trying things out. It says I use MCCI LoRaWAN LMIC library version 2.2.2 but I currently use this GitHub - matthijskooijman/arduino-lmic at 1.5.0+arduino-3 but as Matt has retired the library, I’m re-evaluating the different Arduino stacks.

The software is typical opinionated open source - I find the original IBM source hard to read (I have actually read the MCCI implementation) and there are no road maps or design docs or many (if any) automated tests. Most of the issues on the various repositories aren’t bugs, just people getting to grips with the complexity of the software. I personally sideline the mini-RTOS/scheduler as it allows me to sleep the Arduino - but when people use it on ESP32 and use FreeRTOS in the application, I suspect the software complexity becomes so high (FreeRTOS which schedules the stack which has it’s own scheduler) that I could never justify deploying firmware where a I couldn’t begin to explain what was going on inside.

But the good news is, as long as you don’t try to build a heart bypass monitoring machine powered by a nuclear power station that flies, it does work - I’ve nodes that just keep on going, even when I try to run them over with the lawn mower.

@descartes thank you for the nice replies. I think I’ll drop by here in the forum much more often. This community is so helpful after doing the basic google homework.

I’ve come across your github project previously when googling or a related topic, thank you!

1 Like

I don’t know if your problem is linked with mine but do not forget that MCCI_LoRaWAN_LMIC_library\project_config\lmic_project_config.h file is used in your case for the configuration. So I don’t know if this file is overwritten during update process but it could explain what happened to you …