Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Analog input - Ext clock of 768khz cause unreal measurments

Hi All,

I've problem acquiring Analog voltage of 100khz, with external clock from my system at rate of 768khz.
The DAQ I'm using is PXI-6259, which can acquire up to 1.25Ms/s, and after I acquired 1 sec with sample rate of 768kHz, i got some unreal frequencies of 32kHz x N (when N is integer). How ever when I set the DAQ to use his internal clock (i guess the 20MHz) its work fine.

I have few questions:
1. What is the best relation between the real sample rate of my external clock  , and the parameter i choose in the DAQ to acquire with?
2. If my DAQ can acquire up to 1.25MHz, does it means that i can connect ext clock only up to 1.25MHz?

Thank,
Liron
0 Kudos
Message 1 of 5
(3,492 Views)
When you say you acquire at 768khz, you mean hardware triggered by the external clock, right?

Try setting the acquisition rate higher so that one acquisition is slightly faster than a cycle of your external clock...

If you connect an external clock, your DAQ rate needs to be at least slightly faster than this.  I would recommend setting the DAQ acquisition frequency to 1MHz, and see what happens.

Bearing in mind I've never performed a external-triggered Acquisition before in my life......

Shane.
Using LV 6.1 and 8.2.1 on W2k (SP4) and WXP (SP2)
0 Kudos
Message 2 of 5
(3,486 Views)

Sounds like you get frequency artifacts from your external sampling clock but not from the board's internal clock, right?

How constant is the external clock?  How is it being generated?  Can you vary its frequency?  If so, do the artifacts disappear, shift proportionally, or stay right at 32 kHz.

I notice that the 768 kHz external clock is an integer multiple of the 32 kHz artifact.  I would be pretty suspicious of such a "coincidence," and work hard to rule out irregularities in the external clock before moving down my list of suspects.

-Kevin P.

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 3 of 5
(3,478 Views)
Sorry for the delay answering back, and 10x Shane & kevin for the quick response.

However, I got still this weird problem.
Regarding the external clock, there is three places when I could use an external clock for acquiring my data.
1. Task Triggering and I assume that its for starting the Task.
2. Reference Trigger and i really don't have a clue whats his purpose.
3. As part of Task Timing - "Advanced Clock Setting"  <- The one I am using to specifiy my Ext Clock.
In that "Clock Source" option, I have few option that i really don't know where they are come from, such as 20MHz/80MHzTimebase & 10MHzRefClock.  What is the different between the DAQ Onboard clock and those clocks? and if I choose for example 20MHzTimebase, what is the Maximum sample rate i can use?

Now about my HW external clock, originally its raise from 24.576MHz clock, divide by 32. After input this clock into spetrum analyzer, I found its was very stable and thin (without any skirts). also, I examine this clock 768k reletive to its original 24.576M and found those two locked and synchronized.

Liron
0 Kudos
Message 4 of 5
(3,456 Views)

I've gotta confess -- I haven't developed the automatic habit of "trusting" DAQmx to handle things behind the scenes.  So I haven't really explored the options for specifying an external clock and also specifying its (alleged) frequency in the call to DAQmx Timing.  When I *do* use an external clock, I always wire a "1" into the input for sample rate and construct the rest of my app to think of it as "samples per cycle."  Then I deal with the actual timebase information manually.  DAQmx may handle everything just fine, but most of my uses of external clocks are clocks that aren't necessarily a constant freq.  In such a case, there is no single constant value to feed to DAQmx Timing anyway.  Also, I tend to avoid the waveform datatypes, dealing directly with arrays for efficiency. 

I would agree with your choice to use the external signal as an External Clock rather than as a Trigger.  You'll need to check your board's specs for maximum external clock rate -- it may be a bit less than when it uses an internal clock. I'm assuming you're sampling only 1 channel?  If more than 1 channel, you're already in trouble because the max conversion rate of 1.25 MHz with an internal clock must be divided by the # of channels.  So the max sample rate for 2 channels would be 625 kHz with an internal clock, possible less with an external. 

Again, I still find the fact that the 32 kHz artifact is an integer multiple of the 768 kHz sampling rate to be suspicious.  Just a gut feel from general experience -- such relationships usually arise from a systematic source rather than purely by coincidence.  You've checked the clock itself though, so I'm not certain where else to look.  You might try adding an analog anti-aliasing filter and see if it helps, because if there were a real phenomanon at 800 kHz while you sampled at 768 kHz, it'd show up as if it were a phenomenon at 32 kHz.  Anti-aliasing would help suppress the 800 kHz, thereby suppressing the apparent 32 kHz artifact.  No guarantees here, just another avenue to investigate.

-Kevin P.

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 5 of 5
(3,445 Views)