Big ESP32 + SX127x topic part 3

End Devices (Nodes)
242

LoRaMac-node for ESP32 available

Can be used for Heltec ESP32 LoRa products only

Essential parts of the source code are obfuscated (compiled to assembly).

“An unique license relate to Chip ID is needed, you can check your license here: Search ChipID relative License – Heltec Automation”

Great initiative but mixed feelings because of its closed character and license requirement per node. Applications using this library are limited to Heltec hardware which limits wider application
(therefore less attractive for developers). :+1: :smiley: :thinking: :roll_eyes: :disappointed: :-1:

Also see: Overview of LoRaWAN Libraries [HowTo] - #11 by bluejedi

Has anyone used it already?

243

I don’t think the ecosystem of Heltec hardware is worth to accept a vendor lock-in.

Meanwhile good old LMiC stack is close to a LORAWAN 1.0.3 certification, thanks to the great work by Terry Moore: https://github.com/mcci-catena/arduino-lmic

2 Likes
244

Correct.
Even with current developments on LMIC it would still be ‘nice’ to have LoRaMac-node implementations more widely available.

1 Like
245

I made a sketch for the TTGO-LoRa32-V2.1 (version T3_v1.6 20180606).

I am looking for people to test it. It has ABP and otaa activation. It also supports the OLED display. You can check it on: https://github.com/rwanrooy/TTGO-LoRa32-V2.1-TTN

246

ESP32-S2

Espressif recently introduced a new member of the ESP32 family: the ESP32-S2

ESP32-S2%20Architecture
ESP32-S2 datasheet is available here

Comparison with regular ESP32

(Source: https://esp32.com/viewtopic.php?t=10632)

What do we gain over ESP32?

  • Xtensa LX7
  • USB FS OTG
  • Support for larger external SPI RAM up to 128MB
  • Support for larger external SPI Flash up to 1GB
  • More GPIOs (39 gpio + 1 gpi, 22 rtcio)
  • 14/15 ch Waterproof touch sense? & Proximity sensing
  • Improved SPI (OSPI)
  • Improved ULP (RISC-V)
  • WiFi Indoor Positioning (802.11mc)?
  • V2I (802.11p?)
  • Lower cost
  • External ram access from instruction cache
  • Auto-zero ADC
  • PSRAM encryption

What do we lose?

  • Bluetooth
  • ### Dual core ###
  • RAM space (320KB vs 520KB)
  • ROM space (128KB vs 448KB)
  • UART (2 vs 3)
  • SDMMC
  • MCPWM
  • Ethernet
  • I2S (1 vs 2, no PDM)
  • RMT (4ch vs 8ch)
  • PCNT (4 vs 8)

ESP32-SOLO-1

ESP32-SOLO-1 is a new Espressif module that is based on the new ESP32-S2.

Available here:

2 Likes
247

Hi bluejedi,

yes I have used this source code and board from Heltec, but I found it a little bit complicate due to make for each board a new compilation because of the unique license. Also after some good joins during test also the OTAA fails. Why I can’t found out. ADB work with lmic fine.
Now I’m go to test deep sleep and OTAA as well.

I uses also the lmic from mcci-catena now.
I found two pin configuration for V2 of this board:

I uses:

//LMIC LoRa module pin configuration
//For Heltec Wifi LoRa 32 use:
const lmic_pinmap lmic_pins = {
    .nss = 18, 
    .rxtx = LMIC_UNUSED_PIN,
    .rst = 14,
    .dio = {/*dio0*/ 26, /*dio1*/ 35, /*dio2*/ 34}
};
and also I found:

//LMIC LoRa module pin configuration
//For Heltec Wifi LoRa 32 use:
const lmic_pinmap lmic_pins = {
    .nss = 18, 
    .rxtx = LMIC_UNUSED_PIN,
    .rst = 14,
    .dio = {/*dio0*/ 26, /*dio1*/ 34, /*dio2*/ 35}
};

only changed in dio 34 and 35. Why? For me it seems to be clear the first one. Have others other experience?

Also OTAA fails because the board misses the agreed downlink. Also in ADP downlink seems to be critical.

Perhaps I’ll make LMIC with interrupt:
https://www.thethingsnetwork.org/forum/t/big-esp32-sx127x-topic-part-1/10247/11

Hope to help other to go further with his project and this board.

1 Like
248

A real pity that their LoRaMac-node port to ESP32 is not open / not available for general use. So there still appear to be issues with it. Because not open there will be much less people that are going to test it and less people to report any issues.

Yes for Heltec WiFi LoRa 32 V2 the first you listed is correct (the second is incorrect):

const lmic_pinmap lmic_pins = {
  .nss = 18,
  .rxtx = LMIC_UNUSED_PIN,
  .rst = 14,
  .dio = {/*dio0*/ 26, /*dio1*/ 35, /*dio2*/ 34 }
};

Also note that GPIO ports used for I2C OLED display are not the standard ones for I2C:
Display-SDA = 4 (not 21, SDA=21)
Display-SCL = 15 (not 22, SCL=22)
Display-RST = 16

1 Like
249

Check out latest paxcounter version 1.8.0, it runs LMiC controled by hardware Interrupts. I found the bug in MCCI LMiC which broke this feature last week and made a Pull Request, this was merged meanwhile.

1 Like
250

Can hardware interrupts be enabled for LMIC without requiring further changes to Arduino application code?
When would enabling hardware interrupts for LMIC be useful and when not?
Is this valid for both the original LMIC-Arduino library and for the MMCI LoRaWAN LMIC library?
Is that independent of type of MCU used?

Until recently I have only seen remarks like ‘enabling interrupts for LMIC is best avoided because it can cause issues’ while you seem to promote it (use it in Paxcounter).
I understand that interrupt based is usually better than polling but if so, why hasn’t that been the norm with LMIC previously?

Can you please elaborate on that?

251

It’s pretty easy with current MCCI LMIC code, you just have to enable the function in lmic_config.h:

#define LMIC_USE_INTERRUPTS 1

The original LMIC arduino library does - as far as i see - not and did never include this function.

Using hardware interrupts instead of polling has in my opinion more advantages than disadvantages: Is frees up CPU from polling and thus allows a more “sharp” timing for the time critical opening of RX-windows. This saves power and thus is relevant for all real low power applications. While power savings maybe not significant with Class A devices, it will with Classes B / C.

Another advantage, also for Class A, might be that in busy multithreaded applications (like paxcounter) timing by hardware works better than by software, because by software will cause more jitter, and this could result to missed RX packets. That’s the reason why i decided to switch paxcounter code to use interrupts.

Only disadvantage in my opinion is, that the used GPIO pins for LORA_IRQ (= DIO0) , and LORA_DIO1 must be connected to interrupt capable pins of CPU. This might be an issue on hardware with small CPU footprint, but on a ESP32 system you have lots of suitable GPIOs, and as far as i see it works with all Heltec, TTGO, Pycom etc. development boards. So why not using it?

There was an issue, that broke the interrupt function working in MCCI LMiC on ESP32, but recently i spotted the bug in the HAL code, and made a PR for it. This was merged in MCCI LMIC master last week and since then i have some test clients up and running on interrupts, so far working smooth and i don’t see any RX packet loss any more.

1 Like
252

Next level would be to have ESP32 proprietary interrupt function, which captures the timestamp of the interrupt by hardware. This should be somehow possible with ESP32 hardware, i guess, but i did not yet find out the way how to. This would allow a further sharpening of timing, what opens up opportunity to have a high precision (< 1ms) “NTP” via LORAWAN.

253

TTGO Beam V1.0 now supported by paxcounter.
To get this running, i did register power management chip AXP202X Library by LilyGo to platformio (after asking them for permission) and added it to paxcounter.
This chip has a bunch of power management features; unfortunately we still miss a schematic for TTGO Beam V1.0 to use all functions.

1 Like
254

You need interrupts if want to sleep all the time between events (e.g. TX begin, TX complete, RX begin, RX complete, etc.). Pretty sure no-one uses LMIC this way.

Sleep aside, using interrupts might allow you to reduce your clock error compensation since there will be less jitter in determining RX begin compared to polling at both ends. Reducing compensation might mean the radio is waiting to receive for less time.

255

I got a TTGO T-Beam V1.0 and enhanced the paxcounter software to support some of the new board features:

  • GPS PPS interrupt line
  • PMU (power management unit)
  • Two Buttons

As PMU an x-powers.com AXP192 chip is used. Although this is an older model dated around 2011, is has a bunch of interesting features, look at the data sheet (unfortunately chinese only, does anyone has english version?)

In paxcounter code i added some examples for the various power interrupts - works! Now you can easyly trigger on power events, like battery connected/removed, USB plug connected/removed, battery overheated/charged etc.

The second user button is also controlled by the PMU.

256

You may try to (partially) translate it here: onlinedoctranslator

257

Did that already, but doesn’t work well with that technical datasheet.
Meanwhile i found that the datasheet to the very similary AXP202 chip is available in english, so i can use the register map from this source.

258

Recent TTGO product T-Watch belongs to a ‘wearable appliance’ category. And like majority of their products, the T-watch is also based on ESP32 SoC.
This is an option to buy the watch together with ‘GNSS+LoRa daughterboard’ which has SX1276 RF IC (been wrapped inside S76G SoC) and LoRaWAN compliant firmware built-in.
The RF daughterboard performs quite well, provided that external SMA antenna is in use.

Below is an illustration of how SoftRF firmware is driving the watch to transmit and receive packets with LoRa modulation (FANET protocol):

3D design of ‘cargo bay’ for the T-Watch is available on my Thingiverse page.
It is designed to fit for two SMA <=> uFL/IPEX adapters.

259

Is there a software for the S76G, which replicates the SX1276 signals on GPIO pins? This way LMIC stack could be run on the watch.

264

I have a TTGO LORA32 board that I am going to use as a soil moisture sensor, however the results of esp_deep_sleep_start() is underwhelming. I have the consumption down to ~15mA when sleeping, but I was hoping/expecting to get down to double-digit uA.

I’ve noticed that the moisture sensor continues to draw current when the ESP32 is in sleep (~5mA), so it looks like there is more to be done with the config.

My current setup is:

esp_sleep_pd_config(ESP_PD_DOMAIN_RTC_SLOW_MEM, ESP_PD_OPTION_OFF);
esp_sleep_pd_config(ESP_PD_DOMAIN_RTC_FAST_MEM, ESP_PD_OPTION_OFF);
esp_sleep_pd_config(ESP_PD_DOMAIN_RTC_PERIPH, ESP_PD_OPTION_OFF);

and rtc_gpio_isolate doesn’t compile.

Does anyone have a working config or suggestions on how I can better reduce deep sleep power consumption?

TIA.

265

Long discussion about similar problems on the ESP32 support forums;

A bare bones ESP32 board, with a carefully selected regulator, may well get down to 30uA or so in deep sleep, but very often the boards are not designed for that.

Most ESP32 boards have components that may consume current even when the ESP32 device itself is in deep sleep; USB-Serial devices, displays, charger ICs.