cRIO-9068 time synchronization and data timestamping - the Big Picture

[hshane]

I'm working with a number of cRIO-9068 chassis that are distributed over a large physical area. I wish to timestamp data acquired be these chassis with microsecond resolution and relative accuracy. The various documents that I've run across hint at how this might be accomplished but none of them really describe the overall architecture for synchronization of chassis clocks over a network and acquisition of the local clocks for the purpose of data timestamping. Is there a document that addresses this topic?

[scotia673]

What documentation have you already looked through? It might be helpful to have a point of reference to get a sense of what you're looking for.

[hshane]

http://www.ni.com/pdf/manuals/376007a.pdf:

Using the Internal Real-Time Clock

The system clock of the cRIO-9068 is synchronized with the internal high-precision real-time clock at startup. This synchronization provides timestamp data to the controller. You can also use the internal real-time clock to correct drift of the system clock. Refer to the Internal Real-Time Clock specification in the Specifications section for the accuracy specifications of the real-time clock.

What are the "system clock" and "real-time clock"? How are they related? How does the synchronization provide timestamp data to the cRIO-9068 controller? How does the internal real-time clock correct drift of the system clock?

---

http://www.ni.com/pdf/manuals/373185a.pdf:

No theory of operation whatsoever.

Note: https://forums.ni.com/t5/LabVIEW/cRIO-9068-amp-NI-TimeSync/td-p/2838178 suggests that NI-TimeSync may not be available for the cRIO-9068:

Currently NI-TimeSync 1.3 is not supported on Linux RT. This is something that's in the works but there is no ETA.

[scotia673]

The system clock is the clock maintained in the operating system while the RT clock is the clock time actually stored on the hardware. http://digital.ni.com/public.nsf/allkb/9DCFB7C0EB06CA9786257440006182E2

Also, NI-TimeSync 1.3 is quite old. Is there a reason you're using 1.3? Version 14.5 should work with Linux RT: http://www.ni.com/download/ni-timesync-14.5/5146/en/

[hshane]

Actually, I'm not using anything yet. I'm trying to figure out what I should be using and the referenced forum posting was just one of the few items that I ran across on this topic. I searched around the NI site a little more for "NI-TimeSync" and found this article, which moves me a few steps closer to understanding the big picture:

http://www.ni.com/white-paper/11466/en/

[scotia673]

Sure! So is there anything in particular you're looking to know that isn't covered in the white paper you linked?

[hshane]

- What are the Nanosecond Engine performance parameters? What is the period of a clock tick? What is the repeatability? What is the time-of-day accuracy relative to network time as communicated either by IEEE 1588 or SNTP?

- If I use a Timed Loop structure, what sort of execution timing jitter should I expect? For example, if I perform an analog/digital conversion on an analog input module at a 1 ksample/rate, I would expect the sample interval to be 1 msec +/- x. What is the value of x?

- When working with NI platforms that include an FPGA, e.g. cRIO-9068, where the timing of activity such as A/D conversion is controlled by the FPGA, what is the relationship between the Nanosecond Engine and the FPGA? Again, in the A/D conversion scenario, what execution timing jitter should I expect?

[scotia673]

I don't think we have documentation available that would have those details as the level of determinism available is generally sufficient for most applications but the following document might answer some of your questions:

http://zone.ni.com/reference/en-XX/help/370622K-01/lvrtbestpractices/rt_time_budgeting/

What are you working on developing?

[smithd]

1-The RT and FPGA clock accuracies are spec'd out in the manuals, pg 20 in the one you linked. Its 5 PPM. Other controllers are less precise, I think the normal spec is 200 ppm. I can't recall for sure, but I believe the FPGA 40 MHz clock is also 200 ppm.

For cRIO, 1588 is implemented in sw meaning accuracy is on the order of 1 ms. I don't remember where I found the source but heres another https://decibel.ni.com/content/message/83514#83514

2-You have to measure the timed loop yourself based on your specific code. On the RT utilities palette you'll find a set of functions for doing just that (and an example in the example finder). 

Broadly speaking I've seen the timed loop on a 9068 able to hit somewhere between 2 and 3 kHz and jitter is on the order of 10s of usec -- but this was with 2013, when linux rt was first released. It may be better now. If its important you can also dedicate a block of code to a single core and just poll as fast as possible without sleeping. This will probably give you higher rates and lower (absolute) jitter but again I can't say for sure.

3-If you use scan engine, the nanosecond engine drives the scan clock which if I remember correctly triggers the scan. But if you want a high level of accuracy you'd probably want to go fpga-only. As such jitter will depend on the accuracy of the clock, and there are multiple varieties of clock. DSA modules have an internal clock. SAR modules you depend on the accuracy of the 40 MHz clock. I'd take a look at section 3, chapter 6 here: http://www.ni.com/compactriodevguide/

I'd also generally recommend:

http://www.ni.com/tutorial/9735/en/

http://digital.ni.com/public.nsf/allkb/C1DCC95927F9C4CD86257526006FA720

To directly give you a 'big picture' answer. If you have to use cRIO and it has to be over large distances and you want a high level of synchronization, I only know of two core options, the 9467 and 9469. The 9469 uses ethernet cable (meaning 100 m per hop) to synchronize all DSA modules in a set of chassis.This makes sure that for all chassis T0 and dT are the same, but does not tell you what T0, T1, etc. are exactly. The 9467 is GPS meaning you can put it over longer distances but are limited to open areas where you can get a signal. The GPS provides an exact time in ns and a pps trigger. You can use these tools in conjunction with the FPGA timekeeper (separate download, start here http://digital.ni.com/public.nsf/allkb/EFDC35727D4F2CC086257A0700693003) to set a start time for all chassis and then use the GPS/timekeeper time to trigger the SAR A/D conversion making it more accurate. Since DSA modules have their own clock you can still timestamp data when it arrives but can't control the convert clock.