11-30-2017 11:58 PM - edited 12-01-2017 12:01 AM
Hi,
I am using one of the example vis "Multi-Function-Synch AI-AO.vi" to run a synchronous Analog Input (AI)- Analog Output(AO) operation on one of my test devices. I find that the first sample of the waveform I read from my AI is before my AO starts its operation.
Let's say I am sending a waveform of 10 samples to my AO which is a square wave with a frequency set in such a way that, I expect the first 5 samples to be positive, and the last 5 to be negative. Instead, what I see is that the first sample being read on my analog input is always the state of AO before I run the program. For example, the AO is outputting 0V. If now I start my program to output a square wave of 1V, I read the first sample as 0V on my AI, and the samples 2 to 6 as 1V, and samples 7 to 10 as -1V. I do not know why it doesn't start from 1V.
I suspect I am doing something that is a very common mistake. I am attaching my vi, just in case. It has already the output saved from my previous measurement.
Solved! Go to Solution.
12-01-2017 05:53 AM
you are sampling 100hz signal with sample rate of 100hz. sampling freq > 2fmax.
Increase sample rate.
12-01-2017 08:35 AM
Naidhili wrote: I find that the first sample of the waveform I read from my AI is before my AO starts its operation.
This is expected. After all, it takes time for a signal to output from the ADC and then get to the AI channel. By the time the ADC is done, the AI channel has already taken the sample. So what you are seeing is correct.
12-01-2017 08:55 AM
Agreed, it's behaving as expected, but you *can* configure differently and get the behavior you want.
1. If AO and AI are using the same sample rate, I would strongly advocate that you simply share a sample clock between the tasks. There will then be no need for triggering and some of the additional timing subtleties *that* can introduce.
Designate one as the master task, share its sample clock over to the other task, and be sure the master task is started last.
2. If you want your 1st AI sample to show the system response to the 1st AO sample, you need to give your system time to respond. You can do this by setting the AO task to sample on the leading edge of the sample clock (probably rising) and the AI task to sample on the trailing edge (probably falling).
3. You can get more control over this offset timing by setting up a non-square pulsetrain that acts as sample clock to both tasks. It should be started after both AO and AI. You can then define the pulse duty cycle to put more time between the AO's leading edge and the AI's trailing edge for a given sample rate.
Here are a couple different threads I've been in that discuss this more.
-Kevin P
12-01-2017 07:42 PM - edited 12-01-2017 07:53 PM
@crossrulz wrote:
Naidhili wrote: I find that the first sample of the waveform I read from my AI is before my AO starts its operation.This is expected. After all, it takes time for a signal to output from the ADC and then get to the AI channel. By the time the ADC is done, the AI channel has already taken the sample. So what you are seeing is correct.
I thought the time for the physical signal to reach AI should be in ns though so I didn't expect a lag in the first place. And strangely enough, no matter what sampling rate I use, the lag is always of a single sample.
12-01-2017 07:50 PM - edited 12-01-2017 07:52 PM
@bharathp10 wrote:
you are sampling 100hz signal with sample rate of 100hz. sampling freq > 2fmax.
Increase sample rate.
I don't see how that is a problem. After all, I am only interesting in discrete samples and not the frequency information of the whole waveform. I can actually sample exactly my output waveform except that there is an offset of 1 sample.
12-01-2017 09:59 PM
@Naidhili wrote:
@crossrulz wrote:
Naidhili wrote: I find that the first sample of the waveform I read from my AI is before my AO starts its operation.This is expected. After all, it takes time for a signal to output from the ADC and then get to the AI channel. By the time the ADC is done, the AI channel has already taken the sample. So what you are seeing is correct.
I thought the time for the physical signal to reach AI should be in ns though so I didn't expect a lag in the first place. And strangely enough, no matter what sampling rate I use, the lag is always of a single sample.
For the sake of discussion, I wanted to correct myself and say that this lag could be more than a single sample in case you are sampling at very high rates (500K)