Lowering get_downlink_data_delay

Hello,

what does lowering the value of get_downlink_data_delay from default 100ms to 50ms involve? Is it safe to have a faster uplink / downlink roundtrip time?

Thanks, regards

It means the ChirpStack Network Server will wait less time for the ChirpStack Application Server to (possibly) enqueue a downlink payload.

Hello Brocaar,

thanks for your answer, may i ask you why this delay should be usefull?

Thanks, regards

https://lora-developers.semtech.com/library/tech-papers-and-guides/lorawan-class-a-devices/

1 Like

Have some A-class end-devices that expect an answer within 50 ms (according to their manual).

Though I have seen the queued messages, this wouldn’t work for this case, since the message is to set the device’s clock.

Excuse me Chopmann, i understood Lora tx delays mechanism but i would like to know if in an environment with high network latency deacreasing get_downlink_data_delay may help to respect a rx1_delay of 1second.

Another help may be decreasing deduplication_delay but this results in a weaker packet detection from many gateways, i think.

Are get_downlink_data_delay and deduplication_delay part of rx1_delay time ?

Thanks, regards

I was not trying to imply that, sorry if it was rude.
I think it depends who is having the latency. The sensor it self (should) also has setting to adjust the window, so you have a bunch of ways how to accommodate for latency.
To you questions:
Afaik that knob would help if the NS is having Issues with the AS, the DDelay would be if your GW are having high latency, so in a Sense they are part of the rx_delay_time, it all adds up and setting the timers too wide might make you miss the window. I might be wrong thou.

It is useful as the NS will wait with sending the downlink to give the AS some time to schedule a downlink. Thus, the NS will sleep the given amount of time and then it will check if there is a downlink in the queue. Note: the uplink delivery from the NS to the AS happens async.