Downlink is not happening

Hi All,

We use chirpstack server to enqueue downlink data to device. Data is showing in the queue with pending status no and after some times it vanishes. Device is in class A and it is sending uplink data properly.
but downlink is not working. Region EU868. We tried with confirmed downlink and unconfirmed downlink, both are not working. Uplink is reaching fine and OTAA join requests work fine.

Is there any reason why downlink is not working? Hope someone here can help or give suggestions for troubleshooting


Have you taken a look at the logs, including the logs of your gateway?
Chirpstack normally logs something about the downlink being sent, while the gateway bridge logs requests on the /command/down topic, of which requests come from Chirpstack itself. The gateway would normally log something when the request is received and after the frame is transmitted (or not).

The downlink disappearing, is perhaps an indicator that the gateway did transmit the downlink, so Chirpstack removed it from the queue.

If the gateway has been going “online” and “offline” in Chirpstack, and if you are using the UDP packet forwarder, please check that your gateway is sending the statistics message often enough. Often enough to meet the threshold that you set in Chirpstack.

Is the device rejoining before every uplink (rare, but I’ve seen it)? That could invalidate the queued downlink.

I tried it 20 sec ago, if I rejoin and then send a message, I don’t get the downlink provided before rejoin. Why is that the case?

There are a number of threads on this topic:

I don’t think v4 ever got the “flush device queue on join” flag.

No this is not the case, Device joins only once

After scheduling confirmed/unconfirmed downlink, event is getting logged as track, relative log is available in Gateway logs also, Device side downlink not received and the acknowledgement received on Chirpstack is “false”

Did you click on the TxAck to see whether the message was successfully transmitted? You may also want to cross-check with the gateway’s side. TX_ACK is the response to PULL_RESP, but it can either be successful or a failure.

If the transmission was successful but the device did not get it, then you may need to study the device. Being able to join the network successfully means that it can receive downlinks, especially if it can do this without difficulty (no need to make multiple attempts). Is this a device you developed or is it something you purchased?
Have you checked that you entered the correct FPort for the downlink? Some devices may ignore downlinks for the wrong FPort.

Downlinks we have verified with TTN Server and found to be working fine at the device.

When we click on TxAck, data is as below,

Can you please suggest what it indicates, whether it has transmitted the message successfully or not?

Also the port on which we have transmitted downlink is not visible on Gateway logs, we are not able check the payload as it is encrypted.
we are seeing all the downlink packets with port 0 only in the gateway logs.


Did you manage to solve this issue. I have the same issue with my Downlinks not reaching the device.
I am getting gateway acks but I see now Downlink reaching the device (self developed or 3rd party devices all have the same issue)

Hi @dewetdt,

Issue is still persisting, not resolved for me.

It is in the device-profile :slight_smile:


Ah ha, I was looking in the wrong place. Thanks.

This configuration is enabled in my device profile

Hi @sp193

Regarding “please check that your gateway is sending the statistics message often enough. Often enough to meet the threshold that you set in Chirpstack”

Where in chirpstack can I set this threshold?

I believe this is under the gateway’s profile (the details page). There is a field for an interval to be entered.

1 Like