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!


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

Here 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


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.

Thanks for reading!

Last Updated 2019-07-25

41 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

    • 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

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

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

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

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

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

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

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

    • 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

      • 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

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

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

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

    • 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 vtgerritsen@gmail.com!

  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.

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

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

  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

    • Thanks Jon!
      While you assemble it, please feel free to email me with any questions (vtgerritsen@gmail.com). 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.

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

  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

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

  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

    • 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 vtgerritsen@gmail.com

Leave a Comment