Big ESP32 + SX127x topic part 3

Thanks, have since confirmed you can do it

For future reference of others, using RX, TX, GND and 3v3.

When using in Arduino, hit the upload button and wait till it compiles and starts to try and find a serial port, then hold down program, press reset briefly then let go of program.

Then the sketch should start uploading


1 Like

Yes thanks, that is how a sketch should be ‘manually’ uploaded to the ESP32.
(The same sequence is used for the ESP8266.)

Almost any (breadboard-friendly) ESP32 board already has a USB to Serial adapter integrated on the board so most users never have to press the program and reset buttons sequence (not know about it).
(The integrated onboard USB to Serial adapter uses two transistors in combination with DTR and RTS signals to make uploading go automatically without having to press any buttons.)

Be aware of the 3.3V: When using the separate USB to Serial adapter with your ESP32 board never connect two power sources to the board at the same time. If the board is already powered by a different power source (e.g. a battery or power supply connected to a breadboard) then you should NOT connect the 3.3V power line from the USB to Serial adapter to the board at the same time.
(When normally using the USB connector to both power and program the board this is less/not an issue because power from the USB is normally protected with a diode that prevents reverse currents to the USB port if you have also powered it on the 3.3V pin. But when you power it via the USB to Serial adapter that security measure is not present.)

(Also note that certain CP2102 based boards have a bug where they can output near 5V instead of 3.3V (on the 3.3V line). There also exist CH340 based USB to Serial adapters that you can switch between 5V and 3.3V output but (totally unexpected!) the Rx and Tx signals levels always stay at 5V.
To prevent possibly damage, it is best to measure the output supply voltage(s) and signal level voltages of your (Chinese) USB to Serial adapter before blindly trusting it’s advertised specifications.)

1 Like

New Heltec v2, running the Paxcounter software

Strange I just received this board and not receiving a EV_TXCOMPLETE event. As if DIO’s were not connected correctly. Could also be a bad board … which would simply be bad luck :frowning:

1 Like

Hi maybe there different boards out threre? I found an Answer that made my TX complete on the git, See below. Greetings from Vienna to Verkehrsrot who is doing a great Job!

ssozonoff commented 4 days ago

Had to change as follows in heltecv2.h file else you wont get a complete event for the lora sends.

#define LORA_IRQ 26
#define LORA_IO1 35
#define LORA_IO2 34

There was a bug in paxcounter software, pin mappings of v1 were used on v2. I fixed this today.

1 Like

Hi All,

I am using a TTGo V2 as a base for a tank and cattle trough sensor using a pressure transducer.

I would like to send the TTGo to sleep in between readings to save power, and have been able to achieve this fairly simply.

The issue is that when it wakes up it has to rejoin the network every time from scratch.

Would anybody be able to share a sketch that stores your OTAA session keys before sending to sleep so that it doesn’t have to rejoin every time it starts up.


1 Like

what do you mean by ’ have been able to achieve this fairly simply.’… shutting down power completely ?

Just by using the ESP32 Timer Deep sleep example

esp_sleep_enable_timer_wakeup(TIME_TO_SLEEP * uS_TO_S_FACTOR);
and using this line after a TX Complete


edit: I am guessing the answer might be in using some of this but its a bit beyond my coding experience.

Thank you so much man !
Saved me


second: My Problem: No EV_TXCOMPLETE occurs.

Board TTGO V2.1 1.6

Connection OTAA

Pin mapping:
lmic_pinmap lmic_pins = {
.nss = 18,
.rst = 12, //12?
.dio = {26, 33, 32},

Arduino IDE LMIC

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

Programm based on the example OTAA in the library

Package arrived in the Application and is decodet, but no EV_TXCOMPLETE occurs.

Had someone any idea?

Greetings Ernst

first :you can… now :wink: (but this is the right topic and your question is in english)

what gateway do you use ?

My Gateway is a Raspberry Pi with IMST ic880A-Board.

gateway%20traffic gateway%20traffic2

looks that on your gateway side everything is ok :sunglasses:
the OTAA node joins So it must be related to your code / board

maybe a timing issue, the node won’t receive the otaa join
I’m not a specialist … but adding to this line your code ? it increases the receiving window a little bit
LMIC_setClockError(MAX_CLOCK_ERROR * 1 / 100

1 Like

Thanks for the tip, I tried it, but unfortunately without any success.



Today, in the morning without any change, it works:

Packet queued
452010: EV_JOINED
582620: EV_TXCOMPLETE (includes waiting for RX windows)
Packet queued
4463227: EV_TXCOMPLETE (includes waiting for RX windows)
Packet queued
8343837: EV_TXCOMPLETE (includes waiting for RX windows)

Click to see code

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

// This EUI must be in little-endian format, so least-significant-byte
// first. When copying an EUI from ttnctl output, this means to reverse
// the bytes. For TTN issued EUIs the last bytes should be 0xD5, 0xB3,
// 0x70.
static const u1_t PROGMEM APPEUI[8]={  0xxx, 0xxx, 0xxx, 0xxx, 0xxx, 0xxx, 0xxx, 0xxx  };
void os_getArtEui (u1_t* buf) { memcpy_P(buf, APPEUI, 8);}

// This should also be in little endian format, see above.
static const u1_t PROGMEM DEVEUI[8]={    0xxx, 0xxx, 0xxx, 0xxx, 0xxx, 0xxx, 0xxx, 0xxx  };
void os_getDevEui (u1_t* buf) { memcpy_P(buf, DEVEUI, 8);}

// This key should be in big endian format (or, since it is not really a
// number but a block of memory, endianness does not really apply). In
// practice, a key taken from ttnctl can be copied as-is.
// The key shown here is the semtech default key.
static const u1_t PROGMEM APPKEY[16] = {  0xxx, 0xxx, 0xxx, 0xxx, 0xxx, 0xxx, 0xxx, 0xxx, 0xxx, 0x8A, 0x30, 0x13, 0xC4, 0x88, 0xCB, 0xCB  };
void os_getDevKey (u1_t* buf) {  memcpy_P(buf, APPKEY, 16);}

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
const lmic_pinmap lmic_pins = {
    .nss = 18,
    .rxtx = LMIC_UNUSED_PIN,
    .rst = 12, //12?
    .dio = {26, 33, 32},

void onEvent (ev_t ev) {
    Serial.print(": ");
    switch(ev) {
        case EV_SCAN_TIMEOUT:
        case EV_BEACON_FOUND:
        case EV_BEACON_MISSED:
        case EV_BEACON_TRACKED:
        case EV_JOINING:
        case EV_JOINED:

            // Disable link check validation (automatically enabled
            // during join, but not supported by TTN at this time).
        case EV_RFU1:
        case EV_JOIN_FAILED:
        case EV_REJOIN_FAILED:
        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(F(" bytes of payload"));
            // Schedule next transmission
            os_setTimedCallback(&sendjob, os_getTime()+sec2osticks(TX_INTERVAL), do_send);
        case EV_LOST_TSYNC:
        case EV_RESET:
        case EV_RXCOMPLETE:
            // data received in ping slot
        case EV_LINK_DEAD:
        case EV_LINK_ALIVE:
            Serial.println(F("Unknown event"));

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() {

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

    // LMIC init
    // Reset the MAC state. Session and pending data transfers will be discarded.
    //LMIC_setClockError(MAX_CLOCK_ERROR * 1 / 100);

    //--Frequenzband Europa---------------------------------
    // 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

    // Disable link check validation

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

    // Set data rate and transmit power for uplink (note: txpow seems to be ignored by the library)

    // Start job (sending automatically starts OTAA too)

void loop() {

Now, after testing with my software with sensor-data, the same behavior, no EV_TXCOMPLETE occurs.

I executed the programm i published here (in the morning EV_TXCOMPLETE occurs) , also no EV_TXCOMPLETE occurs.


  • are you moving the node
  • is it very close to your gateway

can you show a new screenshot the node joining again, I see one strange thing and I want to compare new and old screenshot, if possible with different payload

So, the node is 8m away from the Gateway, but now i changed the board. Now i think it is possible a hardwareproblem with one TGGO-Board.

I changed the board and then EV_TXCOMPLETE occurs. I got TGGO-Boards from different suppliers.

Here some Infos!


Packet queued
404147: EV_JOINED
534101: EV_TXCOMPLETE (includes waiting for RX windows)


Thank you BoRRoZ

ok but that’s different hardware now (dev addr)
I assume you use the same code on both modules , except for the keys
indeed conclusion could be:

  • pinmapping is possible different , hw design not the same
  • board is defect