New to timesync - need some guidance

[CaseyH_UI]

Hi all,

I'm using a cRIO-9045 chassis as a headless data acquisition system on a roving vehicle. Data are being acquired with DAQmx (real time), X-Net, and NI-VISA. The data collected over RS-232 with NI-VISA are from a GPS unit, and they already contain UTC timestamps derived from GPS timing packets. I need to ensure that the CAN and analog waveforms are timestamped with a consistent absolute time.

X-Net, in particular, synchronizes its own timestamp to the RT system clock during session creation. For this reason, I think my best approach is to synchronize my RT system time to UTC using a GPS reference - prior to opening sessions on any hardware resources.

I am using a third party GPS module (SEA 9405), which effectively works as a drop-in replacement for the 9467 - with some small changes in the I/O property nodes.

It seems to me that this should be achievable. However, I am waiting on a driver update for the SEA 9405 to actually use it, so I haven't had an opportunity to test my theory. It would be very helpful if I could get some feedback on whether my planned approach is correct.

Here's my plan:

1. On the FPGA, I use the Timekeeper library. I synchronize the FPGA clock using the GPS PPS as a timing source. I send an updated FPGA time to the front panel on every loop, along with an indicator for the 'locked' status of the FPGA timekeeper.

2. On the RT target, I create read nodes to the FPGA VI. Wait for the 'locked' indicator to signal a GPS time fix. Read the latest FPGA time and the current RT system time in the same frame. Use the 'FPGA Time to Labview Time.vi' to get a UTC timestamp.

3. Feed both timestamps into 'NiTimeSyncAdjustTime.vi' from the Custom Time Reference plugin for NI Timesync.

I think I can get away with doing this only once (or for a handful of loops to achieve convergence) prior to starting my acquisition/logging VI.

Is this the right approach? 

Edit: I'm having trouble getting the 'NiTimeSyncAdjustTime' VI to work in LV2018. Alternatively, could I use another method to programatically set the RT clock and/or system clock?

[RossH · Accepted solution]

I don't think that approach is going to work.  The Custom Time Reference stuff you are using only works on VxWorks and PharLAP controllers, and the cRIO-9045 is a LinuxRT controller.  You might try using "Set Time.vi" that ships with RT.

[CaseyH_UI]

Thanks - I've been gradually headed toward the same conclusion.

The "Set Time.vi" sets the OS time, correct? If my understanding is correct, the OS time is incremented using the RT clock, and so should remain fairly stable / minimal drift over short periods of time. Each of my acquisitions should be on the order of 5-10 minutes, so drift isn't a big concern if that's the case.

[RossH]

Yes, it will set the OS time.  The RTC on that controller is about 200 ppm, so if that amount of drift over 5-10 minutes doesn't add up to a significant number for you I think you're going to be successful. That adds up to 0.12 seconds of drift over 10 minutes in the absolute worst case, but I suspect you are actually going to see much less drift than that.  FYI, I wouldn't put that "Set Time.vi" inside the loop if determinism is something you care about.  I suspect it's a very non-deterministic operation.

[CaseyH_UI]

Thanks - more good insight.

I'm not planning on putting it inside of any regularly-executed loops - though all of my acquisition is buffered using onboard clocks for the respective devices, so determinism isn't a huge concern.

What I will probably try to do is update the OS clock once when the VI is executed, and then again whenever I throw the software trigger to begin a new acquisition. That way, when each API (DAQmx, X-Net, VISA) is first invoked, it will see a recently-updated system time. From there, each generates timestamps using their respective module clocks, as I understand it. I'd realistically be updating the OS time once every half hour or so, and only between acquisitions, when all tasks are either suspended or cleared.

On reflection, I suppose that my drift would then be a function of my modules' on-board clocks. I can probably try to force modules to use a shared timebase to eliminate inter-device drift, but I'm not sure how well that would work with the mixed APIs. I'll probably head over and bug the DAQmx and XNet forum boards now for more details on when timestamps are queried.

Thanks for the help!