RX1 delay does not delay command frames

ChirpStack Application Server
#1

my edge devices were tested on numerous frequency and data rate combinations and they can send and receive on all of them. However I have never been able to get any edge device to even see a command frame arriving from the gateway. If an error occurred (CRC, bad MIC, etc) my devices would say so but it is like they are not seeing the frames at all. Indeed my edge devices are set to print out that no payload was received.

After nearly a week of testing, my current hypothesis is that CS application server is turning around the enqueued commands too quickly after detecting an uplink. So quickly that my devices do not have enough time to switch to a listening mode.

I have attempted to increase the RX1 delay in the device profiles and restarted the service. This has absolutely no effect, as can be seen in the time stamps below. There is no delay reported (at least at the resolution of a second). But my RX1 is supposed to be 3 seconds.

What should I try next?

rx1delay
rx1delay1005×501 45.7 KB

…

instant-command-frames
instant-command-frames1173×515 90.4 KB

1 Like
#2

I have added the following to chirpstack-network-server.toml ,

[network_server] net_id="01FDCE" get_downlink_data_delay="600ms" [network_server.band] name="US915" [network_server.network_settings] enabled_uplink_channels=[8, 9, 10, 11, 12, 13, 14, 15, 64] rx_window=0 rx1_delay=4

The get_downlink_data_delay at 600ms appears to have an effect. However if i set this above about 800ms, then no command frames are sent.

The rx1_delay=4 has absolutely no effect. Any advice here?

Also these changes have caused bugs in the FPort number. The downlink queue shows them as 2, but the live frames display zero. Any advice here?

downlinkfport2
downlinkfport2725×432 16 KB

…

buggyfports
buggyfports1004×472 78.4 KB

#3

The rx1_delay setting will be reflected in the scheduled tmst of the gateway transmission.

For OTAA devices the rx1 delay is sent in the join accept. For ABP devices it shouls be configures to the correct out of band, the CS and device delay need to be in sync to have a successful downlink.

The CS expects the gateway to queue the packet until the time to transmit. Additional metadata not shown in the UI is sent with the packet dr, freq and payload.

#4

Thanks Jason. I have since solved this problem.
I present the solution here.

If changes are made in Device-Profiles, then all devices using that profile must be reactivated. Do this by going to

Applications >> (click name) >> Devices tab, >> (click device name) >> Activation tab >> click (RE)ACTIVATE DEVICE

1 Like
#5

The reason why changes to (some of) the device-profile fields do not affect until re-activation is that the chirpstack-network-server.toml configuration has priority over the values in the device-profile. The Device-profile values define the initial values that must be used to successfully communicate with the device. After that, ChirpStack will push the configuration as defined in the chirpstack-network-server.toml configuration to the devices. Per device ChirpStack stores a device-session with the configuration that is currently in use by the device (which initially are set to the device-profile values in case of ABP).