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
Cheers
Paul
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.)
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 
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!
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.
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.
cheers
Paul
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
Specifically
esp_sleep_enable_timer_wakeup(TIME_TO_SLEEP * uS_TO_S_FACTOR);
and using this line after a TX Complete
esp_deep_sleep_start();
regards
Paul
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
Hallo,
second: My Problem: No EV_TXCOMPLETE occurs.
Board TTGO V2.1 1.6
Connection OTAA
Pin mapping:
lmic_pinmap lmic_pins = {
.nss = 18,
.rxtx = LMIC_UNUSED_PIN,
.rst = 12, //12?
.dio = {26, 33, 32},
};
Arduino IDE LMIC https://github.com/matthijskooijman/arduino-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 
(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.
looks that on your gateway side everything is ok 
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
Thanks for the tip, I tried it, but unfortunately without any success.
Greetings
Ernst
Today, in the morning without any change, it works:
Starting
Packet queued
3326: EV_JOINING
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)
#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(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"));
// Disable link check validation (automatically enabled
// during join, but not supported by TTN at this time).
LMIC_setLinkCheckMode(0);
break;
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;
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;
default:
Serial.println(F("Unknown event"));
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() {
Serial.begin(9600);
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();
//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
//LMIC_selectSubBand(1);
// 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 (note: txpow seems to be ignored by the library)
LMIC_setDrTxpow(DR_SF7,14);
// Start job (sending automatically starts OTAA too)
do_send(&sendjob);
}
void loop() {
os_runloop_once();
}
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.
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!
Monitor:
Starting
Packet queued
3199: EV_JOINING
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: