5922 phase coherent continuous acq

[dansch]

Hello Tim,

I am not sure what you mean that the timestamps are a whole number of samples off? The absolute intitial x values returned by the fetch function are from a free-running counter on each board. The values are almost guaranteed to be different, and really are not meant to be compared relatively. What you can do is fetch a single sample or something to that affect at the beginning of the acquisition to determine the absolute initial x value of each digitizer, and determine what their offset is (the difference between the two in counts of the absolute timestamp value, from the 100 MHz free-running counter).

One application for digitizers is to measure the precise time between events by using two boards (one board for each trigger event) and comparing their timestamps. The method of comparing the absolute timestamps together at the beginning is necessary to determine the offset between the boards, and then once the events actually occur, we can compare the difference in the absolute timestamps, with the offset in mind, to determine the precise time between when the events occurred. Further precision is gained in determining the actual trigger time by looking at the relative initial x value, which has sub-sample period resolution thanks to the time-to-digital converter. An example program using this method (called a "Time of Flight" measurement) can be found on this page.

I hope this helps, please let me know if you have any additional details or concerns.

[TimS.]

In the modified version of your example that I attached in my previous post, if you compare the timestamps returned (in the WDT fetch) and multiply by the current sample rate, this gives the difference in samples between the two returned timestamps. However, based on what you are saying, if the timestamps returned in the fetch function are based on free running 100MHz clocks in each board they won't be the same. Just to reiterate so I understand it correctly; Even though I've synchronized my digitizers in phase using TClk and the same 10MHz ref clock, the timestamps returned for an aligned sample will not be the same because they have their own 100MHz free-running clocks that are not synchronized?

If that is the case then I think I will have to implement some sort of comparison between the absolute timestamps and align one of the digitizers with the others time from that point on.

Thank you,

Tim S.

[dansch]

Hi Tim,

The timestamps are based off the oscillator on each board. For the 5922, a 120 MHz oscillator is used (that is the oscillator that is sent to the ADC which then samples the data based on the resolution requested). [For the 5122 and some other similar boards, it is based on a 100 MHz clock that I mentioned in my previous post... sorry for the confusion.]

Even despite synchronizing the clocks on each board, which is what is being done with T-Clk, you are correct that the timestamps will be different based on a constant offset between the two boards, which is a result of when the board was first initialized in the system and the counter began running. Currently, there is no way to reset/initialize the boards such that the timestamps will be identical. This is why I recommended a similar approach to the example program I posted in which the offset between the boards' absolute timestamp values is measured. However, the clocks themselves are synchronized, so the timestamp counts will occur at the same time (the counts will just be off because they started at different times).

Also keep in mind that the timestamp values are only valid for a given session and will change/reset when the board is powered off or reset in any way. Also, it is possible, given a long enough period of time, that the timestamp counter will roll over, but since a 64-bit counter is used on this board, that time period is something around 5000 years and therefore not a concern.

Regards,

[TimS.]

Just an update:

I've resolved the issues using a combination of the TClk code and some Timestamp sharing. As mentioned previously, the niTClk code was used to align the samples for each set of digitizers that I needed to be synchronized. For the timestamp issue that I was having, I now send the "SW Start Trigger" on the master digitizer and then proceed to read one sample from each of the digitizers in a set. I use this more as a debugging step to see what the difference in timestamps is between digitizers. The "master" digitizer's timestamp is used as the initial timestamp for all digitizers and for every fetch I just add to the initial timestamp via; T(n) = T(0) + (NumSamples/Fs)*Acq#. A shift register is used with a counter to keep track of the Acq# that I'm on and I've printed out debug for ~50 Acq blocks to verify that the calculated timestamps are correct based on the amount of time that should elapse for a given block size at my particular sample rate.

So, my downstream phase coherent dependent processes are happy due to TClk and the downstream logging/reporting/indexing processes are happy since the timestamps for each independent stream of digitized data are now the same.

Thank you very much for the help,

Tim S.