first of all thanks for the support. Sure, I would like to receive your modified files. (www.gadotti.eng.br)
I am working in a new board and my intention was to use the RUI3 firmware and follow the oficial releases from Rak Wireless. But, after FW 4.1.1, I am facing a severe crash. Unfortunatelly the LA915 implementation was not further maintained.
I will take a look on the STM32LoRaWAN option as well.
I read in other module documentation about selecting AU915 and just change the RX delays, this would be the LA915. As I can see, it is not that simples, right?
The Tecsus team assisted the RAKWireless team in including LA915 in the RUI. We followed Everynet’s specifications (LA915 · Everynet Network Server).
Our system has been working well with RUI versions 4.2.0 and 4.2.1. Occasionally, we encounter minor issues with downlinks, but nothing critical.
Our company has been using the LoRaWAN network with the RAK3172 module on the LA915 plan in several cities, including São Paulo, São José dos Campos, Campinas, and Rio de Janeiro, and we haven’t encountered any issues so far
Just to clarify: we didn’t make any code changes ourselves. The RAKWireless team has already included LA915 support in the official RUI firmware. We’re currently using it with the RAK3172 module and RUI versions 4.2.0 and 4.2.1, and it’s working as expected.
So there’s nothing we need to merge — we’re simply using the existing support already available in the latest RUI version.
Interesting, so it works for you. But others report problems with LA915.
Wondering why. But again, we still don’t have any LA915 environment for testing.
Setting up a gateway would be no problem, but I can’t find a LoRaWAN server that supports LA915 (beside of Everynet, which is not free to use).
Most of the issues were actually opened by our team. There was a misunderstanding due to the fact that both LA915 and AU915 are technically supported by networks in Brazil, which sometimes caused commissioning errors. In June 2024, Everynet Brazil published a guideline called “Política de Dispositivos - Conformidade Mandatória” (https://iot-labs.io/wp-content/uploads/2024/07/Politica-de-Dispositivos-Conformidade-Mandatoria.pdf), which clearly directed everyone to use LA915 correctly. Since then, we haven’t had any further issues.
There are still a few minor issues related to downlink reception failures, but these are directly tied to coverage and device RX sensitivity — not related to the LA915 implementation itself.
Don’t worry about not being able to test LA915 in the field — we’ve tested it extensively, and it works. We have dozens of devices deployed across different cities in Brazil, running perfectly.
If other developers are struggling to implement their code, the root cause is likely elsewhere.
We’re happy to support our fellow developers in Brazil with tips or benchmarks if needed.
Hi Diogo, this is really good to hear the latest versions are working fine under LA915 region. Hopefully the problem is on my side.
I am using the RAK3172 module with a host controller, communicating via AT commands. Not sure you have the same setup.
FW 4.1.1 is working, close to one year in the field and no issues. When FW was updated to 4.2.0 the module died after a reset. I could repeat it in different modules.
Here you can see the steps I did when problem happened:
I guess the problem is not related to the network configuration, because in some tests the issue happened even before a connection to the NS.
My configuration is same as your screen:
Activation: OTAA
Cryptography: NS
ADR: ON
Class: A
Maybe this issue is not related to LA915, but with the module operating in AT commands mode! Probably most of the users are in API mode. @beegee , have you experienced any similar problem when in AT commands?
I did not test yet the latest FW 4.2.1, want to check it as well.
In your first post I see that the channel mask is set to 0001. That means it will use channels 0 to 7.
Are your sure it is the correct channel selection? See AT+MASK.
E.g. TTN is using channels 8 to 15 which is mask 0002.
