GPS timestamping continously sampled data

[bertrik]

Hi all,

I'm working on an application that samples 32 analog and 5 digital signals at a fixed rate of 4 kHz and I'd like to accurately timestamp each sample using a GPS time reference.
The timestamp accuracy should be better than 120 us. The application is written in C/C++ and uses the DAQmx C API.

The hardware I have available is the following:
* PCI-6224 card (A/D with 32 analog channels, lots of digital I/O and 2 timer/counters)
* PCI-6602 card (8 timer/counters and a 80 MHz clock)
* TrueTime XL-AK (model 600-000) GPS time reference, with serial ASCII output, IRIG-B timecode output and PPS (pulse-per-second) output.
Unfortunately my GPS is not equiped with a 1 MHz or 10 MHz reference output. Also the IRIG-B output is not easily useable because it is AM modulated on top of a 1 kHz carrier (therefore not compatible with a digital input and all 32 analog inputs have already been allocated)

I plan to implement this application by doing all timing generation on the PCI-6602 and doing all sampling (analog/digital) on the PCI-6224. A pair of counters is configured to do GPS timestamping as demonstrated in the document in this thread:
http://forums.ni.com/ni/board/message?board.id=250&message.id=8560
By routing the same sample clock and digital edge start trigger to all blocks that sample data (analog or digital), the data from all measurement tasks would be synchronised to each other. This would result in 3 streams of parallel data: timestamp values (second + sub-second count), analog data (32 channels) and digital data (say 32 bits for each sample).

However I suspect that the counter arrangement from the thread mentioned earlier does not produce *buffered* timestamps. This would make it impossible to use it as I just described above. Is this correct?

Does anyone know another solution?

I've been thinking about the following alternatives:
1) Sample the PPS signal at a higher rate to more accurately find out where the first sample in the current second starts. Then the timestamp for each sample can be calculated as Tsample = Tpps + Tfirst_sample + N/F, where Tpps  = time (in seconds) of the last PPS pulse, Tfirst_sample = offset of first sample in the current second, N = sample number within the current second, F = sample frequency.
2) Same as above, but using buffered two-signal edge-separation measurement to get the offset between PPS and sample clock at even better accuracy.

[bertrik]

Perhaps I was introducing too many things at once.
Basically, my question is:

Can the counter arrangement shown in thread
http://forums.ni.com/ni/board/message?board.id=250&message.id=8560
be used to take buffered time stamps?

I'm asking this because I want to use it in that way, but the PCI-6602 suggests that this is not possible (there are no use cases where a linear encoder is used in buffered mode).
Thanks in advance.

[Kevin_Price]

I could only look at the doc, not the code, because my network PC is far from my LV PC.  As shown in the doc, the position measurement task IS buffered -- that's the purpose of the "Sample Clock."  You can expect to find a call to "DAQmx Timing.vi" in the code to implement buffered acquisition.

You definitely CAN use buffered mode for a linear encoder position measurement.  I configure most of my buffered encoder measurements (even with rotating shafts) this way and then read raw counts.  If I want to convert to degrees for a chart, I scale it myself.

(Aside: early testing when DAQmx first came out showed some kinda strange treatment of some of the angular encoder inputs as I played around with initial counts, pulses per rev, and X1,X2,X4 decode modes.  It didn't act like I expected, and I couldn't even figure out how to predict exactly what it would do.  Was initial count a scaled value or not?  How would it interact with the X1,X2,X4 setting?  Would it round to the nearest discrete angle based on integer multiples of 360/ppr?   I really haven't gone back to give it a good workout in later versions of DAQmx because I'm content dealing with the data in raw counts.)

-Kevin P.

[bertrik]

Kevin, thanks for your reply. I haven't looked at the .vi myself yet, because I don't have LabView (and I am not very familiar with it anyway).
One other question:

What counter input is the "Sample Clock Source" in the drawing?

I guess it's either SRC or GATE.
The name suggests that it is the counter SRC input. In that case I'll have to route the A signal to another PFI terminal since the A and SRC inputs share a terminal in the default configuration. I can also imagine that "Sample Clock Source" is connected to the counter GATE input (in many other use cases the GATE input causes the current count to be buffered). In this case, I think I need to reroute the Z signal to another PFI terminal since the GATE and Z inputs share a terminal in the default configuration.

[Kevin_Price]

Typically, (and sometimes necessarily), a sample clock signal used for counter measurements would be connected to a counter GATE pin.  For the specific case of "encoder" measurement on the 6602, the Z-index signal must be physically wired to the counter's default GATE pin, so the sampling clock signal would need to be physically wired to the GATE pin of a different counter.  Having wired the sample clock signal to a single GATE pin, both of the 2 counter measurement tasks can programmatically specify that their sampling clocks come from that single pin.

The M-series board offers more flexibility in programmatic PFI signal routing than the 6602.  You can pretty much wire to any PFI pin and then programmatically specify which pin to use as Input (SOURCE) and which as Sample Clock (GATE).  I still typically adopt the convention of using default pins whenever possible.

The terminology for counters can be a bit confusing.  In my opinion, the old traditional NI-DAQ was a little more cryptic at first glance but much more consistent overall.  The new DAQmx terminology tries to hide implementation details more, but in the process generates multiple aliases to the same pin assignment, depending on how you're using it.

A quick rundown.  A SOURCE edge causes the count register to increment.  Under DAQmx, this may be referenced as an "Input" or a "Timebase" terminal, depending on the measurement mode.  When counting edges, it's an Input.  When measuring period or frequency, it's a Timebase.  Whatever it's called, the natural behavior at the counter hardware is to increment a count register on each active edge.

A GATE edge can cause a count value to be stored in the acquisition buffer.  Under DAQmx, it may be referenced as a "Sample Clock" source when counting edges.  When measuring period or frequency it may be a "Channel" or an "Input terminal."  Again, whatever it's called, the behavior at the board level is to store an instantaneous count value into the data acq buffer on each active edge.

[There are exceptions, of course.  The GATE pin is also used for "Pause Triggering", and can also be used to reset the count register for position measurement with Z-indexing enabled.  And so on.]

-Kevin P.