Issues with Bin v0.2.3 on TTGO LoRa32 v1 and v2 boards

Development
1

I think I understand why I could’t get any of my TTGO-LoRa32 v1 boards to work with the TTGO_LORA_V1 .bin and none of my v2 boards with the v2 .bin file…
And why the v1 board works when I load the v2 .bin file in it; and why the v2 board works when I load the v1 .bin file in it !!

Short explanation: Meshtastic config-file is not using the right pins, because there are interpretation mixups betweenTTGO’s LoRa32 v1 and v2 boards.

I noticed this when looking at an excel file I found elsewhere in our group:


In the above excel sheet (columns B, C, D), the first three TTGO LoRa32 boards, are actually ALL version 2 boards, and there is NO v1 board between them.
The board in column B is the first real v2 board which brought out by TTGO (it had no printed markings at all).
The one in column C is definitely the most recent v2 version of LoRa32, introducing the IP5302 powerbank IC (and 4 totally un-economical blue LEDs), also in several later editions of TTGO’s ESP32 (non-LoRa) boards like T-Cell, T8, TQ…
The v2 board in column D is indeed a V_2.1.6 or T3_1.6 as TTGO marked this 2nd version of an earlier one, with the only difference that the older one merged LiPo and USB inputs via 2 onboard fuses. This could cause the LiPo to overheat when both were connected at the same time. The issue was rapidly solved by TTGO, replacing the LiPo fuse by a schottky diode in a corrected version of T3_V1.6. which is still for sale.

Despite all dubious or non-printed board markings or descriptions on AliExpress, all TTGO’s version 2 LoRa32’s are easy to recognize:
All of them are based on PICO-D4 chips,
upgraded CP2102 to 2104,
they have a microSD-slot on the ESP32’s H-SPI (but somewhat pinswapped), plus pins 2 and 4.
This is why they moved I2C to pins 21 & 22 as a main difference with v1 (which used 4 & 15).
And, to me, this appears contradictory with the Meshtastic config file, which is defining I2C pins on 4 & 15 for v_2 (and not 21 & 22) - while 4 & 15 are precisely the I2C pins used by all v_1 boards of TTGO’s Lora32.

(see an excel file I share gladly with you, regularly updated, as I’m sorting out things: https://www.dropbox.com/s/gly6z21qqps7uvc/espMeshtasticBoards_ev01.xls?dl=0 and see other topic [Issues with Heltec and TTGO pinouts in relation to our config file] )
I’ve been testing various physically different LoRa board versions from Heltec and TTGO, and put their pinouts, including those I don’t own but I’m aware of, in this spreadsheet.
As you will notice, per board, there are 4 columns to illustrate differences in pinouts between by the vendor datasheets, espressif board definition, 3rd column is based on current version in 0.2.2. Meshtastic configuration file, and 4th column is my personal conclusion which pin is actually or probably the right one…

I admit I did a lot of research and sometimes confusion made almost made me pull out my little hair left.
Luckily I got very much inspired by a very big topic on ESP32 LoRa boards, especially BlueJedi’s work on TTN’s forum https://www.thethingsnetwork.org/forum/t/big-esp32-sx127x-topic-part-2/11973 , as well as various info found on Bernard (BeeGee) Giesecke’s site and in Andreas Spiess (@sensorsIOT) video’s which helped me a lot clearing out some misunderstandings. I think confusion is mainly caused by typo’s, unclear, missing or update-lacking manufacturers’ documentation on these boards. Note that we can absolutely blame neither Heltec nor TTGO, because they did a real nice job by producing them in the first place, and listening to their customers to improve those!

So, in my opinion, the solution seems really simple: re-swap I2C pin definitions between v1 and v2 TTGO-Lora32 versions.
If it appears true that the LoRa RST pin is not physically connected to any ESP32 pin, then we don’t need to bother if we define it to 12, 14 or 23 depending on the referrer.

And, maybe, this will permit to take decisions on adding more board versions or changing the layout of the config file, looks more and more like the latter is the simplest thing to remediate this problem, as it will stick to a v1 and v2 version fitting all earlier TTGO boards.

2

oops forgot to share the 2 logs for the v2 boards, which didn’t work with .bin file for V2 but worked well with .bin file for v1 !

and

and one i added later on (the msg also showed up in y Tbeam log in the other post)

1 Like
3

This is a super useful post (I don’t actually have any of these boards). So you are saying I should just swap the SCL/SDA settings between LORA v1 and LORA v2 and we should be good to go? If so, I’ll make that change.

4

I can’t confirm the v2 as I only have a V1 board. I can confirm the V1 pins are not correct, and it does work fine if using the defined V2 pins in place of V1 defined pins.

2 Likes
5

I have a pair of V1 boards. There are no markings on my board and wondered what version I had until I checked eriktheV-king’s awesome spreadsheet. I locally changed the definitions as suggested for the I2C pin for the V1 board, compiled and can confirm that everything works as expected. Bonus is the blue LED now works, pin 2 (v1) vs 25 (v2). I was having to compile for v2 before, with the pin definition swap I now compile for v1.

Well done you guys!

2 Likes
6

good. We just need to swap I2C pins, then !

1 Like
7

ok - I’ll make that change soon. Erik, what is your github name?

8

Hello Kevin je m’y gitlab and github. Same is Erikthev-king. Good to see that crash report mail works!