USB-6259 AI-AO Synchronization

[manjagu]

I am using a USB-6259 multifunction DAQ to acquire data.  I would like to excite a circuit and measure the resulting signals over N channels.  In order to test the idea, I have ganged ai0:7 together with ao0.  I then use a modified version of the Multi-Function-Synch AI-AO.vi found in the LV examples library.  I have attached a picture of the code to be clear on the changes.

The steps in the program are accurate.  The program works mostly as I would expect.  One issue is in step 2a.  I would have thought that the triggering would be handled internally in hardware.  Consequently I am surprised that the AO task (the master trigger) takes longer to begin running that does the AI task.  Without the triggering delay, the first sample acquired looks erroneous and is in fact the last voltage set by the DAC (AO) before terminating from the previous execution.  I could understand this if the triggering was occurring in software, but would have thought it would be corrected for in hardware.  Either way, at least the delay on the AI trigger seems to have eliminated the erroneous data and allows the AO task to settle.

Tied with this, however, is the next problem.  This is an image from the program.  I have intentionally left is big so I can see the phase skew in the data acquisition as each channel is sampled sequentially with this hardware.

 

Sorry to blow your screen away with the large image.  What I want you to notice is that the first waveform (white) in the image on the right leads the other 7 channels by one sample.  I think this might be caused by the other 7 channels not acquiring their data at the same time (okay, within 8/1.25Msps =6.4us).  Otherwise I cannot explain why the waveforms after the first one are always delayed by 1 complete sample.  This occurs no matter what channel I choose to begin sampling from.  For example, I can choose ai1:7 or ai:5:6 and I always get the same effect.  I thought perhaps the issue was that the DAC is not holding the data for long enough (setup/hold violation in the digital world...if I can make the comparison).  That may be an issue, but I would have thought that would have been corrected by changing the delay value in ticks to bring the ADC task (next eight samples) in line with the DAC waveform step immediately following the current one.  That didn't work either.

In case you are wondering, I am sampling the DAC output at the same rate with the ADC.  Throw Nyquist out, I will be undersampling faster signals that can be acquired with the ADC in a traditional sense.  Now I have to sample over many periods to acquire the data.  This is why the above has to work right.

A quick check on timing calculations: I assume the ADC will sample as fast as it possibly can during an acquisition (let's assume this is 1.25Msps) even though it will be triggered at a slower rate (in this example 10kHz).  This would still mean that one sample acquisition over 8 channels should occur within 6.4us and then wait for the next ADC trigger to begin again.  Correct me if I am wrong on that.  That is a necessary assumption.  In this example, The DAC update rate is 10kHz.  That means a voltage is held by the DAC for 100us before a subsequent update.  That leaves ADC task with 93.6us to complete the 8 channel acquisition.  This should be easily done.  

So, any thoughts on why this is giving me bizarre results?

[manjagu]

I found a solution. The issue really is in the triggering delay.  I simply wasn't delaying for long enough.  If I allow for a delay of 35 ticks, things become synchronized again.  So, any idea on how to figure out the optimal delay?  Do any of the hardware engineers designing this thing know what the delay is?

[A_Person]

Hi manjagu:

I'm glad to hear that you got your application working!  I'm not sure that there is a specific amount of trigger delay that you will see every time but will certainly look into it.  Does a 35 tick delay seem to work consistently for your application or do you ever need to change it?  Also, how accurate is 35 ticks?  Can you change the delay by a certain number of ticks and still see the same kind of synchronization?

[aNIta B]

Hey Manjagu,

          Something you might want to take a look at is the Analog Trigger Bandwidth.  I suspect that what you're seeing is related to that specification.  You can find more clarification in the KB: How Fast Can the Analog Circuitry on a DAQ Device Trigger Off an Analog Signal?.  The specification for your device can be found HERE. If this is not what you're looking for and need more help, please post!  Have a good one!

aNItaB

Applications Engineer

National Instruments

[manjagu]

---

I'm glad to hear that you got your application working!  I'm not sure that there is a specific amount of trigger delay that you will see every time but will certainly look into it.  Does a 35 tick delay seem to work consistently for your application or do you ever need to change it?  Also, how accurate is 35 ticks?  Can you change the delay by a certain number of ticks and still see the same kind of synchronization?

---

Thanks for the reply.  Between 25 and 25 ticks seems to work relatively well.  If I go more or less I lose synchronization.  It also seemed to have changed depending upon the sample rate.

[manjagu]

---

aNIta B wrote:

Hey Manjagu,

          Something you might want to take a look at is the Analog Trigger Bandwidth.  I suspect that what you're seeing is related to that specification.  You can find more clarification in the KB: How Fast Can the Analog Circuitry on a DAQ Device Trigger Off an Analog Signal? .  The specification for your device can be found HERE. If this is not what you're looking for and need more help, please post!  Have a good one!

aNItaB

Applications Engineer

National Instruments

---

Thanks for the suggestions aNIta B.  I am not sure how it is related, but I'm not saying it isn't.  I looked at the spec and the FAQ.  I am not triggering off an analog signal per se.  I am triggering off an internal digital start trigger from the AO start.  There just seems to be some odd timing involved.  What I see suggests, despite arming the AI task first and triggering off the AO task, there is a lag time between the two tasks.  I think what I mentioned in the first post was incorrect.  The AO task starts faster than the AI task.  The delay ticks in the AI task allowed me to skip a full AO step and start at the next step with the AI task.  Without the delay, all 8 channels of the AI task cannot capture the data before the AO task (DAC) takes another step.  So I have two options: delay the start of the AO task so the AI task (the slow one) has a chance to start closer to the beginning of the AO task and therefore has time to finish all acquisitions; or I can do the same as above and delay AI task by the residual ticks left in the AO task so that I effectively skip the first DAC step and start acqiring at the beginning of the second.  Confused?  I'm getting there...

I tried this another way with the same effect.  I grabbed the multi-function synchronization digital-in digital-out counter example and modified it.  In this example the DI and DO tasks are clocked by a counter.  I changed it so that there is an AI, AO, and DO task clocked (synched) by the counter.  (In the end I need DO waveforms as well).  Despite supposedly being in synch, I see that the AO task is updating before the AI task can finish the acquisition.  It is again only the first waveform that has an issue (that is the first waveform aquires correctly but is not the same as the next 7).  But this time I don't have the ability to tweak the delay ticks to compensate.

So, the big question is: How do I either delay the start of the AO task by some tick count and still trigger the AI task at the appropriate time OR conversely, do what I am doing above and delay the AI task by some tick count to skip the first DAC output.  This question becomes more important when one tires to synch three tasks using one counter and is no longer able to delay things by tick values.  

It just seems to me that there should be hardware compensation for this somewhere so they can remain in synch without having to tweak the software.

[aNIta B]

Hey Manjagu,

         Just wanted to let you know I'm going to do some more research on this. I noticed you have a service request open with one of our other application engineers, I know that she's escalating this issue, and I'll work on it with her to get you an answer!

aNItaB

Applications Engineer

National Instruments