Someone has succeeded to register an E5 module with The things Stack (successor of The Things Network V2 that is disconnected in few months !) ?
I followed the tuto outdated here (https://wiki.seeedstudio.com/LoRa_E5_mini/#2-develop-with-stm32cube-mcu-package) but I have 4 praameters in E5: AppKey, DevEui, AppEui that I have also in TTS console for setup of end device but I have also a DevAddr in E5 that I can’t find out how to setup in TTS console or if it’s needed !
I selected the proper frequency (EU868) everywhere applicable and selected hw platform: nucleo-wl55jc1 in TTS console to create the end device.
Any reasons joining failing ? (I’m in a covered TTN/TTS area as I have an other Lora device connected on TTS in same room !).
I use Lora_End_Node in CubeIDE as a starting point and have successfully registered several devices in TTN. Here is how I do it:
In TTN I use template from LoRaWAN Device Repository:
Brand: STMicroelectronics
Model: Nucleo-WL55JC1
Hardware version: 1.0 (default)
Firmware version: LoRaWAN End Node 1.0.0 (default)
Region: I am in EU868
Frequency plan: Europe 863-870Mhz (SF12 for RX2)
AppEUI: <same as Application key in MX, all zeros is Ok>
DevEUI: <read from your device, it has to be globally unique afaik. Same as "LoRaWAN device EUI" in MX>
AppKey: <I generate it in TTN and copy/paste to Application key, Network key and Network session key in MX>
End device ID: <I leave it default. It is human-readble unique device name, it is not used for communication with the device>
After I register device, I disable Class B and Class C support in the “General Settings” tab, Network Settings block. Otherwise it will not join.
In the Device Configuration Tool (aka MX) in CubeIDE:
Middleware -> LoraWAN
**LoraWAN Commissioning** tab:
All default values, besides:
LoRaWAN device EUI: <DevEUI in TTN>
App/Join EUI: <AppEUI in TTN>
Application key: <AppKey in TTN>
Network key: <same as Application key>
Network session key: <same as Application key, but I think it doesn't matter>
Application session key: <doesn't matter>
**LoRaWAN application** tab:
These settings will influence your joining and range:
Default class: CLASS_A
Handler Adaptive Data Rate: On
Default activation type: OTAA
**LoRaWAN middleware** tab:
These should already be good if you are using Seeed template, not Nucleus. Otherwise there is more to be done.
Select radio Driver: User Board
TCXO support: On
DCDC support: On
Tx Rfo Config: CONF_RFO_HP
I am not sure about what should be put in the session keys, since they have to be negotiated during join. I fill it in for now as described above, but I think it is a good idea to have a look once at how LoRaWAN security works and what is smart to do. For now I am just experimenting, so I do not care to be honest as long as it works.
Thanks I’m using AT commands for now on E5 to clear the Lora communication issue first and I’m a little confused by your configuration ! Are you really using TTN V3 (known as TTS) ? as it looks like a configuration on TTN V2 (that will be shut down end of year). May you please confirm ?
I have done a quick check of your settings I can apply at my configuration and it’s similar out of App Session Key (APPSKEY) and DevAddr that you don’t use ?
I managed to connect Lora-E5 modules with stock firmware with TTN v3/TTS. Only 3 parameters were needed really: DevEUI, AppEUI and AppKey. It worked.
Do you see anything in the live data console in TTS? Even if something is incorrect, you get a message there anyway. If not then no gateway is able to receive your join request.
You are saying you are using ‘Lora E5 module’, ie not board, right? How did you connected it to the antenna? Maybe your RF part is not able to transmit enough signal to reach a gateway?
It’s what I tried at first but join was always failing ! I got one time an indication of an incoming message in TTS console but nothing else and it did it only one time
Sorry for confusion but no I’m using one E5 on a dev board and other one is mini E5 module
You have to join each time you power your board. For me it was not obvious at first. AT+JOIN will send out join request at DR0, unless you switched ADR off. Once any gateway in the area be able to receive your request, you should see something like that in your live data stream:
18:52:27 <your device id> Accept join-request
or you see an error message. If you do not see anything then there is no reach. Reasons can be: antenna, placing of the antenna, settings: region, DR, transmission power. Also: I think there are/were modules/boards for 433MHz, cannot find it on internet any more. Is your module on board LoRa-E5-HF? If yes, then it is 868/915 MHz board.
Could you try the antenna from the working board and place your board at exactly same place and antenna position?
What RSSI and SNR do you see when working board sends out data? And which DR does it use?
Yep I got that well when I registered my other Lora device that is working fine ! But while checking data of that device (Dragino LHT65: outdoor Lora sensor) I noticed that TTN was not receiving all messages of the device (it emits one message every half hour with datas) so I think I’m now not so well covered by TTN and on their realtime map I noticed quite few TTN gws around me are down
i ordered a Lora Gateway Hat for a PI4 (RAK2287) that i’ll setup on TTN as soon as I receive and so I’m sure I don’t get anymore any range problems and be able to work properly with the E5 Will keep posted here when I receive it and first tests with E5 !
SNR: -10.5 RSSI: -112 on the Dragino device as reported in TTN console
This is challenging. You need a good antenna. I was buying 868MHz antennas and checking them with NanoVNA. If it was not good I was asking either for return or replacement. Sellers usually wanted to send me another ones, but new antennas were not always better. So, I ended up with a bunch of antennas:
excellent for WiFi, poor 868MHz
excellent for 915MHz, poor 868MHz
very good 868MHz antennas
good for some weird frequency ranges
not good for any frequency (or some narrow range I could not detect)
All these antennas were selling as 868MHz antennas, mind you. As I said, in my case sellers were ready to send me bunch of other antennas for free as replacement or return money or both.
Once you get a gateway in close proximity, all of it becomes irrelevant: LoRa is really good at picking up a signal. Once I forgot to attach antenna at all and still was picking a good signal on short U.FL antenna cable. Any decent antenna will allow you to reliably send data with DR5 and lowest transmission power (if battery life is of any concern). This is at close proximity, of course. Let’s say at WiFi range or so.
As of packet loss - this is inherent on LoRaWAN network. Expect 10% packet loss - this is what they say. Even at close proximity. I can confirm it. My GW is pygate from pycocom.
Thanks for the infos, I’m not so surprised working a lot with Wifi systems for my customers and I noticed that very often antennas specs are “very” approximate
That’s why on gw I receive next week and I’ll setup on TTN, i’m going to exchange the basic spring style antenna supplied by a 2.8dB antenna optimised for Lora 868 (my band here) so it gets best coverage possible and I’ll update it in few weeks with a 5.8dB fiberglass antenna for the same band I’ll do some coverage tests in neighborhood once fully setup with TTNMapper so I cann check how it works (hopefully well
yep pretty amazed already how my sensor outdoor device still gets Lora cover while out of coverage and having far of the best antenna inside The counterpart of that very good range is probably the delay it takes to receive some paquets sometimes !
Thanks the info as I would have expected it that in current usage in the field but not on short coverage So no panic at first paquet not received
