Hello folks! I’ve a problem for a few weeks already and I can’t solve it unfortunately. I’m using an ESP32 + RFM95 module to send data to TTN. I’ve dug through all datasheets + specifications, but still out of luck. The problem is that no matter what data I send, it won’t be received. At least, nothing is shown in the console. Since I’m not using a preprogrammed module, I have to activate it, and I’m using OTAA.
According to the LoRaWAN specs (6.2.2), I have to send [JoinEUI, DevEUI, DevNonce] as the main payload, whereas the MDHR is just 0 (a Join-Request), and the MIC is calculated properly. Copying the JoinEUI and DevEUI from the console into my code, and sending the full payload.
But… it still doesn’t arrive. Nothing is shown in the console, no Join-Request or anything else. So, it could be that my RFM95 module is setup wrong, or my code is wrong, or the protocol is wrong, or…? I’m stuck at how to properly find the error, so I’m posting here and hope anyone of you can find it.
The RFM95 module is properly connected to the ESP32. I can read and write via SPI. Reading the version returns 18, as it should be
I do get an interrupt after sending the data, which means data transmission is done (properly??)
Nothing is shown in the console from TTN.
The closest gateway is about 3 km from my location, in an urban area. However, I tried at another location where the gateway was a few 100m away, and still no data.
I’m located in The Netherlands, so SF7BW125-SF12BW125 is supported (?).
I don’t have a second RFM95 module to test if the data is actually sent. If it’s needed, I can buy one and connect to my Arduino.
I tried different MicroPython implementations found on GitHub, none results in data being sent.
Some config from the TTN console:
My wiring:
So yeah, I’m stuck for a few weeks and no idea what the problem is. Can anyone help me? Could it be the soldering? Wrong protocol? Something else? Thanks in advance!
Please don’t try to make you own implementation of the LoRaWAN protocol on an end device until you have substantial experience with existing ones.
There’s just too much that can go wrong, in ways that are not only hard to debug without experience, but likely to make a mess of uselessly repeating failed traffic in the shared network environment as well - even if part of the functionality were right, failure to fully implement the spec in all of uplink, downlink, and MAC command behavior causes problems.
Actually, for the actual LoRaWAN implementation I do use an existing library for that. But that’s not what my problem is. I want to send some data, but before I can send data I have to register my device. So that’s what I’m currently trying, not to implement a full LoRaWAN implementation (yet).
None of that is evident in your code - you have coded the join request - there’s a whole heap more to a LoRaWAN library for the join accept, uplinks, downlinks, the MAC command processing and too many other things to mention.
So the most obvious question is, is your project about creating a LoRaWAN library / stack?
To use an analogy, you wouldn’t sew your own parachute for your first skydive, you’d try out known good ones and find out what kit would be useful if not essential - like having your own gateway so you can see if it is hearing your radio module, even if it’s dropping the request. And by having a known good device that uses the same radio, you could watch the SPI bus to see what’s going back & forth to command the radio.
Then there is the reality of LoRaWAN - I feel pretty cutting edge when using the Microchip WLR089U which requires LoRaWAN v1.0.4 with incrementing Join/Dev Nonces which means I have to set settings to do testing to get around the (relatively) frequent restarts. Mostly at the moment I’m using STM32WL modules which sits best with v1.0.3 using the official LoRaMAC-node stack. The go to stack for maker devices is LMIC which uses v1.0.3. So you are well in to unknown territory by using v1.1.0, which shouldn’t matter, but you are striking out on a journey not many else have made.
Setting power to 23 means you need to read the EU radio regulations, a legal document that is the law with the usual consequences for disregarding.
But mostly, trying to create a stack without your own gateway is like assembly PCB’s without the benefit of a soldering iron.
Thanks for your response! Maybe I should have clarified better what my goal was. In fact it’s really simple, just a few sensors connected to an ESP32 which would send data to the TTN every X minutes. That data is being read by another application, unrelated to my question. I chose an ESP32 + RFM95 because it seems they were able to program. Well, they are, but apparently it’s the bare minimum . I searched on GitHub for LoRaWAN libraries, written in Python, but those were still pretty basic. I found something like LMIC as well, but that one is written in C, so that’s hard to get working with MicroPython. But since it’s better to use existing, well-tested libraries rather than something new, I should probably think about using another microcontroller, which could be put in low power mode and has enough external pins available for the sensors (1x UART, 2x SPI at least). And maybe I should think about buying a gateway, as that certainly makes things easier with testing. I did have some experience with LoRaWAN in the past, where I used a LoPy, although that thing is very simple to program heh.
Maybe it’s out of scope for this question, but is the LoRa-E5 Development Kit fine for newbies?
Again, thanks for your response, it’s never too late to learn
It’s still absolutely required to be a complete and correct LoRaWAN implementation. Partial implementations are not allowed.
I searched on GitHub for LoRaWAN libraries, written in Python, but those were still pretty basic.
The device end of LoRaWAN tends to be played by small battery powered MCU’s which are not traditionally programmed in python. Its unclear that there are any complete and correct LoRaWAN implementations which are.
I found something like LMIC as well, but that one is written in C
Indeed, and its widely used on your ESP32 hardware
that’s hard to get working with MicroPython.
That desire is probably the original mistake.
Python is great for tooling, tolerable on the server, but not so much on the tiny devices.
If you really insist on micropython rather than traditional embedded systems development, you probably want to chose a module with its own processor and LoRaWAN stack that can you interact with via an AT command type interface from your micropython code. Plenty of people have gone the route of using such an encapsulated LoRaWAN stack when developing their code in C, Arduino, etc, too.
Writing a compliant & community friendly LoRaWAN stack for use on the community network (note the double use of community) so as to not disrupt the use by the TTN communities (ok, triple) with their activities is not congruent with just wanting to run a few sensors. It would be simpler to translate in your head the rather simple C used for the LMIC implementations in to Python than to write a stack from scratch - particularly as I’d have to assume you targeting bleeding edge versions means there is still a lot of detail for you to catch up on.
As such there is no reason not to use something like LMIC-node that has comprehensive documentation and direct support for ESP32.
The LoRa-E5 will require you to use the ST LoRaMAC-node implementation - which as well as being in C, is not targeted as a quick-win or soft-start or for the casual user. You could, as suggested by @cslora, use the LoRa-E5 as an AT style module - which is the firmware that they are shipped with, and then do Python on your ESP32.
Or use the Pycom offerings - they do a gateway too (although that’s largely irrelevant as the gateway isn’t something you need to code for).
Almost everyone starting out without a gateway ends up getting one. The TTIG which is around 80 $/€/£ is OK as a minimal gateway.
I’m a bit late with my response, but I heartly thank you for your posts! I switched to C and used LMIC Node, and now it works like a charm! It’s pretty easy to use and works out of the box, so I’m super happy with that! Programming the sensor libraries in C took a bit time to move from MicroPython to C, but I’ve got everything working. Thanks again, and have a nice day
. I searched on GitHub for LoRaWAN libraries, written in Python, but those were still pretty basic. I found something like LMIC as well, but that one is written in C, so that’s hard to get working with MicroPython. But since it’s better to use existing, well-tested libraries rather than something new, I should probably think about using another microcontroller, which could be put in low power mode and has enough external pins available for the sensors (1x UART, 2x SPI at least). And maybe I should think about buying a gateway, as that certainly makes things easier with testing. I did have some experience with LoRaWAN in the past, where I used a LoPy, although that thing is very simple to program heh.
