Help requested using AT-MIO-16DE-10 (samples are being averaged)

[jevans]

I'm using an AT-MIO-16DE-10 and have assigned PFI2 as the external trigger input [Select_Signal (AT_MIO, ND_IN_CONVERT, ND_PFI_2, ND_LOW_TO_HIGH);]. My source is a peak-held signal which can vary between 0 and 5v (hold time is 80 uS after the trigger signal) and repeats at a rate of 430Hz. I'm using DAQ_Op to synchronously acquire the signal peaks followed by DAQ_VScale to convert them to a voltage level.
My problem is this: instead of digitizing the level of the signal at the trigger, the system seems to be returning the mean value of the signal as a whole. In the example described here, the signal is ~ 4v for ~90 uS and 0v for the remaining 233 uS. Taking 10 samples using the DAQ_Op, DAQ_V
Scale sequence returns ~1.5v for each sample and 1.5 happens to be the time averaged value for the signal (4*(90/233)).
Does anybody out there in NI-land have a clue as to why this is happening? (I'm developing my app in CVI. I've attached two files, showing the input signal and a code snippet.)

Thanks in advance for all your help.

Jesse Evans

[Russell]

"Hello Jesse,

This is the same as your other question I guess?

Have you tried using a similar shipping example program just to try things out? I did look over your code and I do have a few comments/questions/clarifications. It looks like you have the CONVERT clock as an input on PFI2 and DAQ_Config() is set up for a software start trigger with an external sample clock. I think you are calling this external signal going into PFI2 the trigger, but it is actually the CONVERT/sample clock. I believe you are just taking one sample per trigger. I think you are intending to take 10 samples per trigger.


In fact, I think you'll see much different behavior if you just reverse the 0, and 1 parameters in your DAQ_Config() call.


DAQ_Config (AT_MIO, 1, 0)
;


Also, you could delete the Select_Signal() statement. You actually want an interal CONVERT clock. Then apply your trigger signal to PFI0 as that is the default.


Now, you should also be aware that you may only have one trigger per DAQ_Op call. After that, you will need to reconfigure to prepare for the next trigger. This may not be a problem if your program is fast enough to keep up with the triggers however. If not, there is another method you can use that will basically use a counter to gate the sample clock.


Anyway, I hope this hasn't been too wordy.


Russell
Applications Engineer
National Instruments
http://www.ni.com/support"

[jevans]

Russell,

Thanks for responding. Yes, this is a dup. of my earlier question; I wanted to make clear in my subject what is going on.

One sample per trigger (CONVERT) is what I want and seems to be what I get, however the values returned are not the peak at the trigger but rather the average value through the duty cycle of the signal (see signals.jpg).

As I understand the API, by selecting a software start, the acquisition begins when the DAQ_Op call is made, thus the DAQ_COnfig (AT_MIO, 0 1); should be correct for my app.

So, my problem still exists.

Jesse

[jevans]

Further clarification and confirmations:

Refering to the image in the signals.jpg file, the upper trace is the signal I wish to digitize and the lower trace is a trigger signal. I want to capture a series of values, one per trigger, each one being the amplitude of the signal at trigger time. I want to start the acquisition via the call to DAQ_Op, hence the second parameter in the DAQ_Config call should be 0 and I want to digitize the signal when the trigger occurs, hence the third parameter to DAQ_Config should be 1.

I inserted a couple of calls to Timer (), bracketting the DAQ_Op call, to assure myself that I am actually getting individual samples at the trigger rate. Results were as expected... the DAQ_Op call takes the appropriate time p
eriod for single samples at the trigger rate.

I can modify my input signal so that it holds its level until the next update trigger and when I do that I get the true value of the signal. However, when I set things up to only hold for a portion of the update time, I get values that are roughly the average value of the signal as a whole. In other words, when the duty cycle of the signal is 50%, each sample value is 50% of the level at trigger time; 25% duty cycle gives 25% of the level, etc. Again, I only get the true value of the signal if its duty cycle is 100%. It's as though the signal were AC coupled into the card. Is that possible with the AT-MIO-16?

Thanks again for your help.

Jesse

[Russell]

Hi Jesse,

I checked just to be sure and only DC coupling is available on the AT-MIO-16.

One thing that I notice about your signals (that graph is very helpful by the way) is that the trigger (sample clock edge) occurs almost right on top of the signals sharp transition from 0 to 4 volts. In this case it seems as though the board may be sampling the signal during this transition which makes sense that it could return voltages halfway inbetween. I don't think the board is averaging the total signal, I think it's just a coincidence that the average value is also inbetween that transition.

You did say that when you held the signal value until the next sample you got expected results. Did you mean that the signal is always kept at ~4V DC? I
f so, the trigger (sample clock edge) is not occurring during a transition so it won't have the same problem.

If you can, move the trigger so that it happens a little bit later than the signals transition and I'll almost guarantee you'll get the values you're expecting. Try this and let me know what you think.

[jevans]

Russell,

Ok, here's a couple more images showing the relationship between the signal and the trigger. (Image signals0.jpg shows the trigger and the entire signal; image signals1.jpg zooms in to show the trigger and signal separation.) The signal becomes steady ~2µS prior to the rising edge of the trigger and remains steady for ~90µS afterwards. (The trigger itself is ~200nS wide.) Is 2µS sufficient separation between the signal and the trigger?

Jesse

[jevans]

Russell,

Regarding the DAQ_Op function, since I only want one sample per trigger, what effect does the value of the SampleRate parameter (parameter 6 in the call) have on the acquisition operation?

Jesse

[Russell]

Hello Jesse,

Since you have configured an "externally clocked" acquisition, the SampleRate parameter shouldn't have any effect on the acquisition. This might be a good time to go ahead and synchronize our terminology. The "trigger" as you call it whose edge initiates taking a sample, we call the sample clock. If I'm not mistaken, it seems your signal and sample clock are actually the same frequency, only out of phase by about 2us, right?

Anyway, the point is the signal is sampled about 2us after it rises. Since this is just after a very abrupt change, there are a lot of high frequency components there. The bandwidth of the AT-MIO-16DE-10 board is mentioned on page A-14 of the manual.

AT E Series User Manual
h
ttp://digital.ni.com/manuals.nsf/webAdvsearch/6FB4341E8E3080F086256BD000550261?OpenDocument&vid=niwc&node=132100_US

It says this is value is 150 kHz. So the period of the fastest signal that can get through is about 6.66us so I would allow at least that much settling time from an abrupt transition and probably more.

If you want to verify the board is not simply returning an average value of the signal, try running the DAQsingleBufSync.C DAQ shipping example. Change the dSampRate parameter to be about 10x's the frequency of your input signal for best results. (You may have to do less since the max rate of the board is 100 kS/s.) You should be able to see the signal plotted with varying values and not just a flat line of one value.

In summary, my suggestion is to give your signal even more settling time before sampling it. You might experiment with various delays starting further towards the back of the pulse instead.

If this isn't an option, perhaps there is a different
board that would suit you better. The 6070E, for example, has a bandwidth of 1.6MHz.

I hope this helps. Let me know if you have any questions.

-Russell

[jevans]

Russell,

Thanks for the info. I was able to sample the entire signal and get its shape using the MAX utility, so I thought I was using the acquisition function incorrectly. I can change the firmware on the device which is generating the signal and sample clock (as you call it) to increase the time delay between sampling the signal and generating the sample clock. I'll let you know what happens.

Jesse

[jevans]

Russell,

Turns out I'm unable to increase the delay between the signal going high and the trigger edge, as this is a result of the external stimulus which generates both the signal and the sample clock (trigger).

I reviewed the manual page you mentioned. The two important parameters are the input bandwidth and the full-scale settling period. In my application, the signal is being clocked at ~3.5 KHz, so that's not an issue. As for the settling time, that parameter generally refers to the time period after sampling during which the input signal must be stable for accurate conversion by the successive approximation circuitry. Thus, this is the time after the trigger, which in my app is ~80µS, so that
should also not be an issue.

I cannot use the 6070E, as my app needs the 24 DIO lines provided by the AT-MIO-16.

Any more suggestions?

Jesse