Many instruments use more than one camera. A national lab diagnostic may view the same event from two or three angles. A multi-channel fluorescence instrument may split light with a dichroic onto two sensors. A test stand may pair a wide-field camera with a high-resolution one. In each case the images are only useful together if they were taken at the same moment, or at a known offset.
This post covers how to get several cooled scientific cameras to expose together: where the timing should come from, what the sensor does after a trigger, how to keep the data flowing and how to check the result. We use Finger Lakes Instrumentation (FLI) cameras as the worked example.
Why multi-camera setups need a shared clock
Starting several cameras from software looks simple, but it rarely holds up. Each camera runs on its own internal clock, and each command passes through the host operating system, USB stack and driver. Those paths add small, variable delays. Independent cameras also drift relative to one another over a run, so frames that start together do not stay together.
For loose alignment, such as frames that only need to land within the same second, software start may be enough. For anything tighter, the cameras need a hardware signal. FLI's guidance is direct: independently timed cameras drift, and tight synchronization requires an external sync or trigger cable driving all of them.
Drive every camera from one timing source
The cleanest design uses a single timing source for the whole experiment. That might be a pulse or delay generator, the master clock of a pulsed laser or X-ray source, or a motion controller. Each camera's trigger input is wired to that source, so every camera sees the same edge at the same time.
External trigger in and out is standard on FLI Aurora and Revelation cameras, and listed on Kepler and MicroLine data sheets. Trigger outputs are useful for logging when each camera actually acted; check the manual for your model to confirm what the output signals before you build on it.
The same timing source can drive other parts of the system. Our post on fast filter switching for multi-band imaging shows how a filter wheel can step in time with the camera exposures.
Know your sensor's exposure timing
A trigger starts an exposure, but what "start" means depends on the sensor's shutter mode.
In a rolling shutter, each row starts and ends its exposure a little later than the row before. For a steady scene this does not matter. For a fast event, different rows see different moments. In a global-reset mode, all rows begin exposing together, but readout is still row by row, so the end of exposure still varies down the sensor unless the light itself is brief.
Kepler cameras use a rolling shutter with a global-reset mode; they do not have a true global shutter. Aurora cameras offer a triggered global-reset mode as well. For pulsed or flash illumination, global reset works well: open all rows, fire the light inside the exposure, and the short pulse sets the effective timing for every row.
If all your cameras use the same sensor and mode, their timing behavior matches, which makes alignment easier. Mixing sensor types is possible but means characterizing each one.
Account for trigger delay
No camera starts exposing at the exact instant the trigger edge arrives. In triggered global-reset mode, an Aurora camera has a row-reset delay of roughly 300 to 350 µs before exposure begins. For a flash source, trigger the camera well before the flash and keep the exposure short, often a millisecond or two, to limit background.
Delay is usually not the problem; variation is. A fixed delay can be built into the timing plan once you know it. Our posts on indirect X-ray imaging and laser beam profiling cover this single-camera timing in more detail.
Keep the data moving
Synchronized exposure is only half the job. Every camera's frames still have to reach the host. Aurora cameras connect over USB 3.0, and their on-camera memory is a working frame buffer, not long-term storage. Plan for continuous transfer to the host for the whole run.
One PC can run multiple FLI cameras. For several large-format sensors at once, size the host for the combined data rate: enough USB controllers and bandwidth, fast storage, and headroom in the acquisition software. Large sensors like those in our post on cameras for national labs make this especially important.
Software and the capture loop
Most multi-camera systems run a custom acquisition program rather than a point-and-click viewer. FLI provides an SDK for each camera line, and the Kepler SDK is available for Windows and Linux. Many customers wrap the SDK in their own code, for example in Python. SDKs and manuals are on our support page.
In a hardware-triggered loop, the program arms each camera, waits for the trigger and reads each frame with a timeout. With the Kepler SDK, one detail matters: abort the capture after every triggered frame, including after a timeout. Skipping that step can cause an error when you switch back to software capture.
Tag each frame with the camera, the trigger count and the host time it arrived. If a frame is ever dropped, those tags make the gap obvious instead of silently shifting one camera's sequence by a frame.
Verify timing before you trust it
Measure the timing before the real experiment. A simple test uses a short LED pulse, fired from the same timing source, that every camera can see. Step the pulse delay across the exposure window and record which frames capture it. That shows each camera's real exposure window relative to the trigger, and how much it varies.
An oscilloscope on the trigger line and the camera trigger outputs adds a second check. Repeat the test at your operating sensor temperature and frame cadence. Our post on acceptance testing for gain, noise and linearity covers the other checks worth running when cameras arrive.
Questions to settle before you choose
- How tight does the synchronization need to be: seconds, milliseconds or microseconds?
- What is the master timing source, and can it drive every camera's trigger input?
- Which sensor mode will each camera use, and will all cameras use the same sensor?
- Is the light continuous, or pulsed and short enough to set the timing itself?
- What exposure times and how many back-to-back exposures does a run need?
- What is the combined data rate, and can one host PC keep up?
- Which operating system and software will run the capture loop?
Talk to our sales team
To assess a multi-camera setup, we need your sensor mode, exposure time, number of back-to-back exposures, interface, PC and software, and the timing tolerance you need. Send those to our sales team and we will suggest the camera models and trigger arrangement that fit. FLI cameras are Made in USA, and our sensor chambers are assembled in our 1,000+ sq ft ISO Class 7 clean room. Request a quote to get started.
