Azure Service Bus Integration: Are duplicate uplinks expected?

ChirpStack (v4) Integrations
1

Hi Everyone,

I’m hoping to get some advice on a deduplication question.
I’ve got about 400 pulse-counting LoRaWAN devices installed in a building, and as expected, many are picked up by multiple gateways.

When I check the ChirpStack UI, I can see deduplication is happening — the frame counter (FCnt) only increments once per real uplink, and every second event shows:

Code: UPLINK_F_CNT_RETRANSMISSION
Level: WARNING

However, I’m using the Azure Service Bus integration and I’m still seeing all the duplicated events being sent to the queue.

My question is:
Does ChirpStack publish every received packet to the queue (even retransmissions or multiple gateway receptions), and it’s up to us to deduplicate on the Azure side?
Or is it meant to only send messages when FCnt increments (deduplicated uplinks)?

Thanks in advance for any clarification!

2

Never used the azure service but I believe all device type errors get sent with most integrations. The real issue is why you are seeing so many of these.

The uplink_f_cnt_retransmission error will only appear when the delay between the duplicate uplinks is larger than the deduplication delay. Otherwise Chirpstack will silently ignore the duplicates.

There is a setting in the [network] section of your chirpstack.toml called deduplication_delay, which defaults to 200ms, maybe try increasing that.

3

thanks - makes sense it definitely exceeds the default 200ms

image
image974×603 32.9 KB

I haven’t seen it before as we were using embedded NS in the gateways and having multiple gateways in a fleet with 1 master GW forwarding to IOT hub - now switching to chirpstack network server might need to tune this delay.

ive made some adjustments but still seeing the issue i can see alot of retransmission error
currently using these settings there are still some that are 2-3 second delays but increasing more seemed to then create downlink errors.

Time to wait for uplink de-duplication.

deduplication_delay=“1000ms”

Get downlink data delay.

get_downlink_data_delay=“500ms”

2025-04-23T07:27:56.094840Z INFO up{deduplication_id=a78ba597-6328-439f-9729-a97b6abcb258}:data_up{dev_eui=“24e124136e147750”}: chirpstack::maccommand::link_check: Received LinkCheckReq dev_eui=24e124136e147750
2025-04-23T07:27:56.095250Z INFO up{deduplication_id=a78ba597-6328-439f-9729-a97b6abcb258}:data_up{dev_eui=“24e124136e147750”}: chirpstack::storage::device_gateway: Gateway rx-info saved dev_eui=24e124136e147750
2025-04-23T07:27:56.104229Z INFO chirpstack::integration::azure_service_bus: Publishing event event=up dev_eui=24e124136e147750
2025-04-23T07:27:56.115452Z INFO up{deduplication_id=a78ba597-6328-439f-9729-a97b6abcb258}:data_up{dev_eui=“24e124136e147750”}: chirpstack::storage::device: Device partially updated dev_eui=24e124136e147750
2025-04-23T07:27:56.622086Z INFO up{deduplication_id=a78ba597-6328-439f-9729-a97b6abcb258}:data_up{dev_eui=“24e124136e147750”}:data_down{downlink_id=1736775781}: chirpstack::storage::device: Device partially updated dev_eui=24e124136e147750
2025-04-23T07:27:56.684821Z INFO tx_ack{downlink_id=1736775781}: chirpstack::storage::device: Device partially updated dev_eui=24e124136e147750

I also noticed there might be a bigger delay between the “time” in the payload to the EnqueuedTimeUtc from my understanding the time in payload is the time the packet is received from the sensor and the enqueued time is when the service bus is delivering the message on the queue?

for these devices with retransmission alerts I see some high latency like this one received 2025-04-22T00:49:04.153+00:00 but sent to the queue 2025-04-23T02:01:49.5730031Z

“rxInfo”: [
{
“gatewayId”: “24e124fffef6ecb6”,
“rssi”: -57.0,
“snr”: 14.0,
“channel”: null,
“metadata”: null
},
{
“gatewayId”: “24e124fffef71910”,
“rssi”: -100.0,
“snr”: 10.5,
“channel”: null,
“metadata”: null
}
],
“time”: “2025-04-22T00:49:04.153+00:00”,
“txInfo”: {
“frequency”: 916800000,
“modulation”: {
“lora”: {
“bandwidth”: 125000,
“spreadingFactor”: 7,
“codeRate”: “CR_4_5”
}

checking logs it seems like chirpstack does publish every uplink to the service bus integration as soon as they arrive though…

4

the retransmission errors have improved - but is possible to apply ChirpStack’s internal de-duplication logic to filter outbound integration Azure Service Bus? so the messages sent to queue match what is shown in the chirpstack UI?