What does "Locked" status really mean in FPGA Timekeeper

[Matt_Dennie]

The help says, "FPGA Timekeeper locked is TRUE if the FPGA Timekeeper has locked on to and is tracking the given time reference."

That's not very specific. 

- The Timekeeper is only "tracking the given time reference" when "Sync Time.vi" is called by the code, right?  Otherwise isn't it just predicting time base on the FPGA clock cycle, and apparently some filtering, gain and interpolation?  That wouldn't really be tracking the time reference.

- Is the Timekeeper checking the interval at which Sync Time.vi is called?

- Is it comparing the offset of the two time values input to Sync Time.vi  to its internal prediction?

- Is it making some judgement after a series of Sync Time.vi calls (how many?) that it has figured out the relative variations between the time reference and the FPGA clock?  How does it make that judgement?

- If a long time passes between Sync Time.vi calls does it decide it has lost its lock?

- Does calling Time Synce too frequently or too infrequently contribute to not achieving locked status, or to losing it?

Thanks for the help!  I love the idea of the FPGA Timekeeper but I don't know how to interpret the lock.  I can get the offset from the time reference, but what I'd really love to know is the size of the error when calling Time Synce.vi.

[Matt_Dennie]

No one has any ideas?  Does anyone use the FPGA Timekeeper?  How do you evaluate the accuracy/reliability of the time it provides?

[j_bou]

Hello Matt_Dennie,

The article below indicates that when using the FPGA Timekeeper with NI-9467 hardware, you will be able to correlate absolute time with system events at an accuracy of around 100 ns.

How Do I Use the FPGA Timekeeper to Synchronize Data with the NI 9467 GPS Module?:

http://ae.natinst.com/public.nsf/web/searchinternal/efdc35727d4f2cc086257a0700693003?OpenDocument

FPGA Timekeeper 1.1b0 GetStatus.vi:

http://forums.ni.com/t5/LabVIEW/FPGA-Timekeeper-1-1b0-GetStatus-vi-Locked-indicator-never-goes/td-p/...

The example VI for FPGA Timekeeper explains (briefly) the process used for synchronization (Synchronize to GPS – cRIO.lvproj). 

j_bou

[xl600]

I'm very interested in this as well.  The timekeeper VIs are all password protected so there's no way to see how it works.  I would actually like to place it on an FPGA which uses a 100MHz default clock, but I can't since there's obviously something inside that relies on a 40MHz clock.

For quality, I just look at the offset.  I'm only synchronizing it to my controller's clock so I never see better than about 1us accuracy using a timed loop set at a high priority.

[kdevelle]

Hello,

I am interested as well to know more about the FPGA Timekeeper locked control really mean.

I have notice that when it went false, the timestamp of my data are not coherent anymore :

I am aquiring data at 2kHz, so I am suppose to have 500us between 2 samples. It happened sometime that the intervall between 2 samples is completly wrong when timekeeper is not locked. Usually I have one intervall of 160us and a bit latter 840us, so it looks like it compensates the error but I really need to keep 500us (+/-1 us is fine) between 2 samples

Does someone know how to keep timekeeper always locked?

Thanks

Kevin

[xl600]

That's an effect I haven't seen.  I don't collect data when it's not locked (Not by design, just the way I tend to collect data).  I've never seen the timekeeper go unlocked after going locked unless some major disturbance occurs.  Regardless, I've encoded the locked flag into my datastream so I can tell when timestamps can be trusted.  I also keep a separate free-running counter (1us) next to my timekeeper timestamp.  That will allow me to spot the effect you've seen and compensate over short sample periods if lock is ever temporarily lost.

[kdevelle]

Thank you for your response

I suspect that I get some timekeeper unlocked because of the NTP daemon running in background when it resynchronised

I have add a free running counter as you mention and it allows me to keep my time vector coherent even if I lost timekeeper