I have been using the RAK811 LoRaWAN device for quite a while on TheThingsStack V3. I have noticed that when I booted the RAK811 the parameters are as highlighted below:
After joining the Network server, the RECEIVE_DELAY_1 & RECEIVE_DELAY_2 got changed from 1000ms, 2000ms to 5000ms, 6000ms as shown in the snapshot below.
Note the Region is set to EU868. So basically I wanted to know how the RECEIVE_DELAY_1 & RECEIVE_DELAY_2 got changed from 1000ms, 2000ms to 5000ms, 6000ms.
It was not supposed to be RECEIVE_DELAY_1: 1000ms & RECEIVE_DELAY_2: 2000ms respectively (the same as before), correct me if I am wrong?.
TTS V3 changed the RX1 and RX2 timing as you know and that is not the default in RAK811. But it will be automatically updated after a successful join. The configuration RX1 and RX2 delays is on the join accept. This is only possible with OTAA activation. If ABP, you need to match both the Network Server and the device manually.
Thanks for your swift response, and regular support.
OK if I understood well the RX1 and RX2 will always remain to 5000ms & 6000ms after the join accept right??
The main reason for me to ask this question is basically, I wanted to reduce the RAK811 Active duration for the uplink as you can see from the snapshot below is 10s, and the RX1 and RX2 contribute to another additional 5s & 6s.
All I wanted to do is to reduce the RX1 and RX2 same as the default that is 1000ms & 2000ms. Can you please suggest if there are alternative ways to reduce the Active Duration??.
If you want to make it shorter and still via OTAA, you can modify the RX1 and RX2 delay on the network server. I am not really sure on the method how it is done in TheThingsStack but I think it should be possible via CLI.
If you want ABP, that is easy because you can set it in the TTS console.
Another thing is you can actually sleep your device in between for 4seconds while waiting for the 5-sec and 6-sec RX delays. I haven’t done it personally but @nmcc shared this approach to the forum.
You do have the option of setting the Rx1 on TTS & other stacks - but the reason it’s that long is to account for any delays in the network, most likely when on GSM/LTE or processing on the stack.
So if you have some very well connected gateways you could in theory reduce the Rx1 figure.
Yes, you are right Gateways can be backhauled through various access modes [Cellular (3G/4G/5G), WiFi, Ethernet, Fiber-optic or 2.4 GHz radio links], makes sense to me now.
Many thanks for your help in highlighting the RX1 and RX2 delays Nick .