Yes, this is expected. With the navigation rate set to 10Hz, the ZED will produce and output solutions every 100ms. The time of the solution will be 000, 100, 200 milliseconds etc..
If you want to capture / timestamp an “event”, you need to use the EXT_INT pin and the UBX-TIM-TM2 message. The TIM-TM2 message will contain the time of the most recent rising and falling edge EXT_INT events - with nanosecond resolution.
Understood — however, we’re expecting a random trigger or GNSS signal that provides timestamps accurate to three decimal places. Ideally, this would start at a point like .666 seconds and continue from there — e.g., .666, .766, .866, etc.
Do you have any insight into why the timestamps are consistently aligned to .100, .200, and so on? Why not more varied intervals like .121 or .221?
The precision down to the third decimal place is important in our case, as we’re working on a time-syncing process where the camera timestamp needs to be accurately aligned with GNSS time.
The UBX-NAV-PVT message and the NMEA GGA/RMC message contain the time and position of each solution. The GNSS is saying “At exactly H:M:S.900, my position was this Latitude and this Longitude”. If you know your camera frame was taken at exactly H:M:S.921, you can interpolate the position from the previous (.900) and next (.000) solutions.
How do you plan to synchronise the camera to GNSS? That’s the critical thing…
Triggering the camera shutter from the GNSS timing pulse output is one possibility.
Or, you could generate an interrupt on the GNSS EXT_INT pin when the camera frame starts to arrive. The TIM-TM2 message will give you the accurate time of that event - down to the nanosecond. You would need to manually calibrate out the delay between the image being recorded and the data starting to arrive.