cRio 9467 module....question/problem with converting PPS timestamp to UTC...

[J_Webster]

Hey

I have a program running on a cRio chassis with a 9467 GPS module.  I used the examples "NI 9467 Datalogging.lvproj" and "NI 9467 Getting Started.lvproj" as a guide.  The code I use to covert the PPS time from the GPS into UTC time is...

But when I run the program, the PPS UTC Timestamp displayed is local time, not UTC time (which should be 7 hours ahead of local time...

I fully expected (and need) to get the UTC time.  I must be missing something, but I don't know what.  Any help?

[RavensFan · Accepted solution]

Timestamps in LabVIEW are always inherently UTC under the hood.  What gets displayed in a timestamp indicator or control, by default, is the date/time for the local timezone (when LabVIEW started, if you change the timezone on the PC while it is running, the LV program won't know it until you restart LabVIEW.).

What you can do is change the display settings of the indicator so that it shows the value in UTC.  I'm not finding the exact format code in the LabVIEW help at the moment.  (Format codes seemed to be buried and spread among different pages.)

But I found this thread.  https://forums.ni.com/t5/LabVIEW/How-to-get-time-in-UTC-format/td-p/880345

If you show the advanced format for the indicator and put a carat ^ near the beginning. You'll get the UTC time.  So   %^<>T

[J_Webster]

that's what I love about labview, you learn something new every day

That worked.

Comparing the view to an online utc time display, it appears I'm off my a second now,  but maybe that's worth another post.

[RavensFan]

I'd say that could be caused by delays in the processing of network shared variables, perhaps on top of whatever processes calculated the GPS time.  Are you sure the Windows clock is accurate?

[J_Webster]

Hmmmm, I compared it to a couple of internet time servers (time.gov, www.timeanddate.com) and I seem to be close to a second behind both, and I'm a second behind my computer clock which gets set via .  Maybe there is a delay.  Would processing the network shared variables take that long?...that would surprise me

Maybe an interesting problem...how do I verify that my time is correct?

[RavensFan]

Possibly.  I've used network shared variables, but I've never needed to get precise timing on them.  Some people swear to never use them.

I don't know all the details behind how they work.  This link helps explain it.  https://www.ni.com/en-us/support/documentation/supplemental/06/using-the-labview-shared-variable.htm...

Since the transfer of data is a several step process through various services and buffers, I'm sure there is a delay at each step.  Whether they accumulate to a full second or not, I don't know.  Make sure that you don't have buffering enabled.  That may be causing a delay of an element if the situation is just right.

[J_Webster]

if there is just a delay in the display, then that's not an issue. However, my setup has a data acquisition loop running on the RT target, and the GPS running on the FPGA.  The data acquisition loop is programmed in daqmx.  My idea is to sync the loop with the gps so that it starts taking/logging data at the top of a second and timestamps the datafile it logs to with that time.  I would stream data for 15 min, or 30 min, then restart the process with a new file. That way I have manageable sized files with fairly accurate absolute times (I only need accuracy of a millisecond or two for now)

The way I communicate between the fpga gps and the rt program is with shared variables...I had assumed the latency there would be very small, but maybe I should rethink the whole thing?  What would be a better method of communicating the arrival of the PPS?  Do the whole thing in FPGA?