Ideas for parallel input of asynchronous DAQ data

[george seifert]

I'm not sure if the topic title fits exactly, but it sounded kind of impressive. I'm just looking for a general idea here of a direction to take. Any thoughts are welcome.

I have 4 channels of data that I want to sample for 15 msecs. When I start sampling each of the channels depends on a corresponding independant trigger that the code will initiate. For instance, trigger 1 happens so sample channel 1 for 15 msecs. Trigger 2 happens so sample channel 1 for 15 msecs. The triggers can happen any time in relation to one another so for instance trigger 2 could happen during the sampling of channel 1. Part of the problem might be that I have existing DAQ boards I need to use that don't have parallel DAQ inputs.

I was thinking that I have to do a continuous acquisition of all channels and then somehow pick out the data of interest based on a timestamp of when the trigger happened. Does that seem reasonable or is there a better approach?

Thanks,

George

[dthomson]

I have 4 channels of data that I want to sample for 15 msecs. When I start sampling each of the channels depends on a corresponding independant trigger that the code will initiate. For instance, trigger 1 happens so sample channel 1 for 15 msecs. Trigger 2 happens so sample channel 1 for 15 msecs. The triggers can happen any time in relation to one another so for instance trigger 2 could happen during the sampling of channel 1. Part of the problem might be that I have existing DAQ boards I need to use that don't have parallel DAQ inputs.

I was thinking that I have to do a continuous acquisition of all channels and then somehow pick out the data of interest based on a timestamp of when the trigger happened. Does that seem reasonable or is there a better approach?

George,

As a (hopefully) relevant benchmark, I can tell you about a program I wrote some years ago that uses the approach you suggest at the end of your message. It uses a 4 channel 6110 (which has 4 independent DAC's that share timing/triggering). I run all four channels at 5MS/s and grab 200ms buffers of data. I then scan the first two channels for "events" and whenever either channel finds an event, I save a window of data from all four channels around that event. The program can keep up with this data load, including writing the events to disk, up until you get to about 5000 events/second. At that point the duty cycle drops. The program is architected in such a way as to continue running at reduced duty cycle, and writes the duty cycle to another data file for later analysis.

You don't mention your data clock rate, but hopefully that example will give you an idea of what is possible. You could bump it up even more with a faster computer, faster hard disk, and improvements to the memory management scheme. Since you already have DAQ boards, which might mean they are a bit older, and they don't have multiple DAC's, I'm guessing that they are E series, maybe M, but probably limited to 100's of KS/s. If this is the case, it should be possible to write an app that does continuous acquisition on 4 channels and scans the data in memory for triggers.

You can get more info from a paper on my website: Go to www.originalcode.com, under Publications, and look for "SP2". Or let me know if I can be of more help.

Regards,

Dave

[jdunham]

I'm not sure if the topic title fits exactly, but it sounded kind of impressive. I'm just looking for a general idea here of a direction to take. Any thoughts are welcome.

I have 4 channels of data that I want to sample for 15 msecs. When I start sampling each of the channels depends on a corresponding independant trigger that the code will initiate. For instance, trigger 1 happens so sample channel 1 for 15 msecs. Trigger 2 happens so sample channel 1 for 15 msecs. The triggers can happen any time in relation to one another so for instance trigger 2 could happen during the sampling of channel 1. Part of the problem might be that I have existing DAQ boards I need to use that don't have parallel DAQ inputs.

I was thinking that I have to do a continuous acquisition of all channels and then somehow pick out the data of interest based on a timestamp of when the trigger happened. Does that seem reasonable or is there a better approach?

Thanks,

George

Hi George: I have done plenty of applications with complex access to the DAQ buffer. The normal DAQ read mode keeps track of an internal read mark, but if you bounce around in the buffer you will need ot use a different mode and keep track yourself. Just set your DAQmx Read.Relative To property to "First Sample" and specifiy DAQmx Read.Offset and you will get the data you want. You will probably want to request a larger DAQ buffer size than the default to make sure the data is still available by the time your code gets around to requesting it.

You may also want to set the DAQmx Read.Channels to Read property if you don't want all of the channels. You can also query the DAQmxRead.Status.TotalSampPerChanAcquired property to see which samples are currently available so you don't have to wait for DAQmx Read to return or risk a timeout error.

Jason Dunham

[george seifert]

Thanks for the inputs. That helps a lot.

George