Could make sense to alter this topic ‘subject’ line…
This is a new TTGO LoRa32 V2.1.6 with SX1262 radio.
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.
Yes, I was already considering that for ‘part 4’ of this topic.
Additional options and considerations are:
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?
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.
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:
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.
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
in the shematics of the board TTGO Lora32_v2.1.6 shematics is the LoRa1 to 33 and LoRa2 to 32 connected
They have started 'migration onto SX1262’ process by offering a new variant of TTGO T-Beam board at first:
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?
Excellent ressource!
I’ve purchased a v1.0 board:
http://www.lilygo.cn/prod_view.aspx?TypeId=50003&Id=1136&FId=t3:50003:3
I don’t have any problems connecting it to TTN/Cayenne. However, my v1.3 just does not work:
http://www.lilygo.cn/prod_view.aspx?TypeId=50003&Id=1253&FId=t3:50003:3
I am quite sure that I use the correct pin mapping, as provided by the manufacturer:
Besides the reset pin, the code between v1.0 and v1.3 should be identical. What do you think about that?
I’m now planning to buy a newer version of those boards. Can you recommend the V2 ones?