Category: Arduino

  • Mac OSX Serial Terminal for ARC

    I’ve long wanted to build a terminal and testing application for my products. Using the exceptional QT Creator, I was able to cook one up in a relatively short period of time!
    This application was built using the QT Terminal example program, so it will work for the ARC Triggerscope 2, 16, and Triggerscope 3 products, as well as the ARCLED.
    In addition, anyone using an Arduino or other serial-based device may find it useful. You can find the program on my Github.

    I am aware that the vast majority of end users rely on Windows for control of devices, so if you read this and have an interest in a compiled x64 version, I’d be interested to know.
    Over time I plan on expanding this application to include full configuration over delay timing, sequencing, and other functions.

    Quick Demo of the program
  • DIY Syringe Pump

    Interesting little project.

    Not sure the money pans out considering how much time it would take to build, but if one wanted to learn mechanical control, this would be a good way to dive in!

    https://www.drdflo.com/syringe

     

  • A serial monitor that works in Win7x64!

    David Biggs at KB Imaging LLC put me onto this serial monitoring software, called SUDT Accessport . I’ve used it a bit for some work on the triggerscope, and it works very well! You can watch data transmitted between USB emulated serial ports, under RS-232, and it will output the communication in either ASCII or HEX. I hope others find a use for it!

    -Austin

     

  • How to use external triggers on scientific and industrial cameras

    Controlling a camera from an external trigger can be very useful. External triggering provides greater timing accuracy, direct control over exposure duration, and remote operation from TTL devices. This is a prime reason I made the Triggerscope controller, so I though it would be useful to explain how this works and what you can do with it.

    What is “triggering”?

    Most cameras built for scientific imaging or life science have a high density connector located on the back. 90% of the time, this is only used by savvy customers, or OEM integrators (companies buying a camera to place inside a machine for resale). The connector on the back of the camera will typically include 2 basic functions: Inputs (connections which send signals into the camera) and outputs (signals which activate when the camera is in a process or cycle).

    Why use Triggering on a camera? Doesn’t the software control image capture?

    Of course, software can tell a camera to snap an image. But when will that image be captured? Software needs to do more than say “snap” when you capture an image. Behind the scenes, a LOT of stuff happens!

    • the top level controls you see are converted into camera-specific commands via the camera “device driver” in your software.
    • The camera commands are fed into a control card or USB port and up to the camera.
    • The camera accepts the commands, which activate sets of tables in the camera firmware, to set up a sequence of turning on and off clocks and transistors at very high speed, all depending on your binning, ROI, etc.
    • The camera performs the above operations, and sends back an image.

    What is quickly apparent is how much has to happen to get an image. In addition, the camera firmware will process some instruction sets faster than others! So some exposures might come back 200ms from issuing the “snap” button, while others will return in 130ms, 30ms, who knows!

    So when precise timing is desired, and you really want that camera to fire at a specified time, triggering may be used. In this configuration, all software comms with the camera are pre-compiled, everything’s done. All of the steps above are performed, but the last step, the “camera performs operations above” sits….and waits…for the trigger line to run from 0 Volts to 5 Volts. As soon as that happens, an image is captured.  For single frames, this is somewhat useful, but for sequences, this is great. We can capture images at some interval with 100% confidence timing is accurate.

    Example

    Let’s look at a typical camera, and pull the information we need from the user manual, in order to better understand triggered control. For this post, I’ll use the Photometrics CoolSNAP MYO camera, and as Photometrics makes it easy to read up on the user manual for their products, you can find the user manual here.  Page 21 of the PDF describes the various operating modes for the trigger input. Note, the PDF also gives us information on EACH PIN used in conjunction with input and output signaling. There’s more than one!

    Screen Shot 2016-01-15 at 2.33.15 PM

    Note, PM also provides short descriptions for each pin:

    Screen Shot 2016-01-15 at 2.33.29 PM

    So – now we know which pins communicate which functions from the camera head connector – to connect to any of these, we’d simply connect a ground wire, and a positive pin wire to our chosen camera pin (for our needs, say Pin 1 – Trigger In)

    Now – the most pertinent for us is the trigger in line, which runs in a few modes.  Let’s review each, and why we might use them:

    Trigger-First (sometimes called other things like “Fire”)

    In this mode, the camera is set to snap some # of images (let’s say 10), but waits for a trigger input. Once that input goes high, the camera snaps 10 images as quickly as possible.

    Strobe

    In this mode, the camera is again configured for some # of images, but every image waits for a trigger.

    Bulb

    In this mode, the exposure time for each image is controlled by the input trigger. Again, multiple images are assumed (although Image qty of 1 is acceptable), and each frame waits for a trigger input pulse.

    These three modes constitute the majority of uses for a typical triggered input line.

    So, what does “receive a trigger” actually mean? Good question!

    Triggering = TTL Control

    Cameras, like almost all computer systems, are made to interact with external systems. One of the oldest, and most common methods, is referred to as “transistor transistor logic” or TTL. This boils down to the concept that if we specify an electrical voltage value of X as “off” and Y as “ON” then we can remotely flip a switch.

    Many imaging devices use this communication method. A simple uniblitz shutter for example, can accept USB/serial data to open and close the shutter, but using TTL is faster and simpler. (just one thing to do, send 5Volts or 0Volts.) Below is an oscilloscope capture of such a signal. The vertical scale = Voltage level, and the horizontal scale from left to right = time elapsed. My annotations are in red. Note the yellow line, which indicates the signal.

    ttl_example

    Example Signal

    Let’s say we have a device, for now, it’ll be the triggerscope 2, which is connected to the “TRIGGER” line of our camera. We want to signal the camera to capture immediately after we turn on an LED. In this case, we might use the triggerscope line 1 for the LED on and off, and line 2 for the camera signal.

    In our software, we’d specify the camera exposure time, binning, and other usual parameters. In our controller, we’d set the output to high when we wanted to capture our image. Let’s use an example of 1 image:.

    Tell the camera to acquire using software (nothing should happen yet!)

    -Camera waits for a trigger signal

    Tell our triggerscope to send a TTL high

    -Camera captures an image.

    Tell our triggerscope to send a TTL low

    (nothing changes)

    The above sequence can be used for a series of images. In that case, the acquisition would be configured for some # of frames (say 10), and the camera would capture 1 frame each time the signal swung from low to high.

    To tie everything together, I’ve recorded  quick video explaining this on the scope. Check it out!

    [youtube width=”600″ height=”365″ video_id=”4KNe5GxpuOo”]

    So – now you know how cameras can be controlled via TTL – if anyone has questions please comment below, so I can address them. Thanks!

    -Austin

     

     

     

  • Acquisition Speed Comparison of MetaMorph, NIS Elements, Micro-Manager

    How fast can a typical imaging system really run? What factors affect this? While most research might not require rapid sequential capture, almost all experiments can benefiet from tight exposure/illumination timing, yet few microscope users are aware of timing delays injected into experiments by the control software they are using. So how much delay is caused by software? I’ve long wanted to look into this, and finally got the chance!

    In order to accomplish this, I programmed a microcontroller to accept commands from the Lumencor Spectra-X. This high power/high speed LED engine is popular for fluorescent excitation, as a result, almost every available software application can control it. I set up my code to measure the time in which a known shutter, or known wavelength command was received on the serial line (well, USB serial).

    The team at Technical instruments were kind enough to loan me the use of their equipment, so a generous thanks to Reese Allen and the entire Technical instrument staff!

    Experimental conditions were as follows:

    • All software packages were installed on a clean OS install of Win7/x64
    • Test machine was a Dell Precision series
    • Tests were performed by configuring the camera to run ~100fps. This was accomplished using a 4×4 binning, and an exposure of 9.8mS.
    • All software applications were set to send at minimum one shutter and one wavelength change per acquisition cycle. (i.e. 1 picture from the camera, + 1 wavelength change + open shutter, then switch wavelength and cycle shutter).
    • All applications were first tested in a “free run” mode, to confirm the camera configuration was capable of 100fps at minimum.
    • No other devices were installed for these tests.

    The results were quite interesting:

    Software
    NIS Elements V4.30
    Micro-Manager V1.4.22
    Metamorph V7.8.12
    Metamorph Streaming
    Average Overhead
    60mS
    71mS
    65mS
    11mS
    Max FPS
    16
    14
    15
    90

     

     

     

    Here are some videos showing each of the programs performing. You can see some timing variation (likely caused by my capture device) but the averages are easy to resolve, and they correlate to the speed seen on the captured image stacks.

    NIS Elements

    Micro-Manager

    MetaMorph

    What becomes quickly apparent is the influence of asynchronous device control using metamorph’s “Stream” function. This is making use of a patented computer-based device sequencing technique. This technique waits for a camera “event flag” (interrupt) to fire, and when it does, a pre-defined set of events occur which control devices. This is similar to what many external trigger devices do, such as a configured national instruments card , or a pulse oscillator, or the triggerscope. The key difference here is that an external card and/or device isn’t needed, this occurs within the PC itself.

    Some further thoughts:

    • Micromanager is a great open-source competitor to other pay-for solutions. Good speed performance for a low up-front cost! (the cost of setting it up!)
    • It’s interesting that this never really seems to come up for 90% of customers who purchase “high speed” devices. Either the exposure times needed for acquisition of dim signal are so long as to never reach the speed thresholds shown here, or the capture frequency needed for a given study doesn’t require these speeds, or some other cause, but in my experience this is rarely a complaint on behalf of clients. Why isn’t this a bigger problem?
    • Many, many devices can’t reach the speeds shown here. In my tests I was using an LED driver. LED’s should have a switch time in the <5mS range. The slowest components usually found on a common automated microscope are the filter wheels and turrets, which usually run at the 50ms range when fully loaded with filters. (that’s on the fast side). So is this the reason the problem isn’t exposed more often?
    • By far, the slowest components you’ll find for microscopy are found on automated microscopes. Shutter open/close times on a common scope (i.e. big 4 name brand scope) can be in the upwards of 100ms! Moving a big filter turret usually takes 200mS. Again, this begs the question of how important speed really is for the common researcher….
    • For those who want the fastest possible speeds, have no fear! I’ll be announcing some major improvements to my triggerscope soon, to include programmable high speed sequencing capability!

    -Austin

     

     

     

  • Sub $2 microcontroller solution

    I’ve been working with Arduino boards a lot lately, and they are great. But some elements of the arduino can be even better.

    What is an Arduino?

    An Arduino is a breakout board for the Atmel “ATMega” series of microcontrollers. These microcontrollers allow for high speed measurement of analog and digital signals, as well as high speed output of analog and digital signals (well, quasi-analog using PWM, which is another post). So, the arduino houses one of the ATMega Chips at heart, and provides things like a voltage regulator, Serial – USB adapter, 1mm pin connections for several of the chip’s pins, and other nice to have or required-for-operation items one might want or need for these chips.

    Now, there are large Arduino boards with a great number of pin connections, like the Mega2560. This board has a ton of capability,

    Arduino Mega2560 pinout Diagram from Pighixxx

    with a great array of connection options. On the other hand, there are super small but capable boards like the RedBearLabs Blend Micro – which includes BOTH an ATMega ship and a BLE transciever!

    But each of these options has drawbacks, cost being one. The Mega is around $45, and the nano or tiny boards even without BLE are ~ $11. Yes, this is cheap, amazingly cheap considering the capability they provide, but if you want to integrate these into several projects, this cost aggregates rather quickly. So, can we go cheaper? In many cases, the answer is yes, and it can be found in the excellent little ATTINy series of controllers.

    ATTiny pinout

    The ATtiny85 is excellent for sensing a few lines on input, and driving a few outputs, like an LED, or speaker. For powering the IC, I prefer using a USB cable, which usually provides a clean source of 5V power.

    Now, to program the IC, you’ll need a programmer. The folks at Arduino have conveniently included an option for “Arduino as ISP”. Basically, you use the communication lines on an existing arduino to program your Attiny. I’ve found that a homemade shield makes this easy, as when you need to program an IC, you take any arduino laying around, drop the shield + chip on, program, and then continue using the arduino board for whatever project you’ve got. An example of a shield for an Arduino mega can be seen below. It took maybe 15 minutes to get this wired up – not a pretty solution, but fast and easy to use.

    IMG_4253

     

    Of course, you don’t need a shield to program the IC’s, a breadboard and some jumper wires will do.

    Once you have the IC programmed, it’s a matter of popping it out of the socket (or breadboard), and placing it into whatever socket you use for your project!

     

    There are numerous examples online of how to program these chips, a few of which I’ve used as guides. I like the one here, and there’s a nice video showing the general process here:


    Anyway – if you do plan to tackle this, just make sure to follow the directions for your specific version of Arduino IDE – there’s a big difference between v1.6 and the earlier version(s). ***IMHO, V1.6 is WAY easier to set up.

    -Austin

     

Social Media Auto Publish Powered By : XYZScripts.com