Big ESP32 + SX127x topic part 3

Not exactly clear what you mean here.

The standard procedure to push the ESP32 into firmware upload mode is to temporarily connect IO0 to ground, then connect Reset to ground, release Reset again and then release IO0 again.
On ESP32 boards like the TTGO LoRa32 this is done programatically via the DTR and RTS serial port lines using a circuit consisting of two transistors connecting DTR, RTS, IO0 and Reset. The USB to serial adapter is integrated on the board. Connecting reset to ground can also be done with the reset button but the board has no button for IO0.

If you have problems with pushing the ESP32 board automatically into firmware upload mode via USB/Serial but it works when you manually connect IO0 to ground this may indicate a hardware defect of the board.

Could make sense to alter this topic ‘subject’ line…

This is a new TTGO LoRa32 V2.1.6 with SX1262 radio.

image

Datasheet (in Chinese) for the HPD16A module that was custom designed by HPDTeK upon request from LilyGO company (owner of TTGO brand) and SoftRF open source project.

1 Like

Yes, I was already considering that for ‘part 4’ of this topic.

Additional options and considerations are:

  1. Continue this topic in a new topic “ESP32 LoRa boards part 4”.
    In part 4 in the start topic, information available for each board will be presented in collapsed form as a list of board names. Clicking on a board name will then reveal the information for that board.
    Bij collapsing the information, the start topic will not be cluttered with a long list of information for all boards. People are usually interested in only one board at a time and having to scroll information for all boards to find the information for a specific board is not exactly efficient.
    Possible disadvantage: Will people then still be able to find the information they are looking for or will they no longer notice it and just quickly scroll over it?

  2. Create a separate topic for each ESP32 board (family) instead of having one main ESP32 topic (option 1)
    That way board specific questions and information are concentrated in a single board-specific topic.
    The disadvantage of this option is that ESP32 specific/generic information will be fragmented over several topics.

Which option would you (users of this ESP32 topic) prefer and why?

Are you using LoRa or LoRaWAN for SoftRF?
Which library currently supports LoRaWAN on ESP32 for SX1262?

I would personally vote for option 1:

“Big ESP32 +…” topic has a long history on this forum (since 2017, right?) and is one of the topmost popular threads here.

It aggregates every news that happens with LoPy, HELTEC, WeMos, TTGO and other LoRa ESP32 development boards on the market.

De facto, almost every of individual ESP32 boards has their own thread(s) here. But advantage of this particular one - this is the place where we can compare them.

1 Like

It was already answered here before.

SoftRF is using LoRa Phy layer / modulation to operate on so-called FANET radio protocol.
FANET is 1 out of 4 protocols supported. Other 3 are FSK modulation based.

FANET (LoRa based) is a standard feature of ‘factory’ SoftRF firmware.
However, one LoRaWAN ‘application’ - TTNMapper is included into SoftRF source code and can be activated by a custom build.

Semtech Basic MAC (successor of LMIC) derivative named ‘arduino-basicmac’ (adapted for Arduino by Matthijs Kooijman upon request from Lacuna Space) is known to work good enough on ESP32+SX1262 with TheThingsNetwork.

“Already answered … before”?
If you mean:

That does not answer my question above.
It is also hidden in a different topic in a post from 2 years ago.
I looked in the SoftRF README.md on GitHub but it does not mention anything about whether LoRa or LoRaWAN is used.
It is better to add that information to the SoftRF README.md than to hide it in some topic on this forum.

Of course. That slipped my mind, probably because I have not yet used it.

Hello,

I could also mention this library: GitHub - ngraziano/LMICPP-Arduino: Lmic (LoraWAN-in-C) modified to C++
“Add SX1262 chip”

Is it posible to buy this new TTGO LoRa32 V2.1.6 with SX12 62 radio somewhere ?

This SX1262 based TTGO T3 dev. board (a.k.a. “LoRa32”), as well as other updated “TTGO LoRa series” products (such as T-Beam, T-Fox, etc), are expected to appear in AliExpress stores within July.

This is an example of TTGO T22 (a.k.a. “T-Beam”) with HPD16A (SX1262) LoRa module:

image

Is there a particular reason or advantage for wanting to use an SX1262 ?

The SX1262 has some power advantages over the SX1276 in receive mode, but TTN nodes dont do a lot of time in receive mode.

Over these two years Semtech is aggressively pushing the 126x family onto the market and likely will cease some use cases of older 127x family in favour of the new one within a year or two.

High volume price tag of 126x IC is the same or less than 127x has.

One of the examples of the Semtech ‘arguments’ is that 126x family is best suited for upcoming ‘LoRa Space’ applications. Lacuna Space efforts are intended to prove that.

According to this ‘press release’ from RFThings : https://rfthings.com.vn/shop/ , Lacuna will (likely) NOT make their ‘Space dev. kits’ available in July as intended before but is going to slide them onto September.

If you want to do LoRaWAN over satellite with Lacuna you will need SX1262.

And that is maybe a very small percentage of TTN users.

But what is the specific reason that the SX126x is required ?

IIRC, in case of satellite usage this has to do with a special LoRa modulation mode that uses more frequencies for the chirp spread spectrum modulation. To allow for more capacity, because the satellite covers a very large area.
(But I don’t remember the exact technical details.)

Interesting, the only significant difference reported in the datasheet I can recall is that the SX126x supports explicit mode in SF6 and has an additional SF5. SF6 on the SX126x is not compatible with SF6 on the SX127x.

The SX126x has a TCXO and that allows for stable operation down to a bandwidth of 7800hz, which was never really possible with SX127x.

In many way the SX1261 would be a better choice, it allows for a DCDC converter in TX mode which ought to cut node power use in half, meaning much longer battery life. The SX1262 has the DCDC converter on RX only, and that does more or less, cut receive power consumption in half.

TTGO LoRa32 V2.1.6:

ESP32          LoRa (SPI)      Display (I2C)  LED
-----------    ----------      -------------  ------------------
GPIO5  SCK     SCK
GPIO27 MOSI    MOSI
GPIO19 MISO    MISO
GPIO18 SS      NSS
GPIO23         RST
GPIO26         DIO0
GPIO33         DIO1 (see #1)
GPIO32         DIO2 (see #2)
GPIO21 SDA                     SDA
GPIO22 SCL                     SCL
GPIO25                                        LED
  1. Required. Unknown if this already wired on PCB or must be manually wired .
  2. Optional (needed for FSK only) . Unknown if this already wired on PCB .

in the shematics of the board TTGO Lora32_v2.1.6 shematics is the LoRa1 to 33 and LoRa2 to 32 connected

1 Like

They have started 'migration onto SX1262 process by offering a new variant of TTGO T-Beam board at first:

New ESP32-S2 modules: ESP32-S2-MINI

Espressif’s ESP32-S2-MINI series of modules currently consists of ESP32-S2-MINI-1 and ESP32-S2-MINI-1U , which are two powerful, generic Wi-Fi MCU modules with a rich set of peripherals. They are an ideal choice for a wide variety of application scenarios relating to the Internet of Things, wearable electronics and smart home.

ESP32-S2-MINI-1 comes with a PCB antenna, whereas ESP32-S2-MINI-1U with an IPEX antenna. They both feature a 4-MB embedded SPI flash.

At the core of the ESP32-S2-MINI modules is ESP32-S2FH4 , an Xtensa® 32-bit LX7 CPU that operates at up to 240 MHz. This chip has a low-power co-processor that can be used instead of the CPU, in order to save power while performing tasks that do not require much computing power, such as the monitoring of peripherals. ESP32-S2FH4 has up to 43 GPIOs and integrates various peripherals, such as SPI, I2S, UART, I2C, LED PWM, LCD, camera interface, ADC, DAC, touch sensor and temperature sensor. ESP32-S2FH4 also includes a full-speed USB On-The-Go (OTG) interface which enables USB communication in any place, at any time.

Will go into mass production end of 2020.

Using the TTGO LoRa32 board with the LMIC library works fine with next setup:

– board Heltec WiFi LoRa 32
– LMIC library
– included demo sketch ttn-otaa
– edited some lines as below to meet the requirements of the TTGO board:

const lmic_pinmap lmic_pins = {
        .nss = 18,
        .rxtx = LMIC_UNUSED_PIN,
        .rst = 14,
        .dio = {26, 33, 32},
        };

The demo sketch sends the message “Hello, world!” once every 10 minutes (TX_INTERVAL = 600). So far so good.

Between the tranmissions I want to measure incoming analog values from a pin, say every 10 seconds, calculate the average thereafter which I want to send to TTN. Trying to code this part within the loop of the sketch does not work, I suppose this is LMIC (timing) related.

Can someone help me with a sketch which does above or similar? Or are there other libraries I can use?