Uplinks processed despite large gwTime/nsTime drift — no rejection or flag raised

Question

Hi
We're seeing uplinks processed and forwarded to the application even when there is a very large discrepancy between gwTime and nsTime in rxInfo. This is causing out-of-sequence readings downstream in our interval-based application, since the reading is effectively timestamped incorrectly relative to when it was actually measured.

Example:

"uplinkId": 52089,
"gwTime": "2026-06-24T07:29:57.261191+00:00",
"nsTime": "2026-06-24T08:39:19.111590107+00:00",
"timeSinceGpsEpoch": "1466321415.261s"

Drift here is approximately 69 minutes 22 seconds. Despite this, the uplink was decoded, processed, and delivered via integration with no error, warning, or flag of any kind in the event payload.

Environment:

ChirpStack v4
Device class A, LoRaWAN EU868
Confirmed uplinks
Devices are on sites with known weak RF conditions / retransmission behaviour

Question / request:

Is there any existing mechanism (event code, log level, or configuration) that flags or surfaces this kind of drift on an uplink event, beyond rx_timestamp_max_drift?
We understand rx_timestamp_max_drift only governs which timestamp ChirpStack trusts internally (falls back to another gateway's timestamp, or server time) — it does not reject the packet, and it does not alter the raw gwTime/nsTime values exposed in rxInfo. Can you confirm this understanding is correct?
Would it be feasible to have ChirpStack optionally reject or flag uplinks where gwTime/nsTime drift exceeds a configurable threshold, rather than relying on downstream consumers to calculate and validate this themselves?

Impact:
For interval-based metering/telemetry applications, a reading with a significantly delayed or drifted timestamp can be worse than no reading at all, as it risks being allocated to the wrong time period downstream.

Orne Brocaar · Answer

The exposure of both the gwTime and nsTime was exactly to cover these kind of use-cases, as comparing these two could indicate that there is a time-sync issue (at the gateway side). In the past only one timestamp (provided by the gateway only) was available.

However, even if there is a time-sync issue, ChirpStack will not reject these uplinks, as long as the frame-counters etc.. are valid. For ChirpStack, the timestamps are just meta-data (except when it receives a DeviceTimeReq mac-command, in which case it will not use a gateway provided timestamp with significant drift).

I would suggest implementing such logic in your application, or potentially use the frame-counter of the device to sort on (within the same activation, as it will reset to 0 on re-join).

shaun croman · Answer

Orne,
Thanks for your quick reply. To fill out some detail i missed earlier. This is only happening on transmitters that have a very poor signal strength, I can see that downlinks often fail, some uplinks are missing as well. I have modified some transmitters to switch confirmed mode off, which "seems" to have erradicated the issue, under the guise that no reading is better than a bad one. The NTP sync of the gateways has been fine as this was one of the first things I checked. I am thinking abut some ingestion logic comparing gwTime and nsTime and rejecting the packet if these are too far apart.
Interestingly these packets are always preceeded by the error "level": "ERROR",
"code": "DOWNLINK_GATEWAY",
"description": "TOO_EARLY",
"context": {}.
I think this maybe something to do with the way confirmed mode works.

regards

Uplinks processed despite large gwTime/nsTime drift — no rejection or flag raised

2 Answers