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 
, I will check this possibility!
I don’t want to seem stupid or lazy 
.
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. 
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
hi, how to install that BSP on Arduino ?
hi @beegee
Why now is open source ? This is not problem if the guys use that to other processors that are not of RAK??
It is not a problem for us. As much as possible we want to have our products open, so customers have as well the option to change things.
wow! This thought is fantastic!
Btw, is it how to enable the VERBOSE of the LoRaWAN join command ?
VERBOSE ???
What exactly do you mean?
hi,
these messages
315s533:MAC txDone
320s370:RX_1 on freq 926300000 Hz at DR 10
320s566:IRQ_RX_TX_TIMEOUT
320s566:MAC rxTimeOut
321s382:RX_2 on freq 923300000 Hz at DR 8
321s595:IRQ_RX_TX_TIMEOUT
321s595:MAC rxTimeOut
Never saw them.
My guesses
(1) enable Debug in Arduino Board to Level 1 or Level 2
(2) use AT+DEBUG=1
