Due to the open nature of our driver system, it’s relatively straightforward to write a new driver file for almost any imaginable device in Nebula. However, driver development can be a pain, so I though I’d share some debugging tricks.
For all commands, we will navigate to the command line using windows Command prompt or powershell. Here I show command prompt syntax. Nebula is commonly installed under program files. So in the windows start bar type “cmd” and press enter. This should open the command prompt. The commands below navigate to the install location.
First, is the use of logging to the command line. When Nebula is launched from the command line, a series of optional switches can be used to report logged output. By opening this alongside the app, it’s very fast to figure out what or where something is going wrong. To see log output, use –printlog.
c:\Program Files\Nebula>Nebula.exe --printlog
This launches the app, but shows a live log output on the console at the same time.
Get a full list of Supported Drivers
This command will return a complete list of drivers found in the Nebula supported list. To print this list, use:
c:\Program Files\Nebula>Nebula.exe --listdrivers
Here is live example of that command and the expected result. A list of drivers is shown, press enter to close the listing.
Testing a specific Driver File
Next, let’s load up one of these drivers in the test utility. Now, this is where things get cool! The test utility can load a host device driver, inspect it’s shown devices, attempt to connect them, and even test every sub-device!
So, let’s assume we have a new camera driver we want to work on. The camera should do things like snap an image, show various properties etc. In my example I use a real UVC (web) camera, and inspect the driver. The driver actually pulls the real camera info and even snaps a test image. The goal of this function is twofold, first to validate a given driver, and second to validate the device itself.
For this command we will use –testdriver *drivername* and optionally –port *portname*, for example, COM5
Here we can watch the expected output in real time. Note a new window is spawned to show us the results for these tests.
Testing Host and Sub Devices
Let’s say we have a controller, for example, an ASI or Marzhauser box, which has a Z motor attached. In Nebula, the controller can be thought of as the Host (the resident controlling brain), and the device can be considered an appendage attached to the host. So all drivers must have a Host, but a Host may only have one device. In this example, we use a demo Focus device. First the host is loaded and analyzed, and then, you ca select to test any device provided by that host. I choose option # 1 (focus) and the test runs, even showing my driver has a small error I missed!
Obviously, if you have a driver which isn’t behaving, please contact us – yet I hope these options provide a first-line of interface for power users, so simple things can be corrected and analyzed quickly!
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:
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!
LED Control via Software (PC → LED Controller → GPIO)
A host PC issues serial commands. The LED Controller parses each command and drives a GPIO pin. The oscilloscope captures the resulting digital waveform on PA5.
OSCILLOSCOPE · CH1 — GPIO PA5RUN 1V / div · 500 ms / div
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.
Software-Commanded vs. TTL-Triggered LED Control
A single event fires two paths simultaneously: the PC issues a serial command (software path), while a TTL line drives the controller directly (hardware path). The oscilloscope shows the resulting latency gap.
OSCILLOSCOPE · 3-CH · ALIGNED TIMEBASERUN 1V / div · 10 ms / div
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.
Trigger Switch — Camera-Driven LED Sequencing via Triggerscope
Each time the camera completes a frame, it emits a TTL pulse. The Triggerscope (Advanced Research Consulting) uses that pulse to advance its state machine and re-route its outputs — alternating TTL1 and TTL2 to the LED Controller so LED1 and LED2 illuminate consecutive frames.
OSCILLOSCOPE · 3-CH · CAMERA-SYNCHRONIZEDRUN 1V / div · ~16 ms / div
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.
Thomas Spieker from Opto Gmbh was kind enough to send us a demo assembly of several microscopes made by his company. Opto manufactures a series of highly integrated microscope modules, all provided in a small, integrated form factor.
I was able to work with two different variations. One is a complete transmitted illumination setup with camera and objective at 20x. The second is a reflected light device with integrated LED illuminators.
It’s neat to see such a compact setup on the desk. Using the 20x with a typical gut section stained sample was a piece of cake. Field uniformity on the illuminator was great, and color balance was as expected.
The reflected design unit has both a coaxial and ring-style illuminator position – both are provided in Nebula as control LED options.
Use of the camera was straightforward. It supports 8 and 12 bit readout on a color sensor. I can definitely imagine hooking this up to a small XYZ gantry or even a 3d printer for inspection use. Thanks to Opto for the demo unit!
Here is a video review and live demo of hte unit while running on Starlyte Nebula.
Recently, I had two different requests to support the cameras manufactured by Touptek. Ash from Scientific Imaging was kind enough to let me borrow one for in-house integration and testing.
These cameras support Sony IMX-174 sensors, use a USB 3.1 (locking!) cable, and are straightforward to hook up and use. A GPIO connection is provided for I/O, and some models also have opto-isolated IO as well.
Binning, ROI and bit depth readout modes are also supported.
The camera I had hands on had a color version of the sensor, and while today has been a lot of rain, I was able to get a gloomy scene outside for my demo video below.
For questions on running this camera in Nebula, please contact us at www.starlyteimaging.com
If you are interested in these cameras, please contact Scientific Imaging.
Here is a brief video demo of the camera in Starlyte Nebula!
Starlyte Imaging has completed support for Allied Vision array scan cameras. The driver suite fully supports:
Gain modes
Color & Bit Depth selection
Mono / Color Debayering
This addition enables users with existing cameras to easily integrate Nebula on machines used for inspection, materials processing, and other industrial applications.
Below is a short video introducing the Triggerscope Mini, as well as demonstrating how to set it up in micromanager.
If you’re in a hurry, I’ve also outlined the basic steps below with screen shots.
Connect the triggerscope mini to a USB-2 compliant port, via it’s USB C connection cable (included).
Open micromanager, select the device configuration wizard, and browse to the add device page.
Scroll the device list until you see “Triggerscope-MM” expand that and select the -Hub device.
A window will appear, set the COM port to the port used by the triggerscope mini, and set the baud to 115,200, then click OK.
After a few seconds, a list of components will appear. Note this is for the full triggerscope, so we will only choose the TTL 1-8 Bank, and DAC 1 + DAC 2. Below is a basic chart showing what devices are supported on the mini vs the standard triggerscope.
When prompted for the DAC voltages, only select 0-5V (default), and click OK.
That’s it! Follow the manager to complete the install. Once done, you’ll have the common TTL output control, DAC control, blanking, sequencing and other features of a standard triggerscope!
We had a recent customer asking to solve a rather standard but annoying problem. If I have a manual filter turret, and still want to overlay images, how easy is it to do?
To solve this, we added the ability to drag+drop any image from our capture sidebar into our main view. By adding a demo filter turret to the system config, we captured the real ex, di and em filter settings from the image, insuring metadata is transferred with the images collected. The resulting view is a true multi-dim architecture, saved as an OME set or RGB combined view. Our team made the addition, ran bug testing and edge case validation, pushed the changes and compiled the application in 1 business day.
Being able to react to our customers’ needs in a short timeframe is one of the best parts of working with my team. Nice work!
A few months back, I started promoting a new software application called Nebula. As I introduced it to people I realized that I’d not explained the development or release of it on my website, and so here I’ll take a minute to explain that.
The Why
20 years ago I fell into a career in the life science imaging industry, working for an integration and microscope dealer in southern California. One of my first jobs was installing a copy of software application called MetaMorph. This was an interesting thing to me, having a background in building computers from the days of ISA cards and DOS boot menus.
Metamorph could move things like a filter wheel (then a Sutter Instrument 10-2), and capture images from a camera like the then-new Photometrics 1300 YHS.
It fascinated me to watch the camera snap images with it’s mechanical shutter as the filter wheel switched positions, compiling images into a singular display. I was intrigued by this ability and also how it was used in research.
As time went on, I eventually moved from building the basic systems to maintaining them in-field, and then to offering complete hardware and software systems as a direct rep for the company who made this software, Universal Imaging Corporation.
The Need
What made MetaMorph appealing was the wide array of devices it could control at speed – from stages, to microscopes, to illuminators, basically anything. The company had no specific lockout, and would integrate device drivers for any product.
Over time, UIC was acquired by Molecular Devices, and after a long run ceased offering product sales in 2023. By that time, the industry was somewhat locked into the major microscope companies selling brand-specific products. Further, these companies would refuse support (understandably) for specific competing devices. Yet, this posed a genuine challenge for users:
Once invested into an automated microscope, I am forced to use proprietary software with restrictions, or use open-source software alternatives like MicroManager.
Now, MicroManager is an exceptional suite of software with device drivers, but for customers who want a simplified approach to control, with minimal hands-on configuration, and someone to call when things go wrong, there really aren’t many commercial applications filling the need. This situation led me to conclude that a new company was needed in the industry to:
Provide Custom Integration Support for existing microscopes
Offer hardware driver support for smaller and newer companies excluded by the major brands.
Wrap device control into a simple, easy to use interface
Provide exceptional support for products.
With this in mind, I engaged with my friend and colleague Jacob Gewerth, to launch Starlyte Imaging, and build our core product, Nebula. It’s been a long development process, but what Nebula does is something very special:
The What
We imagined, and have released, a software application geared to capture, and capture alone:
We are dedicated to controlling devices as the priority – it’s all about getting data
Our drivers are completely developed in Python, and our driver standard is open – meaning YOU or any company who wants to, can write device drivers for our software.
Our pricing is approachable and fair – no huge budget outlay for software – we offer fixed licenses, or service-based pricing.
We can support old as well as new devices – many older microscopes are perfectly suitable as a chassis to perform any modern study, they just need to be tied into the capture control scheme.
We also can support data collection and metadata recording from perfusion systems, peristaltic pumps, or any other environmental control device you want to talk to.
More than anything else, I wanted to bring the simple, fair and honest product support I’ve enjoyed providing to this industry for my career. Things fail, mistakes happen, but what makes the difference to me, is the dedication to see projects through, supporting your research, and seeing the project through.
