Continuous sampling at 100% duty cycle with external trigger per capture?

[DrGomer]

Let me "dumb down" the description.

Say I have a function generator that has a 100Hz sawtooth and a corresponding 100 Hz TTL pulse

I have an X series daq USB-6361.

I want to acquire the 100 sawtooth with 1000 sample points. 

This is easy to do with finite sampling in a loop. each acquisition is triggered by the TTL with trigger regeneration, no problem. Except the start-stop process has a ~40ms reset. So instead of a process loop operating at 100Hz, it only operates at 25hz and all data during that ~40ms reset is discarded. 

if I do continuous sampling with the TTL start trigger, it is fine on the first capture, but because the clocks are perfectly synchronous, they slowly drift out of phase with each other (the sawtooth drifts through the captures rather than starting always with the TTL edge).

is there a way to get 100% capture of every sawtooth ramp in real time?  I'm sure it has to use some sort of buffer since where one ramp ends, another begins.

Thanks!

[Kevin_Price]

Dunno where things are going wrong since you didn't post any code.  But it sure seems like this should be plenty doable with a simple continuous acquisition task.

Probably the easiest thing is to capture both sawtooth and 100 Hz pulse on 2 different AI channels in the same 1000 Hz sampling task.   If both are sourced from the same function generator, the signals should maintain sync.  And if you capture both with the same AI task, your data should retain that sync.

Whatever time drift you see is likely caused by something about the code you didn't post.  But you should be able to try this out directly with one of the shipping examples for continuous voltage acquisition.

-Kevin P

[DrGomer]

Sorry about that. new to posting here.  I have attached the code and a screenshot of the backend, and front end.  The Finite always is synched.  The Continuous shows the desync after about 10 seconds of acquisition.  The signal keeps drifting left if I let it keep going since the clocks are slightly different.

The finite should be 100hz but because of the start-stop delays, it can only manage ~20hz. The continuous is 100hz since it uses the internal clock but only uses the function generator TTL to start the acquisition initialization.

[Kevin_Price]

I really have no idea what you mean by "synced" or not when you post pictures of plots that show data from only 1 source.

I again recommend you start from the shipping examples, acquire both signals in the same task, and iterate your reading loop at something more like 10 Hz than 100 Hz.  This is a good rule of thumb even for desktop devices but *especially* for USB devices.

-Kevin P

[DrGomer]

What I mean by synced is that if I have a 100hz saw tooth and set the daq to 100hz acquisition, I'd want the sawtooth to  not move over time.  ie, the falling edge is the start of the scan. How continuous behaves in the above, is that it drifts. This is the case also with the shipping examples using continuous.  With finite, it doesn't but the start-stop in the loop adds a delay for not 100% duty cycle. 

[Kevin_Price · Accepted solution]

Oh, ok.  Now I think I understand better.

Your first screencap was the closest because you were configured for hardware-based retriggering from the TTL signal that's sync'ed to the sawtooth waveform.  Here's what else you need to do with it:

1. Start the task before the loop, Stop the task after the loop.   Inside the loop you should only Read.

2. You should set your buffer size so it's nearly, but probably not quite 10 msec worth of samples at your chosen sample rate.   Right now you're showing a 1 MHz sampling rate but let's reduce that down to 100 kHz for now.  That'll get you 1000 samples in 10 msec. 

    I'd probably choose a starting point of reducing that by maybe 1%.  Let's try configuring for 990 samples.  Under Finite Sampling, the task will need to acquire this many samples before it will consider itself done and then re-arm the trigger. 

3. Wire that same # as the 'number of samples per channel' when you call DAQmx Read in your loop.  That'll give you the first 99% of the waveform, leaving just a little breathing room for the task to re-arm before the next trigger while you to clear the buffer to make room for new data.

4. Alternately, you could go ahead and capture the full 10 msec worth of the waveform, but that may not finish until just barely after the next triggering condition, so you may end up only capturing every 2nd cycle.  Depends what's most important in your app.  Would you rather capture 99% of every cycle or 100% of half the cycles?

-Kevin P

[DrGomer]

Thanks Kevin, I'll give that a shot and report back when I get to it again.

[DrGomer]

Kevin, just wanted to give you an update that your suggestions work and this is issue is now solved. Appreciate your patience and guidance with this one. (I normally don't use an external trigger, so this is was a little different than my norm).