Edgerton, A High-Speed LED Flash #DIY

2019-07-25 – The list price of the well-designed Vela One has recently dropped.  I originally quoted it at about $1,750 CAD but unfortunately don’t have any proof.  As of today, the Vela website indicates it is exactly $1,526.70 CAD. The archive.org website shows that the price has indeed fluctuated over time.

2019-08-01 – A big THANK YOU to NQTRONIX who has kindly gifted me an active light probe of his own design.  The probe will be used with an oscilloscope to measure the flash duration, trigger response time, light output -v- current, and other helpful things.  I will update this post with the data once testing commences.  NQTRONIX put a TON of time into designing, testing, and optomizing his probe.  Please consider checking out his instructable page and leaving him a like or comment!

2020-03-20 – Main control boards are available at https://www.tindie.com/products/19592/.


EDGERTON

Named in honour of the legendary 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 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 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 (among other equipment) 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 using Edgerton!

A recent kickstarter campaign (Vela 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 $1,500 CAD!  Similarly, other internet hobbyists have documented their experiments with LED’s for high-speed photography (notably petermobbs.wordpress.com and tomscircuits.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 and sharing the plans to manufacture your own copy.


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 are constant and do not change with flash duration, increasing the flash duration also increases the total light output (exposure).  The response time (time to turn ON and turn back OFF) 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).

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, traveling about 280 m/s.  This demonstrates the advantage of using a high-speed flash for high-speed photography.


Components

Below is a partial parts list.  All prices in CAD.  Total cost: About $165.  The complete bill of materials can be found at the Github repository.

  • 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

Controller:

  • ATMega328P Microcontroller – $3.31
  • LM7805 Linear Regulator (from eBay) – $0.25
  • TC4452 FET Driver (datasheet) – $3.38
  • 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 20mm Socket-Head Screws
  • 3x M3 x 8mm Socket-Head Screws
  • 8x M2 x 12mm Socket-Head Screws


Why Not Use Cheaper LED’s?

You may wonder why I use expensive CREE LED’s instead of the cheap LED’s available on eBay.  Here’s why: cheap LED’s simply aren’t tough enough to be overdriven (more on that below) the same way that these CREE LED’s can be.  I had originally tried several types of LED’s from eBay and found that none of them were useful for high-speed flashes.  It would take several eBay LED’s to replace a single CREE LED.  This means the CREE LED’s are cheaper bang for buck!  It also means that a working flash with knock-off LED’s would be ridiculously large and difficult to control.

I’ve been contacted by a few people who were building a flash with cheap LED’s instead of the CREE LED’s prescribed below.  At the time of this writing (2020-03-05), I haven’t heard any success stories from people using cheap LED’s.  If you built a high-speed flash with knock-off LED’s that is truly functional, let me know and share some images!

Still don’t believe me?  Read the tomscircuits.blogspot.com post where he discovers the same thing.  He compared a CREE XM-L LED with a no-name LED and found the expensive LED was worth the price.

One more thing.  One of the most valuable parts of this design is the extensive testing done with the CXA2530 LED’s.  In order to use a different LED, destructive testing is required and that will cost $$.


Assembly

Detailed assembly instructions can be found at the Github repository.

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.

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.  Since then I’ve strobed several LED’s to failure in order to test how much current they can handle, and 200 V was a pretty good design choice.  The boost converter is currently set to 120 V, which is fairly conservative given that I’ve seen them strobe 15,000 times at 125 V without failing and even several strobes at 200 V.

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!

UPDATE 2019-07-01 The circuit now includes a ‘high-pass filter’ to the MOSFET driver.  This simple RC circuit prevents the driver from receiving a signal longer than about 5 microseconds.

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.


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 (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 to the LED’s high-voltage rail through series resistors.

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 $6 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 and 4 μs).  The flash was strobed 10,000 times at 1 μs and 5,000 times at 4 μs.  The flash’s firmware calculates the average current by measuring the change in capacitor voltage during the flash.  ImageJ was automated to analyze the brightness of the centre of each image.

Testing began at 70 V and incremented by 5 V per test.  The LED was still functioning at 125 V but I had to stop testing due to limitations on the control board.  I did a small number of strobes at voltages around 200 V but did not collect any data.  The LED did not fail during testing!

This testing was performed without the series resistors installed.  I now have the series resistors included in the design and the voltage is set to 120 V, of which the LED’s receive about 95 V.


Transistors

The ATMega328P is good at generating a 5 V pulse, but there are several higher-voltage 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.

It’s very apparent that the new TC4452 gate driver handles the MOSFET’s much better.  I didn’t bother testing the inverting driver after seeing these results.  The pull-down resistors are still in place, but I’m not sure if they’re necessary anymore.  However there now 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.

UPDATE 2019-07-01 I’ve recently added ferrite beads in series with the gates.  Shown below are the before / after traces and you will note how much the ringing has been tamed:

Additionally, the high-pass filter going to the MOSFET driver prevents the LED’s from turning on for too long.  The TC4452 input voltage goes ‘low’ when the voltage falls below 0.8 – 1.3 Volts (per the datasheet).  It can also handle negative voltages, so the signal inversion isn’t a problem.


Interfacing With The Sensor

UPDATE 2019-07-01 The Tripwire Function is now included in the firmware and allows for triggering using a very simple and cheap jig.  Please visit https://gerritsendesign.wordpress.com/2019/07/01/cheap-trigger-for-high-speed-photography/ for more information.  I will personally continue to use my ballistic chronograph, but for those just starting in high-speed photography, the tripwire will make the hobby much more accessible.

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.


Firmware

The firmware for the flash is available on Github. It’s pretty simple – an encoder selects the flash duration and trigger delay, and a long-hold executes a flash immediately (the complete user’s manual is available on Github). 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 1kB of EEPROM, and each data entry uses 3 bytes.  There is room for 340 entries, so I can probably download and clear the data monthly or yearly.


Future Updates?

Here’s a list of changes I plan for this flash.  I don’t plan on making heavy modifications to this flash, given that it seems to work so well.  Note that a brand-new ‘Mark 2’ is in development and I will update this post when the prototype is functional.

  • (Coming in the Mark 2) -> A lower-power boost capacitor optimized for low-current supply.  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 (DONE).
  • (Coming in the Mark 2) -> It’s annoying having to use 8 AA batteries, I would hope to redesign for 4 AA batteries.  It will probably go through a 12 V boost regulator, which would also be helpful to maintain a 12 V gate driver voltage (instead of the driver voltage varying with battery charge).
  • DONE -> 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.
  • DONE ->Thanks to Lars – Add a firmware function for ‘broken-wire triggering’ of the flash.  That will make this a standalone solution for high-speed photography – no separate triggering system required.
  • DONE -> Thanks to Lightning Phil – Low-Inductance series resistors to dampen the current through the LED’s.
  • Thanks to TheBestJohn – An alternative case for use with 18650 or 26650 batteries.
  • Thanks to Volker from Germany – A single detachable Fresnel lens to focus the light
  • Lower-voltage capacitors would be cheaper and smaller.  These 400 V caps are overkill, I would look for some 150 V caps. Given how much voltage the LED’s can handle, I’ll continue using the 400 V caps.

Creative Commons License
This work is licensed under a Creative Commons Attribution 4.0 International License.


Thanks for reading!

Last Updated 2020-03-05

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

  1. 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.

    Cheers,
    Phil

    Reply
    • 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!

      Tyler

      Reply
      • 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)

        Reply
      • 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.

        Reply
    • 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!

      Reply
    • 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

      Reply
  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!

    Reply
    • 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!

      Reply
    • 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.

      Reply
  3. 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.

    Reply
    • 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

      Reply
  4. 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
    Dennis

    Reply
    • 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

      Reply
      • Thanks for the assembler dump. The relevant section starts at line 3473. All assembly commands start with a 4 digit hex address, followed by a 4 digit hex command (the actual data in the flash) and a short human-readable explaination behind that. You can find the few relevant instructions in the instruction set: https://www.mikrocontroller.net/download/instructionset.pdf. All other C-code in between is just there to help you understand what’s going on.

        The macros make it harder to read (it becomes clearer if you just paste the asm command the required amount of times), but basically the compiler tries to be smart and tries to re-use some code by jumping around. Jump instructions take 4 cycles on the AVR and are not accounted for by your code. In addition the compiler loads the output value into a temporary register just before it writes it to the output, causing an additional 1-2 cycle delay. To pulse a pin it is therefore best to toggle the pin twice by writing to the PIN register, so the compiler only need to load one value before the delay. This trick is available on all modern (~2005 ish) AVRs.

        I’ll send you preliminary documentation when I order the PCBs, the full docs with explainations will be published once everything is working. As I said I’ll have more parts and PCBs anyway, so I’d simply send 2 of those your way.

        “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.”
        That will indeed also work just fine, especially since you’re using the same camera for taking picures iluminated by the flash anyway. Sometimes I’m blind to the most obvious solution.

        I’ll keep you updated on the probes.
        Cheers, Dennis

        Reply
    • 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!

      Reply
  5. 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

    Reply
    • 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!

      Reply
  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,
    Volker

    Reply
    • 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

      Reply
  7. Amazing project… can I buy one? Or pay you to make one? I was looking into an airgap flash but this is a way better solution.

    Reply
    • Hey Kevin, thanks! We could work something out for sure. I need to update this post, since I’m wrapping up development of this model and am preparing to start building a prototype of the ‘Mark 2’. The main feature improvement is better power usage (4x AA batteries will last much longer than the 8x AA’s needed for this current model).
      Email me at tyler@td0g.ca!

      Reply
  8. You really should think about selling kits of the Edgerton and Chrongraph. Price the Edgerton at $300 with the 3d body and I bet that you would sell a lot. Must be some place that you could get a the bodies printed at a cheaper price.

    Reply
    • That’s a good idea Zack. My first thought is that anybody can get the case custom 3D printed, so I could save on shipping costs by not including the case. Or is that too much bother? Hmm…

      Reply
      • Find out how much it would cost to get a bunch of them printed. Probably could get a good deal somewhere. Then offer to sell a basic kit without the case and a deluxe kit with the case. Most people will buy the deluxe version.

        Reply
  9. Amazing project.
    I cannot afford the Vela one at moment, so have ordered the parts for this. Looking forward to getting started.
    Many thanks for sharing this.
    Jon

    Reply
    • Thanks Jon!
      While you assemble it, please feel free to email me with any questions (tyler@td0g.ca). I would appreciate any feedback you have!
      What do you want to use for batteries? The current model can only use 8x AA batteries, but I was considering designing another case for 3x 18650 batteries or even 3x 26650. And right now I’m working on a redesign that uses lower voltage, and will use 4x AA batteries. That won’t be ready for at least a couple weeks, maybe more.

      Reply
    • That sounds good. How much too small is your printer? I designed with the idea that most printers are 200mm x 200mm, but if many are a bit smaller than I should try redesign it to fit on those.

      Reply
  10. Many thanks Tyler. I might take you up on the offer..
    I am going to follow the 8AA batteries to start with. Then possibly change to 3S lipo if that is appropriate. I do have a couple of questions if you do not mind, but will wait until i have got the parts and started assembly. By the way, my 3D bed is too small so have printed front in two halves after cutting using tinkercad; seems to work.
    Jon

    Reply
    • Thanks! Good question. Testing is in progress, I’m hoping within the next few months. It’s my spare time project after all… cheers!

      Reply
  11. Hi there,

    Very interesting! I wish I could understand all the electronic stuff!
    I have a very simple question.
    I would like to wire a “camera flash” or anything else that flash powerfully once, to a motion sensor (typically used for outdoor light), It will scare away wild animals shewing on my trees at night. I don’t want to use noise at night when people sleep ; )

    What would be the most simple and cost effective way to do something like that?

    Thanks

    regards

    Ivan

    Reply
    • Thanks Ivan! That’s a fun question 🙂 Two thoughts:
      – I’m assuming you might already have a camera flash. You could wire it up to an Arduino with an infrared motion sensor. The tricky part will be keeping the flash on ‘Standby’ for the whole night. That will be difficult to impossible depending on the flash model.
      -An Arduino with an infrared motion detector could also control a powerful LED. I know that IRL540N MOSFET’s can be controlled directly from an Arduino and handle alot of current, so they would be a good option. Then you need to select a power supply and suitable LED’s, don’t forget current-limit resistors! Old ATX PSU’s can be found for a good price and have good 12V output. You could hack one together for pretty cheap, just remember that each LED adds some cost.
      Let me know if you have more questions! Feel free to email at tyler@td0g.ca

      Reply
  12. Hi there Tyler,

    I plan to stay away from high voltage Xenon tubes and your project is very well documented.

    Is there any way to allow for continuous flash pulses of 1 microsecond at 10-20 Hz?

    Thanks in advance.

    Ewout

    Reply
    • Thanks Ewout!

      Yes, 10 – 20 Hz is possible with these LED’s. When I did the strobe testing, the maximum strobe rate was about 50 Hz and no damage occurred.

      I think 1,000+ Hz would be possible, but haven’t done any testing at that speed. It would be good to know how fast they can strobe without damage.

      The firmware doesn’t have an option for multiple strobes, only a single strobe. I plan to add that feature but haven’t had time yet.

      Cheers! Tyler

      Reply
      • Hey Tyler,

        I did not yet read where I might input this strobing frequency. Only the trigger with a delay for photography. I plan on using something like this for high-velocity video imaging so therefore I must sync the camera with the strobe so setting a frequency in both will make this a lot easier. Is this something which can be set in the firmware?

        Or is this what you meant in your sentence:
        “The firmware doesn’t have an option for multiple strobes, only a single strobe. I plan to add that feature but haven’t had time yet.”

        I have several 3d printers and a little knowledge on electrical circuits so I think this is a manageable project for me. Not yet far enough into circuits to source a project like this on my own.

        And what’s this MK2 which I saw someone else mention? Something I should wait for?:)

        Once again kudos on the documentation, it keeps surprising me the further I get into it:D

        Thanks for the reply.
        Best regards,

        Ewout

        Reply
        • Sorry, I wasn’t very clear… Yes and No.

          Yes, the circuit and LED’s can strobe at 10hz no problem.

          No, the firmware isn’t set up for multiple strobes. That can be added though!

          So your video setup can send a signal every time it captures a frame? That would be cool. Otherwise you would need to tune the strobing rate (maybe it’s 10.001hz or 9.999hz, it would eventually go out of sync!)

          MK2 is coming along slowly… The main changes are: continual lighting mode (~150 Watts!), partial metal case, and it can run on 4x AA batteries.

          Cheers! Tyler

          Reply
  13. Hi Tyler,

    I’m a retired old-school photographer who followed Harold Edgerton’s work. My college girlfriend’s mom even worked at EG&G in Santa Barbara CA. So anyway, I’m an interested photographer but unfortunately not I am not any sort of electrical engineer.

    Can you or anyone out there recommend an electrical primer which would give me some grounding so I can understand what I’m reading in your assembly notes? Just enough that I can understand what I’m doing here.

    Thanks,

    Graham

    PS. How’s Mark 2 coming along? And also, I’d be game for a kit like Zack Schindler mentioned.

    Reply
    • Hey Graham, interesting connection to the man himself! I assume you’re still shooting, do you still use film?

      I wish that I had a really good resource for this stuff, but it’s really been a learning experience along the way. I have two textbooks that have been helpful, Practical Electronics for Inventors (Paul Scherz) and The Art of Electronics (Paul Horowitz). There are online PDF’s available, links can be found at http://td0g.ca/r/.

      The new version is slowly coming along. There have been a diverse number of challenges, but the electronics have been almost completed. The plans will be freely available, but there are a few custom-made boards so it will be difficult to build without a kit.

      I just made an order for some main control boards for the MK1 and they will be available shortly.

      Thanks for the interest! Tyler

      Reply
  14. very cool – was just looking for this type of output for a flash project i was revisiting – you’ve done most of the work for me 😉
    I currently have a front end using a Arduino Due (sam3x8e) using a 1602 display
    – with repeatable flash in 10us increments from trigger

    & rather than a trip wire, I use laser element & optical sensor for a trigger

    my LED flash end sucked – yours looks great !
    ordering the necessary parts shortly

    Reply
    • Thanks Ralph! I’m interested in your repeating flash… Are you willing to share more details? I’ve spent quite a bit of time and money optimizing the LED’s for single-pulse use but have no experience with repeated strobing faster than 50 hz!

      I made the tripwire system to see if somebody could do high-speed photography without complex sensors. My best shots were taken using the light sensor method you described: https://td0g.ca/2016/07/28/ballistic-chronograph/

      Reply
      • I’ll read it in more detail in a bit – but much more complex than my system
        (only looking a a single point with the laser & only looking at single drop at a time )
        — see http://ralph.ca/other/drip/index.html
        for even older timing stuff / using a at2313 in asm to do timing/irq (same laser/sensor set up ) —

        sadly at this time due to lockdowns my device & code are both in my studio – only have access in July (…maybe …)
        BUT been looking at other processors anyway / code should be fairly straight forward
        I liked the Due because it was 80Mhz + had one at hand
        but there are ST devices that could work just as well .. hard timers & fast IRQs

        Reply
        • Love the photos you linked to!

          You would think that an 80MHz board would be superior to an Arduino, but for my purposes the humble 8MHz ATMEGA328P built-in clock rate is fine. I finally got around to uploading the scope traces for my boards at https://github.com/td0g/high_speed_flash/tree/master/R%26D/2020-04-15 . The 2-microsecond trigger delay might become an issue with very high-speed photos, but the triggering device should be able to account for the delay and send the signal 2 microseconds early.

          That said, it never hurts to use a faster board… 🙂

          Reply
          • the Cree LEDs (and a few other parts) arrived in less than 24 hrs ..
            voltage booster will take 2-4 weeks … might take the time to make a board to press fit the leds & hold the other components
            have you had any temp issues with the leds ? need heat a sink ?

            2us delay for most applications should be negligible providing it is constant
            quick calc : wiki says a “bullet” speed is between 500-1250m/s *2us -> 2.5 mm travel past the trigger ..

          • been thinking about flash “modes” (while waiting for parts)
            http://ralph.ca/other/FastFlash/flashModes2.jpg
            & a couple of questions :
            1) Had you tried large uF “flash” capacitors (I.E. 350uF) rather than the 10uF ?
            2) could you have chosen to do a 4×3 (4 led bank) rather than a 3×4 (3 Led bank) ?
            I’ve decided to use stm32f411 MCU at 100Mhz & has enough timers to do near anything ..(potentially clk’ed at 100Mhz)
            Utilizing pre-made modules – near the same size as Arduino Nano

Leave a Reply

%d bloggers like this: