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
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.
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)
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.
