Skip to main content

PTP time conversion formula?

Answered

Comments

15 comments

  • Official comment
    TDY_Demos
    Community team
    Expert (Gold)

    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.

  • TDY_Ifeanyi
    Community team
    Great answers
    Expert (Gold)

    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:

    1. What is the topology of this network? 
    2. 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/)?
    3. How did you determine both devices are synchronized?
    4. What is the camera model and firmware version currently running in this camera?

    Thanks,

    Regards,

    Ifeanyi

    0
  • Nghia Ho

    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
  • TDY_Ifeanyi
    Community team
    Great answers
    Expert (Gold)

    Hello Nghia,

    It is strange with this time jump. Please I have more questions to narrow this down:

    1. What is the IEEE 1588 Status node of the camera before and after turning ON PTP?
    2. Does camera IEEE 1588 Mode node configured as Automatic or Slave Only? I will recommend to configure it in Auto mode?
    3. Does this time difference drift over time or remain the same?

    Thanks,

    Ifeanyi

    0
  • Nghia Ho

    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
  • TDY_Ifeanyi
    Community team
    Great answers
    Expert (Gold)

    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
  • Nghia Ho

    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
  • TDY_Ifeanyi
    Community team
    Great answers
    Expert (Gold)

    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
  • Nghia Ho

    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.963291

    The 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: n

     

    Nghia

    0
  • TDY_Demos
    Community team
    Expert (Gold)

    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
  • Nghia Ho

    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
  • Nghia Ho

    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
  • Nghia Ho

    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
  • TDY_Demos
    Community team
    Expert (Gold)

    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
  • Nghia Ho

    Thanks for the info. I think I got everything I need to move forward!

    0

Please sign in to leave a comment.

Powered by Zendesk