ESP32S3 LoRaWAN Communication with TTN Using LA66 Module

https://youtu.be/i_y3ftt9oOs
In this tutorial, I am demonstrating ‘CONNECT’ Board that I have designed that has ESP32S3 and LA66 LoRaWAN module that communicates with LPS8v2 Gateway.

The ESP32S3 reads the internal temperature sensor and sends the read data over UART in form of AT Command to the LA66 module that sends the temperature data over LoRaWAN to the LPS8v2 gateway, which sends the obtained data to the TTN.

Some features of the TTN network are also presented and shown as a real life example in the tutorial. Then, it is compared with Helium network in terms of map coverage and usage pricing.

LPS8v2 gateway also features built in Node-Red server that allows IOT data management and offers UI. This feature is used to get the temperature data from the TTN application MQTT broker to make it available to the connected IOT device.

The ‘CONNECT’ board GERBER files are here

GitHub Repository:
https://github.com/UsefulElectronics/la66-lorawan-ttn/tree/main
ConnectPinout_Layer 1_copy_2

Which programming environment is this project for ?

Few tips I picked up from a very quick brows.

  1. Sending a stringing is not a good practice with LoRaWAN or any IOT, learn how to encode your data, you are wasting battery life and air time. Air time is a commodity used by everyone, you are consuming it unnecessarily and wasting it.
  2. Please implement FUP (Fair usage policy) you are allowed 30 seconds uplink time a day and max 10 downlinks.

I use Eclipse with ESP-IDF for ESP32S3 development.

Thank you for the feedback.
I am new in LoRaWAN world and wanted to share my experience with it as a starter.

I would advise you to read and learn a bit more about LoRaWAN, the TTN documentation is great and searching on here you will find lots of information. Rather share good practices and habits, as bad habits are not easy to change to good habits.

Great that you share you projects.

2 Likes

Please can you update your GitHub repro to accommodate the two issues of sending text and how often. Both of these are critical to the efficient use of the shared spectrum & the free LoRaWAN server we use. Both of these, particularly the uplink frequency, are critical issues.

These will help:

https://www.thethingsnetwork.org/docs/devices/bytes/ (ignore the pink message)

and

https://avbentem.github.io/airtime-calculator/ttn/eu868/2

hi,

after scrolling thru the forums i couldn’t find a relevant to post in and as a new user I’m an able to make a new topic, so please excuse me for highjacking this one.

also i am new to Lorawan programming so please bare with me, and thank you for any guidance.

i am setting up a dragino LA66 shield with the arduino uno and LSP8 gateway.

using the example code provided by dragino i have able been build a basic program and join TTN.

although along the way i have had a few issues, mainly with downlinks.

the serial is no longer printing :
"RX on freq 9XX.XXX MHz at DRX "

so i am assuming this means the RX window is no longer opening?

when resetting both the shield and gateway i get a flood of RX and TX windows that open, this will usually send at-least 2 join requests to TTN.

when resetting just the shield i will only have the TX window open and not be able to receive a MAC downlink for OTAA, this triggers TTN to repeatedly send MAC downlinks possibly exceeding my fair use.

i find i get the best results when resetting mac settings on TTN and shield at the same time. so would this have something to do with RX window Date?

under all situations after initial start up the node will not receive downlinks.

I have checked gateway traffic and will receive and send scheduled downlinks at join, but never custom payloads from TTN.

the following is the serial feed from LA66 when rebooting both node and gateway;

/////

Dragino LA66 Device

Image Version: v1.1

LoRaWan Stack: DR-LRX on freq 923.900 MHz at DR 10
RX on freq 923.300 MHz at DR 8
uplink payload:AT+SENDB=0,2,4,00000046
H(Q}9=}9 Q})=%9 5
***** UpLinkCounter= 0 *****

TX on freq 916.200 MHz at DR 2
R***** UpLinkCounter= 0 *****

TX on freq 918.800 MHz at DR 2
RRX on freq 924.500 MHz at DR 10
RX on freq 923.300 MHz at DR 8***** UpLinkCounter= 0 *****

TX on freq 921.0 MHz at DR 2
RX RX on freq 926.300 MHz at DR 10
RX on freq 923.300 MHz at DR 8
uplink payload:AT+SENDB=0,2,4,00000046
H(Q}9=}9 Q})=%9 5
***** UpLinkCounter= 0 *****

TX on freq 921.800 MHz at DR 2
R***** UpLinkCounter= 0 *****

TX on freq 924.400 MHz at DR 2
R***** UpLinkCounter= 0 *****

TX on freq 925.200 MHz at DR 2
RRX on freq 924.500 MHz at DR 10

/////////

and when resting only the LA66:

////
Dragino LA66 Device

Image Version: v1.1

LoRaWan Stack: DR-L
uplink payload:AT+SENDB=0,2,4,00000046
***** UpLinkCounter= 0 *****

TX on freq 918.0 MHz at DR 2

O
uplink payload:AT+SENDB=0,2,4,00000046
***** UpLinkCounter= 1 *****

TX on freq 917.800 MHz at DR 5

////

okay, with further investigation i have noticed the device addresses are not lining up.

it would explain at least half my problems. I’m guessing its due to OTTA not working correctly? whats the easiest way to fix this if the device cannot receive downlinks to update the address?

It’s hard to tell what connection method you are using which would inform us on the log which appears to have quite a lot of the things you mention is happening missing.

MAC downlinks are not our fault if we’ve got a good config at our end, so aren’t really in scope for the FUP. There is no reason why you should be getting lots of them and not getting application downlinks arriving, so there is work to do.

No point redacting anything other than the keys, everything else is transmitted in plain text at some point, but particularly not the frequencies - which channel plan & region are you in and have you got them matched up between device & gateway.

I’d reset the whole system for each test so you are starting from a clean slate each time.

Bit of housekeeping:

LA66 USB module join request fails - MIC mismatch is on the front page still and is the third entry in the search. It may help. Search is your friend.

And with your scrolling, no doubt you’ll have seen lots of code formatted with the </> on the toolbar. Please use the pencil tool to edit your post and format the log output.

There should not be a need to reset a gateway, in 8 years of end device development I never needed to reset a gateway. The only reason I can think of that resetting it changes anything is when too many downlinks are scheduled and the TTN stack decides to not schedule additional ones for that gateway. A gateway reset would reset the state at TTN starting with a clean slate (counters zeroed).