-
Notifications
You must be signed in to change notification settings - Fork 4
Testing Your Trigger Generator
← Previous topic: Making A Trigger Generator
After you have built an external trigger generator for your cameras, it is important to test it. There are two parts to testing, of course.
To have a good idea of the timing accuracy of your trigger generator, you need to measure the pulse output times. The most critical measurement is the period between consecutive falling edges, or rising edges if your camera uses a rising-edge trigger. You should also try to measure the pulse width since the camera will have a required minimum pulse width to triggering, and if your trigger is too short the camera may not trigger reliably. (To fix this using the code from the Making A Trigger Generator page, add a "delay(1);" or "delayMicroseconds(100);" command immediately following the "now += 500000;" line. This will stretch the pulse width by 1 ms or 100 microseconds.)
There are a couple of ways to make these measurements.
Every good technician's test bench has an oscilloscope. Measuring the duration and interval for the trigger pulse can be as easy as looking at the signal and setting a couple of software cursors. That's if you have a boss that will pay for a good, modern oscilloscope.
A second way of testing requires a semi-specialized piece of test equipment called an EPUT or timer/counter. Some examples of these are:
The author (JS) has both of these. The former is a good, low cost device with ms capability. The Racal-Dana has a lot more features, including the ability to average readings, and better accuracy. You get what you pay for. (The Racal was a Christmas present, the Fluke my own purchase 'cause it's cool.)
This is something you might not think about until you've been burned by it several times, but knowing that your cameras are actually taking images when you tell them to, and more important, they are all doing it at the same time, is important. You can look at the time stamp data in the collection software, but sometimes that data is, well, a vague representation of the truth.
A very simple way of testing this is to point your cameras at a relatively fast digital counter. Set the system so that it collects stacks at a fixed interval, and design a pixel array that captures either the entire display or the individual segments of the seven segment display. (If you do the latter, then you can trivially write a Matlab function that takes the stack data and converts it to the numeric display value. This is left as an exercise for the reader.)
Instead of actually collecting images, it is also sufficient to watch images in real time, if your software has that capability.
Do the images all show the same count? There are some considerations in doing this, however:
-
Time resolution. If you have the camera set with too long an integration time, it will smear the count. To measure to a reasonable resolution a 5ms (0.005s) integration time is sufficient.
-
Time increment. If the counter you are using has a slow display (LCD!) then you may not be able to identify the actual count at which the image was taken. LED displays are much faster, but may also be multiplexed. That is, each digit in a five digit display is shown sequentially, but fast enough that human persistence of vision makes the display look continuous. Cameras with appropriate integration times will not be fooled, and are a good way of identifying a multiplexed display.
These two issues can be a tradeoff. You may have a multiplexed display that is unusable at a very short (1ms or less) integration time, but 10ms causes the display to be over-averaged.
Some counter/timer units have a self-test mode that will provide an internal pulse generated by the same timebase the timer unit uses, and will display an incrementing count automatically. The Racal-Dana unit does this. This is Nirvana since you need nothing else to test both the trigger circuit and the cameras using it.
What can you do if you don't have a counter/timer unit? Here's how to make a cheap one using an Arduino Nano and an industrial counter.
First, get ahold of Amazon.com and order a Sestos Industrial Counter or similar device. The important criterion is the maximum counting speed and trigger voltage. This one will count up to 10kHz and accepts a 5V pulse.
Second, if you don't already have four spare Arduino Nanos left over from when you bought a five-pack, buy another one. Program it with a 1kHz pulse generator. (See Making A Trigger Generator for code that does a 2Hz pulse, and replace the 500,000 microsecond constants with 1,000 microsecond (1ms).
Power the counter and Nano with a spare 12V supply. A 12V wall-wart with 0.5A or more output is more than adequate. Power to the counter goes in pins 9 (+12) and 10 (ground). +12 to pin 30 of the Nano comes from pin 4 of the counter, ground (pin 29 on the Nano) from pin 5 on the counter. Pin 7 from the Nano comes back to counter pin 1.
During setup of the counter using the front panel, make sure you select the 10kHz counting frequency. (This sets the multiplexing rate of the display.)
When you power up you should see a rapidly increasing count. Aim and shoot and see what the cameras tell you.
For an example of how multiplexing the display works, set the camera to increasingly shorter integration times. At some point, if you can get the cameras fast enough you will start to see just a few digits in the image and the rest will start to disappear (which ones depends on when the image is taken). As some point you will see just one. Science roks, huh!
CIRN
Wiki Home
CIRN Website
CIRN Research and Workshops
CIRN Monthly Webinars Existing Monitoring Stations
Sampling Goals
Pixel Resolution
Fixed Mounting Platforms
Temporary Towers
FOV and Lenses
Installation Design
Cookbook
Data Processing
Understanding Image Geometries
Photogrammetry
Intrinsic Calibration
GCPs
Extrinsic Calibration
File Naming
Directory Naming
Time Conventions
Common Variable Names
Parallel Processing Issues
Etc
GitHub Help
GitHub Cheat Sheet
CIRN repository help
GitHub Best Practices and GuidelinesGitHub Repository Structure
GitHub Workflow Overview
Using Teams & Roles
Issues
Testing & Review
Code Requirements
General Guidance
Admin
Software Development Life Cycle