Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Sampling in DAQ 6368

Solved!
Go to solution

I'm doing a DAQ loop back by forcing a sine wave on analog output and capturing at the AI. to match the coherency and get a single tone in the FFT power spectrum. Im struggling a lot and im new to both signal processing and using DAQ. So, please help me to understand the sampling rate and frequency bins in Labview VI terms.

I have written a simple DAQ loop back program i wonder why coherency is not good. And im not able to see a single peak at my frequency designed. Please have a look at my code and any help would be appreciated.

Thanks in advance.

0 Kudos
Message 1 of 12
(4,384 Views)

Per Nyquist, you have to sample a signal at over 2 times the signal bandwidth in order to be able to do a spectral analysis.  So since you are sampling at 500kHz, the maximum frequency you can detect is 250kHz.  Your signal is at 500kHz, so it will actually show up at DC in your FFT.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 2 of 12
(4,361 Views)

Hi Thanks for your reply,

 

I made the Sampling frequency at capture side equal to 10 times of source sampling side. and still i see a spectral leakage at the frequency bin.and there is still no clue y it is happening. I guess i should increase the number of samples being captured or something like that. Please correct if i am doing something wrong

vi.pngvi2.png

0 Kudos
Message 3 of 12
(4,358 Views)

It looks like you have aliasing from your Analog Output.  Notice the spikes are around ~5kHz (your output frequency) on each side from 80kHz (your analog output sample frequency).  This is quite normal.

 

Since I now see you are setting your output frequency to <5kHz, I would set the analog input to sample at more around 50kHz.  40kHz would probably be more appropriate since aliasing from the analog output can go down to 80kHz/2 (Nyquist).

 

Another option is to throw in a Low Pass Filter on your read data.  Since your output sample frequency is 80kHz, a 40kHz filter would be appropriate to remove any aliasing from the output.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 4 of 12
(4,351 Views)

Couple other quick points:

1. The frequency *resolution* you get from spectral analysis is (1/capture_time).  And capture_time = (num_samples / sample_rate).    So overall, freq resolution is (sample_rate / num_samples).   For you, that's 800000 / 6784 ~= 118 Hz.  That's another factor contributing to your spectral leakage.

 

2. You mentioned coherence of AO and AI.  You'll need to get your tasks synced in hardware (via shared clock and/or trigger) to get consistent phase results.  I usually sync via sample clock when feasible, but I think your app will be easier to sync with a shared start trigger (b/c you'd want AO and AI to operate at different sample rates.)

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 5 of 12
(4,340 Views)

If you exite with a (more or less) pure sine , capture more than 15 preriodes at 10x to 50x higher SR and apply a tone detection on both (input and output) measured signals.

But keep in mind that this type of analsys is blind to nonlinearities.

The tone detection vi can output the residual signal ... always worth to monitor 😉

 

 

Greetings from Germany
Henrik

LV since v3.1

“ground” is a convenient fantasy

'˙˙˙˙uıɐƃɐ lɐıp puɐ °06 ǝuoɥd ɹnoʎ uɹnʇ ǝsɐǝld 'ʎɹɐuıƃɐɯı sı pǝlɐıp ǝʌɐɥ noʎ ɹǝqɯnu ǝɥʇ'


0 Kudos
Message 6 of 12
(4,337 Views)

HI Kevin,

Thanks for your points,

1. Now i have calculated my frequency to be a multiple of my frequency bin. i.e 1607424/20608 = 78. Now i have made my frequency designed so that it would be a multiple of 78 i.e(Fs=569088, m=1,n=128) which make my Fin=4446 Hz. But i'm seeing a problem here, my programmed sampling rate at input side is 569088 samples/sec. But when i read the actual sampling rate from the property node i'm seeing a different sampling frequency i.e 568181.8181. I am trying to figure out y is this happening. Even at the capture side my Fs is 1607424 samples/sec. But from the property node it  is 1612900 samples/sec. 

2. As you mentioned about the sample clock i'm using the on board clock for both source side and capture side. In DAQmx help there is some information on the start trigger saying it is a terminal from device. But when i go to device pinouts. I don't see any signal. So, bit confused in this context.

 

Download All
0 Kudos
Message 7 of 12
(4,318 Views)

The samplerates the DAQ device natively supports are not arbitary , details are noted in the spec/manual... usually it's something like  f_clock *n/m  with n and m beeing 8 or 16 bit numbers. The driver will coerce the actual samplerate to the next higher possible value.

 

 

Greetings from Germany
Henrik

LV since v3.1

“ground” is a convenient fantasy

'˙˙˙˙uıɐƃɐ lɐıp puɐ °06 ǝuoɥd ɹnoʎ uɹnʇ ǝsɐǝld 'ʎɹɐuıƃɐɯı sı pǝlɐıp ǝʌɐɥ noʎ ɹǝqɯnu ǝɥʇ'


0 Kudos
Message 8 of 12
(4,315 Views)

1. As Henrik said, the actual achievable sample rate can only land on discrete frequencies that are an integer divisor of the board's internal master clock.  On the X-series boards, that clock runs at 100 MHz.  You'll find that your requested rate would have needed a divisor of 175.72.  Not an integer.  So DAQmx chose the nearby integer divisor 176 to give you the sample rate of 568181.8181.

 

2. Trigger signals for tasks would normally be inputs, not outputs.  That's why you don't see anything on the terminal block.  However, there *are* a number of internal timing signals used within the board which *can* be exported to terminal block pins on request or can be used by other tasks without putting them on terminal block pins.

   An internal task "start trigger" signal pulses when a task starts.  You can tap into this signal with the other task.  To make the AO task get triggered by the start of the AI task, the AO task would be configured to use a start trigger named something like "/Dev1/AIStartTrigger".  Then you'd start the AO task before starting the AI task so it'll be ready for the trigger pulse.

 

I'd further suggest you try generating a waveform with a larger # samples per cycle than 128.   It's one more step toward a cleaner looking spectrum as you experiment and learn.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 9 of 12
(4,308 Views)

If you tell us more about your task (seems like you want to measure some kind of transferfunction),

we migth give you better hints 😉

Greetings from Germany
Henrik

LV since v3.1

“ground” is a convenient fantasy

'˙˙˙˙uıɐƃɐ lɐıp puɐ °06 ǝuoɥd ɹnoʎ uɹnʇ ǝsɐǝld 'ʎɹɐuıƃɐɯı sı pǝlɐıp ǝʌɐɥ noʎ ɹǝqɯnu ǝɥʇ'


0 Kudos
Message 10 of 12
(4,298 Views)