GPS timestampi​ng continousl​y sampled data

Question

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.

Answer 1

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.