AustinBlanco.com

Category: Laser

  • Understanding TTL control, Blanking & Device Streaming, and why it matters for your research.

    While this is an old subject in terms of technology, I find that every few years I end up describing it to a new group. Surprisingly to me, every time people seem to appreciate the information, and I think it’s just not covered often in broader imaging trainings. So today I’m writing about a favorite subject of mine – TTL control. To do this I’ll be referencing some fun technology – namely:

    TL:DR

    The Problem

    For illustration of the device control, I’ve captured a few real example frames from my oscilloscope, but also added some simulated oscilloscope examples that I hope will better depict the work behind the scenes for these devices.

    I think it’s most important to frame this in a question,

    When my software controls devices, how fast do they respond?

    Assume we click a shutter button in any software. This can be for a laser, an LED, even an old mechanical shutter. In every case a bunch of things must happen for the end device to actually change it’s state. For that state (let’s say, “OFF” to change to “ON”,

    • the software must accept the command
    • and issue control signals to the device connection.
    • That connection talks to the device controller (normally, a microcontroller)
    • The microcontroller reads the command and does what it’s told
    • The state changes.

    Now, along the way, each device has a communication bus, and each bus has a traffic control system to insure multiple communications don’t conflict. As a result, the timing from the start of the button click to the end is variable – sometimes, up to 20 milliseconds!

    Now, because the software is typically programmed to “confirm” each thing it does, it doesn’t just shout orders into the dark. Instead, the software waits for a confirmation, or acknowledgment, of the command being received, and oftentimes it will confirm the new state is active.

    Consider this means a new set of jobs which must be completed.

    • The device controller changes state
    • The device controller then replies, or reports state
    • The communication connection on the PC receives the reply
    • The software reads the reply, and confirms it’s correct
    • The software continues to the next job.

    And so again, we can see a stack-up of not only delay, but a variable amount of delay.

    If we visualize this in a graphic example like the one below, we can see the software code is sent to an LED microcontroller, the command is processed, and the led illuminates. However, we can also see there is a lot of room for improvement!

    Another way to look at this control is what happens with a typical complex instrument. Below is a video where I control 3 devices. The PCO Camera, a Zaber filter turret, and the Tetrem. Notice how long it takes just to get 3 time points for 2 channels. The exposure is short, that's not the issue - the issue here is of course, the devices need to move, but also each device must receive + process + move + report positions, and this takes a long time.

    TTL Control -> Old + Fast = Awesome

    So what is TTL? Basically, nothing more than an on/off switch! Just like a light switch allows an electrical signal to feed a light, TTL uses a voltage to send a signal to another device. You can find a thorough history on this communication method here if interested.

    What we care about is that we have an on/off control system. Because it's nothing more than a voltage, no crazy translations need to happen for things to immediately react. If a TTL control line is on, or "High", then the device should be doing whatever ON is. Many devices have this input, but few people even know about it! For example, most Focus controllers, XY Stages, Peristaltic Pumps, Perfusion systems, and many other devices like lasers, shutters, and actuators accept a TTL input for control.

    TTL Logic typically comes in 2 flavors. Older systems will use 5V for "on" and 0V for "off". The device being controlled might use thresholds or a midpoint. Some devices, assuming you give them at least 2.5V, will go active. Others want at least 4V or 4.5V before they enable. Newer devices often use 3.3v control. This is the same concept as 5V, just with lower voltages. One word of caution here - before connecting things up, it's good to confirm the logic of your devices. Generally, the amount of power these use is quite low, and signal inputs won't break things - but in the case of an exposed microcontroller pin, you can definitely cook a 3.3v input with a 5V line!

    TTL Blanking - A partial Solution

    So what can be done about this overhead? First, we can consider that the only time we really need the illumination on, is when the camera is truly collecting data. One way to do this is to use the I/O control cables found on most scientific cameras. In my case I routed the expose signal from the edge camera into the Tetrem on a single channel, and then, told the tetrem in my software to use "TTL Control". With these changes, the LED source now waits for a TTL input to go high, before it enables it's emission.

    So now, let's assume that when the camera is exposing, we can enable the LED line. The software can act as a logical "AND" if needed, but the line won't enable unless there is real collection of light by the camera. You can see an example of this below.

    For the example, the yellow line is the camera output, or trigger output, the teal line is the LED B brightness result, and the purple line is the software-only reaction. In this example, we can see the delay (latency) of the response, yet in most software, the purple line will illuminate before the camera exposure. What this means for research is your cells are being exposed to excitation energy, and you aren't even collecting that light onto a sensor! So, we are in effect just cooking cells for fun. NOT GOOD!

    Oscilloscope reading TTL from PCO camera

    Using the Triggerscope for State Control of Devices

    This is great for a single LED, but how can we control more than 1 channel? For this, we would use a logic controller like the Triggerscope Mini! With the mini, the camera expose line is routed to it's TRIG input, and up to 4 output channels are connected to it's TTL control pins.

    Triggerscope Mini with Tetrem Controller for intensity

    With this done, we can assign an active line using the triggerscope. This provides fast easy state switching, and can even be done over multiple devices. Doing this will mean, for this example, we won't be moving our filter cube device. Instead, we would use a multi-band dichroic. However we can switch the LED excitation, and that's how we will gain some speed here.

    In the example above, we see a high speed switch. This is simply by telling the Triggerscope Mini to change channels, instead of the LED. But - there is still more to do to improve our speed!

    Streaming for the Win

    The above example uses the triggerscope via USB, and while we only have 1 device, we are still using a "set + capture + set + capture" type of sequence. What if we just told the camera, "run as FAST as you can." Then, we used the output signal from the camera to count frames, and we told the triggerscope, "every other frame, switch from LED 1 to LED 2, then back to 1". THIS is the power of "Streaming", or also called "Sequencing". With this capability, we pre-load stuff to do into the triggerscope. Then, we arm the triggerscope. With that done, our triggerscope is sitting, locked into a state, simply waiting to receive camera frame TTL inputs. Below is a graphical depiction of this technique.

    Now, we tell the camera, "Give us 2 channels * 10 frames = 20 pictures, and do so as fast as possible". In effect, "give us video of 20 frames".

    In this method, there is zero control overhead. The camera free-runs, the triggerscope switches, and the LED reacts. Below is a video example of this, note also there is a small in-view live feed from a web camera (for all these video samples), and you can see that, indeed, streaming is crazy fast! For the below example, we've tied the camera "transfer" line into the triggerscope. This way, the triggerscope recieves a brief pulse before capture occurs. We enable on the "low" side of the signal, and illuminate. You can see for the CMOS style readout on the left of the example, once readout is done, the channel switches.

    So what does the above look like in real life? Check out this example below! Note that I select in my "lambda" control box the "Stream" checkbox. Then once start capture is pressed, the triggerscope is armed, the camera is readied, and we snag 20 images in < 300ms!

    Of course, we can extend this using the 5V DAC control line on the triggerscope for capture of Z as well as channel, and if using the more capable triggerscope 4B, we can control even more devices.

    I hope this article has helped explain not only why I make devices such as the triggerscope, but also how it's important to use software that provides complete control for your light sources and other devices, as well as the ability to do things like this. My sincere thanks to Excelitas for lending me the Edge camera and Tetrem LED, both of which have worked flawlessly on my system. Nebula has drivers for both products fully integrated for streaming control if you have interest in using it.

    -Austin

  • xTool Conversion utilities

    We are about to announce some new products made using the amazing xTool UV laser engraver. Along te way, we needed to convert the 3d files used on the system to SVG. I figured I may as well share that, and so you can find it on my github here .

    Of course, the first thing I made using this engraver was a 3D engraving of the USS Enterprise 1701-D inside of a BK7 Prism. Because why not?!?!

  • Optical Design comes to the iPad!

    Over the past 5 years, almost every project I’ve worked on has required some level of optic design. In many cases, simple designs suffice. For example, projecting an LED can be accomplished at a basic level with an aspheric condenser. But when designs require flat fields, especially corrective elements, or apochromatic performance, it’s time to leverage commercial tools like Zemax. Luckily, I have one of the best Zemax gurus on the planet on hand for such work. But there is a middle ground where I want to work on designs I’d call basic+. This is where there has never been a clear solution. In such cases, the best compromise is to buy experimental grade lenses, and test them empirically.

    Obviously this presents 3 problems:

    • shipping time + setup time = a long iterative design process.
    • when issues are found, the only solution is to snag a few more lenses and test, vs.  modeling a solution.
    • The end result is “good enough” , but it’s unknown as to where other improvements may be found.

    So imagine my surprise when I found an app for ray tracing and modeling, in the App store! Too good to be true – has to be a joke, right? Nope – Check out this short example, showing the Nikon 105mm SLR lens.

    [youtube width=”600″ height=”365″ video_id=”KPwETNTQfFI”]

    You can read more about RayLab here – http://www.raymak.com/wp/  or can download it on the app store here.

    The basic app is ~ $2.00. Adding all of the features will run just under $30. Considering that the cheapest alternative runs ~ $1500, this is an amazing deal. Anyway – I hope others find this as useful as I have!

    Oh one more example – here’s the optical design for a Zeiss 40x objective! Cool huh?!?!

    Zeiss_40_Raylab

    -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

     

     

     

Social Media Auto Publish Powered By : XYZScripts.com