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.
Solved! Go to Solution.
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.
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
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.
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.)
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 😉
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.
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.
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.
If you tell us more about your task (seems like you want to measure some kind of transferfunction),
we migth give you better hints 😉