Heltec V3 versus LilyGo LoRa T V2 comparision table

These are two LoRa development boards and both are good for Meshtastic networks.

 

LilyGo:

Heltec T3 V2:

 

Key Takeaways

• Heltec V3 is a better choice if you need better power efficiency and are working on battery-powered IoT applications because the SX1262 LoRa chip consumes less power than the SX1276.
• LilyGO LoRa32 V2.1 is a good option for projects that don’t need extreme power efficiency but want to use a well-supported and reliable LoRa chip like the SX1276.
• Both boards offer similar OLED display capabilities using I2C, but the GPIO pin assignments differ, so check compatibility when switching between them.

 

A very quick reference chart for two LoRa modules, the Heltec V2 and LilyGo T V2 (T is with the OLED already mounted).

Feature	Heltec V3	LilyGO LoRa32 V2.1
Microcontroller	ESP32 (dual-core, 240 MHz)	ESP32 (dual-core, 240 MHz)
Flash Memory	8MB	4MB
OLED Display	Yes (0.96 inch, 128x64 pixels, I2C)	Yes (0.96 inch, 128x64 pixels, I2C)
OLED SDA (I2C)	GPIO 4	GPIO 21
OLED SCL (I2C)	GPIO 15	GPIO 22
LoRa Chip	SX1262	SX1276
LoRa Frequency Bands	868MHz / 915MHz	868MHz / 915MHz
LoRa SPI MISO	GPIO 19	GPIO 19
LoRa SPI MOSI	GPIO 27	GPIO 27
LoRa SPI SCK	GPIO 5	GPIO 5
LoRa SPI CS	GPIO 18	GPIO 18
LoRa RESET	GPIO 14	GPIO 23
LoRa DIO0	GPIO 26	GPIO 26
LoRa DIO1	GPIO 35	GPIO 33
Power Management	Better low-power modes with SX1262	Good, but SX1276 consumes more power
Antenna	U.FL connector for external antenna	Spring-type antenna (can be replaced)

Meshtastic ESP_32 DevBoard

Everyone know MESHTASTIC!

It is the promise of a new communication meaning over long distances and without any infrastructure needed.

Somethink preppers love!

This communication system has two important features that make it particularly effective for facilitating message communication over long distances:
-LoRa type modulation;
-Self-configuration of devices in a MESH network.
 

I will not go into details, Google is your friend and you will learn everything about LoRa modulation and MESH networks.

In this post I want to talk about how I made my own devices, using cheap modules available on various sites in China.

Things are not so simple; you need some knowledge in electronics to deal with the ready made modules on the market or you can order some 100% finished products. Then you need to program them but that's pretty straightforward as it can be done via a web flashing tool that work with Chrome browser.

But if you are a BRAVE HAM like I am and you already have some modules in the junk box, you may want to make it more flexibile from more basic components.

First, the ESP-32 to SX-1278 module (LoRa Transceiver) is this:

Pretty straightforward; the LoRa TRX communicate with ESP32 via SPI interface.

As we're gonna use the already compiled firmware "Meshtastic DIY", I used the connection from that firmware:

MISO > D19

MOSI > D27

NSS/CS > D18

SCK > D5

RST > D23

DIO0 > D26

But, if I was going to design the board, I must do there something to have some features for future experiments...

So, a number of GPIOs were provided.

A special circuit to activate or deactivate the GPS to save some power was added; the special High-Side switch circuit AP2151 was put into design.

Because, sometime, the circuit is not available, U3 can be tied to 3V3 to keep GPS permanently powered.

Then, two 18650 LiIon battery holders were provided, and a TP4056 module to charge them.

 

Some users complained about unstable operation when the voltage of the battery drop beyond 3V so, a watchdog circuit was added. This monitor the voltage of the battery and, if the voltage drop under 3V (or any other voltage of the user's choice), the ESP32 will be kept into RESET mode until the battery is recharged.

The circuit of choice was TLV840MADL30DBVRQ1.

 

 

 

What other features the board have?

Well, maybe I want to have an external antenna; the SX1278 module came with some kind of short antenna at the end of a thin coaxial pigtail but an external one increase the range of the radio link.  I sometime want to use SMA antennas but to be able to use BNC ones if I want to!

Being a BRAVE but sometimes UNDECIDED ham, I provided the PCB for both kind of connectors. Just a small cut-and-solder of that coaxial and the problem is solved!

 

The GPS of choice ISN'T a uBlox but the but, when designing the PCB, the footprint of the Neo6M was satisfactory to allow installation of several types.

What other feature? Well, a voltage divider to measure the battery voltage, I2C connectors provided for an OLED and for a BME80 pressure/temperature monitor and, of course, a lot of GPIOs spreaded all around the board but some grouped together for some sort of a future expansion board on pogo pins...

In the development process, I ordered the PCB's with some componentes mounted directly in China.

I hoped to solve three problems simultaneously: make the PCBs, buy the components and, if they have to come together, they'd better come mounted on the board! But the count at the fair doesn't match the count at home so, when I received the first version of the PCB, I realized that I had made some major mistakes, which could only be corrected by redesigning it. So, I redesigned it, changed its color from black to blue, made it thinner, from 2mm to just 1mm and ordered it without the components mounted because I was going to transfer them from the V1 boards to the V2 boards...

Then, after I had done the transfer on all ten boards, I realized that in the selection process I had ordered the wrong circuit... AP2141 instead of AP2151. The difference? Well, the former commands the GPS when the command pin is grounded and the later, correctly, commands the GPS when it receives the positive voltage command. So I've hit the wall again...

Fortunately (remember?) I provided a hardware mean to permanently power the GPS... :-)

Next comes replacing that circuit, then will be another hassle...

That's when ham radio bravery goes out after midnight, that's when I get these ideas! 

You can find all the relevant documentation on my Github repository.

LE:

Farnell was very fast and the correct AP2151 is now installed on all boards and everything is performing as expected!

Cheers!

MESHTASTIC TTGO T-Beam V.1.1 Power On issues

 A few weeks ago, I start to play with Meshtastic using two TTGO - TBeam V.1.1 LoRa boards based on ESP32 MCU.

Because plans are to use them as ROUTER_CLIENT, I choose to recharge the battery using a separate TP4035 module and a solar panel.

Of course, I could very well use the built-in AXP192 battery management but the circuit was pretty unsuitable for small solar panels and the TP4056 offers a more stable configuration. 

In the tests I observed a strange behaviour that can negate the usage of these boards as a reliable remote installed device: 

if the battery voltage drops under the Low voltage treshold, the board will not boot into operating mode.

The same behaviour was consistently observed even the charging was resume on the USB port on the T-Beam board itself.

The ESP32 datasheet have some clues about why this issue occurs and how to mitigate it.

Once the power is supplied to the chip, its power rails need a short time to stabilize. After that, CHIP_PU – the
pin used for power-up and reset – is pulled high to activate the chip. For information on CHIP_PU as well as power-up and reset timing, see Figure 2-4 and Table 2-2.

• In scenarios where ESP32 is powered up and down repeatedly by switching the power rails, while there is a
large capacitor on the VDD33 rail and CHIP_PU and VDD33 are connected, simply switching off the
CHIP_PU power rail and immediately switching it back on may cause an incomplete power discharge cycle
and failure to reset the chip adequately.
An additional discharge circuit may be required to accelerate the discharge of the large capacitor on rail
VDD33, which will ensure proper power-on-reset when the ESP32 is powered up again.
• When a battery is used as the power supply for the ESP32 series of chips and modules, a supply voltage
supervisor is recommended, so that a boot failure due to low voltage is avoided. Users are recommended
to pull CHIP_PU low if the power supply for ESP32 is below 2.3 V.

I run some tests and found that if the above hints are observed, the recovery of the ESP32 from transient voltage induced coma is 100% so a supervisor chip was ordered.

The STM1001 microprocessor reset circuit is a low-power supervisory device used to monitor power supplies. It performs a single function: asserting a reset signal whenever the V_CC supply voltage drops below a preset value and keeping it asserted until V_CC has risen above the preset threshold for a minimum period of time (t_rec).

To be continued...

LATER EDIT:

The STM1001 finally arrived (after three days) and I was eager to test the validity of my rationale.

 

 

So, I installed it on the board; the Vss was soldered on a little island of Copper exposed by a sharp razor and the Vcc was tied to the Source pin of the P-channel NCE3401 MOSFET.

 

 

This transistor is there to protect the board against reverse polarity from the battery.

The RST of the STM1001 was tied to RST of the T-Beam board.

And here it is, the final installation:

Now, for the tests...

There are two distinct situations, depending on how the battery is charged; internal or external.

 

FIRST VARIANT - battery charged internally, using the AXP192

The battery is directly installed on the board and the AXP192 circuit is used at it's full. 

The battery is a small capacity one (1.28 Wh), to be able to have it quicly charged to observe the parameters.

The battery is charged by AXP192.

Going from a flat battery (around 2.5V), the  voltage of the cell, measured at STM1001 Vcc and Vss.

The blue LED is signalling the charging, the voltage is rising and when it reached 3.19V (on my DVM), the RST is released from Vss to 3.2 V (the Vcc of the ESP32).

The ESP32 start to run, the LoRa RTX is sending the first beacon.

This was consistent during a set of 5 tests.

SECOND VARIANT - battery charged externally through a TP4053 board.

The same battery is connected to a TP4053 board with protection and the output of the board is connected to the T-Beam board in place of it's battery.

The AXP192 is not able to manage the charging process because it cannot detect the external power presence.

Therefore, the AXP192 will not start and will not be able to Power On the T-Beam board, at least in the current firmware used for Meshtastic.

Due to the way it works (it is a very complicate process - if you don't believe me, read the AXP192 datasheet) it is mandatory to simulate PEK press (Power Enable Key) after the voltage reach 3.2V which is beyond my scope.

I did some crude tests and it is doable but the solution will be more complicate than the one I am searching for.