Analog Output Failure

[dmhuffman2010]

Hello everyone,

I need some help with generating analog output.

In one loop, I am reading in 2 signals (400 samples @ 400 Hz) and passing them to a queue.  A second loop, I am analyzing and classifying these signals into 3 states. Since I am reading 400 samples @ 400 Hz, I am performing classification once per second.  If the classification is equal to a "target" classification, I have a boolean flagging detection.  If detection is on, and a "stimulate" button is also on, I trigger another boolean flagging "stim".  If "stim" is true I want to write an waveform to the AO channel

 This analog output is carried out by a third loop. In this loop, I am initializing an AO channel (500 samples @ 10k Hz) and generating 500 points of a sinewave to be written to the AO channel.  If "stim" is false, it multiplies the sine wave by zero (well actually is multiplies it by an exponential decay, but we'll say zero). If "stim" is true, then it passes the sinewave through to be written to the AO.

With this configuration, the VI will run, but after an indefinite amount of time the AO will stop being physically generated.  I probed for an error and found "DAC conversion attempted before data to be converted was available...".  A colligue suggested I try configuring an AO buffer as done here.  Playing with number of samples per write, sampling rate, and buffer size, I now have a VI that runs without dropping out, but that has a 300ms delay before its written to the AO channel.

Does anyone have any suggestions as to how I can make this AO generation more "responsive" to when it is triggered by the "Stim" boolean?

The VI and all necessary sub VIs and files can be found in the zip file attached.

[DiegoH214]

Hello dmhuffman2010

THe issue you were having is that you were generating faster than you were acquiring. If you cannot change the rates of your DAQ tasks then is expected. You can try sending less points to the AO to avoid the buffer taking so long to get the data it needs.

Diego Hidalgo

Applications Engineer

[dmhuffman2010]

Thanks dihidalg,

I tried writing less samples per write to midigate the delay. For example, writing 1k samples at 10k with a 4000 buffer size would run reliably (but with a 400ms delay), but if I dropped it to 500 samples per write with a 2000 point buffer, then the voltage generation dropped out after some time, giving me an error along the lines of "data conversion attempted before data was available".  

Would writing AO at a lower sampling rate help? The reason I am writing at a high rate for AO is because I am sending it to an audio device (of sorts), which produces an alias frequency equal to my sampling rate (i.e. sending a 50Hz singal to the device causes it to vibrate at 50Hz, but it also "rings" at the sampling frequency).  So I am writing at 10k so I can implement a low pass RC filter to get rid of the "ring" while preserving the desired freqency being written to the device. 

[DiegoH214]

What Hardware are you using?

Its an option to acquire faster then?

Diego Hidalgo

Applications Engineer

[dmhuffman2010]

I am reading in through a NI USB-6211.  I'm reading two channels: one EEG and one EMG from an amplifier. I want to read in one second of data, compute features of this data, classify these features based on a model, and trigger AO generation upon a certain class.  The only issue with changing my acquisition is that I have a multitude of filter coefficients that are dependent on sampling rate, so I'd prefer to leave them alone if possible.  

Does having acquisition and AO generation in seperate loops not make them run independently? I thought the only limitation would be that I could only trigger AO on/off with 1-second resolution, since reading in 1 second of EEG/EMG limits my decision making to once per second.  i.e. the stim boolean only changes every second.  I am wanting to reduce the time delay between the "stim" boolean changing state and the AO being physically generated (which to my understanding is finding a happy medium between samples written, sampling rate, and buffer size).

[Kevin_Price]

USB is not ideal when your needs are for low latency.  That alone will limit what you can hope to get from a best-case scenario.  That said, here's a snippet illustrating some DAQmx property node settings that may be helpful.

1. There's a property to tell DAQmx when to move data from the PC's RAM over to the daq board.  You get low latency by having both the driver and your app set up to deliver data just-in-time.  If the AO task requests data from RAM only when it's onboard buffer is empty, then the data it gets will be D/A converted pretty much immediately.

   The trick is that you also need to have your application write data to PC RAM just a little at a time, and just barely before the driver needs to move it to the board.  You may find that DAQmx Events or some other DAQmx properties will help get you there.

2. This little trick lets you read from the AI buffer as though it's a sliding window.  You could query it 100 times a second, each time reading the most recent 1.000 second worth of samples.  This lets you make decisions based on a significant quantity of data but keep re-deciding at a high rate.

   Note: this trick doesn't play nicely with data logging as you will read the same data many times.

3. ??? I'm not sure about this one.  But there's a property node that *seems* to suggest you can control where in the buffer you would write your data.  Not sure that most hardware supports this, but hey, it's something else to experiment with.

-Kevin P