manuelbl / ttn-esp32 Goto Github PK

Hi,

Is this library compatible with the ESP32-S2?

I see no reason for it not to be, I have it compiling, however I am getting stuck at line 222 of TheThingsNetwork.cpp:
xQueueReceive(lmicEventQueue, &event, portMAX_DELAY);

I have managed to have 3 packets send through to the TTN but not sure what was done differently. The code wouldn't work with these lines from radio.c:

803: ASSERT((readReg(RegOpMode) & OPMODE_LORA) != 0);
925: ASSERT((readReg(RegOpMode) & OPMODE_LORA) != 0);
1162: ASSERT( i != 0 );
1372: ASSERT(0);

After commenting those lines out the code runs.

The output I am getting is this:
--- WARNING: GDB cannot open serial ports accessed as COMx
--- Using \.\COM4 instead...
--- idf_monitor on \.\COM4 115200 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
ESP-ROM:esp32s2-rc4-20191025
Build:Oct 25 2019
rst:0x1 (POWERON),boot:0x8 (SPI_FAST_FLASH_BOOT)
SPIWP:0xee
mode:DIO, clock div:2
load:0x3ffe6100,len:0x172c
load:0x4004c000,len:0xa04
load:0x40050000,len:0x2b34
SHA-256 comparison failed:
Calculated: bb00b9c49a5696d12d64acd52be127a64e4068d644bb285e0ffebddc022cefd2
Expected: dcf2571cd019a6b73d9f7272f52a52787ec3e7936b0b7cb0e18511e1e06c4c07
Attempting to boot anyway...
entry 0x4004c1f4
I (42) boot: ESP-IDF v4.4-dev-1594-g1d7068e4b 2nd stage bootloader
I (42) boot: compile time 21:44:14
I (42) boot: chip revision: 0
I (46) boot.esp32s2: SPI Speed : 40MHz
I (51) boot.esp32s2: SPI Mode : DIO
I (55) boot.esp32s2: SPI Flash Size : 4MB
I (60) boot: Enabling RNG early entropy source...
I (66) boot: Partition Table:
I (69) boot: ## Label Usage Type ST Offset Length
I (77) boot: 0 nvs WiFi data 01 02 00009000 00006000
I (84) boot: 1 phy_init RF data 01 01 0000f000 00001000
I (91) boot: 2 factory factory app 00 00 00010000 00100000
I (99) boot: End of partition table
I (103) esp_image: segment 0: paddr=00010020 vaddr=3f000020 size=0a4e0h ( 42208) map
I (123) esp_image: segment 1: paddr=0001a508 vaddr=3ffbe4a0 size=01e6ch ( 7788) load
I (126) esp_image: segment 2: paddr=0001c37c vaddr=40022000 size=03c9ch ( 15516) load
I (136) esp_image: segment 3: paddr=00020020 vaddr=40080020 size=1d370h (119664) map
I (171) esp_image: segment 4: paddr=0003d398 vaddr=40025c9c size=087fch ( 34812) load
I (183) esp_image: segment 5: paddr=00045b9c vaddr=50000000 size=00010h ( 16) load
I (189) boot: Loaded app from partition at offset 0x10000
I (189) boot: Disabling RNG early entropy source...
I (203) cache����~f^,W��
����� : size 8KB, 4Ways, cache line size 32Byte
I (203) cpu_start: Pro cpu up.
I (215) cpu_start: Pro cpu start user code
I (215) cpu_start: cpu freq: 160000000
I (215) cpu_start: Application information:
I (219) cpu_start: Project name: hello_world
I (224) cpu_start: App version: 3e38aeb
I (229) cpu_start: Compile time: Jun 26 2021 15:01:18
I (235) cpu_start: ELF file SHA256: 7ad958c9a84b0a4e...
I (241) cpu_start: ESP-IDF: v4.4-dev-1594-g1d7068e4b
I (248) heap_init: Initializing. RAM available for dynamic allocation:
I (255) heap_init: At 3FF9E000 len 00002000 (8 KiB): RTCRAM
I (261) heap_init: At 3FFC0F28 len 0003B0D8 (236 KiB): DRAM
I (268) heap_init: At 3FFFC000 len 00003A10 (14 KiB): DRAM
I (274) spi_flash: detected chip: generic
I (279) spi_flash: flash io: dio
I (283) cpu_start: Starting scheduler on PRO CPU.
I (296) ttn_hal: IO initialized
I (296) ttn_hal: SPI initialized
I (306) ttn_hal: Timer initialized
I (326) ttn_prov: Dev and app EUI and app key saved in NVS storage
Joining...
I (336) ttn: event EV_JOINING
I (336) ttn: event EV_TXSTART
I (5676) ttn: event EV_RXSTART
I (6666) ttn: event EV_RXSTART

Any thoughts on what could be happening here?

I have had results similar to Joining infinite loop #37, it did loop at some stage, however since starting a fresh attempt it does not loop.

Cheers

I've been stuck at this point for a long time. Any idea why this might be happening? I am using a ESP32S2 with RFM95

I (206) cpu_start: Project name: hello_world
I (211) cpu_start: App version: 1
I (216) cpu_start: Compile time: Mar 23 2022 10:09:12
I (222) cpu_start: ELF file SHA256: aaced9e8575a2a3f...
I (228) cpu_start: ESP-IDF: v4.4-dirty
I (233) heap_init: Initializing. RAM available for dynamic allocation:
I (240) heap_init: At 3FF9E000 len 00002000 (8 KiB): RTCRAM
I (246) heap_init: At 3FFC1C60 len 0003A3A0 (232 KiB): DRAM
I (253) heap_init: At 3FFFC000 len 00003A10 (14 KiB): DRAM
I (259) spi_flash: detected chip: generic
I (264) spi_flash: flash io: dio
I (268) cpu_start: Starting scheduler on PRO CPU.
I (280) ttn_prov: DevEUI, AppEUI/JoinEUI and AppKey saved in NVS storage
Joining...
I (280) gpio: GPIO[20]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
I (290) gpio: GPIO[2]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
I (300) gpio: GPIO[34]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
I (310) gpio: GPIO[37]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
I (320) ttn_hal: IO initialized
I (320) ttn_hal: SPI initialized
I (330) ttn_hal: Timer initialized
E (340) ttn_hal: LMIC failed and stopped: ../components/ttn-esp32/src/lmic/radio.c:1206

Thank you very much for your great work. An esp-idf library for lorawan is really appreciated.

I got following error when trying to compile latest master branch version:

Executing task: platformio run 
Processing ttgo-lora32-v1 (platform: espressif32; board: ttgo-lora32-v1; framework: espidf)
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/espressif32/ttgo-lora32-v1.html
PLATFORM: Espressif 32 (3.3.1) > TTGO LoRa32-OLED V1
HARDWARE: ESP32 240MHz, 320KB RAM, 4MB Flash
DEBUG: Current (esp-prog) External (esp-prog, iot-bus-jtag, jlink, minimodule, olimex-arm-usb-ocd, olimex-arm-usb-ocd-h, olimex-arm-usb-tiny-h, olimex-jtag-tiny, tumpa)
PACKAGES: 
 - framework-espidf 3.40300.0 (4.3.0) 
 - tool-cmake 3.16.4 
 - tool-esptoolpy 1.30100.210531 (3.1.0) 
 - tool-ninja 1.7.1 
 - toolchain-esp32ulp 1.22851.191205 (2.28.51) 
 - toolchain-xtensa32 2.80400.210211 (8.4.0)
Warning! Starting with ESP-IDF v4.0, new project structure is required: 
https://docs.platformio.org/en/latest/frameworks/espidf.html#project-structure
Reading CMake configuration...
LDF: Library Dependency Finder -> http://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 1 compatible libraries
Scanning dependencies...
Dependency Graph
|-- <ttn-esp32> 4.0.0-pre+sha.8fa345a
Building in release mode
Linking .pio/build/ttgo-lora32-v1/firmware.elf
/home/vrees/.platformio/packages/toolchain-xtensa32/bin/../lib/gcc/xtensa-esp32-elf/8.4.0/../../../../xtensa-esp32-elf/bin/ld: .pio/build/ttgo-lora32-v1/lib470/libttn-esp32.a(TheThingsNetwork.o):(.literal._ZN16TheThingsNetwork13getRFSettingsE13TTNRxTxWindow+0x0): undefined reference to `ttn_get_rf_settings'
/home/vrees/.platformio/packages/toolchain-xtensa32/bin/../lib/gcc/xtensa-esp32-elf/8.4.0/../../../../xtensa-esp32-elf/bin/ld: .pio/build/ttgo-lora32-v1/lib470/libttn-esp32.a(TheThingsNetwork.o): in function `TheThingsNetwork::getRFSettings(TTNRxTxWindow)':
/home/vrees/work/git-repos/wasserstand-harry-b/.pio/libdeps/ttgo-lora32-v1/ttn-esp32/src/TheThingsNetwork.cpp:17: undefined reference to `ttn_get_rf_settings'
collect2: error: ld returned 1 exit status
*** [.pio/build/ttgo-lora32-v1/firmware.elf] Error 1
============================================================================== [FAILED] Took 7.82 seconds ==============================================================================
Der Terminalprozess "platformio 'run'" wurde mit folgendem Exitcode beendet: 1.

I checked, that TheThingsNetwork.h also includes ttn.h ant that line 670 has the method defined:
ttn_rf_settings_t ttn_get_rf_settings(ttn_rx_tx_window_t window);

So normally it should compile. What is wrong?

platformio.ini:

[env:ttgo-lora32-v1]
platform = espressif32
board = ttgo-lora32-v1
framework = espidf

lib_deps =
  https://github.com/manuelbl/ttn-esp32.git
  
monitor_speed = 115200
monitor_port = /dev/ttyUSB0
upload_port = /dev/ttyUSB0

debug_tool = esp-prog
debug_init_break = tbreak setup

build_flags =
    -Wno-expansion-to-defined
    -D DISABLE_PING
    -D DISABLE_BEACONS
    -D LMIC_DEBUG_LEVEL=0
    -D ARDUINO_LMIC_PROJECT_CONFIG_H_SUPPRESS
    -D CFG_sx1276_radio=1
    -D CFG_eu868=1
    -D CONFIG_TTN_LORA_FREQ_EU_868=y
    -D CONFIG_TTN_RADIO_SX1276_77_78_79=y
    -D CONFIG_TTN_PROVISION_UART_DEFAULT=y
    -D CONFIG_TTN_PROVISION_UART_NUM=0
    -D CONFIG_TTN_TIMER_1_GROUP_0=y
    -D CONFIG_TTN_SPI_FREQ=10000000
    -D CONFIG_TTN_BG_TASK_PRIO=10  

I got the same problem as in the following closed issue:
#13

"'ESP_INTR_FLAG_IRAM' was not declared in this scope [64,11]"
"'gpio_install_isr_service' was not declared in this scope [64,36]"

I am using PlatformIO so I don't know how to use another version of ESP-IDF.

My system:
macOS 10.15.4
VSCode 1.45.1
PlatformIO Core 4.3.3 - Home 3.2.2
ESP-IDF 3.40000.200303

I am relatively new to PlatformIO, so I hope I didn't do anything wrong. I just followed your Get-Started Guide (https://github.com/manuelbl/ttn-esp32/wiki/Get-Started) and did anything you mentioned.

Hi,
many thanks for this library.
I am testing with an ESP32 Pico Dev Kit and Hope RFM95W using the Heltec pin config.

I have to report the same observation. Only mode=1 works.

Changing hal_esp32.c to .mode=0 results in:
E (1128) ttn_hal: /home/hlk/esp/hello_world/components/ttn-esp32/src/hal_esp32.c:464

From what I can tell, the library does not allow the end user to configure the supported LoRaWAN channels. This is a problem for us in the U.S. at least, where we have 64 standard LoRaWAN channels, but The Things Network only operates on 8 channels (and most budget consumer gateways only support up to 8 channels anyway) as it leads to an automatic uplink packet loss of 75% (random channel uplink from a pool of 64 channels against a max supported 8 channels on the gateway).

On a side note, this library also works with Chirpstack and other LoRaWAN infrastructure as it is built against LMIC, which might be nice to reference in the README/project notes that it isn't exclusive to TTN.

P.S. Thanks @manuelbl for this library, I appreciate the time you've spent to port LMIC to the esp-idf

I'm using a regular ESP32 along with this RFM9x module.

https://learn.adafruit.com/adafruit-rfm69hcw-and-rfm96-rfm95-rfm98-lora-packet-padio-breakouts/pinouts#spi-logic-pins-2-6

I've hooked it up such that the pins are connected to the following pins on the module:

#define TTN_SPI_HOST      HSPI_HOST
#define TTN_SPI_DMA_CHAN  1
#define TTN_PIN_SPI_SCLK  [SCK]
#define TTN_PIN_SPI_MOSI  [MOSI]
#define TTN_PIN_SPI_MISO  [MISO]
#define TTN_PIN_NSS       [CS]
#define TTN_PIN_RXTX      TTN_NOT_CONNECTED
#define TTN_PIN_RST       [RST]
#define TTN_PIN_DIO0      [G0]
#define TTN_PIN_DIO1      [G1]

However, it fails at radio.c:739. I instrumented the code and found that the RegVersion returned is 0x9 (0b1001) instead of the expected 0x12 (0b10010). Given the similar-but-shifted binary representations, I suspect a timing/sync problem on the bus.

Any ideas?

Hi.

This library does not compile under esp-idf 5.0. I have cloned the latest source code. I try to compile the monitoring example. And I have got this error message:

ttn-esp32/src/hal/hal_esp32.c:22:10: fatal error: esp_timer.h: No such file or directory
 #include "esp_timer.h"
          ^~~~~~~~~~~~~

Does this library work under esp-idf 5.0 or I need to use previous esp-idf? Or How can I compile this library properly?

Thanks for your help

I've followed the quick start guide and once my ESP32 TTGO board has been flashed, it sends only one message and then stops.

On the ttn console looks like the message is in "retry":

And on the console it never prints "Message sent":

I (328) cpu_start: Starting scheduler on PRO CPU.
I (0) cpu_start: Starting scheduler on APP CPU.
I (421) ttn_hal: IO initialized
I (421) ttn_hal: SPI initialized
I (421) ttn_hal: Timer initialized
I (451) ttn_prov: Dev and app EUI and app key saved in NVS storage
I (461) ttn_prov: Dev and app EUI and app key saved in NVS storage
Joining...
I (461) ttn: event EV_JOINING
I (6731) ttn: event EV_TXSTART
I (11761) ttn: event EV_RXSTART
I (11871) spi_master: Allocate RX buffer for DMA
I (11871) ttn: event EV_JOINED
Joined.
Sending message...
I (11871) ttn: event EV_TXSTART
I (12911) ttn: event EV_RXSTART

(no "Message Sent" print here for more than 2 minutes).

Would you know what is related to?

Thank you

When an ESP32 goes into deep sleep, the main memory is cleared. The programs starts from the beginning when the device wakes up.

Using ttn-esp32, at startup a join procedure is done. Say I have a device that only wakes up very seldomly. This device should only join once (in the factory/during initial programming), or periodically (±once a month). Therefore the state of the LoRaWAN session should be kept during sleep, and updated when a transmission is made.

Possible solution:

1. After a successful join save the session (AppSessionKey, NetworkSessionKey, UplinkFrameCounter, DownlinkFrameCounter) in RTC memory (or in Flash).
2. At startup check if there is a valid session stored in RTC memory. If there is a valid session, do not do the provisioning/joining and use the existing session.
3. If we do not have a session stored, do a join and save the session.
4. When sending a message, update the frame counters of this session.
5. When receiving a message, update the frame counters of this session.

Nr 4 and 5 should already be done by LMIC, but it is in volatile memory. If we can move the variables that are use by LMIC for the session keys and frame counters to non-volatile memory it will already solve most of this. Then we just need a way to query the current session to see if we need to join or not. LMIC already has a way to do this too - it only joins when the first message is sent, and never joins when a session is hardcoded (ABP mode).

Hi,

I have a ESP32 Heltec V2 Lora board. I use this ttn-esp32 firmware pack. I try to send a sensor data to the chirpstack Lorawan system, but I have a problem.

The Joining to the chirpstack system is OK. I send 2 byte data. After that I wait 30 second and I try to send another data, but It is not successfull. It is stopped the firmware. After the debuging of the firmware, I have realized, the freezing is in the ttn.c/ttn_transmit_message function:

while (true)
 {
        ttn_lmic_event_t result;
        xQueueReceive(lmic_event_queue, (void*)&result, portMAX_DELAY);
       ...
}

What is the problem?

Thank you very much for your help

I (0) cpu_start: App cpu up.
I (197) heap_init: Initializing. RAM available for dynamic allocation:
I (204) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM
I (210) heap_init: At 3FFB3228 len 0002CDD8 (179 KiB): DRAM
I (216) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM
I (222) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (229) heap_init: At 4008ABB4 len 0001544C (85 KiB): IRAM
I (235) cpu_start: Pro cpu start user code
I (29) cpu_start: Starting scheduler on PRO CPU.
I (0) cpu_start: Starting scheduler on APP CPU.
I (111) ttn_hal: IO initialized
I (111) ttn_hal: SPI initialized
I (111) ttn_hal: Timer initialized
I (131) ttn_prov: Dev and app EUI and app key saved in NVS storage
I (131) ttn_prov: Dev and app EUI and app key saved in NVS storage
Joining...
I (131) ttn: event EV_JOINING
I (141) ttn: event EV_TXSTART
I (7491) ttn: event EV_TXSTART
I (22241) ttn: event EV_TXSTART
I (29631) ttn: event EV_TXSTART
I (38821) ttn: event EV_TXSTART
I (45881) ttn: event EV_TXSTART
I (56601) ttn: event EV_TXSTART
I (63571) ttn: event EV_TXSTART
I (85311) ttn: event EV_TXSTART
I (92591) ttn: event EV_TXSTART
I (99701) ttn: event EV_TXSTART
I (106511) ttn: event EV_TXSTART
I (125831) ttn: event EV_TXSTART
I (132461) ttn: event EV_TXSTART
I (150531) ttn: event EV_TXSTART
I (157131) ttn: event EV_TXSTART
I (163221) ttn: event EV_JOIN_FAILED
I (173881) ttn: event EV_TXSTART
I (180911) ttn: event EV_TXSTART
I (196591) ttn: event EV_TXSTART
I (203091) ttn: event EV_TXSTART
I (216811) ttn: event EV_TXSTART
I (223821) ttn: event EV_TXSTART
I (239891) ttn: event EV_TXSTART
I (246541) ttn: event EV_TXSTART
I (254371) ttn: event EV_TXSTART
I (261211) ttn: event EV_TXSTART
I (274851) ttn: event EV_TXSTART
I (282221) ttn: event EV_TXSTART

When using platformio: got a linker error related to main.cpp
I changed main.cpp to have extern "C" directives
extern "C" void app_main() {}
The linker error disappeared after this change.
I suggest main.cpp is updated or the wiki info on how to use platformio is updated.

Need to add IRAM_ATTR to hal_ticks() to prevent it executing from flash region. That function is called by dioIrqHandler handler.
Otherwise the application will crash in case of OTA updates or other things that disables the flash.

Hi, thank you for this great library.
I have a problem.
I am using two TTGO v1 boards without the display. They can communicate with each other i tried with the arduino-LoRa library.
I configured the parameters and uploaded the send_recv example but they are stuck at the Joining loop.

Joining...
I (402) ttn: event EV_JOINING
I (8292) ttn: event EV_TXSTART
I (13342) ttn: event EV_RXSTART
I (14342) ttn: event EV_RXSTART
I (14582) ttn: event EV_JOIN_TXCOMPLETE

I tried to send and receive with one board (Arduino) and the second with the send_recv example (IDF) but no message received.

I am using IDF 4.0.
Do i need a real connection to the TTN network ?
Can i send messages between boards without connecting to the TTN network ?

Thank you for taking me into consideration.

For ESP-IDF I had to perform following changes for hello_world example to compile:

• add #include <freertos/semphr.h> to hal_esp32.h
• add #include "driver/gpio.h" to main.cpp

Thanks for awesome library!

I have several different LoRaWAN stacks running on various devices, such as the ST Micro LRWAN stack, whatever's in the Microchip RN2903, and the LMIC stack. The LMIC stack is running on a Heltec V1 board configured for the US915 band plan. It's talking to the The Things Network server, but the server is sending a downlink message on every uplink, unlike the other stacks. Now I suspect this is a LMIC thing, but I'm starting here, wondering if this has been seen before. It occurs almost every time, although there's the occasional packet that doesn't.

Any ideas what I'm looking at here? As I say the data is showing up decoded in the TTN console, so the DevEUI, App EUI and App Key are all correct.

Bad:

Sending message...
75061095: engineUpdate, opmode=0x808
I (1201387) ttn: event EV_TXSTART
75061120: engineUpdate, opmode=0x888
75061234: TXMODE, freq=904300000, len=19, SF=7, BW=125, CR=4/5, IH=0
75126858: setupRx1 txrxFlags 0x21 --> 01
start single rx: now-rxtime: 6
75126992: RXMODE_SINGLE, freq=924500000, SF=7, BW=500, CR=4/5, IH=0
I (1202447) spi_master: Allocate RX buffer for DMA
75127898: process options (olen=0xa)
75127907: LinkAdrReq: p1:40 chmap:0002 chpage:70 uprt:01 ans:87
75128076: LinkAdrReq: p1:35 chmap:ff00 chpage:00 uprt:01 ans:87
75128429: ??ack error ack=1 txCnt=0
75128629: decodeFrame txrxFlags 0x1 --> 21
75128868: Received downlink, window=RX1, port=-1, ack=1, txrxFlags=0x21
I (1202477) ttn: event EV_TXCOMPLETE
75129530: engineUpdate, opmode=0x800
Message sent.

Good:

Sending message...
77004220: engineUpdate, opmode=0x808
I (1232477) ttn: event EV_TXSTART
77004246: engineUpdate, opmode=0x888
77004359: TXMODE, freq=905100000, len=19, SF=7, BW=125, CR=4/5, IH=0
77069983: setupRx1 txrxFlags 0x21 --> 01
start single rx: now-rxtime: 6
77070117: RXMODE_SINGLE, freq=926900000, SF=7, BW=500, CR=4/5, IH=0
rxtimeout: entry: 77070199 rxtime: 77070107 entry-rxtime: 92 now-entry: 7 rxtime-txend: 62524
77133227: setupRx2 txrxFlags 0x1 --> 02
start single rx: now-rxtime: 6
77133361: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
rxtimeout: entry: 77135924 rxtime: 77133351 entry-rxtime: 2573 now-entry: 6 rxtime-txend: 125768
77135949: processRx2DnData txrxFlags 0x2 --> 00
77183025: processDnData txrxFlags 00 --> 20
I (1235337) ttn: event EV_TXCOMPLETE
77183039: engineUpdate, opmode=0x800
Message sent.

• Increase version numbers
• Update documentation
• Release notes

Would you mind adding the TTGO T-Beam info to the Boards and Pins page of the wiki?

GitHub page with image, etc: https://github.com/LilyGO/TTGO-T-Beam

It may be worth noting on the wiki that the NEO-6M that purports to be on the board is usually counterfeit, and is actually a Hangzhou ZhongKe Microelectronics AT6558 part (datasheet: AT6558 BDS/GNSS Full Constellation SOC Chip Data Sheet
www.icofchina.com/d/file/xiazai/2016.../b1be6f481cdf9d773b963ab30a2d11d8.pdf), so the ublox UBX mode isn't supported.

Here's the pin list:

#define TTN_SPI_HOST      HSPI_HOST
#define TTN_SPI_DMA_CHAN  1
#define TTN_PIN_SPI_SCLK  5
#define TTN_PIN_SPI_MOSI  27
#define TTN_PIN_SPI_MISO  19
#define TTN_PIN_NSS       18
#define TTN_PIN_RXTX      TTN_NOT_CONNECTED
#define TTN_PIN_RST       23
#define TTN_PIN_DIO0      26
#define TTN_PIN_DIO1      33

It may be worthwhile noting the above pin list is for the V6 boards. Looking at the V7 board on the website, it appears that DIO1 and DIO2 may not be supported. I don't have a V7 board to test this on.

Uses standard 40MHz system clock.

I use the ublox UBX mode in a couple products, and replaced the NEO-6M with a NEO-M8Q. I have some example code that pushes the GPS position and ESP-32 chip temperature to The Things Network. I'm fine with sharing it, but as it parses the UBX output and not NMEA, it won't be useful to anyone who doesn't replace the NEO-6M with an authentic ublox part.

Hi,
first of all: thank you for providing this library, it seems to be the most comprehensively documented and up-to-date LMIC library for ESP32.

While porting it to C for use in my projects, I've found a mismatch between documentation an implementation:

The in-code documentation of the function join(const char *devEui, const char *appEui, const char *appKey) explicitly states that the keys are not written into the NVS. However, this function calls TTNProvisioning::decodeKeys() which in turn calls TTNProvisioning::decode(). There, TTNProvisioning::saveKeys() is invoked, writing the keys to NVS. This also leads to the keys being written twice to NVS when calling TheThingsNetwork::provision().

Fixing this issue involves removing the call to TTNProvisioning::saveKeys() in TTNProvisioning::decodeKeys() and adapting the TTNProvisioning::processLine() function, which seems to expect that the decoding functions are automatically saving the keys.

Navigating menuconfig was not possible inside platformio. None of the keys (up, down arrow etc) worked. However ESC worked.

By running pio run -t menuconfig instead in a cmd window outside platformio the navigation keys worked.
(Windows 10 OS)

Hi,
Is it possible to have ABP support?
Probably it is possible to write an ABP client example using lmic low level directive, like LMIC_setSession.
I tried to do it with no success, but probably you could have success.
Can you help me? Using ABP can solve the other issue of deep sleep session.
Thank you
Nino

Greetings, i've been working on a program that is responsible for sending data frames that I get from a BLE scan to TTN. The program works great, so I implemented that the program can receive downlinks to change the operation mode of the program. When the payload type of these downlinks come in bytes I can get it just fine. However, if I change the payload type to JSON, it seems to obtain the message on the port that I assigned but the message is empty (length = 0 bytes). Do you know what may be causing this? Or is it not implemented yet?

Thanks in advance.

Hi,
just revamping my Heltec-based sensors that were up and running under TTN v2. Moving to TTN v3 I have a registered gw but devices are unable to ttn.join.

Any hints/direction on documentation or similar problems?

I register device with joinEUI as all 0x00 as stated, devEUI and AppKey are ok.

I use this library under PlatformIO/VSCode.

Thank you in advance
Mauro

Hello, can you add region CN470 band code to the source code?

The ESP32 has a unique hardware wifi MAC address. It would be useful to use this MAC as the basis for a self-generated Dev-EUI. We are doing a similar thing with Raspberry Pi base LoRaWAN gateway - take the ethernet MAC, split it in half, and add FFFF or FFFE in the middle. The result is a valid self-assigned EUI.

My request is two-fold:

1. Make is possible to use the MAC-based EUI as default, so that the same App EUI and App Key can be programmed to all devices.
2. Add the ability to read out the device MAC address via AT commands. This can be used to make a spreadsheet of MAC, Dev EUI, App EUI, App Key values. The MAC could also be used to generate a MAC-based EUI that is then registered on TTN.

Greetings, i've been trying to use ur library for quite some time but i keep getting stuck at a joining infinite loop.
Sometimes it connects once and starts sending msgs but they either usually get rejected by TTN (v2) or they never reach their platform at all.
I've checked all the keys and reinstalled the component countless times but it doesnt help at all.
The board i'm currently working with is heltec's wireless stick lite.
Any help about my issue or advice would be appreciated.
Thanks.

Hi,
I have been testing my device under different fail conditions such, in this case I was testing what happens with an ACK is not received on a confirmed packet.

What occurred was that the packet of 9 bytes was sent 7 times starting at SF 10 and finishing at SF12.

The SF increase of 11 and 12 which is not allowable on AU915 (or US915 I believe).

On a similar note the 11 byte limit (or sub 400ms time-on-air) on SF10 is not taken into consideration either.

Environment
I am using the latest version of this library:
https://github.com/manuelbl/ttn-esp32
I am using ESP-IDF framework in Visual Studio Code
The region is AU915 for this issue (but I work with 868 and US915 as well)
We are using Loriot as an LNS and SX1276

What's the best to to prevent that SF exceeding it's SF10 limit?

This would need to be applied for all reasons that the SF is changed, such as ADR, linkcheck, packet confirmation.

Cheers,
Dylan

Note comments from here:
mcci-catena/arduino-lmic#929

I am very new to this: is there anything I should be aware of if I want to use your libraries in PlatformIO?

I've started testing ADR and I can see the MAC commands from the network server changing the TXPower, however the TXPower appears to stay at the maximum setting.

Am I able to print out MAC downlinks to see what's coming in?

Cheers,
Dylan

Hi,
I am using TTGO Lora OLED v1 board and tried your hello_world.cpp example.
I configured my SPI pins as below.

// Pins and other resources
#define TTN_SPI_HOST      VSPI_HOST //SPI3_HOST
#define TTN_SPI_DMA_CHAN  SPI_DMA_DISABLED
#define TTN_PIN_SPI_SCLK  5
#define TTN_PIN_SPI_MOSI  27
#define TTN_PIN_SPI_MISO  19
#define TTN_PIN_NSS       18
#define TTN_PIN_RXTX      TTN_NOT_CONNECTED
#define TTN_PIN_RST       14
#define TTN_PIN_DIO0      26
#define TTN_PIN_DIO1      35

These are the logs

␛[0;32mI (887) ttn_hal: SPI initialized␛[0m
␛[0;32mI (897) ttn_hal: Timer initialized␛[0m
␛[0;32mI (937) ttn: event EV_JOINING␛[0m
␛[0;32mI (8887) ttn: event EV_TXSTART␛[0m
␛[0;32mI (8887) ttn: event EV_RXSTART␛[0m
␛[0;31mE (8887) ttn_hal: LMIC failed and stopped: components\ttn-esp32\src\lmic\radio.c:1067

I tested the board before with this tutorial. What am I missing?
Thanks in advance!

There is no option "The Things Network" in esp.idf menuconfig as it should be.
See the Get Started text: "In the menu, select Component config ---> and then select The Things Network ---> (at the very bottom)."

And this is the menu in Component config:

Greetings, i've been working on an program that mounts an WIFI AP for a period of time and then it reads some sensors to finally send the information to TTN.
I've been getting the following error once the device tries to join ttn:
ttn_hal: LMIC failed and stopped: ../programs/weatherStation/radio.c:1166
Is there any special consideration that i gotta have while trying to use the esp32's WiFi and the sx1276?
Thanks in advance.

Hi,

I have been attempting to use this function:
bit_t os_queryTimeCriticalJobs(ostime_t time);

No matter how I've used it it's never returned a True, is this because the library halts other processes before transmission or am I using this function wrong?

I have been finding I need to use VtaskDelay before going to sleep or I risk messages not being sent, this function seems like a perfect solution.

I have also attempted to use vTaskSuspend on the sendmessages function and vTaskResume when required during certain states, it's worked for 1-2 messages but then failed to transmit while still running through the same outputs (EV_TXSTART etc that happens on successful transmits).

I'm attempting to get more efficient with my code but having a few setbacks when it comes to optimising sleep cycles while maintaining a reliable network.

Any recommendations on how I can better manage detecting whether the lorawan message has finished transmitting so I can shutdown ASAP?

Cheers,
Dylan

I hava a heltec esp/lora and every time i make a OTTA conection, my device send a downlink request.
My confirm mensage flasg is set to false.

Hello, awesome code. Thank you for sharing.
I'm already using Wifi of ESP-IDF to communication.
I'm so newbie, I read library but I can't find how to communicate peer to peer... Is it possible? If is how can I do it?
I'm really thankful for attention.

Hi,

I've set things up as per the PlatformIO instructions and am using the AU915 band plan but one thing I'm struggling with is how to select the second sub-band. I can see the LMIC_selectSubBand() function in lmic_au915.c but am unsure how to access it from my main.cpp. Simply adding a call to LMIC_selectSubBand() results in a "'LMIC_selectSubBand' was not declared in this scope" error. None of the examples in the repo demonstrate how to do this, can someone please provide some pointers on how to do this?

Many thanks!

meddling C and C++ is quite annoying.
Is it possible to have a full C version for esp-idf.
As far as LMIC stands for LoraMac In C :)

My application wakes up from deep sleep every hour and sends sensor data to TTN. The code basically follows the hello_world example and works quite well with my self developed ESP32 board in platform.io:

extern "C" void app_main(void) {
      :
    ttn.configurePins(TTN_SPI_HOST, TTN_PIN_NSS, TTN_PIN_RXTX, TTN_PIN_RST, TTN_PIN_DIO0, TTN_PIN_DIO1);
    ttn.provision(devEui, appEui, appKey);
    ttn.onMessage(messageReceived);

    readSensorValues();

    if (ttn.join()) {
        printf("Joined.\n");
        xTaskCreate(sendMessages, "send_messages", 1024 * 4, (void *)0, 3, nullptr);
    }
    else {
        printf("Join failed. Goodbye\n");
    } 
}

After sending the sensor values to TTN the processor is falling into sleep using:

ttn.shutdown();
esp_deep_sleep_start();

So each time the ESP32 wakes up a ttn.join() is performed. As mentioned on Best Practices on the TTN page "devices should perform join operations the less possible in their lifetime".

So I am looking for a solution to do the join operation only once or only when needed.
I cannot find something like public bool isJoined() in the API documentation.

Or ist there an another approach for this kind of application?

Hello,

I'm trying to set up an ESP32 with an e19-915m20s module (based on SX1276) to send data to TTN.

When adding the device to TTN, I have to enter the LoRaWAN (MAC) and Regional parameters (PHY) versions.

Where can I find or set them? Apologies if I missed something.

Cheers
Celine

I'm trying to run a simple example on Wemos D1 R32 board with Dragino Lora shield. This example worked with TTGO boards without issues.

https://wiki.dragino.com/index.php?title=Lora_Shield

SV2, SV3, SV4 jumpers are on the left

J_DIO1 jumper is connected, and two other DIO jumpers disconnected.

The Wemos uses its own GPIO numbers mapped to Uno pins, and the configuration works with a simple Lora example that does not use LMIC. The following is configured:

#define TTN_SPI_HOST      VSPI_HOST
#define TTN_SPI_DMA_CHAN  1
#define TTN_PIN_SPI_SCLK  18
#define TTN_PIN_SPI_MOSI  23
#define TTN_PIN_SPI_MISO  19
#define TTN_PIN_NSS       5
#define TTN_PIN_RXTX      TTN_NOT_CONNECTED
#define TTN_PIN_RST       13
#define TTN_PIN_DIO0      26
#define TTN_PIN_DIO1      27

The board produces an error immediately at start. The same error ocurs if the LoRa shield is removed completely:

I (220) boot: Loaded app from partition at offset 0x10000
I (220) boot: Disabling RNG early entropy source...
I (221) cpu_start: Pro cpu up.
I (224) cpu_start: Application information:
I (229) cpu_start: Project name:     datasender
I (235) cpu_start: App version:      1764376-dirty
I (240) cpu_start: Compile time:     May 20 2020 00:49:52
I (246) cpu_start: ELF file SHA256:  241a3510def0045d...
I (252) cpu_start: ESP-IDF:          v4.2-dev-1575-ga3520970f-dirty
I (259) cpu_start: Starting app cpu, entry point is 0x400817a4
0x400817a4: call_start_cpu1 at /opt/esp/esp-idf/components/esp32/cpu_start.c:286

I (0) cpu_start: App cpu up.
I (269) heap_init: Initializing. RAM available for dynamic allocation:
I (276) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM
I (282) heap_init: At 3FFB30B0 len 0002CF50 (179 KiB): DRAM
I (289) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM
I (295) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (301) heap_init: At 4008C058 len 00013FA8 (79 KiB): IRAM
I (308) cpu_start: Pro cpu start user code
I (326) spi_flash: detected chip: generic
I (326) spi_flash: flash io: dio
I (326) cpu_start: Starting scheduler on PRO CPU.
I (0) cpu_start: Starting scheduler on APP CPU.
I (350) ttn_hal: IO initialized
I (350) ttn_hal: SPI initialized
I (350) ttn_hal: Timer initialized
E (360) ttn_hal: LMIC failed and stopped: ../components/ttn-esp32/src/lmic/radio.c:1147

Set RX2 to SF9 for joining. After the join, the network takes care of it.

Hi all,

I am trying to change the datarate, when I was using the lmic library from arduino IDE I was using the LMIC_setDrTxpow(DR_SF10,14); command to change txpower and data rate. However when I am doing the same with ttn-esp32 do not seem to change according to the metadata in ttn console.

Best,
Haris

Hi,

We have been running lorawan compliance tests on the FW and I've followed the advise given in this slide:
https://lora-alliance.org/wp-content/uploads/2020/11/lora_alliance_certification_deep_dive.pdf

It was still vague in what was required but iterative testing has gotten us through most of it.

The key issue will be the Linkcheck requirements.

Looking at the main LMIC library it appears there isn't the API/function for a linkcheck call.
However there are some people talking/using the in-built compliance testing, I'm not sure how to activate that to test it?

So, two questions:

1. Is there a way to manually request a linkcheck? Or even a guiding start on how I might.
2. How do I start/use the in-built compliance functionality.

I was able to setup the ESP32 toolchain and run the official hello_world project.
But when running the ttn-esp32 hello_world I get the error
'ESP_INTR_FLAG_IRAM' was not declared in this scope

If I add the missing header it continuous with 'gpio_install_isr_service' was not declared

What did I miss?

Hello,

the documentation and/or code does not indicate whether this library supports the device class B.
It would be great for my application to achieve a lower downlink latency.

If not, I would try to implement the Class B support myself, as the arduino-lmic library, which this builds on, states it supports Class B.
Could then someone give me a clue on what needs to be changed?

Best Regards,
Florian

I'm using stable esp-idf, esp32-wroom-32, I got segfault after make flash monitor, here the output:

Hard resetting via RTS pin...
MONITOR
--- idf_monitor on /dev/ttyUSB0 115200 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
ets Jun 8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, 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:0x3fff0018,len:4
load:0x3fff001c,len:6320
ho 0 tail 12 room 4
load:0x40078000,len:11624
ho 0 tail 12 room 4
load:0x40080400,len:6648
entry 0x40080764
I (32) boot: ESP-IDF v3.3 2nd stage bootloader
I (33) boot: compile time 21:32:29
I (33) boot: Enabling RNG early entropy source...
I (37) boot: SPI Speed : 40MHz
I (41) boot: SPI Mode : DIO
I (45) boot: SPI Flash Size : 4MB
I (49) boot: Partition Table:
I (53) boot: ## Label Usage Type ST Offset Length
I (60) boot: 0 nvs WiFi data 01 02 00009000 00006000
I (67) boot: 1 phy_init RF data 01 01 0000f000 00001000
I (75) boot: 2 factory factory app 00 00 00010000 00100000
I (82) boot: End of partition table
I (87) esp_image: segment 0: paddr=0x00010020 vaddr=0x3f400020 size=0x0ef34 ( 61236) map
I (117) esp_image: segment 1: paddr=0x0001ef5c vaddr=0x3ffb0000 size=0x010b4 ( 4276) load
I (119) esp_image: segment 2: paddr=0x00020018 vaddr=0x400d0018 size=0x1d764 (120676) map
0x400d0018: _flash_cache_start at ??:?

I (166) esp_image: segment 3: paddr=0x0003d784 vaddr=0x3ffb10b4 size=0x00e50 ( 3664) load
I (168) esp_image: segment 4: paddr=0x0003e5dc vaddr=0x40080000 size=0x00400 ( 1024) load
0x40080000: _WindowOverflow4 at /home/almoonds/esp/esp-idf/components/freertos/xtensa_vectors.S:1779

I (173) esp_image: segment 5: paddr=0x0003e9e4 vaddr=0x40080400 size=0x09e48 ( 40520) load
I (205) boot: Loaded app from partition at offset 0x10000
I (205) boot: Disabling RNG early entropy source...
I (205) cpu_start: Pro cpu up.
I (209) cpu_start: Application information:
I (214) cpu_start: Project name: hello_world
I (219) cpu_start: App version: 1
I (223) cpu_start: Compile time: Dec 2 2019 21:32:32
I (230) cpu_start: ELF file SHA256: d457863be7c51ee3...
I (236) cpu_start: ESP-IDF: v3.3
I (240) cpu_start: Starting app cpu, entry point is 0x400811b8
0x400811b8: call_start_cpu1 at /home/almoonds/esp/esp-idf/components/esp32/cpu_start.c:270

I (0) cpu_start: App cpu up.
I (251) heap_init: Initializing. RAM available for dynamic allocation:
I (258) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM
I (264) heap_init: At 3FFB3288 len 0002CD78 (179 KiB): DRAM
I (270) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM
I (276) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (283) heap_init: At 4008A248 len 00015DB8 (87 KiB): IRAM
I (289) cpu_start: Pro cpu start user code
I (307) cpu_start: Chip Revision: 1
W (308) cpu_start: Chip revision is higher than the one configured in menuconfig. Suggest to upgrade it.
I (311) cpu_start: Starting scheduler on PRO CPU.
I (0) cpu_start: Starting scheduler on APP CPU.
I (384) ttn_hal: IO initialized
I (384) ttn_hal: SPI initialized
I (384) ttn_hal: Timer initialized
E (394) ttn_hal: /home/almoonds/esp/hello_world/components/ttn-esp32/src/lmic/oslmic.c:53
E (394) ttn_hal: /home/almoonds/esp/hello_world/components/ttn-esp32/src/hal/hal_esp32.cpp:449
E (404) ttn_hal: /home/almoonds/esp/hello_world/components/ttn-esp32/src/hal/hal_esp32.cpp:449
E (414) ttn_hal: /home/almoonds/esp/hello_world/components/ttn-esp32/src/hal/hal_esp32.cpp:449

I'm working on a project at the moment that requires a number of downlink packets to be sent and was wondering if you might have any insight into an issue I've been having.

The device works as expected for the first downlink message, waiting until TTN.transmitMessage() is called and triggering the onMessage callback function correctly.

After handling this however, I see a series of EV_TXSTART / SPI RX buffer / EV_TXCOMPLETE events that are not triggered by transmitMessage(). These don't seem to be triggering the callback function either. transmitMessage continues to be called on a timer, but will fail should an EV_TXSTART event be in progress.

Any help/advice on this would be appreciated, do let me know if this problem isn't related to this library.

I've attached some logs which may or may not be helpful:

Hi,
I have an JOIN and data transfer duty cycle, but I have a question about LMIC timings and task states.

I have this logs (with my comments):

I (157380) Lora driver: Lora new message in queue, goes to join state
I (157381) Lora driver: Lora state check join <--- here we call ttn_resume_after_power_off(60)
I (157382) Lora driver: Lora state try to join TTN <--- here we call ttn_join()
I (157388) ttn: event EV_JOINING
I (164371) ttn: event EV_TXSTART
I (169404) ttn: event EV_RXSTART
I (169512) ttn: event EV_JOINED
I (169513) Lora driver: Lora state try to join - success join, goes to send uplink <--- here we get TRUE result from ttn_join()
I (169513) Lora driver: Lora state send uplink <--- here we call ttn_transmit_message(buffer, sizeof(buffer), 31, true)
I (169519) ttn: event EV_TXSTART
I (170561) ttn: event EV_RXSTART
I (170641) ttn: event EV_TXCOMPLETE
Uplink message [size: 13]: <--- here we get TTN_SUCCESSFUL_TRANSMISSION from ttn_transmit_message(...)*
0xA5 0x11 0x22 0x33 0x44 0x00 0x55 0x66 0x77 0x00 0x00 0x00 0x00

I (170653) Lora driver: Before idle ticks: 4002 <-- then we try to check ttn_busy_duration(), and get 4002 and call ttn_wait_for_idle()

I (174655) ttn: event EV_TXSTART <-- why LMIC open TX-RX1 cycle after transmit success (1 time)
I (176797) ttn: event EV_RXSTART
I (178325) ttn: event EV_TXCOMPLETE
I (290160) ttn: event EV_TXSTART <-- why LMIC open TX-RX1-RX2 cycle after transmit success (2 time)
I (292302) ttn: event EV_RXSTART
I (293298) ttn: event EV_RXSTART
I (293539) ttn: event EV_TXCOMPLETE

I (293610) Lora driver: After idle! <-- here ttn_wait_for_idle() unblock task and then we finish transmission

Help me understand why, after receiving a response about a successful transmission (ttn_transmit_message return TTN_SUCCESSFUL_TRANSMISSION ), the LMIC stack tries to open the TX-RX1-RX2 transmission windows twice more, and only after that goes into the IDLE state?
Thank you for help

My plan is to use this library with Europe configuration on nodes connecting to LoRaServer, not to TTN.
I faced horrible delays when sending uplinks to LoRaServer while everything was OK when connecting to TTN.
My first insight after troubleshooting this issue is that LoRaServer sends unconfirmed downlinks after each uplink. I am not an expert but after reading some posts and tracing the message contents, I found that each uplink coming out from the node has the ADR flag enabled which cause LoRaServer to reply with ADR message, while on the contrary TTN seems not adhering to the same rule.

Now I am not sure about this, but I tried to resolve the issue by inserting a call to LMIC_setAdrMode(false) in TheThingsNetwork.cpp before the join process starts and in deed the issue seems to be resolved.

I wonder if this is the right solution for it or maybe this functionality should be exposed in a public method. Appreciate your feedback.

Just another note, my node is TTGO T-BEAM connected through a Dragino LG308 gateway.