Hi all,
I’m using I-Nucleo-lrwan board from ST as a Device. I use AT_Master application code also from ST. Everythings works fine with ABP. In OTAA, my Device is stuck waiting for the Join Accept.
However, the Join Accept is sent by TTN and received by my GW. At some point, Join Accept is received and the activation process succeed. The problem occurs when the Join accept is sent with the 868,525 Mhz (see console below).
The process can take a long time (as long as TTL stop uses 868,525 Mhz)
I made tests with ChirpStack and the Join Accept is accepted by my Device at the first Join Request. ChirpStack Join Accept were sent without using 868,525 Mhz which confirm the source of the problem.
So my questions are :
Is there a way to prevent TTN from using this band?
Do you think the problem comes from my Device Stack configuration or from TTN ?
I set up a private TTN LoRaWAN Server (V3) [ https://thethingsstack.io/ ] to see the behavior with this server and everythings works because the Join Accept is sent without using 869,525 Mhz. From the log I then assume it uses RX1 :
“rx1_delay”: 5,
“rx1_frequency”: “868300000”,
“rx2_frequency”: “869525000”,
“frequency_plan_id”: “EU_863_870_TTN”
The problems is therefore only with thethingsnetwork.org but I really don’t see why… any hints ? Thanks
A LoRaWAN compliant device for EU868 should accept a join reply in RX2 which uses 869.525 SF12 (for join accepts only in TTN). Does your device mistakenly assume RX2 should use SF9?
temporarily modify you node code to generate serial debug output at each receive attempt so that you see the frequency and air settings it is trying to receive with.
I say temporarily as the act of generating debug output can in certain poorly implemented cases break the node’s ability to receive with proper timing.
In that light, you should make sure that the lack of any response in the RX1 window isn’t generating debug output which prevents proper timing of the RX2 window.
All of that said, the reported degree to which TTN seems to send join accepts in RX2 is a bit odd - it seems doubtful these are all cases of gateways being too busy to transmit in RX1. And while a well implemented node shouldn’t waste much power on the unused RX1, it’s still suboptimal to be waiting for RX2, especially where (unlike here) the join request was sent with a faster data rate, which would allow an RX1 to be sent faster as well.
You got it !!! Thanks so much. I didn’t even have to dive in the Stack as I-Nucleo-Lrwan is a module and I could get these informations just by typing AT command.
I unplugged the module to deal with bare AT command :
AT+RX2DR (data rate for RX2) returns 3 (SF9) on startup. Though the documentation says it should be SF12 …
AT+RX2DR=0 set the SF12 for RX2 and it now works.
That point solved I went back to my “AT_Master code” provided by ST and added Lora_GetDataRateRxWind2(&DataRateRxWind2) during setup.
I understand that you could assumed RX2 data Rate would be wrong. But how did you guessed it would be SF9 ? Thanks again.
Would you care to explain that one? I can’t recall seeing two sets of RX2 parameters for a device in the specification. I do know the specification allows the network to modify the parameters using MAC commands which is what TTN does for OTAA nodes in EU868.
Such modification would only apply to normal RX2, not join RX2.
The whole point of a join is that it has to work without any knowledge of what you are joining - so it has to follow the standards.
Customizations such as TTN-EU868’s SF9 RX2 apply only after joining - the whole issue here is that TTN properly sends join RX2 using the standard settings, while the module (at least in the way it is being used) is improperly applying customizations for normal RX2 to join RX2, when join RX2 must remain consistent with the standard and not be customized.
In practical terms, if someone is using TTN with OTAA then they shouldn’t be customizing RX2 via an AT command, because TTN itself will command the necessary customization. If someone were using ABP, then they might need to manually set it. Perhaps the issue comes from switching from ABP back to OTAA. But a proper LoRaWAN stack would ignore customizations of normal RX2 when implementing join RX2, because the settings of join RX2 aren’t customizable since join needs to be network-agnostic.
Sorry but the standard does not specify such a thing as join RX2. I do agree the node stack and the backend stack should use the default regional parameters while joining, in fact I created the patch for V2 of the TTN stack to observe this behavior early 2016.
In actuality the standard does give the specifications for join RX2 - notice for example how unique and distinct time delays are stated.
It allows allows for customizations of ordinary RX2, but these are obviously inapplicable to joins, both because there’s no language incorporating them, and for the more basic reason that things simply wouldn’t work if ordinary RX2 customizations applied to join RX2 - the exact problem we’re seeing with a non-compliant firmware here.
The very idea of OTAA joins only works if the air settings utilized for joining yet-unknown networks come only from the applicable LoRaWAN regional parameters, without any network-specific customizations.
I read the LoRaWAN specification. Here is the summury:
APB :
No JOIN
Downlink :RX2 must be configured as the Network Server says in its documentation (ie : SF9BW125 for TTN )
OTAA :
JOIN : RX2 must be configured as the LoRaWAN specification says : SF12BW125
Downlink : Then, during the OTAA procedure, information of the RX2 Data Rate is given by the Network Server, so there is no need to deal with that.(ie : TTN gives its SF9BW125 Data Rate for RX2). Whatever network you are using it should be properly configured.
There are 2 different configurations for the delay RX2: one for JOIN and one for Downlink.
There is only one configuration for the Data Rate RX2: common for JOIN and Downlink, but is changed (automatically) during OTAA process.
Yes, if we consider that the RX2 data Rate should be DR0 on startup as mention in LoRaWAN specification. It’s also specified on the documentation of my LoRaWAN module (I-Nucleo-LRWAN), but it’s apparently not the case. Hence my initial problem.
The really key question would be if the data rate setting for ordinary RX2 is changed by command from TTN and not by AT command then if another join is done, is the correct Regional Parameter data rate for RX2 still utilized?
If not, I’d argue that’s a bug.
It might be tempting to think that one should globally reset the module to defaults before doing another join, but actually that would be a mistake, as a LoRaWAN device must remember used join nonces and not repeat them.
