LA915A on RAK3172

Hello everyone =]

I’m using the module RAK3172 here in Brazil with the Everynet public network (in a smart metering application).

And right now I’m having some compatibility issues, because Everynet uses a Latim America LoRaWAN specification (Everynet_LA915A), and I’m using the AU915 specification (the closest spec I can get with RAK3172).

The issue is related to the use of DR0 and DR1, because different from AU915, LA915 have a default uplink dwell time: 0.

It’s possible to create a firmware variation to be compliant with this specification? :thinking:
I would like some help on this matter.

Welcome to RAK forum @joao_berlese ,

I am not sure if LA915 is an official LoRaWAN regional band or a custom one from Everynet. Currently, we do not support this regional band and not configurable in RUI3 firmware of RAK3172.

1 Like

Hello @carlrowan , thanks for your reply!

I know it’s not supported and it’s impossible to configure this in RUI3.

But just to point out, it seems like a common specification for LoRa applications in Latin America, there are other modules out there that support this and this behavior is allowed.

Hi @joao_berlese ,

did you succeed with the LA915 on RAK3172?
Any recommendation?

Thank you.

1 Like

LA915 is a custom region introduced by Everynet.
We implemented LA915 in RUI3, but all the testing was done by a group in Brazil, because we have neither gateways nor LNS that supports it.

There are other threads here about LA915 (some problem with joining) you can check out if there are solutions already.

Hello guys,

@IGtti We have already done some tests with the new RUI3 4.1.0, which allows the new region “12” (LA915), with simple tests we can say that dwell time is no longer a limitation and we can freely change from DR0 to DR5 (SF12 to SF7).

I want to do some more tests, focusing on the UL join request, at the moment I don’t know if the join request is always made with DR2/SF10, or if the DR for the join can be changed (to have the same logic as the normal message, which is now allowed to freely change from DR0 to DR5, which is equally important).

Maybe @beegee can help in this matter.

I don’t know much about LA915 and the DR/SF for the join request.

Hello guys,

After testing the UL join request I can confirm that the join request message is always DR2/SF10, and I want to talk a little more about this, because this is a problem.

First of all, I know that the LA915 rules are a kind of “gray area”, because there is no clear description of how things should be. There is no documentation of the LoRa alliance, as there is for other regions.

And as we can see in the “1.0.3 LoRaWAN® Regional Parameters” documentation there are definitions for JoinReq DataRate [MinDR:MaxDR]:

As the documentation shows, there are regions where the JoinReq DataRate can change freely and are other regions where the JoinReq DataRate is fixed (such as AU915, the region that LA915 is “derived from”).

Ok so what’s the matter:

  • Firstly, it appears that the definitions for LA915 are unclear (leaving gaps for interpretation);
  • Second, the reason why LA915 exist it’s to bypass the limitation of UL data rate from AU915, starting with UplinkDwellTime=0 allowing SF11 and SF12 to be used without network authorization;
  • So based on this fact, the old AU915 limitation for JoinReq DataRate, doesn’t make sense, because you already authorized UL with higher SF from the beginning;
  • And the main point: If you are in a specific location where only SF11 or SF12 works and you suffer a reset, a power interruption or for any other reason you need to join the network again, you have ended up in an deadlock situation. In this case, your device will endlessly try a join request without success because you are limited to SF10.

This last point is a specific problem for my application, as the devices do not move, they are fixed in a water pipe infrastructure…

So please give some attention to this specific issue, as we may face some problems with devices far from gateways using LA915.

We added LA915 as courtesy to a group in Brazil, using the specifications that they gave us.

If there is anything wrong in the specifications, you can implement the changes directly in RUI3, the source is open now, and test it.
As I said before, we cannot test anything.

If it is required to change anything in the implementation of LA915, please do, test it and tell us. We are happy to implement it.

1 Like

This may or may not be relevant, but LoRaWAN 1.0.1/1.0.2 did support DR0 for AU915 for join requests. This actually caused other issues with joining as the network server was responding to the join with an instruction to use DR2 which the end node (STM32-based but not RAKWireless) I was using at the time was rejecting.

If the LoRaWAN Network Server and the end node are not in complete agreement as to the regional parameters in use, this could cause the end node to ignore a JOIN ACCEPT message.

I could only get the device connected via ABP which bypassed the issue with the OEM firmware.

Problem was only solved when I started building firmware from ST reference source starting with LoRaWAN Spec 1.0.3 which solved the AU915 regional parameters issue.

I didn’t know that the source for RUI3 was now open.
Interesting :thinking:, I will check this possibility!

I don’t want to seem stupid or lazy :sweat_smile:.
I found this repositories:

With seems to have the RUI application for RAK3172. Is there any “getting start” on this matter?
For example, being able to use VSCode to compile a version with AT commands and from there start with some small changes to the code.

If there is a link or thread here on the forum about this, I would appreciate it. :nerd_face:

The first URL is the BSP.
The second URL are examples that I just started to share.

The rest, including how to install and how to use VSC is in our RUI3 Documentation

1 Like

Hi, I tested today the connection to the Everynet in Brazil, using LA915 (Band 12), OTAA
ADR ON
Channel Mask: 0001

Rx1: 5s, Rx2: 6s
Join delay using default values: 5s and 6s (I do not know if there is a Everynet requirement for these parameters)

It worked well, Join succeed and messagens transmited.

@beegee
I noticed sometimes I get the “+EVT:TX_DONE” twice for the same AT+SEND (see picture). Any explanation for that?

Hi Joao,

I am from Brazil too. I know the Everynet implementation, and if you take a look in the last LoRa Alliance Regional Parameters, you will not see what Everynet implementation: RP002-1.0.4 Regional Parameters .

I good questions is why they did this variant ?

If you take a look in some Brazilians vendors, as Khomp, you will see the explanation about LA915:

Blockquote

When in AU915, the time for RX1 and RX2 windows, they are 1 and 2 seconds and in LA915 the time for RX1 and RX2 windows they are 5 and 6 seconds.
This difference is reflected when performing Class A downlinks. LA915 is the standard
used by ATC (American Tower Company) in ABP mode in the Latin American region, for use in
OTAA mode does not require changing the region.

Blockquote

Can you send us your AT commands sequence to EVERYNET JOIN ?

And a printscreen of your EVERYNET WEB config ?

And you LoRaWAN version protocol.

Please.

Thanks

@beegee

Got success to use RAK3272 on LA915 in BRAZIL :slight_smile:

1 Like

hi, how to install that BSP on Arduino ?

It’s in the documentation: Arduino Installation

hi @beegee

Why now is open source ? This is not problem if the guys use that to other processors that are not of RAK??