Hi brother. I’m currently using the same type of board as you. But unfortunately i can’t find this board on the list of LoRa development board. Mind to share which dev board you are using? Thanks in advance.
Try looking at the example I made few years back on LMIC with my SAMD21 board. Sleep was included. Many of my end clients uses them in the field with the MCCI version subsequently.
vs
Making it work for what is effectively the Adafruit Feather M0 only would generate lots and lots of “why doesn’t the sleep work on X board”. The ESP32 TTGO range are particularly problematic.
The ESP32 boards has to be treated differently as when it goes to sleep and wake up, it is actually a reset event. In such event, some of the LMIC specific variables need to the stored on the RTC RAM section in order for it to be non-volatile. Your code also actually only run in the setup() section and never went into the loop() in your typical Arduino code. This probably leave you needing to write the code slightly differently.
Hi @rocketscream,
@alihi asked for which board configuration (boardid) was used in LMIC-node.
Your responses do not answer his question and in fact generates noise into the conversation.
Like @descartes already mentioned we are aware about different sleep requirements for different MCU family types and yes the ESP32 is notoriously limited/crippled in this area because sleep/wakeup actually causes a reset of the MCU where program state is not mainted.
Discussions about deep-sleep differences and their requirments for different types of MCU families are off-topic here because this topic is dedicated to LMIC-node (which currently does not support deep sleep for reasons previously mentioned).
Please be clear about EXACTLY WHICH BOARD you are using.
This I know, hence my comment - if you search the forum you’ll see plenty of discussions about how hard it is to sleep an ESP32 board.
Love your MiniUltra - perhaps you could help us all out with a version that has space for an RFM95? Which LMIC-node could support for those getting started - and the sleep add-on would be very simple as you’ve already written the library.
And as you were “forced” to design an ESP32 board, perhaps finish it off with a sleep library and space for the RFM95 - I’m happy to help with the linking in to LMIC - there’s no explicit support for sleep but the API is there.
Firstly, great repo, love the detail in documentation and everything is very impressive. Thanks for all the hard work. However, I have an issue.
I have a TTGO-LoRa32-V2.1-T3_V1.6 board and I uncommented “ttgo_lora32_v21” in the platform.ini file. After build and then uploading I seem to be stuck in a boot loop with the following output on the serial:
rst:0x8 (TG1WDT_SYS_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 188777542, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0030,len:1184
load:0x40078000,len:12784
load:0x40080400,len:3032
entry 0x400805e4
ets Jun 8 2016 00:22:57
I can confirm the board is a TTGO-LoRa32-V2.1-T3_V1.6 by comparing to the linked repo’s image.
Hi @MrBlueSea,
Thanks! 
I have not had the time to look into the issue yet but it appears to be caused by v4.3.0 of the Espressif 32 platform (ESP32 Arduino Core). Version 4.2.0 just works. See below for a workaround:
Workaround:
1 Like
I tried this and got the following issue when trying to build
Building in release mode
Compiling .pio\build\ttgo_lora32_v21\src\LMIC-node.cpp.o
Compiling .pio\build\ttgo_lora32_v21\lib128\SPI\SPI.cpp.o
In file included from C:/Users/MrBlueSea/.platformio/packages/framework-arduinoespressif32@3.20002.220503/libraries/SPI/src/SPI.cpp:22:
C:/Users/MrBlueSea/.platformio/packages/framework-arduinoespressif32@3.20002.220503/libraries/SPI/src/SPI.h:25:10: fatal error: pins_arduino.h: No such file or directory
My mistake, it seemed espressif32@4.2.0 had not been unpacked correctly, I can confirm that this workaround does indeed work. Thanks 
1 Like
Espressif32 platform v4.3.0 has introduced a bootloop issue for TTGO LoRa32 V2.1.6 boards
The issue causes a (re)boot loop when trying to run LMIC-node on a TTGO LoRa32 V2.1.6 board.
As workaround use Espressif 32 platform v4.2.0 for this board instead.
More details can be found here:
Unfortunately the issue still persists in Espressif32 platform v5.0.0.
1 Like
LMIC-node is still a great example, thanks for the great work. My LoRaWAN node with the board “Heltec WiFi Lora 32 (V2)” ran after 5 minutes including display.
If I may wish something:
- Hints, how “deep sleep” can be added
- Support of the board “Heltec WiFi Lora 32 (V3)”.
1 Like
Thanks.
Deep sleep
See previous remark about deep sleep support.
How to implement deep sleep is MCU and board dependent and is also impacted by how the LMIC LoRaWAN library currently still does not provide any generic support for (deep) sleep scenarios with hooks for reliably saving and restoring LMIC state.
Searching the forum for LMIC sleep or LMIC sleep ESP32 may provide you some hints (but not as simple and worked-out as LMIC-node).
SX1262 tranceiver support
Heltec WiFi LoRa 32 V3 uses the SX1262 LoRa tranceiver instead of the SX1276. Unfortunately the SX1262 is currently not supported by the LMIC LoRaWAN library (and unclear if it ever will).
So for this (and any other SX1262 based) board you will have to look for other solutions / other LoRaWAN libraries.
2 Likes
Any one knows for support for heltec_wifi_lora_32_V3?. HOw to get this work?
If it’s not on the list of supported boards, then it’s try it and see.
Have you tried it?
If you have and have issues, then please open a new topic so it can be discussed / debugged.
This example is awesome. I have one question. With this example, can a specify the device class and change a device using this example to Class C for example, to always listen for downlink?
Thanks! LMIC-node was not designed with class C in mind and is bound to the possibilities and limitations of the LMIC library. I haven’t looked at newer LMIC library releases lately so I’m not sure if that currently supports class C. However, if it does, LMIC-node will probably need some changes to support the different device classes.