Hi!
Great topic indeed!
I’ve made a question in the previous topic, so I will ask again:
I can’t make my ESP32 to join my TTN gateway, but in ABP mode, the Arduino sketch says EV_TXCOMPLETE… does this means that my module is correctly wired? (I’m using a ESP32 dev kit wired with a HopeRF RFM95W
Thanks in advance!
For the TTGO LoRa32 v2.0:
OLED:
U8X8_SSD1306_128X32_UNIVISION_HW_I2C u8x8(/* clock=/ 22, / data=*/ 21, U8X8_PIN_NONE);
U8X8_SSD1306_128X64_NONAME_HW_I2C u8x8(/rst/ 16) ;
LoRa-Module:
#define SS 18 // ESP32 GPIO18 (Pin18) – SX1276 NSS (Pin19) SPI Chip Select Input
#define MOSI 27 // ESP32 GPIO27 (Pin27) – SX1276 MOSI (Pin18) SPI Data Input
#define MISO 19 // ESP32 GPIO19 (Pin19) – SX1276 MISO (Pin17) SPI Data Output
#define SCK 5 // ESP32 GPIO5 (Pin5) – SX1276 SCK (Pin16) SPI Clock Input
#define RST 14 // ESP32 GPIO14 (Pin14) – SX1276 NRESET (Pin7) Reset Trigger Input
#define DIO0 26 // ESP32 GPIO26 (Pin15) – SX1276 DIO0 (Pin8) used by LMIC for IRQ RX_Done & TX_Done
DIO1 and DIO2 are connected to the pins labeled 11/12 (see pinmapping).
LiPo Charger:
Chargecurrent: 0,35A (measured with USB-“CHARGER-DOCTOR”)
LED (blue): randomly flickers, if no battery is connected. Lights blue during charging.
Charger-IC marked with LTH7 (could be this one: http://www.mojay.com.cn/enindex.php/proview-32-3.html )
On/Off Switch:
disconnects the battery. the board is always powered over usb.
but there is at least a diode in the path: Battery(+) —|>|—switch—LDO
LED (red):
on if powered by usb or battery.
LED (green) programmable:
#define BUILTIN_LED 22
pinMode(BUILTIN_LED,OUTPUT);
digitalWrite(BUILTIN_LED, LOW); // ON
open issues:
Democode and pinmapping (pay attention to the updated versions in the pullrequests !)
edit: outdated informations removed, updates, gitHub link
Great wrap-up, thank you!
It should be mentioned, at this time, that both boards seem to show up with several quality issues like broken or bad RF path and broken cabling.
For the Heltec boards i can state that they show up with different ESP32 chips in Revision 0 and Revision 1.
I got 4 Heltec boards total so far, from 2 different sellers. 2 boards work fine, 2 have unknown defects causing issues when LoRa packets are sent, and 1 board has broken battery LED (very dim).
indeed… what are the recommended boards @ this moment ?
The LoRa module on the TTGO V2 is very likely from HPDTek:
HPD13A-868S (SX1276) and HPD14A-433S (SX1278).
The layout and pins are compatible with SX127x and HopeRF9x modules. Uses a 4-layer PCB instead of the 2-layer PCB from the HopeRF modules, so the layout will be different (thanks @rocketscream).
The HPD13 (without A, no shield) is discussed in this Rocket Scream article: The SX1276 Modules Shootout
@rocketscream Have you also tested any HPDTek HPD13A modules with the shield?
HPDTek HPD13A
@bluejedi yes tested. If you look at the range mapping on the map, I added the HPD13A plot too. 4-layer board compared to 2-layer boards of RFM95W and NiceRF SX1276-C1. Surprisingly more or less same range achieved but not sure about other aspect like EMI performance and how much easier to obtain FCC/CE with the shield.
So they are using the standard I2C pins now for the TTGO LoRa32 V2 OLED display.
The SPI pins that you list are the same as for the other boards.
If you use the ‘Heltec Wifi LoRa 32’ board definition the I2C (SCL, SDA), SPI (SCK, MOSI, MISO, SS) and LED (LED_BUILTIN) pins are already correctly defined, no need to redefine them.
I see you that you specified no reset pin for the OLED. While many I2C OLED modules don’t use a reset pin the Heltec boards are using a reset pin for the display (not sure about the other TTGO boards).
I would be surprised if they would have dropped the display reset pin on the TTGO LoRa32 V2.
The display on the TTGO LoRa32 V2 is definitely a SSD1306 128x64 not 128x32.
You should be able to use the following instead:
//U8X8_SSD1306_128X64_NONAME_HW_I2C display([reset [, clock, data]])
//When using Heltec Wifi LoRa 32 board definition and reset on pin 16:
U8X8_SSD1306_128X64_NONAME_HW_I2C display(/*rst*/ 16) ;
//When using Heltec Wifi LoRa 32 board definition without reset:
U8X8_SSD1306_128X64_NONAME_HW_I2C display() ;
@TKroenert Could you verify this so I can add it to the topic start?
From a purely specs based perspective the TTGO LoRa32 V2 because:
Pro’s
Cons
Unclear
tnx… there are so many ‘lookalikes’ out there 
A problem on AliExpress and possibly eBay is that sellers show pictures from different boards for one product.
It took me a while before I saw the forest for the trees.
The TTGO LoRa32 V2 is sold by only a few sellers on AliExpress (e.g. Lily GO).
Nice map!
Can you explain that? I only see a much smaller range on the map for the HPD13A (yellow) than for the RFM95W (green) and HPD13 (orange, must enable in menu first). The furthest point that I see for the HPD13A is only 700m from base station.
You may check if your wiring is correct, sometimes tweaking the wires a bit can help (especially on a breadboard). Could be one of the DIO pins, misconfiguration of pins in the software or possibly not having correctly entered the OTAA ID’s/keys (DEVEUI and APPEUI should be in lsb first order, APPKEY in msb first).
I think I didn’t manage to complete it on that day because it started to rain heavily. But, from the plots, they are more consistent within that shorter distance.
I had to slightly modify your code snippet ( U8X8_PIN_NONE ) but it works with and without the reset pin and in FullHD^W 128x64 
:
//When using Heltec Wifi LoRa 32 board definition and reset on pin 16:
U8X8_SSD1306_128X64_NONAME_HW_I2C u8x8(/rst/ 16) ;//When using Heltec Wifi LoRa 32 board definition and reset on pin 16:
U8X8_SSD1306_128X64_NONAME_HW_I2C u8x8(/rst/ U8X8_PIN_NONE);
I also found the green onboard LED connected to pin 22 and LOW == ON (!):
#define BUILTIN_LED 22
pinMode(BUILTIN_LED,OUTPUT);digitalWrite(BUILTIN_LED, LOW); // ON
delay(5000);
digitalWrite(BUILTIN_LED, HIGH); // OFF
Thanks.
You are correct. One has to specify at least one parameter to U8X8_SSD1306_128X64_NONAME_HW_I2C’s constructor (and the first is the reset pin). This appears to be a bug because all constructor parameters have a default value. (I bumped into it before but had forgotten to mention it.)
FYI: BUILTIN_LED is old school. LED_BUILTIN is the new way to go. BUILTIN_LED is (still) supported for backwards compatibility.
FYI: English version of the LTC4054-4.2 Datasheet
As pointed out by @LoRaTracker here, I will redo the test when time permits. We should see a significant increase of range on all 4 modules.
(Somehow) contradicts with / is unclear: “LoRa_DIO1 and LoRa_DIO2 (NOT CONNECTED TO GPIO11/GPIO12)” because pin numbers refer to/are GPIO ports.
Do you mean that GPIO11 and GPIO12 are not available as pins, but DIO1 and DIO2 are available as pins instead and DIO1/DIO2 are not connected to GPIO11/GPIO12?
What made you think that DIO1/DIO2 should be connected to GPIO11/GPIO12 (the other boards use GPIO33/GPIO32)?
Looks like I got the TTGO LoRa32 v1 yesterday. By now I can only say that it has a pretty strong connection if it’s within the same room with the gateway. 
Maybe I have some time for a walk through the neighborhood this evening.
I mean that DIO1 and DIO2 are not connected to GPIO11 and GPIO12, but they are connected to the pins of the pinheader labeled 11 and 12 which are not connected to the GPIO11 and GPIO12 of the ESP.
TL;DR: Connect 11/12 with 32/33 and Bob’s your uncle!
The pinmapping from aliexpress… and that I can toggle GPIO32/33 with digitalWrite() (checked with a multimeter) but I don’t see any changes on the pins DIO1/DIO2 of the LoRa-module.
But I still don’t get it running…
Yesterday I connected 11/12 with 32/33 and for the first time I get a few more lines on the uart:
387386994: RXMODE_SINGLE, freq=868100000, SF=7, BW=125, CR=4/5, IH=0
387449783: RXMODE_SINGLE, freq=869525000, SF=9, BW=125, CR=4/5, IH=0
387451087: EV_TXCOMPLETE (includes waiting for RX windows)
387452201: engineUpdate, opmode=0x900
389327200: engineUpdate, opmode=0x908
389327245: TXMODE, freq=868300000, len=26, SF=7, BW=125, CR=4/5, IH=0
Packet queued
I followed this blogpost My Chinese ESP32 + SX1276 board + DHT11 connected to The Things Network – #1 – ICT en Onderwijs BLOG to setup arduino with lmic library.
I’m using his code: GitHub - PiAir/esp32-sx1276: Code voorbeelden voor het ESP32 + SX1276 board.
I’m not running my own gateway, so I took a walk to a place with better reception ( http://ttnmapper.org/ )… came back, hit F5 and the only thing I see is the framecounter 
Weird that GPIO11 and GPIO12 are not available at pins labeled 11 and 12 (meaning GPIO11 and GPIO12).
That implies that the board has two GPIO ports LESS available and that DIO1 and DIO2 will have to be manually connected to GPIO ports on other pins when needed. I can’t think of any good reason for that.
If the pins labelled 11 and 12 are not GPIO11 and GPIO12 then be prepared for more inconsistencies.
The simplest configuration for testing ESP32+LoRa is download the LMIC-Arduino library (the one mentioned in topic start) and use its ttn-abp.ino example (without adding any additional features). This will send a small string as payload for testing. If that works you can start trying other adventures (OTAA, your own messages etc.).
“and the only thing I see is the framecounter”
No messages showing up in the data tab?
