Synchronized Analog Output Inputs: DAQmx read problem??

[Archivaldo]

Hi,

I'm using LabView to control a device to measure the conductivity of fuel cell membranes. However I'm getting some weird results. My readings are affected by the sampling rate even though the latter is way above of the nyquist frequency of the system (I'm reading a 1000Hz signal using sampling rates from 10000 to 50000S/s).

In order to try to track down the problem I built a "simulator" for the system (conductivity simulation (2 ACs).vi). However, let me explain very roughly how the system works: an AC signal is generated using an analog output (AO) of the PXI-6031E DAQ card we have. The signal goes through a resistor and then excitates a membrane. Both signals, the voltage drop in the resitor as well as the membrane response, are read using two analog inputs (AI) on the same card. The excitation and reading are synchronized (the AO is triggered by the AI). So for the "simulator" I just simply connected the AO0 to AI1 to simulate the membrane response, and the AO1 to AI2 to simulate the signal throgh the resistor. Since the outputs are hardwire directly to inputs I expected to read the exact same signals generated; however, it was not the case. For example this is what I get if I generate two 1000Hz signals with the following parameters: for AO0: Amplitude=1, Phase=0; for AO1: amplitude=2, Phase=15:
 
Sampling rate (S/s)         AI1 phase       AI1 Amplitude     AI2 phase       AI2 Amplitude 50000                                    -7.2                       1                   15                        2

20000                                    -14.4                     1                   15                        2

10000                                    -36                        1                   15                        2

Initially I thought the AO0 had problems, so I swapped the cables and connected AO0 to AI2 and AO1 to AI1. The suprise was that this time the phase lag showed up again on AI1.

Sampling rate (S/s)         AI1 phase       AI1 Amplitude     AI2 phase       AI2 Amplitude 50000                                    7.8                        2                    0                        1

20000                                    -3                          2                    0                        1

10000                                    -21                        2                    0                        1 

Or course the first thing to come in mind is that the input had problems, so I tried with other 20 inputs and the result was always the same. The pattern found was a sample rate dependant phase lag in the 1st signal read by the 'DAQmx read' (which I cannot explain). To confirm the problem was present only on the 1st signal read I just simply changed the reading order of the signals (read first AI2 and then AI1) without changing any connection on the hardware. Again the 1st signal read (in other words, the element in position 0 of the result array created by 'DAQmx read') was the one showing the phase lag. I tried this several times with several inputs and very single time the 1st signal read showed the phase lag.

To make things even easier (and closer to real system) I changed the simulator ( conductivity simulation (1 AC).vi ) to use only one AO. This time the same AO is connected to two different inputs (and I would expect to get the same reading from both AIs). Again the 1st input read showed a phase lag, and the second didn't. For example (Amplitude=1, Phase=0, Frequency=1000Hz):

Sampling rate (S/s)         AI1 phase       AI1 Amplitude     AI2 phase       AI2 Amplitude 50000                                    -7.2                        1                    0                        1

20000                                    -18.1                      1                    0                        1

10000                                    -35.9                      1                    0                        1 

Does anybody have any idea what's going on? I really need to get this problem sorted out since I need to have very accurate phase readings in order to properly calculate membrane conductivity. Attached are the simulator vi's

Thanks a lot for any help you can give on this issue.


                Pedro.

[caz]

Hi Archivaldo,

You're right, thats some weird results.  Since your board does not support simultaneous sampling, it must multiplex signals before the ADC so it really bothers me that you have 2 channels of the same signal digitized by the same ADC giving a different result.

Your code looks sound.  I don't see any glaring omissions.  However, you only mention an error in the phase reading from the extract tone express vi's.  Did the graphed data look wrong when measuring the same signal on 2 AI's.  It should be obvious based on the numbers you provided.

A couple things to try.

1) Try configuring just 1 AI and see if you get consistent and correct results regardless of what channel you use.

2) If step 1 works, go back to using two AI's and try using just one tone measurement express vi instead of having one for each channel.  You can wire the 1D array of measured waveforms and configure the tone express vi to output an array versus a scalar.  Make sure to also change the convert from dynamic data vi to output a 1D array of double versus the scalar.  You may also want to use the extract single tone vi from the waveform measurements palette instead of the express vi.

3) Try setting the read to be 2D double instead of 1D waveform.  You can rebuild the waveforms after indexing the 2D array from the read vi to use the existing measurement vi's in your code.

4)  If nothing worked so far, try configuring the read to be a single channel instead of N channels.  Hopefully this would behave the same as would you get in 1).

Since you tried flipping the order of the channels to read when using 2 AI's and saw that the first channel always had the phase error, the problem can't be in hardware.  If its not something simple like any of the above I will be really interested to hear what the final diagnosis is.

Drew

[Archivaldo]

Hi Caz,

Thanks for your reply.

I tried some other options before posting my question on the forum, including all your suggestions. Unfortunately the result was always the same.

For cases 1 and 4, where only 1 signal was read the phase was wrong regardless of using just 1 AI, or using a single channel instead of N channels. For case 2 I tried to use only 1 instance of the tone measurement express vi and then read elements 0 and 1of the resulting dynamic data output, but same story. I also used the extract single tone vi instead of the express vi, but again the phase didn't match the phase of the AO for the 1st signal read by the DAQmx read vi, the second signal read was just fine. Finally, using a 2D DBL output on the DAQmx read vi gave me the same result as using a waveform output.

Do you have any other idea of what could be the problem? I've been trying for a month testing every single modification that I can think of, but no luck so far.

Thanks a lot,

                           Pedro.

[caz]

Wow.  This is very interesting, but I imagine very frustrating for you.  The last thing I can recommend is to keep the AO task sample clock the onboard clock but change the AI task to use the AO sample clock devX/ao/sampleclock.  This may tighten sychronization between the 2 tasks or at least mitigate a problem you seem to have with the first channel.

Otherwise, my next guess is a DAQmx driver issue.  Perhaps, a fresh reload of the driver is all that is needed.  After that, my expertise is zippo and I guess a problem to deal with NI about.  Perhaps a "bug" or better put "a compatibility issue" with the software and hardware you are using.  Please post any updates.

regards,

Drew

[Robert_F]

Hi Pedro,

The phase shift between the two analog input channels is expected.  The PXI-6031E only has one ADC on board, which means that it uses a multiplexer to read both channels.  It can not read the same signal at the same time.  All of the S Series boards are capable of reading simultaneous because they have an ADC for each channel.

Now the phase shift between the two channels should be constant so you should be able to account for that shift.  Are you getting a constant phase shift? 

Message Edited by Robert F on 06-07-2007 10:26 AM

[caz]

Rob,

I you look earlier in this thread, you will see that its not just a phase error related to the multiplexing but rather a problem with the first channel read.  If he wires the same signal to 2 analog inputs, the second channel read behaves properly where as the first one has a sample rate dependent phase error and the error is NOT something small like the time lag due to 2 channels not sampling simultaneously.  The same error is prevalent if he just configures his task to read 1 channel.  Something is not behaving normally with his read function.

Drew

Message Edited by caz on 06-07-2007 11:53 AM

[Archivaldo]

Hi,

Caz, I tried using the AO sample clock as the clock source for the AI task, but it made no difference. It definitely looks like a bug in the DAQmx or the driver of the DAQ card.

Rob, I know the E series DAQ card we have has only one ADC so I was expecting a small phase shift. However, if you take a look at the results I put in my first post you'll see that:

1) the phase shift is not constant and it varies almost lineraly with the sampling rate: the lower the sampling rate the higher the phase shift with respect to the original signal generated by the AO.
2) the shift is HUGE it goes from 3 degrees up to more than 40 degrees (at most I was expecting a few hundredths or tenths of a degree due to the multiplexing).

3) the extreme phase shift is only present in the 1st signal read. As you can see I read the same signal simultaneously with two different AIs and only the 1st AI read by the DAQmx read vi has a noticeable phase lag. If I invert the order of the AI reading the result is the same (for example if I read AI1 and then AI2 the signal in AI1 shows the phase lag. Then if I read AI2 fisrt and then AI1, without modifying the hardware connections, the signal from AI2 is the one exhibiting the phase lag) 

Now, in order to check the multiplexer theory I connected 10 different AIs to a single AO and read them simultaneously. Again the 1st signal read had a huge phase lag. Conversely, the other 9 signals showed almost constant differences of only hundredths and thousandths of a degree among them. Also, again, the phase shift was sampling rate dependant.

I definitely think there's an issue with either the DAQmx read vi, or the DAQ hardware driver.

For the moment I introduced a "dummy" input in my code to get rid of the phase lag (the signals I need to read to determine membrane conductivity are 2nd and 3rd in the reading sequence). The only problem with this approach is that I loose 1/3 of the total sampling rate available for reading, which becomes an issue when I have to use high frequency AC signals.  

Any suggestion on the issue would be greatly appreciated.

Regards,

                      Pedro.

[Kevin_Price]

Interesting problem.  I looked at the vi's you posted earlier but am not near a LV machine now so will have to work from memory.  Some comments:

1. These measurements are being done by one of the built-in analysis vi's.  It's probably very good, but most any signal processing algorithm will have some limitations.  I would caution against trusting it as a 100% accurate analysis.

2. Nevertheless, the type of discrepancies you observe seem to point away from that anyway.

3. When sampling multiple channels, it's possible to set the multiplexing rate explicitly, otherwise the driver reverts to a default behavior.  That default behavior has varied with DAQmx versions, but I *think* that the last several versions will try to use the lowest possible multiplexing rate to maximize the time between channels.  This allows more time for the circuitry to bleed off charge and can produce more accurate amplitude measurements.  Please tell us which DAQmx version you're using -- maybe someone from NI will know if there's a known issue.

4. Assuming you aren't setting the multiplexing rate explicitly, it does make sense that the measured phase would vary with sample rate.  As you increase the sample rate, the multiplexing rate will also increase.  That decreases the time between channels, so the measured phase lag also decreases. 

To avoid this issue, you should set the multiplexing rate explicitly.  If you set it really fast, then you may see some bleed-over if you switch from a large amplitude to a small amplitude -- there may not be time to bleed off the charge from the earler signal and that can induce measurement error in the next one.  I'd recommend testing with something like a 5V signal followed by a 0.05 volt signal.  Increase the multiplexing rate until you see that the 0.05 volt signal starts measuring out > 0.05 volts.

5. Your "dummy" channel workaround is the only thing I could think to suggest and you're already there.

6. I'm not so sure that your real problem isn't exactly the opposite of what you think.  To me, the measured phase lag for the first channel in your task seems more like the truth, given the reality of multiplexing, and the near-0 values for all the others seem suspicious.

-Kevin P.

[Archivaldo]

Hi Kevin,

I'm using DAQmx revision 8.5 (if I'm not wrong is the latest one) with LabVIEW 8.2.

Regarding some of your suggestions/comments:

As you say the phase lag between simultaneously sampled analog inputs reflects more the truth given the multiplexed nature of the E series DAQ card I have. However, I'm sampling only 2 signals of 1kHz each, which by no means are close to "choke" the ADC of the 6031E card that is supposed to be able to sample up to 100kS/s. For my particular case this translates in 50kS/s available for each signal, or in other words a sampling rate 50 times faster than the frequency of the signal itself; and yet I have a phase lag of 7.2 degrees at this sampling rate (this is equivalent of putting a ~1000uF capacitor in my system, which doesn't make sense). If I lower the sampling rate to 10kS/s (10 times faster than the signal frequency) the phase lag of the 1st signal sampled goes up to 36 degrees (which is way too high to be considered just an effect of the multiplexed ADC). This variation causes a change of up to 40% in my conductivity readings, which of course is not what i would call a reliable reading.

Now going to the multiplexing rate, I haven't set it explicitly. But looking at NI description of the AIConv.Rate Property of DAQmx timing, by default, NI-DAQmx selects the maximum convert rate supported by the device, plus up to 10 microseconds per channel settling time. So if the system is already working at the fastest possible convert rate supported by the device I don't think setting it explicitly would have any favorable effect.

What I'm planning to do in order to verify if the issue is software related or driver/hardware related is to connect a signal generator simultaneously to 2 or 3 AIs of the PXI-6031E DAQ card and check for any phase shift (especially for the 1st AI read). Then I'll repeat the test on a PCI-6220 M series DAQ card (which can go up to 250kS/s) we have in another computer in our lab. If the behavior is the same we can conclude it's an issue of the DAQmx read vi, otherwise it would point to a hardware problem with the 6031E.

Thanks!,

                    Pedro.

[Kevin_Price]

Ok, my memory was faulty about the convert rate settings.  The older DAQmx versions defaulted to slower rate while the newer ones default to a faster rate, as stated in the help file you consulted.  (FYI, here's a link to a posting about the change.)  So now I'd agree with you that the measured phase lag shouldn't vary with sampling rate.

Now let's look at your the results in the last table of measurements.   For a card capable of 100 kHz max, you'd normally expect a convert clock rate corresponding to 10 usec + 1/100 kHz = 20 usec.  If you're measuring 1 kHz signals, then the apparent phase shift you'll see due to the convert clock should be 20 usec / 1000 usec = 1/50th of a cycle, or 7.2 degrees.  However, it seems to me that the phase shift should be constant, unless you max out the sampling rate so that the convert clock doesn't add the extra 10 usec for setting.

When you sampled at 10 kHz, you measured a ~36 degree phase shift or 1/10 cycle.   At 50 kHz, you measured a ~7.2 degree shift or 1/50 cycle.  I can't help but notice that these are exactly the amount of phase shift you'd get from sample (i) to sample (i+1) on the same AI channel.  Maybe that's a coincidence, but it would make my troubleshooting nose very suspicious to see such a pattern.  It's also even more suspicious that channels 2 through N produce a 0 phase shift measurement.  The hardware isn't capable of doing that, so consequently I'm steered toward something in the software.  Offhand I'm not sure what because nothing immediately struck me as a problem.

I don't have LV here to look at the code right now again, but I would have to recommend adding a lot of debug probes / indicators into the block diagram so you can examine the data in greater detail.  You've been struggling with this for a long enough time that it should be worth the hassle and effort to dig down deep.  For example, since you're connecting a single AO to both AI 1 and AI 2, plot AI 1 and AI 2 as separate plots on a graph.  Zoom in on a very small portion near a zero crossing (where differences are most pronounced).  Verify the apparent phase lag the old fashioned way, with your eye & some interpolation.  Make sure the results of the express vi agree with what you can observe.  That kind of stuff.

-Kevin P.