PTP time conversion formula?
AnsweredI got PTP working with a Blackfly S GigE 5MP by enabling GevIEEE1588 with a Novatel CPT7 INS (master clock) but cannot figure out why there is a big time delta as reported by the timestamps (~18 seconds). Here are the two sample data output from ROS2, taken at very similar time. The Novatel does not have a GPS lock, so its time starts from GPS epoch.
Novatel:
gnss_week: 0
gnss_week_seconds: 5673.173168707156
Blackfly:
camera_time: 315970492.3631872
Using the calculator at https://www.andrews.edu/~tzs/timeconv/timeconvert.php to go from Novatel to Unix time I get 315970473.17316.
Diff: 315970473.17316 (Novatel) - 315970492.3631872 (Blackfly) = -19.19 seconds.
Using another calculator https://astroconverter.com/gpstime.html, to go from Blackfly Unix time to GPS seconds, 315970473 (Unix time) -> 5691 (GPS seconds)
Diff : 5691 - 5673.173168707156 = 17.82 seconds
Any help debugging this mystery is much appreciated!
-
Official comment
The camera itself does not do any calculation, the camera follows the IEEE1588 spec and has no concept about UTC time. That is purely on the master side when it sets it's PTP time. We simply follow the PTP time based on the PTP Epoch.
Your PTP master probably converts the UTC to PTP and it knows about the 37s offset from UTC to PTP. As the slave, the camera should just sync it's clock with PTP time provided by the master.
Do you have a comparison between the Master PTP clock and your system time and the camera time? I expect the master and the camera to have the same timestamp, which likely varies from the system/unix timestamp.
-
Hello Nghia,
One potential factor that could lead to this time difference is that both devices are not actually synchronized. For both device to properly sync, they have to support IEEE1588 protocol and must be in the same network. Here is KB article for more details on how this works: https://www.flir.com/discover/iis/machine-vision/precision-system-synchronization-with-the-ieee-1588-precision-time-protocol-ptp/
I have some questions to better understand possible cause of this issue:
- What is the topology of this network?
- Could you double check "Novatel CPT7 INS" as grand master clock support IEEE 1588 PTP protocol and/or connected via switch (similar to configuration in this link https://www.flir.com/discover/iis/machine-vision/precision-system-synchronization-with-the-ieee-1588-precision-time-protocol-ptp/)?
- How did you determine both devices are synchronized?
- What is the camera model and firmware version currently running in this camera?
Thanks,
Regards,
Ifeanyi
0 -
Hi,
1. The Novatel INS and Blackfly camera are both connected to a Netgear GS308EP PoE switch, which then connects to my laptop.
2. I've confirmed Novatel does support PTP (latest firmware). https://docs.novatel.com/OEM7/Content/Commands/PTPMODE.htm?TocPath=%7C%7CImportance%20of%20Antenna%20Selection%7C_____121
3. Here's a sample data from the ROS topic with PTP turned off on the Novatel.
Novatel: gnss_week_seconds: 116.215557202507
Blackfly: camera_time (seconds): 115.87346572800001
Now here's when I turned PTP on.
Novatel: gnss_week_seconds: 280.644900702934
Blackfly: camera_time (seconds): 315965100.00530326
There's a sudden jump in camera time stamp. The calculator says that timestamp is
Sun Jan 06 1980 00:05:00, which is in the ballpark of GPS epoch.
4. The camera is a Blackfly S BFS-PGE-50S5M running firmware version 2103.0.340.0
Nghia
0 -
Hello Nghia,
It is strange with this time jump. Please I have more questions to narrow this down:
- What is the IEEE 1588 Status node of the camera before and after turning ON PTP?
- Does camera IEEE 1588 Mode node configured as Automatic or Slave Only? I will recommend to configure it in Auto mode?
- Does this time difference drift over time or remain the same?
Thanks,
Ifeanyi
0 -
Hi,
1. Here's a screenshot with PTP off.
With PTP on.
In both sceenshots I clicked the Dataset Latch Execute button. What does this button actually do? I noticed the field "IEEE 1588 Status" does not change from Initializing. I guess this indicates an issue?
2. Camera mode is configured to Auto
3. I have not ran a long enough test to determine if there is a drift or not.
Nghia
0 -
Hello Nghia,
I am not sure how PTP was turned off, but the first screenshot shows camera PTP was still enabled (i.e checked). In that case, if there is no other (master) clock to negotiate with, camera IEEE1588 status would have changed to master after few seconds.
Dataset Latch command as the name implies allow user to latch current PTP camera status and retrieve it at any point in future. The "IEEE1588 Latch Status" shows camera was sync as slave. Therefore, "IEEE1588 Status" node is not showing the actual status of the camera clock. You may have to refresh the node to validate the status.
Please confirm if the clock difference drift over time and get back to us.
Thanks,
Ifeanyi
0 -
Hi,
I turned off PTP master on the Novatel side.
I can only confirm clock drift if they are apart far enough. I'm simply comparing messages as they arrive on the host and seeing how similar the timestamps are. So it's mostly eyeballing. What's the idea behind this test?
Nghia
0 -
Hello Nghia,
I would not recommend this approach for testing ptp synchronization.I would rather latch both timestamp at the same time and compare it. If both device are not synchronize, the timestamp is expected to drift overtime. Otherwise, I would double check the comparison approach.
Thanks,
Ifeanyi
0 -
Hi,
The time drift happens instantly when the devices are turned on and PTP is active. It's not something I have to wait.
I ran another test. I connected a Time Machine 2500C device (https://timemachinescorp.com/product/gps-ntpptp-network-time-server-10mz-output-tm2500/) with a GPS lock. The Blackfly picks up the GPS time. I then compared it to my system clock which is NTP sync. Now I would expect the time different to be less than a second or so. Instead I get
camera UTC: 2023-09-15 16:50:04.374641 sys UTC: 2023-09-15 16:49:27.411668 delta: 0:00:36.962973
camera UTC: 2023-09-15 16:50:04.407987 sys UTC: 2023-09-15 16:49:27.444695 delta: 0:00:36.963292
camera UTC: 2023-09-15 16:50:04.441332 sys UTC: 2023-09-15 16:49:27.478259 delta: 0:00:36.963073
camera UTC: 2023-09-15 16:50:04.474678 sys UTC: 2023-09-15 16:49:27.511364 delta: 0:00:36.963314
camera UTC: 2023-09-15 16:50:04.508024 sys UTC: 2023-09-15 16:49:27.545136 delta: 0:00:36.962888
camera UTC: 2023-09-15 16:50:04.541370 sys UTC: 2023-09-15 16:49:27.578254 delta: 0:00:36.963116
camera UTC: 2023-09-15 16:50:04.574716 sys UTC: 2023-09-15 16:49:27.673926 delta: 0:00:36.900790
camera UTC: 2023-09-15 16:50:04.608062 sys UTC: 2023-09-15 16:49:27.719213 delta: 0:00:36.888849
camera UTC: 2023-09-15 16:50:04.674753 sys UTC: 2023-09-15 16:49:27.720966 delta: 0:00:36.953787
camera UTC: 2023-09-15 16:50:04.708099 sys UTC: 2023-09-15 16:49:27.744808 delta: 0:00:36.963291The time diff is nearly 37, which seems far too large. The most plausible explanation I can find is https://en.wikipedia.org/wiki/Leap_second. There 37 seconds is mentioned. How does the Blackfly internally do its time conversion?
This is the Python code I use to do the time conversion
from datetime import datetime
time = msg.camera_time * 1e-9 # nano to sec
camera_utc = datetime.utcfromtimestamp(time)camera_time comes from the ROS message. The field is populated by the function Spinnaker::ChunkData::GetTimestamp().
Also confirmation my NTP is active
$ timedatectl
Local time: Fri 2023-09-15 09:47:41 PDT
Universal time: Fri 2023-09-15 16:47:41 UTC
RTC time: Fri 2023-09-15 16:47:41
Time zone: America/Los_Angeles (PDT, -0700)
System clock synchronized: yes
NTP service: active
RTC in local TZ: nNghia
0 -
Hello Nghia,
The 37 seconds makes sense as UTC time is different than standard unix time due to leap seconds.
As per https://www.johndcook.com/blog/2020/02/05/leap-seconds/, the current time difference between the two was 37 seconds in 2020. From https://en.wikipedia.org/wiki/Leap_second, there have been no new leap seconds added since 2020, so I believe that is the difference you are seeing.
I do not know why you were previously seeing an 18 second difference, but at least regarding your latest results, I believe this could help explain the difference if you are comparing the UTC time with the current system time.
The camera timestamp should pick up the timestamp from the GPS timestamp, I assume it uses UTC time compared to you reading the unix timestamp on your system?
0 -
Hi,
I did notice the Blackfly's timestamp was 37 seconds into the future. It would be nice if someone can confirm how exactly it's doing the calculation inside the hardware.
Nghia
0 -
I just had a closer look at https://en.wikipedia.org/wiki/Leap_second
The 37 seconds is derived from 10 + 27. The 27 is the introduced leap seconds currently and the 10 is a starting offset. Looking at the table from Wikipedia for leap seconds up to GPS epoch (1980-01-06) there were 9 leap seconds introduced. 10 + 9 = 19, which correlates with the values I got earlier.
The relevant snippet from the blogspot you posted
At the moment, TAI is 37 seconds ahead of UTC. There have been 27 leap seconds since leap seconds were first instituted, and TAI started out 10 seconds ahead.
Nghia
0 -
I haven't looked into outputting the Master PTP clock from my computer yet.
Is the Blackfly camera timestamp from the start or end of acquisition?
Nghia
0 -
The chunk data timestamp from a captured image should be the timestamp at the end of exposure.
If you are just latching the current timestamp on the camera though, it is the timestamp at the time you issued the latch command.
I hope that helps clarify the timestamps. Please let me know if I can clarify further.
0 -
Thanks for the info. I think I got everything I need to move forward!
0
Please sign in to leave a comment.
Comments
15 comments