cRIO 1588 Time conversion from TAI to Local Time

[viScience]

I have a cRIO that is a 1588 slave to a PXI based 6682 GPS receiver and 1588 master.  I have observed that the cRIO timestamps

on NSV's are around +34s off from the correct local time.  Upon investigation I learned that the NI-Sync driver uses TAI (International Atomic Time)

which has 15s offset from GPS time.  Furthermore UTC time has a 19s offset from TAI time.  I suppose this accounts for the  34s offset.  Does this mean that

I have to figure out when a new leap second has occured and adjust my offset?  I was hoping that the NI-SYNC driver would take care of that issue.

[AlejandroZ]

Hi.

Indeed, the 34s offset comes from the fact that UTC is 34s behind TAI, which is what the PXI-6682 uses.  Actually, TAI is the timescale the IEEE1588  standard calls for since the lack of leap seconds removes all the complications that leap seconds would introduce.

The offset between UTC and TAI is part of the GPS transmission, to a PXI-6682 sync'ed to GPS would be able to know what that offset is.  It is available through the NI Sync property 'UTC Offset'.  Also, if that PXI-6682 is functioning as 1588 Master, it sends that information as part of the 1588 Ethernet packets.  So the slave also has that information, and it is also accessible by reading the same NI Sync property.

Just be aware that if you are adjusting your timestamps using that, when a leap second is introduced you might get timestamps for the same time for events that were actually not at the same time; or even worse, the timestamps you get might have their chronological order reversed from the real order of events.  That is part of the reason why 1588 and the PXI-6682 use TAI.

Hope this helps.

AlejandroZ

[viScience]

Ok, I follow what you are saying but something still does not add up.  On my system the UTC offset is 15s, which appears to be

the offset from UTC to GPS not UTC to TAI which is 34s.  According to an NI app note:

"TAI time is not adjusted for leap seconds and is ahead of GPS time by 19 seconds".  The question is how do I keep track of this 19s offset as

it changes due to additional leap seconds?

Also I would like to point out a flaw in NI's logic that TAI convers the most use cases.  I would say that one of NI's biggest use cases would be large scale distributed DAQ systems. 

These systems may be large but they generally are within a local time zone.  Commonly, you want the timestamps of such systems to correspond to local time.

[AlejandroZ]

Hi,

I just looked into it, and you are right, the property currently returns the offset between GPS and UTC (which can vary), instead of the offset between UTC and the 6682's timescale, which is TAI, which is what you are really interested in.

NI R&D is aware of this issue, and I am told it will be fixed in the next release of the NI Sync software.

In the mean time an easy work around is to add 19 to the value the property returns, since the 19s offset between TAI and GPS time is constant.

Unfortunately, if you do this and then upgrade to NI Sync 3.2, where the issue is fixed, you'll have a 19s offset again!  Just something to be aware of.

Regards,

AlejandroZ