Edgerton, A High-Speed LED Flash #DIY

This device has been dubbed ‘Edgerton’, in honour of the legendary Papa Flash.

2019-05-21 – This project is entered in the 2019 Hacakday Prize contest.  If you have any feedback or like what you see, please consider following, leaving a comment, or liking the project at https://hackaday.io/project/165622-edgerton-a-high-speed-led-flash.  Thank you!

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 were somewhat limited by the standard ‘speedlight’ flashes that I used – there was always some motion blur. Edgerton is a ‘High-Speed Flash’ which uses LED’s to make one-microsecond flashes to freeze motion.

High-Speed Photo of Bullet & Broken Glass

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 (SEVERE injury).  While I didn’t completely disregard the option, I eventually opted for a safer solution.

Second photo taken with Edgerton!

A recent kickstarter campaign (Velo One) offered a high-speed LED flash.  It can produce flashes lasting 0.5 μs (microseconds), was not dangerous, but was priced about $1,750 CAD!  Similarly, other internet hobbiests have conducted experiments with LED’s for high-speed photography (notably petermobbs.wordpress.com and timscircuits.blogspot.com).  I did some testing with a single LED and came up with similar results.  I’m documenting my attempt at building a full-scale flash.

DIY High-Speed LED Flash
Edgerton, The DIY High-Speed LED Flash
DIY High-Speed LED Flash
DIY High-Speed LED Flash
3.5mm Trigger Port
DIY High-Speed LED Flash
12 Very Bright LED’s

A Little Science

There are three requirements for a high-speed flash: light power (luminous power), beam focus (viewing angle), and flash duration Luminous power is the total power output from a source, while luminous intensity is the amount of power per radial angle.

Because the luminous power and viewing angle do not change with flash duration, increasing the flash duration also increases the total light output.  The response time of all the components are discussed below.  I limited the flash duration to between 0.5 μs and 4 μs, selectable in one-stop increments (0.5 μs, 1 μs, 2 μs, and 4 μs).

Glass wine cup struck by bullet

Below is a comparison of a typical camera flash vs this high-speed flash (1-μs duration).  Both air rifle pellets were fired from the same rifle, travelling about 280 m/s.  This demonstrates the advantage of using a high-speed flash for high-speed photography.



Here is a complete parts list.  All prices in CAD.  Total cost: About $165.

  • 12x CREE CXA2530-0000-U20E3 LED’s (datasheet) – $6.66 ea.
  • 4x Vishay MKP1848S 10μf Capacitors (datasheet) – $6.17 ea.
  • 4x INFINEON IPP60R190P6 N-Channel Power MOSFETs (datasheet) – $3.92 ea.
  • 45-390V Boost Regulator (no model number, no datasheet – just search the description on eBay) – $10


  • ATMega328P Microcontroller – $3.31
  • LM7805 Linear Regulator (from eBay) – $0.25
  • TC4452 FET Driver (datasheet) – $3.38
  • Opto-Isolated Relay (from eBay) – $1
  • TM1637 Four-Segment LED Display  (from eBay) – $2
  • KY-040 Encoder (from eBay) – $0.50
  • AA Battery Connectors
  • Various Resistors
  • Various Ceramic & Electrolytic Capacitors
  • 22-Guage Silicon Wire (multiple colours would be helpful)

Other Hardware:

  • Over 500g of 3D Printed PETG (Please find the STL Files here on Thingiverse) – $20
  • 1/4″ Rare-Earth Magnets (from eBay) – $1
  • Arca-Swiss Compatible Mounting Plate (I milled, but available on eBay) – $5
  • 4x M5 x 16mm Countersink-Head Screws & Nuts
  • 6x M4 x 16mm Socket-Head Screws
  • 3x M3 x 8mm Socket-Head Screws
  • 8x M2 x 10mm Socket-Head Screws



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.


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

The complete circuit diagram can be found in the GitHub repository.  I soldered up the control board on a perfboard PCB.  Since I hadn’t tested the LED’s to failure before designing the control board, everything was designed for up to 200 V.  This was overkill, as I currently have the regulator set to 75 V.  Note that the unit is being tested and has currently fired off more than 75,000 flashes at voltages up to 95 V with no ill effect.  The final voltage will likely be increased above 75 V.

Complete Circuit Diagram 1.0


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 μF capacitor to drive each 3-LED bank. After energizing the LED’s for 4 μs at 60 V, 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!

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 10 V (likely since the UC3842 requires a start-up voltage of about 8.4 V, and the 78L09 regulator has a 1.6 V 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 16 V. 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.

Solder across the two tabs to bypass the 9V regulator


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 (which are HUGE!).


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


Here’s the positive 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 5 V 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 MOSFET driver in case I find one driver isn’t enough for 4x MOSFETs.  Turns out that wasn’t needed, one good driver is fine.


It’s pretty!


Over-Driving the LED’s

Most of the cost was in the LED’s. They were about $12 CAD each. I selected the LED  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$. It has a temperature of 5000K (subject to change under the high-voltage pulse conditions), a rated forward voltage of 37 V, and 115 degree angle of view, it was a solid choice. I anticipated driving the LED’s with up to 200 V (but probably much lower).

The Cree LED’s I used are rated for 1.6 A.  When the pulse duration 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. 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.

Some tests were done to determine the best voltage to drive the LED’s at.  I aimed the flash at an 18% grey card positioned 20 cm away, and photographed the card (which ~almost~ filled the frame) at a constant ISO and aperture (ISO 5000, f/2.8 – max aperture so that there are no variations in diameter) and flash duration (1 μs).  The flash’s firmware calculates the average current by measuring the change in capacitor voltage during the flash.  IRfanview reports the average brightness of the pixels in an image (whether the average pixel value is linearly related to exposure is another thing – please comment if you have any advice).

Testing 2019-05-13.jpg

Testing began at 45 V and incremented by 10 V per test.  The LED’s appear to have failed at 115 V, where illumination began to drop while current increased rapidly.  I tested one entire bank, expecting the LED’s to fail at slightly different rates.  Instead all three failed identically (I watched them during each flash).

Testing 2019-05-13.png

This data isn’t perfect, but it gives me a small amount of confidence in selecting the voltage.  75 V is well below the fail point, but still outputs a reasonable amount of light.  I also wanted some safety margin for the 4 μs flashes, which can damage the LED’s at lower voltages (I haven’t tested these LED’s but testing other models has proven this).  For this reason I have the boost regulator set to 75 V.


The ATMega328P is good at generating a 5 V 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.  The LED manufacturer’s application note says that the LED’s take about 10 ns (0.01 μs) to turn on and off, so they aren’t a problem.


I started with a TC4420 gate driver since it was available in my workshop.  It was tested using an oscilloscope. The gate voltage was simple to sample, just clip onto the output. I tested the transistor’s response by sampling the capacitor voltage. If the cap voltage was decreasing, 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 10 V, while it could hit 11 V without the resistors. But the transistors are still conducting, and I can make up for the slightly increased resistance with increased LED voltage.

Eventually I ordered some more powerful gate drivers: TC4452 (non-inverting) and TC4451 (inverting).  They were drop-in replacements for the TC4420.

TC4420 v TC4452

It’s very apparent that the new gate driver handles the MOSFET’s much better.  I didn’t bother testing the inverting driver with these results.  The pull-down resistors are still in place, but I’m not sure if they’re necessary anymore.  However, there seems to be some ringing.  Based on this application note from ON Semiconductor, it’s probably because I didn’t include a gate resistor, gate clamping diodes, or ferrite bead.  Eventually I will experiment with adding these components and post the results.

Below is the gate driver output (Vgs) on the left and capacitor voltage on the right.  The transistor’s response to the gate driver looks good.  I can’t explain why the 500-ns pulse lasts 1 μs and the 1-μs pulse lasts 1.5 μs, while the 2-μs and 4-μs pulses are very close to 2 μs and 4 μs respectively.  I’ve recently calibrated the flash durations by adjusting the number of NOP delays in the firmware and checking with the oscilloscope.

TC4452 Pulses.png

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 before firing.  I used an active-low signal because it’s common with cameras and speedlight flashes, so it may as well be consistent.


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.  In the past I’ve used opto-isolators, but those introduce their own lag and complicate the entire system – not worth it.


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.

The pulse duration, pre- and post-flash voltages, and current draw for each flash pulse are recorded to EEPROM, and I can review the data using a serial terminal on my PC. This allows me to monitor the long-term health of the electronic components in case anything gets damaged or worn.  The ATMega328P has 2kB of EEPROM, and each data entry uses 5 bytes.  There is room for 400 entries, so I can probably download and clear the data yearly.

Future Updates?

Here’s a list of changes I would make given the opportunity to build another flash.  I don’t plan on making heavy modifications to this flash, given that it seems to work so well.

  • Lower-voltage capacitors would be cheaper and smaller.  These 400V caps are overkill, I would look for some 150V caps.
  • A lower-power boost capacitor optomized for 75V.  Unfortunately that probably means I would have to build my own, which would be more expensive than the cheap regulator I found on eBay.  But it would consume less power, especially if I can remove the relay.
  • It’s annoying having to use 8 AA batteries, I would hope to redesign for 4 AA batteries.
  • An audible ‘Ready’ signal would be nice.  Adding a piezo buzzer would be easy, maybe I’ll update the current board with a buzzer.
  • The firmware could review the EEPROM data to check if there are any changes to the current draw over time.  This may alert me to potential issues without having to download and review the data myself.

Thanks for reading!

Last Updated 2019-05-20

Edgerton, A High-Speed LED Flash #DIY

25 thoughts on “Edgerton, A High-Speed LED Flash #DIY

  1. Lightning Phil says:

    Awesome work!

    For scientific cameras this is true:
    (whether the average pixel value is linearly related to exposure is another thing – please comment if you have any advice).

    Generally pretty good for DSLRs in my experience too – for raw files. Though best to make sure things like Nikon’s active D lighting is off as that dynamically shuffles things around.

    Anyhow, the main motive for commenting is to suggest a resistor in series with the LEDs. Since it’s current behaves linearly with increased voltage, it’ll flatten the curves a bit and encourage similar currents in each chain.

    It’s best effect however, is better damping. With higher currents and voltages, the circuit inductance will play a larger effect in determining the waveform behaviour and more damping helps stiffen everything up a bit.

    But works well – so perhaps best not to change anything.



    1. Thanks for the advice Phil! So I was using a Canon 7D and jpg’s straight from the camera. First I tried converting the Raw files using DCRaw with the ‘linear curve’ option but the output was very dark. If you have ideas on how to get the average pixel value in the raw image, I would be interested.

      I’m aware that LED’s should have a series resistor or dedicated driver, but in this particular application I decided that they would just hinder performance. You’ve convinced me that they might be a good idea. Since I know the current draw, it would be easy to add them and adjust the voltage until it starts hitting the original current. My concern would be the added inductance of the resistors, but reading a few datasheets would probably put that concern to rest.

      I’ll make an update if I add the resistors. Very best!



      1. LightningPhil says:

        Wire wound can come as non inductive types (more zigzag than a coil), and using a couple in parallel is a great way to bring down what’s left of inductance. Probably overkill. Wire-wound are robust and inexpensive, so could be a good first place to start. Though – it works, so probably no need for it. If you do go for it though, perhaps 3 x 10 ohm in parallel to make ~3.3 ohm net.

        Nice camera. The 7D seems to be 14 bit. Perhaps if it was looking dark, you were only looking at part of the bit range – the top 8 bits, where only really bright info would be kept. What do you need super linearity for anyhow? JPEGs are handy things :O)

        Liked by 1 person

      2. Thanks for the info! I ordered some non-inductive resistors. Thing is, now I’ve done some endurance testing with one LED connected, and 15,000 flash cycles later it is still running strong. So I may keep the resistors for the next build and leave this one as-is… They will be added to the schematic for all future builds.


    1. That’s a cool idea! For some reason I thought that I tried and failed to use the thin wire method to trigger years ago. Guess I was doing it wrong 🙂 Since that’s such a simple method of triggering, I’m inclined to add the delay option to the firmware.

      Thanks for the tip!


    1. Hey Ralph, thanks for looking! I understand your argument for a lower LED forward voltage, they were an investment and I would hate to damage them. I’m going to continue running them at 75V because my goal is to maximize the exposure while minimizing the cost, and decreasing the voltage means increasing the number of LED’s required. If it’s possible to continue running at 75V with no ill effect, then a 9- or 6- LED system would be perfectly usable at half the cost!

      If you are eventually proven correct and my LED’s become damaged (I don’t deny the risk), I’ll update the post. Actually I’m considering an endurance experiment, testing if the LED’s can handle 10,000 flashes at 75V. I just need to come up with a way of monitoring the health of the LED’s during the experiment.

      Cheers, Tyler


  2. I wonder if you’d be willing to go with a couple of 18650 lipo batteries, or for that matter 26650s. Those run at 4.2V nominal and are basically purpose build for high current loads. Capacity would go up and availability isn’t a problem nowadays. Great project!


    1. Thanks for reading John! Those LiPo batteries are pretty good, I used them for one project at work where size, weight, and endurance were an issue. Since this flash is for home use, I opted to use AA’s (I have about half a gadjillion rechargable AA’s). At this point, the AA’s have dropped to 9V and the unit is still functioning.

      Eventually I’ll make a model of the case that accepts 3x 18650’s or 26650’s. Thanks for the idea!


    1. Thank you! I’ll upload the completed schematics soon. I’ve been considering fabbing a proper PCB to replace the perfboard, please let me know if you’re interested in one, maybe I’ll get several made.


  3. Laughlin says:

    Excellent project!

    With regard to the pulse duration, I’ve sometimes forgotten to properly define F_CPU and experienced similar. If the processor assumes it was operating at 16Mhz, but was in fact operating at 8Mhz, you would experience the doubled pulse/delay time you are experiencing.


    1. Thanks Laughlin!

      That’s a good though. The firmware uses this line to delay for one clock cycle: __asm__ __volatile__ (“nop\n\t”). I don’t think it matters if F_CPU is defined properly in this case. It’s also strange that each pulse duration needed a different calibration – it wasn’t consistent at all.

      Cheers, Tyler


  4. Dennis says:

    Very cool project with stunning pictures! Glad this was featured on hackaday, would have missed it otherwise. Will stick around for future projects for sure. 😀

    To the odd delay problem:
    “I can’t explain why the 500-ns pulse lasts 1 μs and the 1-μs pulse lasts 1.5 μs, while the 2-μs and 4-μs pulses are very close to 2 μs and 4 μs respectively.”
    That is indeed strange. I checked the code on github and coudn’t figure out the reason either. Is it possible to access the assembler code in the arduino enviroment? That would make things a lot clearer.
    A while ago I’ve written a cycle accurate pulse generator in inline-assembler for a charliplexed LED cube. It supports any pulse width from 2-256 cycles. If you are interested in that, I’d polish it up and send you the code.

    In response to one of your comments:
    “I just need to come up with a way of monitoring the health of the LED’s during the experiment.”
    Recently I’ve started working on a similar challange measuring the performance & longevity of an OLED screen. I couldn’t find any any fast and reasonable accurate sensors, so I designed my own solution. It’s an active probe for an oscilloscope, linear output and hopefully a bandwith of >10MHz. The schematics is almost complete, but I will take some time to get the PCBs made and test the circuit. Assuming I can get the probes working as intended, would you like to have one or two? I’ll have more PCBs and parts than I can use myself anyway.

    Cheers and thanks again for the great write-up


    1. Thanks for the kind words Dennis!

      Yeah, you can see how I had to calibrate the duration for each pulse length. And who knows if the next unit will need to have its own calibration? Anyways, I uploaded the assembler code on GitHub (specifically, you can view Ray.ino.dmp). I don’t understand how to interpret this code, but it looks interesting.

      About the oscilloscope probe, I’m interested. If you have the schematics (and even a PCB) then I could assemble one myself? Let me know when it’s functional (my email is vtgerritsen@gmail.com), and no rush of course. FYI I’m not an electrical engineer, so I will need you to explain how it works 🙂

      I’m probably going to do a very simple longevity test in the next week. If the flash is set to fire once per second (only one LED connected), and a camera with an intervalometer to open the shutter for several seconds every few minutes. Then the exposure of the images and current draw for each flash can be evaluated. It’s much more crude than using an oscilloscope probe, but it should work to prove the LED’s can handle 10,000 cycles.

      Cheers! Tyler


    2. Just to add to this – My main interest in your active probe is the flash duration. Some folks have pointed out that the phosphor in the LED’s may introduce a lag and affect the flash duration. I have the application note from Cree which seems to say otherwise, but it would be fantastic to actually test it!


  5. scientistinsitu says:

    Hey, I was looking at your timings based on code alone, running on at atmega328 – FLASH_ON;FLASH_OFF; seems to give a minimum duration of 1 clock cycle (62.5 ns at 16 MHz/125 ns @ 8 MHz). At present for 8 MHz the pulses are 250 ns (1 nop), 752 ns (5 nops), and 2 us (15 nops) , and 3.75 us (29 nops) from your set of delays.
    Is this the adjustment of pulse widths to make it behave as 0.5, 1.0, 2.0, and 4.0 us? Pulse oddities must be coming in in the driver circuit, because the ATMEGA output is exactly as predicted for me


    1. Yes, those are the calibrated delays which result in 0.5, 1.0, 2.0, and 4.0 us pulses.

      I guess it’s true that FLASH_ON and FLASH_OFF combined will add one clock cycle to the flash duration. I hadn’t actually thought through that very well! It’s also very possible that the driver is introducing the extra delay. Come to think of it, I never scoped the ATMega’s output… I still think it’s very odd that the delay in the driver isn’t perfectly consistent!


  6. Hi Tyler!

    Interesting, how people somehow inevitably always come up with the same solutions… 😉

    I’ve been there before some time in 2018, working with Maurice Ribble (father of the Camera Axe, seehttp://www.cameraaxe.com/wiki/index.php?title=Main_Page, unfortunately, his follow-up Camera Axe kickstarter didn’t turn out too well) and Peter Mobbs (https://petermobbs.wordpress.com/2015/02/06/experiments-with-led-based-flash-gun-for-high-speed-photography/) on something similar. Don’t miss https://www.youtube.com/watch?v=8hdAv_MRyY4, where Maurice shows off his solution, made with a grid of white Cree MHBAWT-0000-000C0BD250E LEDs (https://www.mouser.de/datasheet/2/90/ds_MHBA-531571.pdf).

    WRT to the ringing, http://www.onsemi.com/pub/Collateral/TND6242.PDF (p. 19) could help you. Also make sure not to use standard wire-wound resistors but rather low-inductance types or DIY with https://en.wikipedia.org/wiki/Ayrton-Perry_winding.

    IIRC Maurice was using a TC4420 driver (Microchip) and IRF1407 MOSFET (Infineon). I had a look athttp://ww1.microchip.com/downloads/en/DeviceDoc/21419D.pdf and there is http://www.ti.com/lit/ml/slua618/slua618.pdf (notice the term “gate resistor” being mentioned on page 12ff of the aforementioned document in conjunction with switching speed of high speed drive circuits?). http://www.onsemi.com/pub/Collateral/TND6242.PDF also helped understanding the science of high-voltage fast switching MOSFETs. There’s a chapter about turn-off gate oscillations, about layout parasitics, about adding a ferrite bead to the MOSFET gate, clamp diodes, gate resistors and measurement techniques.

    Later in the project, we simulated the circuit with the Cree XLamp MHB-A LT-Spice model and I did some overdrive calculations based on http://www.cree.com/led-components/media/documents/XLampPulsedCurrent.pdf, the conclusion being that we were probably nearing some sort of “hard limit” at ~190V where it does not make any sense to raise the current anymore because that will just wear out the LEDs quicker with no real benefit in increased light output.

    You might want to experiment with some Fresnel lens to improve efficiency.

    Best of luck and keep up the good work!

    Greets from Germany,


    1. Thanks for looking Volker! Also I appreciate the articles you linked to, I’ll look through them. I’ve learned lots from all the informed commenters such as yourself.

      I’ve already tried added cheap wire-wound resistors in series with the gates to no good effect, but you’ve already pointed out my error there 🙂 I need to read through all the literature you shared and maybe try some methods. As I write, the flash is running tests to check the LED life span. >25,000 flash cycles so far and no degradation observed.

      Since you mention components, I’ll just point out why I used these. The CXA2530’s had the best rated Lum/$ available on Digikey. You’ll note I had used TC4420’s but replaced it with a TC4452 as it was underpowered. The IPP60R190 MOSFET’s I used were spec’d before I knew how much voltage and current was required, they may be overkill and an IRF1407 could be a good solution (They’re good transistors, I’ve used them in other projects) and may match well with the TC4420. But given the cost of the LED’s, a few extra $ for the transistors and drivers is no big deal.

      Regarding the lenses, I am usually backlighting using a diffuser and don’t want to focus the light. The spread from the LED’s seems to be ideal. HOWEVER, there are cases where I’m front-lighting and would like to focus the light. A detachable lens would be nice! I hadn’t considered a single Fresnel (The Vela One uses reflectors, which I thought was a good idea) but since you mention it I’m going to look at the possibility of a single detachable Fresnel lens!

      Cheers, Tyler


  7. […] Both film and digital photography rely on light exposure. With traditional analog photography, it’s the film itself that is being exposed by light. Digital cameras have a CMOS sensor that is exposed by light in a similar way. For any given type of film or CMOS sensor, a certain amount of light is required to get a properly-exposed photo. When all other settings remain fixed, the only way to get a good photo is to have a lot of light or a long exposure time. But long exposure times result in motion blur, which is why Tyler Gerritsen built a DIY high-speed LED flash called Edgerton. […]


  8. […] Both film and digital photography rely on light exposure. With traditional analog photography, it’s the film itself that is being exposed by light. Digital cameras have a CMOS sensor that is exposed by light in a similar way. For any given type of film or CMOS sensor, a certain amount of light is required to get a properly-exposed photo. When all other settings remain fixed, the only way to get a good photo is to have a lot of light or a long exposure time. But long exposure times result in motion blur, which is why Tyler Gerritsen built a DIY high-speed LED flash called Edgerton. […]


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s