GPS Timestamp Anomaly with Here 3 on OrangeCube – Exact 200ms Intervals and Unexpected Drift

Here GPS
1

Hi everyone,

I’m experiencing a strange behaviour with the GPS timestamps on my OrangeCube + Here 3 setup and I’m hoping someone here can shed some light on it.

Hardware:

  • OrangeCube (PX4 v1.17.0)

  • Here 3 GPS (via CAN)

What I observed:

I’ve been logging GPS data over periods of approximately 15 minutes via MAVLink. Specifically, I’m comparing the GPS timestamp (the time the GPS message arrives at the OrangeCube) with the internal system clock.

Two things stand out that I can’t explain:

1. The delta between GPS time and internal clock drifts significantly The difference between GPS-time and the internal HRT (High-Resolution Timer) fluctuates in the millisecond range over time, rather than staying constant. Since the GPS clock is supposed to be highly accurate and the internal IMU clock is the one expected to drift, I would expect the delta to remain small and relatively stable – or at most grow slowly in one direction. Instead, the drift is erratic.

2. GPS timestamps always arrive in exact 200ms intervals – without any jitter Every single GPS measurement arrives at exactly 200ms after the previous one. No variation whatsoever. This seems unrealistically precise. Is the timestamp perhaps not reflecting the actual measurement time, but rather being generated or rounded somewhere in the middleware/firmware?

What I already tried:

To capture the GPS arrival timestamp, I patched the PX4 firmware (GPS_RAW_INT.hpp) to write gps.timestamp into the alt field of the MAVLink message, so I could log it via QGroundControl without a custom parser:

cpp

// msg.alt = static_cast<int32_t>(round(gps.altitude_msl_m * 1e3));
msg.alt = gps.timestamp;

The logged data and graphs have also been posted in the PX4 forum here for reference: https://discuss.px4.io/t/gps-measurements-indicate-a-drift-in-gps-time-and-i-cant-explain-why/48889

My questions:

  • Is the 200ms interval a fixed output rate configured somewhere in the Here 3 firmware or the CAN driver?

  • Does anyone have experience with GPS time synchronisation on the OrangeCube and could explain the observed drift behaviour?

Any insight would be greatly appreciated!

2

Follow-up: Measurements with HERE3+ and HERE3 – GPS vs. IMU Timestamp Comparison

I did some additional measurements to investigate the issue further. All values are in microseconds (µs).

Setup 1:

GPS = HERE3+

GPS2 = HERE3

First measurement:

log

gps:  gps_time: 1776412181800000 , imu_time: 543932581
gps2: gps_time: 1776412181799617 , imu_time: 543934057

Second measurement (approx. 200ms later):

log

gps:  gps_time: 1776412182000000 , imu_time: 544133181
gps2: gps_time: 1776412181999618 , imu_time: 544135255

Observations:

  • HERE3+ (gps): The GPS time delta is exactly 200,000 µs, which corresponds to the expected 5 Hz update rate. However, the IMU timestamp delta is 200,600 µs – a deviation of 600 µs.

  • HERE3 (gps2): The GPS time delta is 200,001 µs, and the IMU timestamp delta is 201,198 µs – a deviation of 1,197 µs.

The HERE3 also shows a fixed offset of approximately 383 µs between the two GPS clocks (1776412181800000 vs. 1776412181799617)

Setup 2:

GPS = HERE3+

GPS2 = HERE3+

First measurement:

log

gps:  gps_time: 1777534774200000 , imu_time: 116696486
gps2: gps_time: 1777534774200000 , imu_time: 116702226

Second measurement (approx. 200ms later):

log

gps:  gps_time: 1777534774400000 , imu_time: 116895618
gps2: gps_time: 1777534774400000 , imu_time: 116900623

Observations:

  • Both HERE3+ units report identical GPS timestamps, which makes sense as they are both receiving the same GPS time signal.

  • The GPS time delta is exactly 200,000 µs for both.

  • However, the IMU timestamp deltas differ: gps: 199,132 µs and gps2: 198,397 µs.

  • This means both GPS messages are being timestamped by the IMU clock approximately 1 ms apart, even though their GPS times are identical.