Thread Subject: DAQ SamplesAvailable never >0 after getdata

I am prototyping a data acquisition system by using the 'winsound' device. The actual device will operate at 200hz and I will need to collect the 200 samples each second, do some processing each minute, and more at each hour. That's a little background.

Right now, I'm trying to collect data from the winsound device at 5000 samples per second. I've borrowed code from the daqwaterfall example in the Complete Application Development class. My thought is to collect the data each second, and I have the TimerFcn being called reliably.

In it, I am using the SamplesAvailable property to see when the data is ready. I use getdata to extract the data...

% timer function
function localtimer_callback(obj,event)

if obj.SamplesAvailable > 0
    x = getdata(obj);
    % do stuff with x
end
...

The problem is that when I use getdata rather than peekdata, the SamplesAvailable is always at 0. The TimerFcn keeps popping along, but there are never any SamplesAvailable.

I have tried this with the SamplesAcquiredFcn as well, with the same result.

What am I doing wrong?

Dave

Hi Dave ,
The callback snippet looks reasonable but there isn't enough code here to know if you're setting up the acquisition correctly.
Whittle your program down to the absolute minimum lines of code to show both the main loop and the callback and post it here (you should be able to do that in under 20 lines of code).
Also, you can post the output of running
daqsupport
(though you can omit the long section with the path - you don't have a path problem it seems).

As long as you've set the acquisition to go as long as you need either via SamplesPerTrigger or TriggerRepeat and started this should work.
All the best,
Sherryl

"Sherryl Radbil" <sherryl.radbil.dontspamme@mathworks.com> wrote in message <hkuaq8$mhm$1@fred.mathworks.com>...
*snipped*
> As long as you've set the acquisition to go as long as you need either via SamplesPerTrigger or TriggerRepeat and started this should work.
> All the best,
> Sherryl

Thanks Sherryl,

I think I found the problem.

ai = analoginput('winsound', 0);
addchannel(ai, 1:2);

set(ai, 'SampleRate', 5000);
set(ai, 'SamplesPerTrigger', 5000);
set(ai, 'TriggerRepeat', inf);
set(ai, 'TriggerType', 'manual');
set(ai, 'TimerFcn', @localtimer_callback);
set(ai, 'TimerPeriod', 0.5);
set(ai, 'BufferingConfig',[5000*2,20]);
set(ai, 'SamplesAcquiredFcn', @localacquired_callback);
set(ai, 'SamplesAcquiredFcnCount', 5000);
start(ai);
trigger(ai);

All the examples had the TriggerRepeat value as 1. Then they would use peekdata to grab samples without actually exhausting that 1. When I set the value to 'inf', it started filling the buffer non-stop.

I hope this solves my problem. I'm not sure what of the above I really need, but I have a start towards development. Any thoughts are appreciated.

Thanks again,

Dave

Hi Dave,
Glad you have it working.
I see two issues with your code.

You should not use both TimerFcn and SamplesAcquiredFcn.
Choose one.

Many programs call getdata() from within a callback and find that they can't keep up when using SamplesAcquiredFcn and SamplesAcquiredFcnCount when data processing time exceeds the data inflow time.
As an alternative they should use TimerFcn and TimerPeriod.
The difference is that SamplesAcquiredFcn callbacks queue up and are never lost while if a TimerFcn callback has not yet executed and another one comes in the previous one is discarded so there is never a backlog. In either case getdata() should get enough data from the engine so that the program does not fall behind. You can check the SamplesAvailable property from within the callback to see how much data is actually available.
As with all these programs it is impossible to give an exact formula on how to set things up. It will depend on the SampleRate and the actual PC and acquisition device in use.

Also, I would suggest removing the line:
set(ai, 'BufferingConfig',[5000*2,20]);
The Data Acquisition Engine will compute the buffering config values for you and unless you are trying to overcome a specific issue you are better off letting the engine do the calcluation.

Other than that your code looks good.
Happy acquiring!
Sherryl

Sherryl,

Thank you very much for your suggestions. As a real-time acquisition program, I am concerned about the throughput of all this stuff. But, ultimately, we'll be grabbing "only" 200 samples per second. The processing of those samples occurs at minute intervals, and more hourly.

The use of TimerFcn and SamplesAcquiredFcn is a result of neither one working for me. Now that I am getting sustained data sampled, I'll get rid of the SamplesAcquiredFcn.

One concern that I have is that the program should get what data is acquired at the minute boundary, rather than waiting for 60*200 samples to be obtained. But doesn't

set(ai, 'SampleRate', 200);
set(ai, 'SamplesPerTrigger', 12000);

mean that I won't get a SamplesAvailable > 0 until I have 12000 samples, even if it takes 61 or 62 seconds?

I guess this issue is outside the topic of this thread, but please know that I have appreciated your help and advice.

Dave Hathaway

Hi Dave,
Glad to have helped. Please see this page about real time and Data Acquisition Toolbox
http://www.mathworks.com/support/solutions/en/data/1-17G8J/?product=DA&solution=1-17G8J

Regarding:
> set(ai, 'SampleRate', 200);
> set(ai, 'SamplesPerTrigger', 12000);
>
> mean that I won't get a SamplesAvailable > 0 until I have 12000 samples, even if it takes 61 or 62 seconds?

SamplesPerTrigger controls when the acquisition stops and not when the data is available.
If you start and trigger the acquisition shown above then pause 1 second and then execute:

ai.SamplesAvailable

you should see close to 200. It may not be exactly 200 because it will depend on what size blocks are being transferred between the adaptor and the engine (see ai.BufferingConfig, first number returned is the block size)
http://www.mathworks.com/access/helpdesk/help/toolbox/daq/bufferingconfig.html

All the best,
Sherryl