Lowering get_downlink_data_delay

ChirpStack Network Server
1

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

2

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

3

Hello Brocaar,

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

Thanks, regards

4

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

1 Like
5

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.

6

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

7

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.

8

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.

9

Hi. One question about that. I am working with uplinks with confirmation. In some situations, I don’t receive the downlinks with the ack (they don’t appear in the LoraWAN frames tab). It could be high latency because of a new Gateway model (Dragino DLOS8) and because of network latencies.
Sometimes only one of four acks is sent. And after a time working in that way, no more acks are sent. If I reset the gateway it works again with one ack four uplinks.
ACK confirmation for (ConfirmedDataUp) uplinks, is queued by the AS or directly by the NS?
I’m thinking lowering get_downlink_data_delay but if the problem is in AS queuing, I’d need to raise it.
The same node and gateway with 4g work ok. Not in a particular LAN where it has several routers to the internet.
Thank you.

10

It is sent by the NS, lowering get_downlink_data_delay could help, as the NS spends less time waiting for a possible payload from the AS before it proceeds with sending the downlink (containing the ACK).

1 Like