Setting RECEIVE_DELAY_1 & 2, defaults don't match recommended?

Issue:
I would like set the RECEIVE_DELAY_1 & 2 parameters myself.
Currently my rak5205 reports them as 5s and 6s but I read in the standards they recommend 1s and 2s

https://lora-alliance.org/sites/default/files/2018-04/lorawantm_regional_parameters_v1.1rb_-_final.pdf

How can I change this config? Id like to experiment with these.

at+get_config=lora:status
at+get_config=lora:status
OK.


==============LoRaWAN Status List================
Work Mode: LoRaWAN
Region: AU915
Send_interval: 60s
Auto send status: true.
Send_interval work at no sleep.
Join_mode: OTAA
DevEui: ################
AppEui: ################
AppKey: ################
Class: A
Joined Network:true
IsConfirm: false
AdrEnable: true
EnableRepeaterSupport: false
RX2_CHANNEL_FREQUENCY: 923300000, RX2_CHANNEL_DR:8
RX_WINDOW_DURATION: 3000ms
RECEIVE_DELAY_1: 5000ms
RECEIVE_DELAY_2: 6000ms
JOIN_ACCEPT_DELAY_1: 5000ms
JOIN_ACCEPT_DELAY_2: 6000ms
Current Datarate: 0
Primeval Datarate: 0
ChannelsTxPower: 0
UpLinkCounter: 0
DownLinkCounter: 0
===================List End======================

Thanks

Those are the required delays for an OTAA join, after it will change to the standard 1 & 2 second windows as instructed by the network server.

Why would you change these, they are part of the official spec.

I did read about the delays for the OTAA join and figured they were represented by JOIN_ACCEPT_DELAY_1 & 2 instead?

Even after running for a long time those delays did not seem to change.

I am just learning and trying to understand why well after the join and many data payload upink messages later, I see the sensor payload uplink message immediately on the network when transmitted but the RUI send success callback takes about 15 seconds to happen, despite being an unconfirm type send. I would have thought this callback would happen after 2 seconds.

Thanks again

So the issue is not really about the delays, but about how long the module takes to give you status on uplink :roll_eyes:

Yes and hence also when the node is permitted to uplink again.

I have just double checked and I don’t see those delays changing to 1s &2s values ever, and in the spec another uplink is not permitted until the second delay has expired. So getting to the bottom of those delays is relevant, but sure maybe not account for the entire lag. Given the closed source nature nature of RUI at least understanding the parameters logged seems like a good place to start.

Would you mind pointing me to anything that discusses the setting of these specific delays by the network server. I have only found reading that suggests they are device defaults.

(I am using a private network and all equipment is within a few meters)

Cheers

You may want to consider that it is something about your setup, as this isn’t a symptom generally reported. I don’t experience anything more than 3 or so seconds depending on DR in getting back a response.

Make them 20m apart. You may well be over loading the RF side to the extent the radio takes time to report back to the MCU.

You still need to abide by local legal duty cycle restrictions, private setup or not.

RUI is a framework built on the ST LoRa code base, which you can look at, and the delays are part of the LoRaWAN spec which is published.