Heltec ESP32 node + LMIC stuck in Package queued

[Orthogonal_Bee]

Hi, I’m trying to communicate data from a sensor to ttn using an Heltec ESP32 v2, I followed this tutorial (https://nathanmcminn.com/2018/09/12/tutorial-heltec-esp32-board-the-things-network/) but it seems to not work very well for me.
From the ttn console I receive the packets but the node is stucked in “packed queued” and never see “EV_TXCOMPLETE” or receive packet.
The only way to see that event is by manually touching the pins and this make me think that I’m so noob that I missed some hardware setup(?).

Note:

-I don’t think it’s a gateway problem, I tried with and Arduino-dragino node and it seems work
-I’m using the ABP example code with the correct(as the tutorial) pin mapping and correct keys
-using LMIC library correctly configured

Maybe is a not so clever question but I’m not able to see the problem

[cslorabox]

The internal logic in LMiC which decides when to put a raw LoRa packet on the air is quite complex and somewhat disconnected from the input of application-level data packets, as it has to take into account various LoRaWAN modes like OTAA, ADR, confirmed uplink, etc which can potentially lead to an earlier on internally generated packet needing to be sent instead, and also various duty cycle limits which can prevent transmission at all. In some versions at some points of time there have also been bugs where this logic could get stuck, sometimes as a result of assuming it was in a mode it hadn’t actually been asked to be (ie, ADR failure leading to an halfhearted attempt at an OTAA rejoin when operating in ABP mode).

With that as a background, to figure out what is actually going on in your case it would be necessary to have:

• A link to the exact LMiC repo and version being used
• A link to the sketch running on top of that
• a log of the output during operation

[Orthogonal_Bee]

Here’s the library from the Arduino manager:

Here’s the code (.ino and I hope formatted):
`

     // 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] = { };

    // LoRaWAN AppSKey, application session key
    // This should also be in big-endian (aka msb).
    static const u1_t PROGMEM APPSKEY[16] = {  };

    // 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 = 0x; // <-- 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 = {26, 33, 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 lmic_setuproutine() {
      // 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.
        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)
        // NA-US 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);
        #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 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);
        SPI.begin(5, 19, 27);
        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_setuproutine();
    }

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

    }`

basically it’s the example one with pinmap modified.

Here’s the serial:

18:04:31.000 -> Starting
18:04:31.033 -> 9567: EV_TXSTART
18:04:31.033 -> Packet queued

[cslorabox]

It looks like you are using MCCI LMiC, the home of which is https://github.com/mcci-catena/arduino-lmic In general this would be one of the more maintained options, though it may not be the most tuned to the unique issues of the ESP32.

Is that the entire output?

The main challenge would be figuring out if the code is then getting stuck or waiting on something that is never going to happen, perhaps due to a mixup about how the radio is connected or some other configuration issue.

Unfortunately, the Arduino IDE/library mechanism makes it hard to simply go put more debug output deeper in the code of LMiC itself to figure out what is going on. But that probably would be the way to approach the problem. If I recall (it’s been a while) you might be able to do it by modifying the source of the installed library, then quitting and restarting the IDE, but not sure on that.

[Orthogonal_Bee]

The idea was to work on parallel project Heltec and dragino but the more I work like this the more I think is not a good idea…

BTW the serial output (not so user friendly to change):

19:23:02.452 -> Starting
19:23:02.452 -> RXMODE_RSSI
19:23:02.452 -> 9591: engineUpdate, opmode=0x808
19:23:02.452 -> 9624: EV_TXSTART
19:23:02.452 -> 9693: TXMODE, freq=868300000, len=26, SF=7, BW=125, CR=4/5, IH=0
19:23:02.452 -> Packet queued
19:23:03.496 -> start single rx: now-rxtime: 4
19:23:03.496 -> 75940: RXMODE_SINGLE, freq=868300000, SF=7, BW=125, CR=4/5, IH=0

update: while trying to change the output on the ttn console the messages arrive. Maybe is the node that can’t receive confirmation ?

I can see that the messages scheduled for the downlink (scheduled once for the test) is always retransmitted and never shows on the node

[cslorabox]

That’s a different situation than you posted before, now it seems like you are transmitting.

Downlinks not working are a common problem with node side projects, often tracing back to running the receiver at the wrong time. It’s very hard to get this right on any given MCU - sometimes I wonder if it wouldn’t be worth having a mode that just runs the receive continuously from the time the TX packet ends until well past any downlink possibility, power consumption would be high for battery use but it might help narrow down the cause of failures when trying to get started.

Can you try to figure out if your node is continually sending a packet with fcount = 0 because it is failing and suffering a watchdog reset, or because it is trying to send confirmed uplink traffic and not getting an ack? Confirmed traffic is generally a bad idea, the algorithm doesn’t work very well and it will quickly waste your downlink allotment.

The fact that you are only showing a single transmission in your node serial log seems odd - are you not capturing the entire log?

[Orthogonal_Bee]

Sadly it’s all the log, it get stuck there and nothing happen.

I think it may be caused by the fact that ‘do_send’ it’s only called once in the setup and re scheduled in ‘TX_COMPLETE’ and that’s called only after the receiveing of and ack (?).
I was convinced that the library call ‘EV_TXSTART’, transmit and once finished call ‘TX_COMPLETE’ but now I start to think that ‘TX_COMPLETE’ it’s called after receiving the confirmation by ttn.

Not having confirmed traffic I think that’s not a problem for my use case (field sensors) as long as I understand what modify (I’m pretty sure that simply ignore downlink transmission is counter-productive for the network).

If I am correct I will manually schedule the call of ‘do_send’, manipulate something in order to don’t ask for ack and consider the transmission “successful” as long I read the data on the ttn console (managing also the counter) without wait for a ‘EX_TXCOMPLETE’.

I hope I’m not saying to many wrong things.

[cslorabox]

@Orthogonal_Bee

Sadly it’s all the log, it get stuck there and nothing happen.

There should be more.

The server side log at 17:34 and 19:02 might be distinct experiments, but then you have four uplinks in sequence. Were you manually resetting the node each of these times, too?

I think it may be caused by the fact that ‘do_send’ it’s only called once in the setup and re scheduled in ‘TX_COMPLETE’ and that’s called only after the receiveing of and ack (?).

TX_COMPLETE should happen regardless if anything is received or not. Most uplinks never generate a downlink, and most are not even expected to. The code itself can at most “hope” in specific circumstances (like an OTAA join or an ADR request) but it can never really “expect” since it might be operating out of range of any gateway, etc.

If your code is not getting through to there, you need to figure out where execution is getting stuck.

[Orthogonal_Bee]

@cslorabox

There should be more.

If you refer to the depth of the debug is possible that I can modify the library file, If you refer to the fact that there are other transmissions is because I was trying to make it work unplugging and re-doing from the start. Every attempt remain blocked to the first packed queued and after some times I unplug that and make some changes.

The downlink, I set it once to try but never appeared on the node and every time it tries to re-send that.

After some searching I found that in v2 of the Heltec ESP32 the correct .dio pinmap is 26, 34, 35, changing that
`
01:19:18.586 → Starting
01:19:18.586 → RXMODE_RSSI
01:19:18.620 → txCnt :0
01:19:18.620 → 9668: engineUpdate, opmode=0x808
01:19:18.620 → 9702: EV_TXSTART
01:19:18.620 → 9770: TXMODE, freq=868100000, len=26, SF=7, BW=125, CR=4/5, IH=0
01:19:18.620 → Packet queued
01:19:19.660 → start single rx: now-rxtime: 3
01:19:19.660 → 76016: RXMODE_SINGLE, freq=868100000, SF=7, BW=125, CR=4/5, IH=0
01:19:19.660 → rxtimeout: entry: 76545 rxtime: 76010 entry-rxtime: 535 now-entry: 3 rxtime-txend: 62375
01:19:20.676 → start single rx: now-rxtime: 3
01:19:20.676 → 138516: RXMODE_SINGLE, freq=869525000, SF=9, BW=125, CR=4/5, IH=0
01:19:20.712 → rxtimeout: entry: 140325 rxtime: 138510 entry-rxtime: 1815 now-entry: 3 rxtime-txend: 124875
01:19:20.712 → 140343: EV_TXCOMPLETE (includes waiting for RX windows)
01:19:20.712 → 140454: engineUpdate, opmode=0x900
01:20:20.697 → txCnt :1
01:20:20.697 → 3890455: engineUpdate, opmode=0x908
01:20:20.697 → 3890477: EV_TXSTART
01:20:20.697 → 3890542: TXMODE, freq=868300000, len=26, SF=7, BW=125, CR=4/5, IH=0
01:20:20.697 → Packet queued
01:20:21.754 → start single rx: now-rxtime: 3
01:20:21.754 → 3956788: RXMODE_SINGLE, freq=868300000, SF=7, BW=125, CR=4/5, IH=0
01:20:21.754 → rxtimeout: entry: 3957317 rxtime: 3956782 entry-rxtime: 535 now-entry: 3 rxtime-txend: 62375
01:20:22.748 → start single rx: now-rxtime: 3
01:20:22.748 → 4019288: RXMODE_SINGLE, freq=869525000, SF=9, BW=125, CR=4/5, IH=0
01:20:22.780 → rxtimeout: entry: 4021097 rxtime: 4019282 entry-rxtime: 1815 now-entry: 3 rxtime-txend: 124875
01:20:22.780 → 4021113: EV_TXCOMPLETE (includes waiting for RX windows)
01:20:22.814 → 4021243: engineUpdate, opmode=0x900
01:21:22.783 → txCnt :2
01:21:22.783 → 7771243: engineUpdate, opmode=0x908
01:21:22.783 → 7771265: EV_TXSTART
01:21:22.783 → 7771330: TXMODE, freq=868500000, len=26, SF=7, BW=125, CR=4/5, IH=0
01:21:22.819 → Packet queued
01:21:23.842 → start single rx: now-rxtime: 4
01:21:23.842 → 7837577: RXMODE_SINGLE, freq=868500000, SF=7, BW=125, CR=4/5, IH=0
01:21:23.842 → rxtimeout: entry: 7838105 rxtime: 7837570 entry-rxtime: 535 now-entry: 4 rxtime-txend: 62375
01:21:24.859 → start single rx: now-rxtime: 4
01:21:24.859 → 7900076: RXMODE_SINGLE, freq=869525000, SF=9, BW=125, CR=4/5, IH=0
01:21:24.892 → rxtimeout: entry: 7901885 rxtime: 7900070 entry-rxtime: 1815 now-entry: 4 rxtime-txend: 124875
01:21:24.892 → 7901902: EV_TXCOMPLETE (includes waiting for RX windows)
01:21:24.892 → 7902031: engineUpdate, opmode=0x900

Better but on ttn console I can only see the first packet after the start.

Googling around I saw that other board need nome pins connected each other, maybe I missed that part ? I tried to connect the dio pins with rst and nss in various combination but none of that worked well…

[cslorabox]

Seems like you’re getting closer to normal operation now, so indeed it sounds like mixed up radio wiring was getting things stuck

@Orthogonal_Bee

Better but on ttn console I can only see the first packet after the start.

Hmm, do you see raw packets at appropriate times on the gateway log page?

There are various reasons LoRa level packets could be dropped by the network software and not validated as belonging to your device, so the first question would be if the gateway is receiving any packets after the first.

What exactly is your gateway? It is a real LoRaWAN gateway and not a single channel abomination, right?

[Orthogonal_Bee]

@cslorabox

Hmm, do you see raw packets at appropriate times on the gateway log page?

Yes

@cslorabox

It is a real LoRaWAN gateway and not a single channel abomination, right?

Ehm… it’s a dual channel abomination, Dragino lg02… I was doing this project with my University but due to the covid lockdown I wasn’t able to reach that anymore, the region where I live was not covered by ttn and I was hoping that lgo2 was enough for test my node and than use that with my university region’s gateway.
Searching in the ‘gateway’ log only packet that I see on ttn console appear.

I made new testing, it seems that the node work correctly at the start:

 10:35:39.517 -> Starting
10:35:39.517 -> RXMODE_RSSI
10:35:39.517 -> txCnt :0
10:35:39.517 -> 9607: engineUpdate, opmode=0x808
10:35:39.517 -> 9641: EV_TXSTART
10:35:39.517 -> 9709: TXMODE, freq=867700000, len=26, SF=7, BW=125, CR=4/5, IH=0
10:35:39.552 -> Packet queued
10:35:40.604 -> start single rx: now-rxtime: 4
10:35:40.604 -> 75956: RXMODE_SINGLE, freq=867700000, SF=7, BW=125, CR=4/5, IH=0
10:35:40.604 -> rxtimeout: entry: 76484 rxtime: 75949 entry-rxtime: 535 now-entry: 4 rxtime-txend: 62375
10:35:41.576 -> start single rx: now-rxtime: 4
10:35:41.576 -> 138456: RXMODE_SINGLE, freq=869525000, SF=9, BW=125, CR=4/5, IH=0
10:35:41.609 -> rxtimeout: entry: 140264 rxtime: 138449 entry-rxtime: 1815 now-entry: 4 rxtime-txend: 124875
10:35:41.609 -> 140282: EV_TXCOMPLETE (includes waiting for RX windows)
10:35:41.643 -> 140394: engineUpdate, opmode=0x900
10:36:11.604 -> txCnt :1
10:36:11.604 -> 2015395: engineUpdate, opmode=0x908
10:36:11.638 -> 2015417: EV_TXSTART
10:36:11.638 -> 2015482: TXMODE, freq=867900000, len=26, SF=7, BW=125, CR=4/5, IH=0
10:36:11.638 -> Packet queued
10:36:12.669 -> start single rx: now-rxtime: 4
10:36:12.669 -> 2081729: RXMODE_SINGLE, freq=867900000, SF=7, BW=125, CR=4/5, IH=0
10:36:12.703 -> rxtimeout: entry: 2082257 rxtime: 2081722 entry-rxtime: 535 now-entry: 4 rxtime-txend: 62375
10:36:13.691 -> start single rx: now-rxtime: 4
10:36:13.691 -> 2144229: RXMODE_SINGLE, freq=869525000, SF=9, BW=125, CR=4/5, IH=0
10:36:13.691 -> rxtimeout: entry: 2146037 rxtime: 2144222 entry-rxtime: 1815 now-entry: 4 rxtime-txend: 124875
10:36:13.725 -> 2146055: engineUpdate, opmode=0x908
10:36:17.773 -> 2400373: engineUpdate, opmode=0x108
10:36:17.773 -> 2400394: EV_TXSTART
10:36:17.773 -> 2400459: TXMODE, freq=868100000, len=26, SF=7, BW=125, CR=4/5, IH=0
10:36:18.832 -> start single rx: now-rxtime: 4
10:36:18.832 -> 2466706: RXMODE_SINGLE, freq=868100000, SF=7, BW=125, CR=4/5, IH=0
10:36:18.832 -> rxtimeout: entry: 2467234 rxtime: 2466699 entry-rxtime: 535 now-entry: 4 rxtime-txend: 62375
10:36:19.831 -> start single rx: now-rxtime: 4
10:36:19.831 -> 2529206: RXMODE_SINGLE, freq=869525000, SF=9, BW=125, CR=4/5, IH=0
10:36:19.868 -> rxtimeout: entry: 2531014 rxtime: 2529199 entry-rxtime: 1815 now-entry: 4 rxtime-txend: 124875
10:36:19.868 -> 2531031: engineUpdate, opmode=0x908
10:36:23.936 -> 2785351: engineUpdate, opmode=0x108
10:36:23.936 -> 2785371: EV_TXSTART
10:36:23.936 -> 2785437: TXMODE, freq=868300000, len=26, SF=8, BW=125, CR=4/5, IH=0
10:36:25.042 -> start single rx: now-rxtime: 4
10:36:25.042 -> 2854898: RXMODE_SINGLE, freq=868300000, SF=8, BW=125, CR=4/5, IH=0
10:36:25.074 -> rxtimeout: entry: 2855811 rxtime: 2854892 entry-rxtime: 919 now-entry: 4 rxtime-txend: 62375
10:36:26.042 -> start single rx: now-rxtime: 4
10:36:26.042 -> 2917398: RXMODE_SINGLE, freq=869525000, SF=9, BW=125, CR=4/5, IH=0
10:36:26.075 -> rxtimeout: entry: 2919207 rxtime: 2917392 entry-rxtime: 1815 now-entry: 4 rxtime-txend: 124875
10:36:26.075 -> 2919228: engineUpdate, opmode=0x908
10:36:35.250 -> 3491928: engineUpdate, opmode=0x108
10:36:35.250 -> 3491948: EV_TXSTART
10:36:35.250 -> 3492014: TXMODE, freq=868500000, len=26, SF=8, BW=125, CR=4/5, IH=0
10:36:36.354 -> start single rx: now-rxtime: 4
10:36:36.354 -> 3561476: RXMODE_SINGLE, freq=868500000, SF=8, BW=125, CR=4/5, IH=0
10:36:36.354 -> rxtimeout: entry: 3562388 rxtime: 3561469 entry-rxtime: 919 now-entry: 4 rxtime-txend: 62375
10:36:37.370 -> start single rx: now-rxtime: 4
10:36:37.370 -> 3623975: RXMODE_SINGLE, freq=869525000, SF=9, BW=125, CR=4/5, IH=0
10:36:37.370 -> rxtimeout: entry: 3625784 rxtime: 3623969 entry-rxtime: 1815 now-entry: 4 rxtime-txend: 124875
10:36:37.404 -> 3625801: engineUpdate, opmode=0x908
10:36:46.550 -> 4198506: engineUpdate, opmode=0x108
10:36:46.550 -> 4198526: EV_TXSTART
10:36:46.550 -> 4198592: TXMODE, freq=867100000, len=26, SF=9, BW=125, CR=4/5, IH=0
10:36:47.755 -> start single rx: now-rxtime: 4
10:36:47.755 -> 4273846: RXMODE_SINGLE, freq=867100000, SF=9, BW=125, CR=4/5, IH=0
10:36:47.790 -> rxtimeout: entry: 4275654 rxtime: 4273839 entry-rxtime: 1815 now-entry: 4 rxtime-txend: 62375
10:36:48.751 -> start single rx: now-rxtime: 4
10:36:48.751 -> 4336345: RXMODE_SINGLE, freq=869525000, SF=9, BW=125, CR=4/5, IH=0
10:36:48.784 -> rxtimeout: entry: 4338154 rxtime: 4336339 entry-rxtime: 1815 now-entry: 4 rxtime-txend: 124875
10:36:48.784 -> 4338171: engineUpdate, opmode=0x908
10:37:07.114 -> 5484284: engineUpdate, opmode=0x108
10:37:07.114 -> 5484305: EV_TXSTART
10:37:07.114 -> 5484370: TXMODE, freq=867300000, len=26, SF=9, BW=125, CR=4/5, IH=0
10:37:08.311 -> start single rx: now-rxtime: 4
10:37:08.346 -> 5559625: RXMODE_SINGLE, freq=867300000, SF=9, BW=125, CR=4/5, IH=0
10:37:08.346 -> rxtimeout: entry: 5561433 rxtime: 5559618 entry-rxtime: 1815 now-entry: 4 rxtime-txend: 62375
10:37:09.326 -> start single rx: now-rxtime: 4
10:37:09.326 -> 5622124: RXMODE_SINGLE, freq=869525000, SF=9, BW=125, CR=4/5, IH=0
10:37:09.359 -> rxtimeout: entry: 5623933 rxtime: 5622118 entry-rxtime: 1815 now-entry: 4 rxtime-txend: 124875
10:37:09.359 -> 5623951: engineUpdate, opmode=0x908
10:37:27.705 -> 6770062: engineUpdate, opmode=0x108
10:37:27.705 -> 6770083: EV_TXSTART
10:37:27.705 -> 6770149: TXMODE, freq=867500000, len=26, SF=10, BW=125, CR=4/5, IH=0
10:37:29.102 -> start single rx: now-rxtime: 3
10:37:29.102 -> 6858266: RXMODE_SINGLE, freq=867500000, SF=10, BW=125, CR=4/5, IH=0
10:37:29.169 -> rxtimeout: entry: 6861867 rxtime: 6858260 entry-rxtime: 3607 now-entry: 3 rxtime-txend: 62375
10:37:30.092 -> start single rx: now-rxtime: 3
10:37:30.092 -> 6920766: RXMODE_SINGLE, freq=869525000, SF=9, BW=125, CR=4/5, IH=0
10:37:30.126 -> rxtimeout: entry: 6922575 rxtime: 6920760 entry-rxtime: 1815 now-entry: 3 rxtime-txend: 124875
10:37:30.126 -> 6922596: engineUpdate, opmode=0x908
10:38:08.847 -> 9342440: engineUpdate, opmode=0x108
10:38:08.847 -> 9342460: EV_TXSTART
10:38:08.847 -> 9342525: TXMODE, freq=867700000, len=26, SF=10, BW=125, CR=4/5, IH=0
10:38:21.856 -> start single rx: now-rxtime: 3
10:38:21.856 -> 9430643: RXMODE_SINGLE, freq=867700000, SF=10, BW=125, CR=4/5, IH=0
10:38:21.856 -> rxtimeout: entry: 9434244 rxtime: 9430637 entry-rxtime: 3607 now-entry: 3 rxtime-txend: 62375
10:38:21.856 -> start single rx: now-rxtime: 3
10:38:21.856 -> 9493143: RXMODE_SINGLE, freq=869525000, SF=9, BW=125, CR=4/5, IH=0
10:38:21.856 -> rxtimeout: entry: 9494952 rxtime: 9493137 entry-rxtime: 1815 now-entry: 3 rxtime-txend: 124875
10:38:21.856 -> 9494969: EV_TXCOMPLETE (includes waiting for RX windows)
10:38:21.856 -> 9495098: engineUpdate, opmode=0x900
10:38:41.291 -> txCnt :2
10:38:41.291 -> 11370099: engineUpdate, opmode=0x908
10:38:41.291 -> Packet queued
10:38:49.999 -> 11914817: engineUpdate, opmode=0x108
10:38:49.999 -> 11914838: EV_TXSTART
10:38:49.999 -> 11914904: TXMODE, freq=867900000, len=26, SF=10, BW=125, CR=4/5, IH=0
10:38:51.432 -> start single rx: now-rxtime: 3
10:38:51.432 -> 12003021: RXMODE_SINGLE, freq=867900000, SF=10, BW=125, CR=4/5, IH=0
10:38:51.466 -> rxtimeout: entry: 12006622 rxtime: 12003015 entry-rxtime: 3607 now-entry: 4 rxtime-txend: 62375
10:38:52.422 -> start single rx: now-rxtime: 3
10:38:52.422 -> 12065521: RXMODE_SINGLE, freq=869525000, SF=9, BW=125, CR=4/5, IH=0
10:38:52.456 -> rxtimeout: entry: 12067330 rxtime: 12065515 entry-rxtime: 1815 now-entry: 3 rxtime-txend: 124875
10:38:52.456 -> 12067347: engineUpdate, opmode=0x908
10:39:31.174 -> 14487195: engineUpdate, opmode=0x108
10:39:31.174 -> 14487216: EV_TXSTART
10:39:31.174 -> 14487281: TXMODE, freq=868100000, len=26, SF=10, BW=125, CR=4/5, IH=0
10:39:32.591 -> start single rx: now-rxtime: 3
10:39:32.591 -> 14575398: RXMODE_SINGLE, freq=868100000, SF=10, BW=125, CR=4/5, IH=0
10:39:32.627 -> rxtimeout: entry: 14578999 rxtime: 14575392 entry-rxtime: 3607 now-entry: 3 rxtime-txend: 62375
10:39:33.593 -> start single rx: now-rxtime: 3
10:39:33.593 -> 14637898: RXMODE_SINGLE, freq=869525000, SF=9, BW=125, CR=4/5, IH=0
10:39:33.593 -> rxtimeout: entry: 14639707 rxtime: 14637892 entry-rxtime: 1815 now-entry: 3 rxtime-txend: 124875
10:39:33.627 -> 14639724: engineUpdate, opmode=0x908
10:40:12.310 -> 17059573: engineUpdate, opmode=0x108
10:40:12.310 -> 17059594: EV_TXSTART
10:40:12.344 -> 17059659: TXMODE, freq=868300000, len=26, SF=11, BW=125, CR=4/5, IH=0
10:40:14.137 -> start single rx: now-rxtime: 4
10:40:14.137 -> 17173505: RXMODE_SINGLE, freq=868300000, SF=11, BW=125, CR=4/5, IH=0
10:40:14.271 -> rxtimeout: entry: 17180689 rxtime: 17173498 entry-rxtime: 7191 now-entry: 4 rxtime-txend: 62375
10:40:15.148 -> start single rx: now-rxtime: 4
10:40:15.148 -> 17236005: RXMODE_SINGLE, freq=869525000, SF=9, BW=125, CR=4/5, IH=0
10:40:15.185 -> rxtimeout: entry: 17237813 rxtime: 17235998 entry-rxtime: 1815 now-entry: 4 rxtime-txend: 124875
10:40:15.185 -> 17237834: engineUpdate, opmode=0x908

on ttn console I see that only 10:36:17 packet is received, and in gateway is the only packet that appear

[cslorabox]

@Orthogonal_Bee

Ehm… it’s a dual channel abomination

In that case the first possibility to consider is the node walking off the supported channel(s).

A subsequent one would be walking off the supported spreading factor.

Your log appears to show both - transmissions on several frequencies and spreading factors.

There are reasons only actual gateways built around sx130x concentrator cards are recommended.

(not clear to me if the LG02 actually uses both radios for receive to cover two uplink frequency/sf combinations, or keeps one for transmit - not a question I’ve considered very interesting when the box itself is a bad idea, though an additional radio for transmit beside an actual concentrator chip is potentially interesting)

Since you’re probably not going to switch gateways today, if you have to keep going against recommendations the thing to do would be search for old threads about how people hacked LMiC to work with a single channel, and disable ADR you have a single spreading factor - those conversations are considered dead to history but are still there.

[Orthogonal_Bee]

@cslorabox

There are reasons only actual gateways built around sx130x concentrator cards are recommended.

I understand, in normal circumstances probably I’ve asked my relator to acquire one of that, in this case I was worried to don’t have the ability to setup everything alone and I hoped that an lg02 was enough for testing … once the situation will resolve I will use real gateway.

Now I will concentrate my attention on the node.

Btw thank you for everything, I’m sorry because this and the pin map are noobie errors but I couldn’t figure out alone and I was quite overwhelmed and worried.

Best regards

[bluejedi]

You can find more information in the ESP32 topics here on the forum (just use search).

Dragino LG02 is not a LoRaWAN gateway but a "single channel packet forwarder’.
Single channel devices are not LoRaWAN compliant and are NOT supported on the forum.

[Orthogonal_Bee]

@bluejedi

Single channel devices are not LoRaWAN compliant and are NOT supported on the forum

I’m sorry, my intent wasn’t to get help for the lg02, at the time I didn’t think to that, I was convinced that the (only) problem was in the the way I was using the node.

[bluejedi]

No problem. This was just to note that the thread shall not turn into a single channel related discussion.

[cslorabox]

As far as I can tell, the current problem is a single channel (well, dual channel) problem - the node assumes a real gateway, so the dragino thing is missing most of the traffic.

There are probably other issues as well, but that is the blocking one.

[heikkij]

FYI: like other posters have stated you may have other problems too, but I never got the LMIC to work on the HelTecV2, like you said it gets stuck connecting (in my case using both an i880a and MikroTik Lora8). The stack HelTec provides worked (but I would prefer LMIC).

Even though its supposed to be the same HW, the TTgo connected, but the V2 never did ?

Btw, if you are going to use this for a low power application, just know that most esp32 board take around 100mA, so basically useless for battery powered applications.

This guy has a spreadsheet somewhere for the power consumption. Since I need power I basically gave up on HelTecV2. Their new CubeCell series is much better when it comes to power.