Sync Bpod with microscope frame acquisition

Thread Rating:
  • 1 Vote(s) - 5 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Sync Bpod with microscope frame acquisition
#1
Hi Josh,

I would like to do imaging while controlling behavior with Bpod, but I am not sure how to sync the two acquisitions. I connected the output of the frame trigger that is sent by the microscope hardware to one of the digital inputs of Bpod, but I am missing pulses (the number of frames acquired is higher than the TTL pulses detected with Bpod). What is the best way to do this?

Thanks,
Sara
Reply
#2
Hi Sara,


If the output is a stream of 3.3V or 5V TTL pulses, you should be seeing the correct number of frames.
How does your microscope encode frame onsets? 
Does the line rest high or low? 
Does the logic level switch with each subsequent frame? Or does it pulse for some fixed duration at each frame onset? 

The state machine may miss pulses that are less than 100 microseconds long (this is its update interval) - so if your microscope indicates frame onsets with a 50-microsecond pulse for example, you may see intermittent timestamps. To be safe, make sure all pulses are 150 microseconds or more.

-Josh
Reply
#3
Hi Josh,

Thank you for your quick reply. In fact my frame TTL signal  meets all the conditions you describe. The frames I am missing actually occur in between trials. My guess is that there is no way of getting that info, so I am planning on just calculating how many frames I lost in each trial transition and discard those from the imaging data. Could you confirm if this is the only way to deal with it?
Thanks!
Sara
Reply
#4
Hi Sara,

I can think of two ways to solve this - 
1. Re-design your protocol to use TrialManager. This should reduce the dead-time between trials to ~200-500 microseconds; less than 1 frame

OR

2. If your microscope hardware has a TTL input, you can have the state machine send sync pulses from any available digital output (e.g. BNC, port LED). That way you'd have timestamps for Bpod events on the microscope clock along with the camera frame timestamps. The sync channel can either toggle its logic level once per trial (precisely indicating trial start and end), or once per state, indicating each state's onset time. To configure the channel and sync scheme, open the settings menu from the Bpod console and click the 'sync' icon.

-Josh
Reply
#5
Hi Josh,

Thanks. I didn't know about the TrialManagerObject, and I will try it, because I noticed that in my current protocols the 'dead-time' is short in the beginning of the session, but it increases drastically in the first ~50 trials and from then on it varies from trial to trial between 1.5 and 2 s, which is something I would like to avoid anyway (with microscope or not).
Thanks,
Sara
Reply
#6
(01-24-2019, 04:34 PM)Sara Wrote: Hi Josh,

Thanks. I didn't know about the TrialManagerObject, and I will try it, because I noticed that in my current protocols the 'dead-time' is short in the beginning of the session, but it increases drastically in the first ~50 trials and from then on it varies from trial to trial between 1.5 and 2 s, which is something I would like to avoid anyway (with microscope or not).
Thanks,
Sara

Hi Sara,

Dead time is partially caused by saving your session data to the hard drive at the end of each trial (e.g. with SaveBpodSessionData). As the session data structure gets larger, it takes longer to save each time. Optionally you can configure your code to call this function once every 20 trials, or only at the end of the session (with the risk of data loss if there's a power outage).

If you really need speed, you can also store your data manually, with low-level file read/write functions: fopen(), fwrite(). These are much faster than SaveBpodSessionData, but you will have to manually write each byte of data you want to store, and read each byte back to recover the data.

You'll probably be best off using TrialManagerObject.

-Josh
Reply
#7
(01-23-2019, 06:37 AM)Josh Wrote: Hi Sara,

I can think of two ways to solve this - 
1. Re-design your protocol to use TrialManager. This should reduce the dead-time between trials to ~200-500 microseconds; less than 1 frame

OR

2. If your microscope hardware has a TTL input, you can have the state machine send sync pulses from any available digital output (e.g. BNC, port LED). That way you'd have timestamps for Bpod events on the microscope clock along with the camera frame timestamps. The sync channel can either toggle its logic level once per trial (precisely indicating trial start and end), or once per state, indicating each state's onset time. To configure the channel and sync scheme, open the settings menu from the Bpod console and click the 'sync' icon.

-Josh

Hi Josh,
I was wondering if the TrialManager object can be used to facilitate two bpods on the same PC? 
If I call each of them with the appropriate com port, and I am willing to tolerate some variable dead time between trials?
Reply
#8
Hi Noa,

With the current software, control of two state machines in a single instance of MATLAB is not officially supported - even with TrialManager.
Unofficially, if you run each state machine in a separate instance of MATLAB, it may work (you want a good, multi-core processor for this, e.g. Intel Core i7 6th-Gen or newer). Also keep in mind that the liquid calibration table uses a single file on the hard drive, so you'd have to run the separate instances with non-overlapping valve numbers for this to work (or calibrate manually).

To use this solution, run Bpod with a serial port argument in each instance of MATLAB, for instance:

Bpod('COM3') % In MATLAB instance 1, and
Bpod('COM4') % In MATLAB instance 2

Here, 'COM3' and 'COM4' are the USB serial ports of your two state machines.

I hope this helps,
-Josh
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)