Psychtoolbox with Data Acquisition Toolbox - data acquisition on hold while looping over frames

Hi!

I’m writing to ask for some advice concerning the use of Psychtoolbox in combination with MATLAB Data Acquisition Toolbox.

We are training head fixed mice in a visuo-tactile task in which the animas have to lick for specific combinations of visual and tactile stimuli to receive liquid reward through a spout.

We are using MATLAB Data Acquisition Toolbox to interface with an NI card for controlling delivery of the tactile stimuli and the read out of the licking output of the animals while Psychtoolbox handles presentation of visual stimuli (that being moving require looping through multiple screen flips).

Our problem is that while the main listener function (Data Acquisition Toolbox) coordinating the flow of inputs and outputs during the experiment is executing the loop to present the visual stimulus (using Psychtoolbox) the flow of input/output signals remains on hold.

This is a problem because it prevents us to detect mouse licks occurring during the presentation of the visual stimulus and to send the trigger signal to timely reward them.

Does someone know a trick to go through the stimulus animation loop without freezing data acquisition in the meantime?

Thanks a lot for your help!

Giulio Matteucci

Postdoctoral researcher in Sami El-Boustani’s Laboratory

Department of Basic Neurosciences,
University of Geneva, Switzerland

Have a look at async flip support, cfe, AsyncFlipTest.m. If you are using Linux + AMD or Intel graphics (or anything not requiring the NVidia proprietary graphics driver, e.g., older NVidia graphics cards, or the RaspberryPi microcomputer), then that additionally allows to use non-blocking regular flips and get timestamping info logged and read back asynchronously, which is even better, but not possible on inferior operating systems like Windows or macOS. Cfe. PerceptualVBLSyncTestFlipInfo.m or PerceptualVBLSyncTestFlipInfo2.m

Both methods allow to not block until a flip completes, so you could continue sampling whatever with that data acquisition toolbox. At least i assume that’s your problem? I don’t have experience with Matlabs toolbox itself, maybe there are also other ways to collect data in the background?

-mario

1 Like

MATLAB cannot easily run different tasks in parallel (the parallel programming toolbox is really designed for running code tasks across data in parallel). One solution is to run two separate MATLAB instances, one for DAQ and one for PTB display. The two MATLAB instances can communicate with each other via TCP. I do this to interface with an Omniplex DAQ from Plexon: https://github.com/iandol/opticka/tree/master/omniplex

Monkey logic uses its own DAQ toolbox (but they have poor graphics as they use a DirectX library for display), you can perhaps look at their code how they do this:


1 Like

Hi Mario,

Thanks a lot for your reply.
Yes exactly, what I need is a way to avoid blocking everything during the flip loop, so to continue sampling with the data acquisition toolbox. For now I didn’t find a way to collect data in the background with the DAQ toolbox.
Unfortunately the computer that runs the behavioral experiment is Windows. I could think about changing OS but on the same computer we use other proprietary software that I’m not sure with be fully compatible with Linux.

Best,

Giulio

Hi!

Thanks a lot for your suggestion! It looks promising, I will definitely look into that.

Best,

Giulio

There’s always the option of dual-booting Linux and Windows. Or even running Windows inside a virtual machine inside Linux if the proprietary software can tolerate VM operation and its constraints.

But if you can’t use Linux, the async flip method also generally works on Windows (unless Windows graphics driver bugs would interfere) and should solve your problem.

-mario

Btw., it would be useful to know what exact type of DAQ / IO cards etc. people are using for their work.

I think having better (as in much better integrated, convenient to use for typical PTB scenarios) I/O support in PTB than what the various custom solutions and Mathworks toolboxes have to offer would be very useful. I don’t know when i will find the time to work on that. Certainly not this year.

But if somebody wanted to contract us to work on a proper solution, i’d certainly be interested. It needs to be funded by someone. In the meantime, maybe collecting a list of commonly used hardware maybe on the PTB Wiki or similar place would be helpful to know if there are certain devices to focus on. Also the specific set of functionality needed, because i’d focus on important subsets of functionality first.

-mario