Specifying time source for RT Get Timestamp vi

[gregoryng]

In the help for the RT Get Timestamp vi, it says that it "Inserts a 64-bit timestamp value from a high-precision timing source into a preallocated array at an index value specified by iteration."

I've seen another thread that gives evidence that the source is the CPU's oscillator, and that it's at least 1 GHz, but I never saw this followed up and confirmed by any NI AEs as to what the source actually is.

I would like to additionally ask if it is possible to directly or indirectly make the source a high precision oscillator from a PXI card such as the 6602.  And if so, how?

I'd like to have some sort of specifications on what the nominal drift and jitter are for the timestamp.

[viScience]

What is your application?  I use the 6682 GPS timesync module which gives a cRIO sub millisecond timestamp accuracy.

[gregoryng]

No, millisecond accuracy is definitely not enough.  10 microsecond resolution jitter is absolute max according to one of our data specs. Tighter is better.

Besides jitter, we also have drift requirements (which I would have to look up) but it is at definitely at least as good as parts per million (probably more). 

I know that the 6602 card that we have satisfies these requirements, and we have that working and meeting our specs, I just wanted to see whether other methods for timestamping might meet our requirements.

Basically I think that what I am asking is whether it's possible to feed the tickcounter's oscillator with the high precision oscillator of the 6602 so that I can have its drift requirements and I don't have to do as much wiring to do clock divide + digital edge counts, etc.

[viScience]

I was told by NI that PXI chassis, each with their own 6682 modules, can achieve sub us sync accuracies over ethernet. 

[gregoryng]

Thanks for the input. 

Hopefully you'll forgive me if I'm a bit skeptical.  I am sure that their statement is accurate when properly qualified, but we have been burned several times by statements made by some NI sales engineers that are not sufficiently qualified with underlying assumptions.  

In any case, we are looking for signal-based synchronization, not time-based synchronization. So buying 6682s doesn't help our goals or our budget (we already have 6602s on hand).

Message Edited by gregoryng on 10-13-2009 03:27 PM

[viScience]

Not trying to get you to spend more money but I think the 6682 will do what you want...

http://zone.ni.com/devzone/cda/tut/p/id/9755

[gregoryng]

sachsm, I would like to respectfully ask you to stop posting suggestions on hardware solutions to my problem, as my question is fundamentally a software question about the Labview API, and I have already stated that the hardware we already have meets our timing requirements.

[viScience]

The forums are a record of public knowledge and may offer others the opportunity to get useful information pertaining to search queries such as

RT, high precision timing source, synchronization.

Sorry if my attempt to be helpful offended you, perhaps someone else may benefit from the information.

Message Edited by sachsm on 10-13-2009 08:41 PM

[George_P_Burdell]

Gregoryng-

Most of our controllers have a 1 GHz Timebase associated with their processor that is used for the LVRT Applications.  You can follow the procedure described in the forum you found to confirm. 

You can use your counter/timer board to obtain higher precision timing tasks associated with the DAQ tasks inside your PXI system.  This can also be used in place of the PXI backplane clock.  However, you cannot use it in place of the RTOS clock. 

[gregoryng]

Thanks Mike.  That makes sense, when you put it that way.