High-Speed LED Flash #DIY


I'm calling this the 'Edgerton', in honour of Papa Flash.

Some time ago I designed and built a ballistic chronograph and used it to take some high-speed photos of bullets striking glass. The results were great, but the photos somewhat limited by the standard hotshoe flashes that I used. Thanks to various internet resources, I found that the fastest flash available to me was a Nikon SB-900 (here's some specs on the Nikon SB-800, Canon 430EX, and a few others), which could be turned to minimum power and produce light for 28 microseconds.

High-speed photography is no recent invention. Doc Edgerton was already experimenting with high-speed photography in the 1940's, and has taken some incredible photos. He was known to use an Air-Gap Flash, which is similar to the Xenon flash tubes found in modern camera equipment. It unfortunately requires much higher voltage which could easily cause injury. While I didn't completely ignore the option, I was hoping for a safer solution.

A kickstarter campaign recently offered a high-speed LED flash, the Velo One. It could produce flashes lasting half of a microsecond, but was priced about $1,750 CAD. Similarly, other internet hobbiests have conducted experiments with LED's for high-speed photography: petermobbs.wordpress.com and timscircuits.blogspot.com. I did some testing with a single LED and came up with similar results. Here is my attempt at building a full-scale flash.

Bullet frozen in front of the inventor
Second photo taken using the flash!

Science:

There are three requirements for a high-speed flash: light power (luminous power), beam focus (viewing angle), and flash time. Luminous power is the total power output from a source, while luminous intensity is the amount of power pre radial angle. The viewing angle of the LED's I used are 115 degrees, which should be a suitable spread.

The flash time has to be short, otherwise this would not be a high-speed flash. I designed the flash to output 500 nanosecond to 4 microsecond flash bursts, in one-stop increments (0.5 microseconds, 1 microsecond, 2 microsecond, and 4 microsecond). Because the light power and beam focus do not change with flash time, increasing the flash time directly increases the total light output. The LED manufacturer reports in an application note that the LED's take about 10ns to turn on and off, so they aren't a problem. The response time of the rest of the circuit is described below.

An important aspect of the design is the current drawn by the LED's during a flash pulse. When the pulse is very short, an LED can handle significantly more power than during constant illumination. See this paper and Cree's application note on the topic. I can't directly measure the current through the LED's in the flash, but it can be calculated as a function of the voltage in the capacitors before and after the pulse, the capacitance of the capacitors, and the duration of the pulse.

Capacitance is the amount of charge per voltage (1F = 1C / 1V) and charge is current times time (1C = 1A * 1s). I've found that the 10uF capacitors go from 70V to about 61.6V (8.6V decrease) during a 4 microsecond flash. That's 86uC of charge and an average of 21.5A of current. That's distributed between three LED's, so an average of 7.2A per LED.

The Cree LED's I used are rated for 1.6A, but as mentioned above, they can handle quite alot more in short pulses. The Cree application note above advised not to drive the LED with more than 300% of the rated current, but that is for 1 kHz continuous pulsing - not the single pulses used in the flash.


Components:

Here is a complete part list. Selecting the LED was done by downloading a list of suitable LED's from digikey, and sorting by luminous flux/$. The Cree CXA2530 series was a good choice, with the U20E3 coming in at 551 Lum/USD$. With a temperature of 5000K (subject to change under the high-voltage pulse conditions), a rated forward voltage of 37V, and 115 degree angle of view, it was a solid choice. I anticipated driving the LED's with up to 200V (but probably much lower).

Controller:

Most of the cost was in the LED's. They were about $12 CAD each. The capacitors were a few bucks each as well, and all other components were pretty cheap.

The boost regulator was purchased on eBay. Some of the components had their markings scratched off, but some kind folks have provided a bunch of info on it (including a schematic) at dalmura.com.au and diyaudio.com forum. Unfortunately it originally seemed to require an input of more than 10V (likely since the UC3842 requires a start-up voltage of about 8.4 volts, and the 78L09 regulator has a 1.6V dropout), so eight NiMh batteries wouldn't work to drive it. After reviewing the schematics for a while, I thought it would be ok to try bypassing the regulator as long as I didn't go over 16V. Then I discovered that the board was actually designed to do this, as shown on the photo below - simply short out the two pads as shown! Now it works on rechargable batteries.

Low-Voltage Input for YH11067 45-390V Boost Regulator
Solder across the two tabs to bypass the 9V regulator

Assembly:

I 3D printed the body in two halves. That's about half of a spool of PETG and over 30 hours of printing! The 12 LED's are configured in four banks of three LED's. Each bank has its own capacitor and MOSFET.

Both halves of the case, the cover, and the Arce-Swiss plate

An aluminum Arca-Swiss compatible plate is mounted on the back. It also has a 1/4" threaded hole so it can mount on tripods without the Arca-Swiss mount.

The two halves of the case screw together with six M4 screws.

The front half has two embedded magnets. A cover also has two magnets, so it snaps onto the front and protects the LED's. The cover will protect the bare LED's when not in use.

The entire flash is powered with eight AA batteries. The batteries slide into a hole in the case.

A capacitor stabilizes the 12-volt rail. The boost converter has a bit of an in-rush current issue, but the rail is quite stable with the capacitor.

The boost regulator screws into the case and the relay is hot-glued into place. I typically try to avoid using hot-glue for permanent solutions, but options are limited in this case. If I could re-print the case, I would integrate zip-tie holes inside - but a third of a roll of filament and 18 hours of printing is too much to just re-print for one little issue.

The main control board screws onto the front half.

Here's all of the electronics installed (except of three of the four LED banks).

The cover was printed half translucent and has a couple embedded magnets. It snaps onto the body nicely. In this photo I only have one bank of LED's installed. If something goes wrong during development and the LED's die, I would rather only lose three instead of all twelve.


Control Board:

I soldered up the control board on a perfboard.

The controller uses an ATMega328P and no external crystal. At 8 mHz, the processor is plenty fast enough to operate the MOSFET driver and user interface.

A major concern is that the microcontroller will reset due to a power fluctuation while the LED's are energized, since it will take some time for the microcontroller to reset and the LED's will remain energized until reset is complete.

To mitigate the danger, I've added additional capacitors (electolytic and ceramic) to the 5V rail, which will stabilize the LM7805's output. All of the high-voltage rails are kept physically distant from the 5V rail. Finally, I've purposely selected a 10 uF capacitor to drive each 3-LED bank. After energizing the LED's for 4 microseconds at 60 volts, the capacitor loses 12% of its voltage. This is enough to keep the output ~almost~ constant, but in case the MOSFET remains energized, the capacitor should drain completely before too long. Hopefully the LED's can handle the capacitor's entire energy reserve without dying!


LED's:

The LED's, capacitor, and MOSFET for each bank are kept physically close to each other in order to minimize impedance in the circuit. I removed the insulation on 22-guage wires and used the bare conductors as high-voltage rails. This is one area I would like to do some more research! As I understand it, using finer stranded wire reduces impedance at high frequencies (the output will have an effective frequency of 2 mHz).

I printed a jig to hold the LED's during assembly. The hold-down clamps are installed using M2 screws. The odd-shaped triangles on top are guides for the capacitor (they're HUGE!).

My rolls of silicone 22-guage wire have very fine strands, which are perfect for this application.

Here's the negative side of the capacitor and LED.

The positive side of the capacitor is tied directly to the LED's high-voltage rail.

Yeah, it's a little bit of a mess inside there. I need to print a separator to keep all the high-voltage wires away from the sensitive 5V components. Note the high-voltage outputs on the lower right corner of the control board can be disconnected, which deactivates an individual bank of LED's. There's also an empty DIP-8 socket which is wired up for a second TC4420 driver (in case I find one driver isn't enough for 4x MOSFETs).

It's pretty!


Controlling Current

The ATMega328P is good at generating a 5V pulse, but there are several components downstream that need to follow suit. The gate driver and MOSFETs need to rise and fall with the signal.

I tested the gate driver and transistor using an oscilloscope. The gate voltage was simple to sample, just clip onto the output. I tested the transistors by sampling the capacitor voltage. If the cap voltage was falling, the MOSFET is active.

The initial test didn't look so good. THe gate voltage rose quickly, but fell very slowly. I tried adding some resistors between the gate and the source on the MOSFETS (200 ohm per transistor) and a 39 ohm resistor on the control board between the gate driver's output and ground.

This had the desired effect - the gate voltage fell much quicker. There's still some lag and the LED's are being driven too long. This can be accounted for in the firmware by reducing the pulse time. I haven't done so at this point since it's reasonably close.

The down side to the resistors is that the gate voltage isn't as high. It now only reaches 10V, while it could hit 11V without the resistors. But the transistors are still conducting, and I can make up for the slightly increased resistance with increased LED voltage.


Interfacing With The Sensor

So the flash would be useless without a sensor to send a trigger signal at the appropriate time. My ballistic chronograph will act as the sensor. The chronograph is already set up to control some typical camera speedlight flashes, so I designed the high-speed flash to use a similar signal.

The flash has a 3.5mm audio cable port. The tip is connected to a pin on the controller. The pin is set to have a pullup resistor in the firmware. The base of the 3.5mm port is grounded to the controller. When the flash is activated, it waits until the pin goes low.

On the chronograph, I made an interface board with four 3.5mm audio ports. Each port has a tip connection to a GPIO pin, and the bases are grounded. The controller GPIO pins are held in tri-state (input) mode, then source (output low) when activated. The ports can control speedlight or this high-speed flash, a camera, and even an automated trigger on my air rifle.

Each port has a clamping diode. This protects the controller in case a device with reversed polarity (tip-ground) is plugged in. I should also add a zener clamping diode to protect the controller in case a device with more than 5V is plugged in, but for now I will just be careful.


Firmware

The firmware for the flash is available on Github. It's pretty simple - an encoder selects the flash duration, a short-click charges the flash and waits for an external trigger, and a long-hold executes a flash immediately. While the capacitors are charging, I can hold the button and the display will continue to show the voltage output from the booster. This helps for adjusting the high-voltage rail. There's also a diagnostics test that checks how the system charges and discharges.

Note that it uses a heavily-modified version of the TM1637 display library. I believe this is allowed under the terms of the license. Nevertheless please forgive the very non-uniform coding style in the library.