Month: January 2016

Leaked pictures show knobby is almost ready

Leaked pictures surfaced on-line this past Friday indicating that the much anticipated release of Knobby is expected very soon.

One Scanbox user that preferred not to give his name welcomed the news: “Finally, as someone trained in patch clamp, I never liked the 3D mouse.  Turning heavy knobs that move smoothly… yes, that feels different!”

The new device features a beautiful 2.8″ capacitive touchscreen for user interaction and independent and simultaneous control of all four axes of the microscope.

The same features previously available in the 3D mouse are implemented in Knobby as well: position memory, zeroing of axes and vertical alignment of the objective, different movement movement modes (coarse/fine/super-fine).  These features are all available via the direct interaction with the unit’s touchscreen.

One advantage of Knobby is that it allows simultaneous movement along all axes and is extremely responsive to the knobs’ movements while still keeping a nice, smooth motion.

The 3D mouse interface will still be available.  A configuration variable will allow the users to select between input from the 3D mouse or Knobby.

Scanbox users that prefer the type of interaction Knobby offers rather than working with the 3D mouse should let us know (send an email to Josh) so we know so we can estimate the number of units we need.


Adding an SLM path for optogenetics

As promised, there has been some progress in adding an SLM path for optogenetics to the microscope and things are looking good…

We are now calling on potential users to provide input into the features that they would need/want in a GUI interface, as this may impact how useful this addition will be to our own work.

At the moment here is our basic plan:

  • Provide a tool to align the SLM and two-photon imaging paths.  This will consist in the user using the camera port to acquire an image of the scan area onto a chroma slide.  The system will then flash a number of single spots on a different slide and acquire their positions to compute the best affine transformation between the SLM image plane and the tw0-photon image.  Calibrations will be required just before the beginning of each imaging session.
  • Once a sample is imaged, provide cell-selection tool to obtain the coordinates of N desired locations in the imaging plane.
  • After cell selection a Matlab-based server will use the calibration and and selected points to accept network commands that describe the desired intensity at each of the N locations and the duration of the pattern. After the optimal phase is computed on the GPU it will be presented to the SLM for the specified duration and the start/end time of the presentation will be logged by the microscope through an event line in Scanbox.

So present and future Scanbox users…  is this a reasonable starting point? As it is, the system would be limited to N (as large as you want) points of different intensities.

Please add  your comments and/or suggestions below.  This is your opportunity to have an input into the design of the SLM path….  don’t miss it!

TTL synchronization

The simplest way to synchronize external stimulation with the microscope data collection is for the user to generate a TTL signal that is HIGH when the stimulus is on and LOW when it is off.

This signal should be split and connected to the TTL1 input of Scanbox and the AUX1 input of the Alazartech card (see diagram below).  This has TTL-compliant signal (do not use 3.3V boards).


The TTL1 input in the Scanbox allows the system to time-stamp the rising and falling edges of the stimulus TTL signal with the frame and time on which it occurred.  The input to AUX1 allows the system to display stimulus markers in real time on top of the traces and save a log of the TTL data along with the real time traces.

If you are using only TTL1, please use imask=2 in your configuration file.  If you are using both TTL1 and TTL0 use imask=3 in the configuration file.  Never enable a TTL event input without having something connected there.

More information here.


Verify the trigger!

You may encounter a situation where shortly after focusing and/or grabbing Scanbox quits and asks you to “verify the trigger”.  If this happens proceed as follows:

First, if  you hear the resonant mirror starting to work (meaning you hear the 8khz tone) when you press focus or grab, skip to the next step below.  Otherwise, make sure the connection from the resonant mirror to the controller is well seated. Also check the connectors to the resonant controller inside the Scanbox.  The resonant controller is the small square board that is mounted on top of the large Scanbox card.  Try scanning again.  If you still don’t hear the resonant mirror working, let us know.

Untitled 6.001

Second, assuming the resonant mirror works, there are two connections that you need to check that may cause this message to appear (see diagram above.)

The first connection runs form the laser SYNC OUT to the Alazartech External Clock input (via a microcircuits filter).  Verify by means of an oscilloscope that, when the laser is mode-locked, you see a clean sinusoidal signal at the input to the external clock with a peak-to-peak amplitude > 1.5V and a frequency equal to that of the laser (typically ~80MHz).

If you are using a Spectra Physics laser, you probably have a video amplifier in-between the output of the laser and the input to the Alazartech card.  Make sure the amplifier is powered and verify the amplitude of the signal. If the signal looks good then proceed to step #3.  Otherwise, let us know.

The second signal that must be checked originates from the Scanbox TRIG OUT SMA connector and must be connected to the external trigger (TRIG IN) input of the Alazartech card. Make the connectors are sitting properly and the cable is Ok.

If, after going through the above procedure, you still can’t get the microscope to trigger please contact us.

Using the quadrature encoder to track locomotion

Scanbox allows you to acquire the position of a rotating platform at each frame of the microscope.  To do so, you need a quadrature encoder to be mounted on the axis of your platform.  We use the US Digital HS-360-IE-S, but any quadrature encoder will do as well.

The encoder needs to be wired to an Arduino board that reads keeps track of the encoder position and gets polled by both Scanbox and a stimulus computer.  The ability of the stimulus computer to poll the position of the platform allows us to close the loop and have stimuli depend on the platform motion.  Having an external Arduino board keep track of the platform position means that the stimulus computer does not have to interfere with the image acquisition at all.

The necessary code for the Arduino can be found in yeti/quad/quad_encoder.ino.  We use the Mega 2560, but most of the other boards will do as well.  You need to download this Encoder library and install it in the Arduino/Libraries directory before compiling.

The default connections are as follows:

US Digital, 5V (red)  goes to Arduino, 5V
US Digital, GND (black) to Arduino, GND
US Digital, A (white) to Arduino, pin 2
US Digital, B (brown) to Arduino, pin 3

Once the program is uploaded into the Arduino the board will show up in your Device Manager as a COM port.  Then you can edit the quad_com variable in the scanbox_config.m file to include this information.

Now, when you start Scanbox the encoder is ready to be used.

While focusing and/or grabbing, and if the quadrature encoder checkbox is enabled, you will see the absolute position of the platform displayed within the encoder panel.  The program automatically resets the value to zero at the beginning of imaging. If you are grabbing data, Scanbox will store the resulting measurements in a separate file that appends “_quadrature.mat” to the name of the file.  The variable in stored in the file is called quad_data, which is a vector of the same length as the number of microscope frames collected. A typical run may look like the figure below, with periods of rest interspersed with periods of locomotion.

encoderFinally, to translate absolute count to position along track one needs to know the number of counts per revolution of your encoder (in our case 4*360=1440) and the radius of the platform (in our case 10cm).  The resulting conversion factor would then be 2*pi*radius / #counts per revolution.  You can store this value in the quad_cal variable of the scanbox_config.m file for easy reference.