Running Bpod in parallel to another Matlab process

morana08

Dear Josh,

I'm interested in purchasing the Bpod system for our new behavioural set, however, I wanted to make sure it can work smoothly with our current software.
We do electro-physiological recordings, and our system combines Matlab for experimental protocols and TDT for stimulation.
We planned to trigger the state machine through a BNC input from the TDT machine.

My question is, will it be possible to run both Bpod and our own protocol on Matlab?
I understood the TrialManager function allows for releasing the program between trials, but I'm not sure how to implement it.

Let me know which further details you need to answer me 🙂

Many thanks in advance,
Moran

Josh

Hi Moran,

Some example code using TrialManager are here (see bottom) and here.

If your other software blocks the command line for the duration of a single trial, you could technically do:

TrialManager.startTrial(sma); 
for i = 1:nTrials

    %%% Run your protocol software here (1 trial) %%%%

    sma = prepareStateMachine; % Prepare next trial's state machine      
    RawEvents = TrialManager.getTrialData; % Hangs here until trial end, then returns the trial's raw data
    if BpodSystem.Status.BeingUsed == 0; return; end % If user hit console "stop" button, end session 
    TrialManager.startTrial(sma); % Start next trial's state machine
end

Depending on how your software uses the PC and your PC specs, there is a chance that TrialManager will not be able to check the serial buffer often enough, and the buffer could overflow - in that case you'd see a MATLAB crash. If you run into this issue, you'd be better off running your software and Bpod in two separate instances of MATLAB. Simply open MATLAB twice, and launch each app from the separate MATLAB command lines. If the two instances need to speak with each other, you can either write files for the other instance to read (e.g. to coordinate data file names), or if you need more bandwidth, you can use the TCPIP class e.g. this: https://github.com/sanworks/Bpod_Gen2/tree/master/Functions/Internal%20Functions/TCPCom

-Josh

morana08

Hi Josh,

Many thanks for your swift reply!
I have some further questions after presenting your answer to my PI 🙂

We consider implementing the Bpod this way:
We use our own matlab-based code for stimulation, divided to 5 minute blocks. The PC sends the sounds to the processor while the trial is playing, so there is no delay between trials. This arrangement might prevent us from using the code you provided above, as there is a break after each trial.

During the block, after each trial we want to send a trigger from TDT via the BNC digital input to the state machine, to drip water.
The mouse licks will cause the state machine to send another pulse via the BNC ditigal output to TDT.

We have our own general timer to coordinate the inputs from the Bpod and our own systems.

and now to my questions:

1) in general, it seems like we don't need to collect the data from the state machine after every trial, as we are using the output channel. am I right? or am I missing something?
2) if we do need to - can one collect the current data <during> the current trial, in real time?
3) last - in case we only check the buffer every block: how large is the memory allocated for each event in the state machine, and how big is the serial buffer the state machine has? assuming a block of 300 seconds, we evaluate a maximal number of 3000 licking/dripping events.

many thanks again 🙂

Josh

Hi Morana,

The state machine must run a state machine description (i.e. a trial) in order to accomplish the two things you want:

1. Translate incoming TTL signals to valve output.
2. Translate incoming lick events to TTL output.

Example state machine descriptions are available here, and example behavioral tasks (including their own state machine descriptions) are here.
For your task, you'd want a two-state description as follows:

-Configure one global timer to control your valve (e.g. here), and set the timer's 'Duration' property to the time you want the valve to remain open.
-Create your first state. Its job is to trigger the global timer (e.g. the 'TimerTrig' state in the valve example above). When complete, go to the second state.
-Create your second state. In this state, go to the third state if there is a 'Port1In' event (a lick).
-Create your third state. This state outputs the TTL back to TDT, and returns (after TTL duration) to state two.

TrialManager automatically uses a MATLAB timer object to check the serial buffer every hundred milliseconds or so. This rate is sufficient for an event stream from the state machine at _~1kHz. Technically you could request more frequent polling, but my concern is that MATLAB will delay the timer callback if the processor is too busy - especially in older PCs with 1 or 2 cores. Ideally you'd use a quad core (or better) Intel CPU.

-Josh