Updating PTP "first sample timestamp" without interrupting continuous sampling

[n7j]

I don't know if what I am asking for is possible. I'll first describe my goal, then rationale, then the request.

Goal:

Obtain a continuously sampled, uninterrupted stream of data over long periods of time (e.g., 50kHz on 8 analog input channels continuously for two weeks) with regularly updated PTP timestamps with a device like a cDAQ-8195 using the nidaqmx Python (or C) library.

Rationale:

I would like to use the cDAQ-8195 in the setting of a PTP aware network with other, non-NI acquisition devices that are transmitting their measurements stamped against PTP timestamps. The cDAQ-8195 will provide a PTP timestamp as the first sample timestamp for a task. However, this timestamp is only provided once. While this may be sufficient for short-running tasks, it is not ideal for long-running tasks because of oscillator clock skew across non-synchronized devices. Over hours, the oscillator clock will drift relative to the first sample PTP timestamp, and without additional PTP timestamps, the precision of the samples to the absolute PTP time on the network (and thus other device's timestamps) will fall. This can be alleviated by regularly updating the PTP timestamp to recalibrate the time of the sampled data. In an ideal world, this PTP updating would be done without any loss of samples.

Request:

I know how to do this by stopping and restarting the task. This is straightforward. It is not ideal because I lose data while the task is being stopped and restarted. Is there any way to perform this task restarting without losing any data so I can assemble a contiguous data stream with periodically updated PTP timestamps? Is there any way to use the wait for valid timestamp function or similar to achieve this?

Thank you for any guidance!

[n7j]

It was suggested by NI support that a retriggerable task may be a way to do this.

I would ideally like to do this purely in Python. There was a post some years back on how to set up a retriggerable task with external triggers, which seems to be on the right track.

Can I set up an internal counter to do this retriggering? Any idea how many samples I might lose if I'm acquiring at 50kHz?

[mcduff]

Your cDAQ can support a Time Sensitive Network (TSN), IEEE 802.1AS is a variant of PTP. Not sure if you have access to it. Theoretically, using a TSN should keep everything synchronized to the master clock without restarting your task. I have not used one yet, so I do not know from experience.

See the following whitepaper

[n7j]

Thank you for the reply,

While it is true that 802.1AS/PTP will keep the device's clock synced with the master, timestamps for samples are not reported on any regular basis besides the first sample timestamp for a task. This is the basis of the question. How might one get additional timestamps reported without restarting the task? It does not seem possible as far as I can tell.

[ZYOng]

---

@n7j wrote:

How might one get additional timestamps reported without restarting the task? It does not seem possible as far as I can tell.

---

Because it doesn't have to. Once you know the timestamp of the first sample, you can compute the timestamp of the remaining samples by simply adding the time interval to it.

[mcduff · Accepted solution]

---

@n7j wrote:

Thank you for the reply,

While it is true that 802.1AS/PTP will keep the device's clock synced with the master, timestamps for samples are not reported on any regular basis besides the first sample timestamp for a task. This is the basis of the question. How might one get additional timestamps reported without restarting the task? It does not seem possible as far as I can tell.

---

Since the sample clock is synced to the master clock, you should not need to record additional timestamps. The sample clock should be accurate. I have used a PXI chassis that was synced to the 10 MHz clock from a GPS. I had NI-Scope in Fetch forever mode, and even though I only got the timestamp for the first point, the sample clock stayed aligned to the GPS master clock. This was confirmed by testing the PPS from the GPS and seeing that they occurred on a second boundary without additional timestamps; I only used the dt from the sample clock.

The whole point of a TSN network is to keep the sample clock aligned to master clock so absolute timestamps can be inferred. If you think about it, what would be the use of a TSN network if only the first timestamp was accurate?

[n7j · Accepted solution]

Thank you for the response,

This was the key piece I was unaware of:

---

@mcduff wrote:
Since the sample clock is synced to the master clock, you should not need to record additional timestamps. The sample clock should be accurate. I have used a PXI chassis that was synced to the 10 MHz clock from a GPS.

---

This is very interesting. I was not aware this was possible. I was initially going to go down the route to see if I can use an analog/digital input to set the 10MHz trigger, but then your suggestion got me to read a bit more at the Multichasis Synchronization: Time-based synchronization of Analog Input C Series Modules. The key line in this document is in that multichasis synchronization section:

When the time-aware chassis share the same grand master, all clocks onboard the chassis are synchronized to this grand master. Thus, clocks across multiple chassis are synchronized to each other. This process is done automatically and without user input. Since each module in the chassis will default to using the chassis backplane clocks for generation or acquisition, clocks used by each module (master timebase, sample clock, and/or reference clock) will all be synchronized.

This is amazing. I had no idea this had been implemented so elegantly. The NI reps also did not communicate/understand this. You are completely correct that there is no need for additional timestamps since the underlying sample clock is continuously kept in sync with the master PTP clock. It is completely sufficient to acquire just a single timestamp and calculate the deltas per sample, with confidence that these samples will not drift over time. This is perfect and a much simpler solution than anything I was fearing.

[mcduff]

The biggest issue for me implementing a 802.1AS solution was finding 802.1AS capable equipment. Not all servers, gps clocks, etc are 802.1AS capable. Maybe the situation has improved since I last looked.

[n7j]

I agree, it's all about hardware support.

802.1AS is just PTP but at Ethernet level. These NI TSN systems support PTP as well, which is more relevant in modern networks. Importantly, linuxPTP supports both PTP and 802.1AS, so things are pretty easy to work with and make compatible when working with Linux systems. There are a growing number of hardware devices that directly support PTP now, which is the situation I am in. Integrating with that network is a key requirement of acquisition setups to make things relatively headache free when doing Ethernet-based sync.