DAQmx Timing VI - Problem With External Clock Source

[szekany]

Hi,

I'm using a M-Series board (6254) with LabView 8 to develop an analog data acquisition program. I'm using the DAQmx VI set (Start Task, Timing, Trigger, AI Read) to read 8 channels of analog data. My project requires the use of an external triggering clock for data collection, because we're trying to synchronize three separate systems within about one millisecond over the course of several hours. The external triggering clock runs at 23.976 kHz (this isn't arbitrary, it's for synchronization with NTSC TV).

Here's the problem - I set the DAQmx Timing VI to continuously sample with triggers from an external clock source. The VI requires the "maximum expected rate of the clock" to be specified, so I specify 23,976 Hz. Despite this, when I analyze the data and synchronize with the other systems we're running, it's clear the data has been sampled at 24,000 Hz. I've tried setting the Timing VI Rate option to 24,000 Hz and some really high values, like 100,000 Hz. Every time, I get 24,000 Hz data.

I'm rather perplexed. I’m sure the external clock is running at the correct frequency, because I’ve verified it several different ways. I know there's some limitations on timing of the board with the onboard counters and the frequencies they can match, but I had thought that was all avoided by using an external clock. Perhaps I was mistaken? Still, even that doesn't make sense, because the information I can find indicates the onboard counters run at 20 MHz and 100 kHz; and 24 kHz isn't a divisor of either.

If anybody can help me make sense out of this situation, I'd greatly appreciate. Let me know if you need more details.

[shoneill]

First of all, you're mixing up KHz and Hz a lot in your text.  I assume you want to measure 23.976 Hz.

How do you ssee that the data is sampled at 24Hz?  Based on what information?

Can you post some code or a picture of the diagram (no BMP please)?

Shane.

[szekany]

I don't believe I mixed up any kHz and Hz designations in my previous post. A kHz is 1000 Hz, yes? Like I said, I need to record at 23,976 Hz / 23.976 KHz but I'm getting data at 24,000 Hz / 24 KHz.

I know the data is being recorded at 24,000 Hz because I have verified it with another program running off the same external clock.

I'm happy to post the code, but it's a very large program, so I'll have to trim it down some before posting.

Message Edited by szekany on 03-20-2007 07:15 AM

[shoneill]

I see now that your Hz and kHz values are correct, but please bear in mind it's asking a lot for people to be able to determine the fact that you're interchanging units like this on purpose.  The fact that many countries use commas as decimal points makes things more difficult.  After a while, I start interpreting commas and decimal points as the same thing.  Even aside from this, it's generally advisable not to mix up units when not absolutely neccessary.  It's a basic rule of scientific writing.

In fact, just leave out the commas as thousand-separators.  They just confuse things.  Here in Switzerland, 24,000 is the same as 24.  24'000 is 24 thousand.  Please take note of this.

"I know the data is being recorded at 24000 Hz because I have verified it with another program running off the same external clock."

Your statement is very vague.  Versus which timescale are you comparing?  Which is your primary and secondary timescale?  What are you comparing with what?

Shane.

[szekany]

Thanks for your help. Sorry for the confusion. My statement was actually somewhat intentionally vague, as I didn't want to have to go into details about the setup. However, since you asked...

I work for a research lab that records neural data. We're trying to replace an older, specialized DAQ program with a newer, multipurpose one written in LabVIEW. When we record data, we have three systems running simultaneously: the DAQ program, a video recorder (with VTC time code encoded on each frame), and a control program. The control program resets the clock, and records the time of "events" in our experiments, like lights going on an off, sounds being made, etc. All three of these systems (the control program, the video recorder, and the DAQ program) are connected to an external clock to ensure they remain in sync. This clock is an Aardvark Aardsync II, running at 47952 Hz. We use this time for the video (NTSC video at 29.97 FPS) and the control program. We divide down the Aardsync output by two using a "flip-flop" chip on a PC board for input into the DAQ program. Because we're recording neural data, all three systems have to be synchronized to within a millisecond of each other. We test this synchronization by having the control program send out a signal to the DAQ program at certain timed intervals, then we compare the data of both to see if it matches. This process works fine on the old DAQ program, but doesn't work with my LabVIEW DAQ program using the setup described in the first post. Since the difference between recording 23976 Hz and 24000 Hz amounts to about 1 millisecond of "slippage" every second, it's very easy for me to tell that the systems are not synchronized after running for several minutes.

In other words, this process has worked fine for years with an older DAQ program, but running the DAQ task under LabVIEW doesn't work correctly, and I'm trying to understand whether it's because I'm doing something wrong or if I've unknowingly bumped up into a LabVIEW limitation of some kind.

[Kevin_Price]

First off, I don't think you're up against a true limitation.  I'm not real sure where the problem is coming from, but I strongly suspect it's possible to resolve.

Just a shot in the somewhat dark:  Are you by any chance reading your data as waveforms with embedded t0 and dt values?

I may be paranoid, but to this day I still don't completely trust timing information in waveform datatypes, ESPECIALLY when using an external clock.  I'm pretty sure that years back I found that even using an internal clock, the dt value was derived from the requested sample rate rather than the slightly different sample rate that was actually possible.  Maybe that's been fixed now, but I don't see how DAQmx can be expected to guess very well about external sampling clocks.  I know there are issues about t0's representing a system time at the start of the task, even if the external clock doesn't start for several more hours.

All that to say that I reflexively do my reads in array format.  When I need to call analysis functions expecting a waveform, I create a t0 / dt on the spot using a method I control.  Soooooooo....

Could your timing comparison be influenced by the 'dt' value in waveform data?  There really is nothing to tie that 'dt' value to any true timing properties of your external clock.  I personally wouldn't trust it at all.  Admittedly, I've got no idea where a round figure like 24000 might come from when it's not an integer divisor of the internal clock.  Still, I'd have to echo Shane's question -- exactly how have you verified the actual sampling rate to be 24000 Hz when driven by an external clock that is "known" / verified to be 23976 Hz.  I've never heard of actual DAQ hardware messing with external clock timing that way, so I first look elsewhere for the anomaly.

-Kevin P.

[shoneill]

I think you're going to have to post at least SOME code for us to find this problem.

There are too many possibilities which can't be eliminated without have some idea how the code is written.

So what you're saying is that the LabVIEW program should record the counter value at the occurrence of certain external signals, and that these values are coming out wrong.  Is that right?

That sounds kind of wierd, because you're basically using the DAQ hardware to do the counting and monitoring.......

Can you post a PNG of your block diagram, even just a bit of it?

Shane.

To Kevin,  That's a good catch.  Not something I thought of.  I personally avoid waveforms like the plague.

Message Edited by shoneill on 03-20-2007 05:26 PM

[szekany]

The data is being read as I-16 values in a 1D array. It then gets written directly to disk and later analyzed using Plexon Offline Sorter (http://plexoninc.com/products/offlinesorter.html).

I've been working from home all morning, but I'll post the relevant part of the code when I go into work this afternoon. I'm also going to play around with the external clock settings and see if I get different results at different frequencies. I'll post the results here when I do.

[szekany]

OK, here's the subroutine in question. I'm posting it as a LabVIEW 8 file, let me know if you would prefer an image.

[Kevin_Price]

I don't have a board here for testing, but my best guess at the problem is that the string "PFI0" may not be enough to specify the source of the external sample clock.  I'm not sure about that though, I only know that the DAQmx terminal constants that are created when you right-click on the input and select "Create-->Constant" also include a Device identifier such as "/Dev1/PFI0".

If indeed the string "PFI0" isn't enough, then the DAQmx Timing vi may revert to generating its own internal clock, which could end up needing to choose an integer divisor of the max 1.25 MHz sample rate.  The one closest to your desired 23976 would be 24038.  The next closest is 23584.

I marked up your example a bit with a couple recommendations.  Try them out and see if you don't get the task to track the external clock properly.  A general tip: make use of the ability to right-click on input terminals to create constants or controls -- then you'll get the correct datatype for sure. 

-Kevin P.

--- Edit: oops, added attachment

Message Edited by Kevin Price on 03-20-2007 10:27 PM