Synchronized Analog Output Inputs: DAQmx read problem??

[Archivaldo]

Hi Kevin,

Thanks a lot for your reply. What you show is very interesting, and to be honest I never thought that the phase lag due to the multiplexed ADC could be so noticeable (I'm a chemical engineer, so my knowledge of electronics , programming, and related topics is very limited).

Following your way of reasoning to calculate the ADC-induced phase lag (which makes total sense):

[1/(sampling rate)+ (10us settling time)] x (signal frequency) = (lag){in cycles). Then (lag){in cycles} x 360 = (lag){in degrees}

I get the following results for a 1000Hz signal, including the 10us settling time per channel (attached is zip file with screens of the readings of a single signal at different sampling rates):

Sampling rate              Calculated lag                    Read lag
100000                     20x0.001x360 = 7.2                   3.6
50000                       30x0.001x360 = 10.8                 7.2
25000                       50x0.001x360 = 18.0                 14.4
10000                       110x0.001x360 = 39.6               36


If I don't include the 10us settling time this is what I get:

Sampling rate              Calculated lag                    Read lag
100000                     10x0.001x360 = 3.6                   3.6
50000                       20x0.001x360 = 7.2                   7.2
25000                       40x0.001x360 = 14.4                 14.4
10000                       100x0.001x360 = 36                  36

Which is a perfect match.  But where's the settling time then?. I tried sampling simultaneously 2 very dissimilar signals (one of 10V and one of 100mV) at different sampling rates to check for any bias due to charge built-up (as you suggested before), or for any change in the phase lag due to increase in the settling time to bleed-off any remaining charge. At the end I didn't see neither: the phase lag followed the pattern of the 2nd table shown above (without the 10us settling time), and the measured amplitude of both signals was unbiased (10V and 100mV respectively).

Supposing then that the settling time of the ADC multiplexer is almost instantaneous, I should see the same phase lag pattern of table 2 above between each channel sampled. That means that if I connect the same AO 1000Hz signal to 4 different AI channels I should have a phase lag of 14.4, 28.8, 43.2, and 57.6 for signals 1, 2, 3, and 4 respectively when sampled at 25000S/s. The problem is that I don't see that behavior, I got 14.4, 0, 0, and 0. So now I'm totally clueless and I don't know what reading to believe. Any ideas?. I tried the same at different phases for the AO signal and everytime the 1st signal read was the one with the phase lag, the readings of the other AIs matched the phase of the generated signal in the AO (see attached zip file with screen captures of some of the reading for 4 simultaneous AIs).

Thanks!,

                     Pedro.


 

[Kevin_Price]

I'm running out of new ideas here, so just to recap:

1. I'm slow to assume this is a problem with the DAQmx driver mainly because I'd expect to hear an awful lot more complaints from others if that were the case.

2. I really don't know what assumptions are built into the various Tone measurement vi's.  So I've got nothing specific to go on, but I have to wonder if they're the right tool for the job.

It appears that you send in multiple cycles of a single signal and let it calculate amplitude and phase values.   You do that individually for several AI channels.  These seem like they must be calculations of absolute phase.  However, what you seem to care about is phase lag between two channels, which you calculate by taking the difference of those absolute phase measurements.  This is a somewhat indirect method.

3. I have a bias.  I'm not a fan of express vi's.  So I kinda mistrust them until I see compelling evidence that forces me to trust them.  That may not be fair, but that's where I'm coming from.

I would strongly encourage you to examine the data manually as a way to double check the Tone measurements.  I also suspect that there are better methods for measuring relative phase of several sinusoid-like signals.  For example, here's a method from a forum poster who has demonstrated a depth of signal processing knowledge.  Personally, I would be more inclined to trust his code than the express vi's.

Try plotting and/or tabulating only the 1st 5 measured datapoints for AI 1,2,3, and 4 and post the results.  (Assuming all are wired directly to a common AO sinusoid). 

4. You've done a great job with the hardware troubleshooting to help characterize and isolate the causes and effects, but most of the attention has been on the 1st channel.  It's looking more and more like that 1st channel is making pretty good sense, while all the *other* channels are wrong.  I'm of the suspicion that the Tone measurement vi is not doing what you're expecting it to do.  Since there haven't been piles of complaints about the vi before, I'm inclined to think that your expectations may be off. 

Poking and prodding, but meaning to help...

-Kevin P.

[Archivaldo]

Kevin,

In order to skip the tone measurement VIs (both the "express tone measurement" VI and the "extract single tone information" VI) I changed the DAQmx read output from waveform to 2D DBL and try 2 different approaches:

1) I used the vi proposed in the link you suggested, and the phase difference calculated between signal in channel 1 and any other channel was always 14.4 degrees (sampling rate was 25000S/s per channel). However, this difference was zero when comparing any two signals different from that on channel 1.

2) I tabulated the data and put it in excel and matlab and signals 2 to n overlap, signal 1 has a lag of ~14.4 degrees. I attached an image of the output 2D DBL array, and as you can see signals 2 to 4 are exactly the same, and signal 1 has a lag. However, if you take a look only the 1st element differs and shift all the other measurements 1 position to the right (I put some red lines to show that).

Some thoughts:

1) I'm wondering if the 1st value of channel 1 is not an artifact like for example a value remaining in the DAQ card buffer that was not flushed properly and shows up when a reading takes place (this is just a guess and most likely what I'm saying makes no sense at all, but as I said before my knowledge on these topics is very little). The question would be if the phase lag of channel 1 is due to an artifact (in case it is), why does it follow the calculations based on the sampling rate and the ADC specifications? 

2) Why there's no ADC multiplexing-induced phase lag in the other channels (other than channel 1) when read simultaneously, and yet the phase read is always correct? For example (taking into account that both generation and reading are sinchronized) if the signal generated by the AO has a 55 degree phase, channels 2 to n read a 55 degree phase. If I put 5, 33, 47, 90, whatever value I want to put for the phase of the AO, inputs 2 to n give me the right value. Should I consider these readings "wrong" because they don't show the phase lag they are supposed to due to the ADC multiplexing, even though the readings agree with the excitation signal parameters?   

3) To try: I'm still trying to get my hands on a signal generator to check the AIs behavior using an extrenal signal source. Also I'll try to add some capacitors of different values to each of the connections. Comparing the capacitor-induced phase shift of each channel with calculated values would be a good way to check if the readings are ok or not.

Thanks,

                    Pedro. 

[caz]

Pedro,

I think you forgot to attach the image of the plotted data.

Also, a thought just came to mind.  Suppose you had an analog input task with N channels and output task that was perfectly synchronized and running at the same sample rate.  That is, channel 0 of the AI and the AO use exactly the same clock edges and AI channels 1 - N are delayed slightly due to multiplexing.  In this situation, AI channel 0 would digitize data exactly at the same time as the AO updates but would never quite get the right value because there will be a physical delay since some distance of wire must carry the signal from the AO to the AI channels.  The AI channels 1 - N would sample the correct voltage since the AO has had enough time to send the signal and this signal will not change until the next clock edge of the AO clock.  On the next clock edge, the AI channel 0 would sample the previous AO sample since it will see that before the AO can update but the rest of the channels will capture the new AO value.  Hence, channel 0 will appear to lag by 1 point but the other channels are appearing to identically sample the AO signal.

If you were to use an external signal generator to produce the same signal, you would start to see the effects of the multiplexing since the signal will change during the sampling of channels 0 - N.

Drew

[Kevin_Price]

Pedro,

Listen to Drew (aka caz) !!!  I really think he's got this issue nailed in his last post.  I had completely failed to account for the fact that you're not sampling a true sinusoid, but are instead sampling a piecewise constant approximation of one.

Let us know how this goes...

-Kevin P.

[Archivaldo]

Drew,

You are right I forgot to attach the file. But it's better since now that I had to do a new run to get the tabulated data I found out that the 1st element of channel 0 of the AI (the one that shifts all the data 1 position as I mentioned in my previous post) seemed to be quite random, then I figured out that this value was exactly the same value at the end of the data arrays of the 1 - N channels once the reading cycle was finished. This means that what you say might actually be the explanation for the behavior I'm witnessing.

Right now I finished running some tests using a simple RC circuit to calculate the capacitance of the capacitor in the system. The capacitor used was 1500uF +/- 20% and I managed to obtain values from 1388 to 1483uF (depending on the frequecy of the signal used for testing) using channels 1 - N. Using channel 0 the capacitance was way off.

I finally will get a signal generator later today. I'll post the results once I run some tests with it.

Thanks a lot,

                        Pedro.

PS: attached is the image of the tabulated data.

Message Edited by Archivaldo on 06-13-2007 03:33 PM

[Mcdan]

Pedro,

The scenario outlined by Drew seems likely to be the cause of the unexpected phase results you're seeing, and the data you attached seems to support this.  If Drew is correct and you have an AO channel sharing a sample clock with your AI channels, then it would be a good idea to introduce a delay between the sample clock and the reading of your AI channels.  The way to do this in the DAQmx API is to use the Timing Property Node, and to set the DAQmx Timing -> More ->Delay From Sample Clock -> Delay Units and DAQmx Timing -> More ->Delay From Sample Clock  -> Delay properties.  By setting these properties you can hold off the scanning of your channels relative to the sample clock by a period of time you control.  The idea here is that you would specify a  delay that was long enough to ensure that the update on the AO channel had completed before beginning to scan your AI channels.

Hope this helps,

Dan

[Archivaldo]

Drew,

Your hypothesis was right. The reason why my AI channels, except channel 0, were all in phase when reading a signal generated by the AO of the same DAQ card was because they were synchronized with the AO clock. I just finished some tests with a signal generator and there was always a phase lag between AI channels (all of them connected to the same source). The phase lag was constant from channel to channel (as seen on the attached image) and was a function of sampling rate (up to a point were I think the sampling rate was slow enough to allow the ADC multiplexing without further increasing the phase lag). In summary the multiplexing effect of the ADC is noticeable only when reading a signal that is not tied to the AI clock source.

So now in order to avoid loosing 1/3 of the available sampling bandwidth for my experiments, I can safely remove the extra dummy input I added to my code and use the data of the 1st channel read by the DAQmx vi by removing the 1st element of the array before analyzing the data.

Finally the "mistery" is solved...actually I thought my DAQ card was behaving like a more expensive "S" series card without any lag between AI channels

Thanks everybody for all the help,

                   Pedro.

[Kevin_Price]

---

So now in order to avoid loosing 1/3 of the available sampling bandwidth for my experiments, I can safely remove the extra dummy input I added to my code and use the data of the 1st channel read by the DAQmx vi by removing the 1st element of the array before analyzing the data.

---

One last tidbit -- Drew gave you the right diagnosis, be sure to try what Dan (Mcdan) said as the cure.  Your idea to remove the first element of the array on the first channel may not be reliable.  His idea of putting a delay between the AO update and the first AI conversion is the better approach.

-Kevin P.

[ClaudeWang]

Execuse me...if Archivaldo's problem is really due to the one-point data shift on AI-0, could "one data" point be just enough to result in the 7.2 phase lag, say at the 50000S/s sampling rate? Could Drew or Archivaldo please give me a simple calculation? Thanks.