Why do I get a timeout error from a call to GetData using an MCC DAQ device?

I'm running a psychophysics experiment in a lab and we just got a new computer to run our programs. Our programs utilize MCC's data aqcuisition hardware. The programs ran fine on the old computer but for some reason, I'm receiving a GetData error on our new one.

Some more background info: I'm using the Measurement Computing's USB-1408FS device and have installed all the necessary drivers. Here's the relevant code and my errors.

AI = analoginput('mcc',0);
chan1 = addchannel(AI,0,'Horiz');
chan2 = addchannel(AI,4,'Vert');
chan3 = addchannel(AI,7,'Trigger');
set(AI,'TriggerChannel',chan3)
set(AI,'TriggerType','Software')
set(AI,'TriggerCondition','Rising')
set(AI,'TriggerConditionValue',2)
set(AI,'SampleRate',960) 
set(AI,'SamplesPerTrigger',960);

Then I get the following error message:

    Warning: This hardware could not support the requested value of 1000.00 for SampleRate. SampleRate has been set to 1000.10.

Then, when I use the GetData command, I get an error (shown below).

>> start(AI);
>> [d,t]=getdata(AI);
Error event occurred at 12:47:48 for the object: mcc0-AI.
A timeout occurred during GETDATA.
??? A timeout occurred during GETDATA.

Error in ==> analoginput.getdata at 200
  [varargout{1:nout}]=getdata(uddobj,samples,dataformat);

[Siddharth Shankar]

1. What version of MATLAB are you using?

2. What platform are you running MATLAB on? (win64, win32, etc.?)

[Radhika]

Try putting a wait before you do getdata().

For e.g.

wait (AI,2)

it is possible that the getdata() is trying to execute before all the data has been acquired.

[Mike]

Hey guys,

thanks for the quick responses.

As for the version of matlab: I'm using 7.10.0 (R2010A).

And I'm running the win32 matlab client on Windows 7.

I tried the wait suggestion but it didn't work. Also, I never got the "This hardware could not support the requested value..." warning on the older computer.

Thanks again!

[Siddharth Shankar]

You likely installed a much newer version of the MCC driver (from their website?) which is producing the warning message that you are seeing. Were you using R2010a on the older machine as well? If not, what version of MATLAB were you using on the older machine?

Either way, I would suggest setting the SamplesAcquiredFcnCount property on the analog input object to a value of 1, and setting the SamplesAcquiredFcn to a custom callback function to detect incoming data (just for diagnostic purposes).

Here's how you might do it:

AI.SamplesAcquiredFcnCount = 1;

AI.SamplesAcquiredFcn = {@customFcn};

where customFcn is something like this:

customFcn(obj, t)

disp('DATA ARRIVED!')

end

Ofcourse, these properties must be configured before you START the acquisition session. When you do this, do you see the message "Data Arrived" within the first few seconds after START?

[Mike]

Thanks again for the help Siddharth.

The old computer was running Matlab2008b and Instacal 5.89, while the new one is running Matlab2010a with Instacal 6.1.

I tried your suggestion with the SamplesAcquiredFcnCount functions, but just to be clear that I am doing it right:

I make a separate script for customFcn, use the code that you suggested, then insert the two SamplesAcquired functions after initializing my analog input but before using the start(AI) function right?

I did that but I'm still getting both errors, the hardware can't support the samplerate and the getData timeout.

[Siddharth Shankar]

Ah, I missed giving you an additional step. Please try NOT using GETDATA. The SamplesAcquiredFcn should be triggered if any data does come in after START (you may need to wait a few seconds). The purpose of this experiment is to see if any data starts coming in from the card a few seconds after the ANALOGINPUT session has been initiated. Everything else you've done sounds correct to me.

Also, I assume that you're able to acquire data from the card using the InstaCal software itself?

Also, since a lot of things have changed in the data acquisition toolbox from 8b to 10a, I would not hesitate to get in touch with MathWorks technical support, just in case they've seen this particular issue before and have an immediate solution / workaround for you.

Answer 1

[Rob Purser]

On the timeout, I'd follow Shankar's advice. The MCC drivers have become careful about validating setup, which may result in longer latencies getting started (but they work a lot better).

On the warning message about rate:

Like the Rolling Stones said: "You can't always get what you want!" The toolbox is forced to adjust the your requested sample rate based on the clock resolutions of the board. You should either use SETVERIFY or GET the SampleRate after you set it to determine the actual sample rate that was selected. The number of channels added may affect the rate that is selected.

The reason for this comes back to hardware clocks on the boards. Most cards offer a number of fixed speed base hardware clocks that are used to drive the timing of acquisition. For instance, the NI E-series cards have 5 base clocks, including a 20MHz and a 100KHz clock. In order to reach a given sample rate, there is a programmable divider that can be set from 1 to 65536. This gives the 20MHz clock a range of 20 million samples/sec (20e6/1) down to ~305.18 samples/sec (20e6/65536). But, these possible rates are quantized: there are only 65534 possible values between those two extremes. So, if you want 1,570,000 samples per second on a single channel, you'll have to choose between 1,666,666.67 (20e6/12) and 1,538,461.54 (20e6/13).

This gets more complex what you add multiple channels to the mix. Now, you need to find the nearest clock rate that is the requested per channel rate times the number of channels you want. So, if you want 80000 samples/sec on 7 channels with a 10MHz base clock, you can only get 84033.61. How'd we get that? 80000 samples/second/channel * 7 channels = 560000 samples/second. The base clock divided by the requested rate gives the ideal divider: 10000000/560000 = ~17.8. The divisor must always be an integer, so we truncate to the lower value (so the sample rate chosen is always higher than requested), which is 17. We then calculate the actual sample rate the card can deliver: 10000000 samples/second divided by the divider of 17 divided by the number of channels 7: 10000000/17/7 = 84033.61.

Note that there are boards that essentially do not suffer from this limitation. Many sound cards and Dynamic Signal Analyzers (DSA) boards have an (expensive) synthetic synthesizer that allows them to acquire at essentially any rate. They are used in audio processing.

-Rob Purser