Huge timestamp difference (INVALID TIMESTAMP)

Setup: ZED 2i, Zbox Orin

Hello,

I used to have the error “GNSS DATA COVARIANCE MUST VARY” when ingesting my gnss data into the fusion, even though it was varying when looking at the data. I couldn’t solve the issue and I’ve read somwhere that it was moved from an error to a warning in the version 4.2.4 of the zed sdk.

So I updated mine from v4.1.3 to 4.2.5, but now I have the error “INVALID TIMESTAMP, The timestamp of the GNSS data you are attempting to ingest for [GeoTracking] is different from the camera timestamp.”.

It says the difference is of -1494893472 ms.
As you can see, when I calculate the difference myself, it is of only 126 ms, which is good, but it seems that it gets one value from somewhere else to calculate his own difference ? What could it be ?

I’ve noticed that the difference goes from -1494894472 ms to -1494893472 ms, which is exactly one second, which corresponds to my gnss timestamp as it is updated every second. So does it not use the ZED Timestamp ? And also, it goes from -1494894472 to -1494893472, which sounds weird to me as it’s heading to 0 and not to -infinity.

Is it a problem with the OS clock not being synchronized ? I’m so lost…

Here is how I set the GNSSData ts:

if "time" in gpsd_data:
                    timestamp_microseconds = int(gpsd_data["time"].timestamp() * 1000000)
                    ts = sl.Timestamp()
                    ts.set_microseconds(timestamp_microseconds)
                    current_gnss_data.ts = ts

And here is how I get the timestamps and log them :

if fusion is not None:
                    last_image_timestamp = zed_camera.get_timestamp(sl.TIME_REFERENCE.IMAGE)
                    current_timestamp = zed_camera.get_timestamp(sl.TIME_REFERENCE.CURRENT)
                    print("Latest image timestamp: ", last_image_timestamp.get_nanoseconds(), "ns from Epoch.")
                    print("Current timestamp: ", current_timestamp.get_nanoseconds(), "ns from Epoch.")

                    # Ingest GNSS data - EXACT match to recording.py
                    ingest_error = fusion.ingest_gnss_data(input_gnss)
                    logger.info(f"GNSS data ingested with status: {ingest_error}")
                    
                    if ingest_error == sl.FUSION_ERROR_CODE.SUCCESS:
                        logger.info("✓ GNSS data ingested successfully!")
                        # Save GNSS data into JSON:
                        gnss_data_saver.addGNSSData(input_gnss)
                    else:
                        logger.warning(f"Fusion ingest error: {ingest_error}")
                         # Get GNSS timestamp
                        gnss_timestamp = input_gnss.ts.get_milliseconds()  # GNSS timestamp in milliseconds

                        # Get ZED camera timestamp
                        zed_timestamp = zed_camera.get_timestamp(sl.TIME_REFERENCE.CURRENT).get_milliseconds()

                        # Log and compare the timestamps
                        print(f"ZED Timestamp: {zed_timestamp} ms, GNSS Timestamp: {gnss_timestamp} ms, Difference: {zed_timestamp - gnss_timestamp} ms")
                        print("Image Timestamp: ", zed_camera.get_timestamp(sl.TIME_REFERENCE.IMAGE).get_milliseconds())
                        print("------------------------------")
INFO:gpsd-reader-rtk:GNSS Position: lat=50.620069, lon=4.615719, alt=99.2m, mode=3
INFO:gpsd-reader-rtk:GNSS Status: 2
INFO:gpsd-reader-rtk:Horizontal precision (EPH): 10.577
INFO:gpsd-reader-rtk:Vertical precision (EPV): 18.046
INFO:zed-camera-server:GNSS data received with timestamp: 1746556795.000s, lat/lon: 50.620069/4.615719
Latest image timestamp:  1746556795007094481 ns from Epoch.
Current timestamp:  1746556795101533404 ns from Epoch.
[2025-05-06 18:39:55 UTC][ZED][WARNING] The timestamp of the GNSS data you are attempting to ingest for [GeoTracking]  is different from the camera timestamp. Timestamp difference: -1494894472 ms.
INFO:zed-camera-server:GNSS data ingested with status: INVALID TIMESTAMP
WARNING:zed-camera-server:Fusion ingest error: INVALID TIMESTAMP
ZED Timestamp: 1746556795102 ms, GNSS Timestamp: 1746556795000 ms, Difference: 102 ms
Image Timestamp:  1746556795007

INFO:gpsd-reader-rtk:GNSS Position: lat=50.620069, lon=4.615722, alt=99.0m, mode=3
INFO:gpsd-reader-rtk:GNSS Status: 2
INFO:gpsd-reader-rtk:Horizontal precision (EPH): 10.112
INFO:gpsd-reader-rtk:Vertical precision (EPV): 17.207
INFO:zed-camera-server:GNSS data received with timestamp: 1746556796.000s, lat/lon: 50.620069/4.615722
Latest image timestamp:  1746556796040503481 ns from Epoch.
Current timestamp:  1746556796125982301 ns from Epoch.
[2025-05-06 18:39:56 UTC][ZED][WARNING] The timestamp of the GNSS data you are attempting to ingest for [GeoTracking]  is different from the camera timestamp. Timestamp difference: -1494893472 ms.
INFO:zed-camera-server:GNSS data ingested with status: INVALID TIMESTAMP
WARNING:zed-camera-server:Fusion ingest error: INVALID TIMESTAMP
ZED Timestamp: 1746556796126 ms, GNSS Timestamp: 1746556796000 ms, Difference: 126 ms
Image Timestamp:  1746556796040

Hello @nathanL,
It seems to be an error related to timestamp unit. Could you print current_gnss_data.ts in micro_seconds to confirm it ?

Regards,
Tanguy

Hi @TanguyHardelin,

Thank you for your reply.

I have added a log as follows :

And this is what I get :

The timestamp in microseconds seems fine to me…

Some additional information:

I have logged the value of sl.get_current_timestamp() as well, and there is no difference either.

Where does the ingest_gnss_data() get the timestamps from ?

I’ve checked zed_camera.get_timestamp(sl.TIME_REFERENCE.IMAGE), zed_camera.get_timestamp(sl.TIME_REFERENCE.CURRENT), input_gnss.ts and sl.get_current_timestamp() and they all have reasonable values.

I updated my zed sdk to version 5 and I have the same issue. As stated before, I had no timestamp issue in version 4.1.3, only a covariance one, which to me seems less severe but I don’t know which error is treated first in the sdk…

From what I understand, the camera timestamp treated by the fusion is 11 days in the future from now (-997924472 ms). At the time of posting, it was 17 days (-1494893472 ms). So the “camera” timestamp used by the fusion is a fixed value in the future which corresponds to :
Sat May 24 2025 01:54:49 GMT+0000 (1748051689472 ms).

Hello @nathanL,
Could you please share SVO2 with the GNSS data so that we can reproduce the issue? It might be related to another problem that is currently being addressed. If that is the case, it will be fixed in the next release.

Regards,
Tanguy

Hi @TanguyHardelin

Thank you for the follow up. Here is the SVO2:
ZED_SN37668145_14-05-2025_20-18-40.svo2 (2.6 MB)

I’ve used the recording and playback samples and I had the same error. Interestingly, I’ve also had issues before I could run them.

First issue (recording sample) :

Second issue (playback sample)

I’ve simply changed M_PI to math.pi and commented the imshow function so that I could send you the svo2 file, but now I’m thinking these issues might give a hint of why the “invalid timestamp” error happens ?

Also, when is the next release planned for ?
I want to make sure that it is not an issue with the current release as I don’t have much time and it is blocking me on other things…

@TanguyHardelin I went through the topics and this seems similar to my issue : “Global Localization Playback Mode - GNSS Ingest Error and Termination (Initial X not PSD) - #9 by karthikreddy157
They also have the “INVALID TIMESTAMP” error even though the actual difference is less than 4 seconds. The only difference with me is that the error doesn’t solve itself when switching from NEURAL to PERFORMANCE depth mode…