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?
Another issue with “Heltec” Lora32 board:
I’m currently running two boards in 24/7 test. Both pcb’s look fully identical from outside view. Both were purchased from same seller on Amazon in one delivery and came in packaging labeled DIYnik.
Both boards connect to my MatchX TTN gateway, which is ~30m away outdoor. Both boards run identical test code, using LMiC 1.5 arduino-2 with OTAA and SF7.
On the gateway logs one board shows up with RSSI values -60…-70, which is, i think, an expectable level.
The other board shows up with RRSI values -90 … -110, which is surely too weak for the short distance.
I checked both antennas and pigtail cables with a multimeter, no shortage.
Any ideas, what may going wrong here?
How could i figure out the root cause? What to measure?
Gateway logs for board no. 1:
"frequency": 868.3,
"modulation": "LORA",
"data_rate": "SF7BW125",
"coding_rate": "4/5",
"channel": 1,
"rssi": -91,
"snr": 7.5,
"rf_chain": 1
Gateway logs for board no. 2:
"frequency": 868.5,
"modulation": "LORA",
"data_rate": "SF7BW125",
"coding_rate": "4/5",
"channel": 2,
"rssi": -71,
"snr": 6,
"rf_chain": 1
Have you already measured with each board in the exact same position, with the same pigtail and the same antenna (and for both pigtails/antennas)?
Not sure how big the difference but I would also test with the antennas in upright position (for best/most reliable results), assuming the gateway antenna is also in upright position.
I changed the antennas already, what made no difference.
You’re right, i should change the pigtails, too, and i will keep boards in exact same positions.
But i don’t think that 20cm difference in position (see picture) can cause such a high difference in RSSI value over a distance of only 30m on SF7.
Issues with Rev.0 of the ESP32 and differences between Rev.0 and Rev.1 could possibly play a role for problems experienced in this topic.
But the tweet you are referring to and the linked readme do not indicate what “was the problem all te time” exactly means and what Rev.1 has fixed (and if it is fixable with Rev.0 if you know its bugs).
I changed the pigtails. Makes no difference. Still one board has 30 RSSI difference compared to the other.
I checked all pigtails on shortage and passage with Ohm meter. All okay.
yes, a bit unclear. but the direction seems to be the same
Hi @Verkehrsrot. When you spend a lot of money with a high-end manufacturer of industrial radios, one of the things that you are paying for is Quality Control and that all the radios will perform within stated limits and that radios that perform outside the stated limits will be discarded by the manufacturer and not sold.
You may well be seeing the natural wide-variability that comes from the manufacturing process and has not been QC-checked by a low-cost manufacturer.
The way that an industrial customer would deal with this situation is to do their own QC-check as part of purchasing and receiving the radios and to quarantine, reject and return any radios that do not meet the purchase specification.
@bluejedi Could you please also include the fixes/some information on the bad range of some boards in your starting post?
For example iirc some boards come with badly soldered resistors on the back or with broken antenna cables or whatever. I think those things might also be interesting for people who are starting to play around with those boards.