close-circle
Close
0%
0%

Bullet Movies

Using red, green, and blue LEDs to capture short movies of very fast objects

Similar projects worth following
close
"Still" bullet photography has traditionally been done with an open camera shutter and fast gas-discharge flash lamps. Recently, LEDs have become bright enough to perform the same function. I'm taking this one step further and using red, green, and blue LEDs to capture three instants in time in a single camera image, which can be reconstructed into three separate frames with a little linear algebra. Although RGB exposures like this were done (on film, with flashlamps and colored filters) in the 1960s, modern technology brings this within reach of the average hacker.

Using 1 us flashes, this system will be capable of capturing images at 1 million frames/second - for 3 frames.

I wanted to call this project "Bullet Time for Real," but some jerks have a trademark on the phrase "bullet time."

The basic idea is to use a DSLR (and the fastest lens you can find/afford) in a darkened room with a long exposure (open shutter). As the projectile moves, three separate flashes of red, green, and blue light are produced, recording three separate instants in time on the red, green, and blue sensitive pixels of the camera sensor. In an ideal world, each sensor pixel would be sensitive to only a single LED color, producing three completely separate images. In reality, there is some cross-sensitivity: for instance, the green sensors see all three LEDs to some extent, causing ghosting from the other frames. I've developed a method for removing these ghosts, as explained in the first project log.

I'm approaching the development of this project in three phases. Each successive phase will work on timescales roughly 1000x faster than the last, introducing interesting new challenges.

Slow Timescale (Human)

I've already done some experiments on this scale - using low-powered LEDs and pulses of several seconds, I've been able to prove that the matrix-inversion ghost correction works. See details and images in the first log.

Medium Timescale (Milk Drop)

For these tests, I'm aiming to create some flashes of around 1 ms duration, fast enough to capture milk drops, popping balloons, and other medium-speed objects. In order to get enough light from the LEDs in these brief pulses, I'll need an array of LED chips driven with pulses tens of amps of current. I'll also need some way to trigger the flashes, and a variable time delay and flash sequencing mechanism to drive the LEDs. I'm planning to design some fast photodiode gates for triggering, and implement the timing functions on a PIC programmed in C and assembly.

Here are some initial results from the millisecond flash regime, shown as the original RGB image, a naively-separated animation, and after the ghost-reduction algorithm:

Fast Timescale (Bullet)

Three things are key to making this work: SAFETY, SAFETY, and SAFETY. Due to constraints of my space, I won't be using any firearms, only air rifles. Even so, these devices are capable of pushing pellets past the sound barrier, although I'll mostly concentrate on projectiles at around 200 m/s. At these speeds, microsecond flashes are required to avoid any blurring in the image. I'll re-use the photogate trigger developed for the slower system. Since the muzzle velocity of the air rifles I will be using shows a large variation between shots, I intend to use a dual photogate trigger to measure the projectile velocity as it leaves the rifle. Assembly code on the PIC can use this measurement to compute, while the projectile is in flight, when to fire the first two flashes so the impact can be captured precisely. The timing of the third flash will be a matter of trial and error, since the energetic interaction between the projectile and target is somewhat unpredictable.

A significant portion of this part of the project will be devoted to safety mechanisms to prevent any sort of accidents. Another challenge will be creating bright enough flashes with LEDs. I have had some custom LEDs made which I intend to drive with 1 microsecond current pulses of up to 150 amps. The lifetime of these LEDs under such abuse remains to be seen: I would consider even a few thousand flashes respectable, considering the setup time required to stage each exposure.

The ultimate goal is a three-frame animation of a 22-caliber lead pellet striking an A19 halogen light bulb. I saved the old bulbs when I replaced them with LED versions for just such an occasion.

  • Pulse Hubs

    Ted Yapo06/18/2017 at 23:13 0 comments

    I assembled the remaining pulse hubs. These accept the pulse signals from the flash controller and distribute them to up to 18 flash boards. Since I only have 9 boards (3 each R, G, and B), I only populated three output jacks on each hub. SMA connectors are pretty but expensive.

    The circuit on each board is simple: a NCP81074B MOSFET gate driver IC serves as a line receiver and line driver for up to (6) 50-ohm outputs. The "B" version of the IC has input thresholds near ground and the gate driver supply voltage (plenty of hysteresis) to ensure no false triggering. The output impedance is a fraction of an ohm, so 47.8-ohm resistors back-terminate each output. The IC has rise-times of around 4ns, so I could generate really narrow flashes, but this also means the transmission lines need to be terminated to avoid reflection problems. Here's the schematic of each board:

    I didn't populate the input AC termination components; I doubt they're necessary. I am considering adding some input protection components in their place. In retrospect, that's what's really missing on these boards. I'll just have to be careful with them for now.

    I really like these driver IC's - they're not just for MOSFETs anymore! There is also an "A" version of the driver IC that I will use on the controller board. The "A" version has input thresholds than can be driven by 3.3V logic, while the output voltage swings rail-to-rail.

  • Cheap DSLRs from Ebay

    Ted Yapo06/18/2017 at 18:02 3 comments

    In 2003, I bought a Canon EOS 10D for over $1k. This 6.3 MP "prosumer" DSLR has been "my camera" ever since - for the past few years I have been hoping the shutter would die to justify buying a more modern body.

    For some of the images I want to take, I'd like to have multiple cameras capturing the scene from multiple angles during the three exposures. This is how the original "bullet time" effect in The Matrix was filmed. I can't afford as many cameras as they used, but I was really pleased to find working examples of the "consumer" version, the EOS 300D, for around $60 on ebay, so I bought 3 of them, enough that each microsecond exposure could be captured from a different viewpoint.

    In fact, with the RGB exposure scheme, this will result in nine total high-speed exposures, three from each viewpoint. If a "normal" exposure is taken of the scene both before and after the event, a total of 15 exposures will be available to stitch into animations. This should allow some creative flexibility.

    I'm incorporating three shutter control jacks into the controller prototype, so that each of the camera exposures can be synchronized to the rest of the sequence. These "consumer" cameras use a common 2.5mm stereo jack for the remote - no need to source the custom connector used on the higher-end Canons.

    A big advantage to using cheap cameras like this is that I won't be too upset if I accidentally shoot one (or more likely, it gets hit by a ricochet). They're essentially consumables.

    As for lenses, I already had an older "nifty fifty" 50mm f/1.8, so I bought one of the updated ones, which I had been wanting anyway. The third lens is a Yongnuo 50mm f/1.8, which at $55 is a bargain, and seems to compare favorably with the Canon lenses. The Yongnuo is supposedly about half a stop brighter wide open, too, although I haven't compared them directly (yet). I have a small supply of UV filters which should offer some protection for the lenses - they're worth more than the bodies.

    I think it's really neat that you can pick up a working DSLR today at "impulse buy" prices.

  • Let there be *more* light

    Ted Yapo06/18/2017 at 00:45 0 comments

    I assembled the remaining two purple PCBs (red and blue LEDs), and six of the green ones. The OSH Park ones on the left have the lenses attached and are connected with some 3D printed connectors I designed to focus the illumination about 25-30cm away from the boards. The lenses have a 25-degree angle and are designed to fit on the 1/3/5W LED cases. I just finished testing the green boards, so haven't had a chance to attach the lenses with thin double-sided tape yet.

    Overall, there are 90 5W LEDs, with 360 total 30mil chips, for around 210 mm^2 LED area. With the full-power pulses, these chips see a pulse of over 2600 total amps.

    Skillet Reflow Failure Rate

    This was a large enough batch of boards that I saw some failures in the assembly process. I applied solder paste with a 1cc syringe and a 22Ga needle, hand-placed the components with tweezers, then reflowed the boards on a hot plate. I caught a few tombstoned resistors during the reflow and pushed them back down with tweezers. I mostly attributed this to the green boards being a little warped and not sitting flat on the hot plate. The resulting uneven heat caused one side of some components to melt first, and erect the tombstones. I didn't have any tombstones on the OSH Park boards, which are definitely more flat.

    After manually soldering the LEDs on the front side, I found two LEDs that didn't work. In both cases, one smd resistor looked connected, but wasn't. A quick touch with a soldering iron fixed both.

    Each board has about 70 SMD components on it, so with 9 boards, that's 630 parts. Two parts got mounted in a way that didn't work, for about a 0.3% failure rate. Looking at it another way, two of the nine assembled boards were defective, for a 22% failure rate. I don't think I could make a business selling boards with this kind of success rate, although they all work now. I don't have any plans to commercialize these boards anyway, but it's interesting to see the issues with hand-assembled surface mount.

    Annoying Miscalculations

    I bought 100 of the aluminum polymer capacitors used to store the LED flash energy. Since I was buying a bunch, I also used them for bulk storage caps on these boards and the pulse distribution hubs. This meant I actually need 102 of them! I can just substitute another cap on two of the remaining hubs, but it sucks to run out of the "right" part.

    Why the angle?

    I designed the red board clips based on some simulations of the lenses in OpenSCAD. Before ordering 100 of them from China, I wanted have some confidence that I had chosen the right beam angle, since there are a wide variety available. I can always switch them, but it would take a few weeks for new ones to arrive. Here's an image of the simulation:

    It's pretty basic, but it let me figure out how to design the mounting clips based on the desired lighting volume.

  • Got One!

    Ted Yapo05/28/2017 at 02:28 4 comments

    I caught a 0.177 caliber pellet in flight using the sound trigger. You can see the grooves cut into it by the rifling of the barrel. This pellet was traveling about 154 m/s during the photo. I used just the green LEDs, since my controller is only single-channel for the moment.

    You can also see a lot of sensor noise in the image. This was a six second exposure (with a 1 us flash) at my camera's "H" ISO setting (3200). At this gain, the pixel leakage currents start to become visible. Much of this noise is repeatable frame-to-frame, however, so it can be removed by subtracting out a "dark frame" image of the same exposure length with the lens cap on. I remembered this after the fact and took a few dark frames. I'll have to try using them to reduce the noise tomorrow.

    The blurring in this image is mostly because the pellet is out of focus. To gain more light, I'm using the lens wide-open at f/1.8, which results in a shallow depth of field. You can see the problem clearly in this image, in which I mis-timed the shot, and got the pellet hiding behind the card (I wanted to catch the pellet to the right):

    The back of the card is out of the focus depth. The real positive here is that there's plenty of light. I might even be able to "waste" one exposure stop on increasing the depth of field or decreasing noise. I also ran the LEDs only at about a 10x overdrive for these tests. Previously, I had tested them at around 21x overdrive, which produces almost twice as much light.

    Now, I need to work on some alignment tools and procedures. Lining up and timing these shots is a real pain. Then, I can add the other two channels and start making some animations.

    I would also like to make a motor- (or solenoid-) based trigger release for the airguns. It's a little un-nerving to discharge them manually in a completely darkened room, even if they are solidly clamped to a workbench. I'd rather be elsewhere.

    The other very interesting thing is that I can clearly see the pellets when they are caught by the 1 us flash. I used to see 9mm rounds traveling in a well-lit range occasionally, but I didn't think I would be able to see anything lit with only a short flash.

  • Sound Trigger

    Ted Yapo05/27/2017 at 16:22 0 comments

    I'm starting to find some time to work on interesting things again, so I've resumed work on this project. One of the blocks to progress before was the need for fast, large area photogates to detect projectiles in flight. A few early experiments didn't turn out as planned, so I've fallen back to a sound-based trigger. I built a simple prototype today, and it seems to work very well for detecting airgun shots. Here's the board (not shown is the 9V battery double-stick taped to the back for power).

    My initial concern about using sound was the possibility of false triggering - on the camera shutter noise, for instance. A few experiments with a 10m target pistol showed that a common electret microphone capsule produced an output of several volts when positioned about 20cm to the side of the muzzle. I came up with the rest of the circuit pretty quickly after that. Here's the schematic:

    The electret mic (and its internal FET) are biased with a 22k resistor from power supplied by a 9V battery. The bias level was chosen to keep the quiescent mic output voltage relatively low, since the pressure wave from the airgun discharge produces an initial positive pulse. This output is compared with an adjustable reference voltage from a trimmer in an LM311 comparator. The output of the comparator triggers a monostable 555 to deliver a 100us pulse to a 50-ohm cable via a BNC connector. Not shown in the schematic is a 78L05 regulator for deriving the 5V supply. The circuit draws about 6mA. I'm sure you could do better with more modern parts, but I had these jellybeans around (the LM311 has a 1989 date code) and I'm on a use-what-you-have kick.

    The resulting circuit seems very robust, consistently triggering on airgun shots, but is insensitive to even the loudest hand-claps I can manage. I have no concern that it will be triggered by the camera shutter.

    Here are the waveforms at the output of the microphone capsule (yellow) and BNC connector (cyan) when triggered by a relatively low-power 10m target pistol:

    The output of the microphone saturates with a positive excursion of more than 5V, and a rise-time of around 11us. The 100us output pulse starts about 5us after the beginning of the detected pulse. This will change somewhat with the threshold potentiometer setting. With this particular pistol, the muzzle velocity is about 150 m/s, so the projectile moves less than 1 mm in those 5us.

    I have seen triggering setups where the initial flash delay is changed by moving the sound sensor relative to the muzzle, using the speed of sound as the delay mechanism. I think I'd rather keep the sensor at a fixed distance from the muzzle and control delays in software.

    The sound level at the microphone is pretty extreme. I'm not sure if it will eventually become damaged, but it's easily replaced if so.

    Next Steps

    I need to wire this sensor to my first flash controller prototype and try to capture some single-frame photos of projectiles in flight. I only have a single-output controller prototyped at this point, so no bullet GIF loops yet :-(

  • Flash Boards Arrived

    Ted Yapo12/11/2016 at 01:22 0 comments

    The PCBs for the flash boards (and the pulse hubs) arrived last night, as did the DigiKey box with all the parts - that doesn't happen often enough :-) I found some time to assemble and start testing one of the flash boards today. The back view shows the aluminum polymer caps:

    The screw terminals are "backwards" so I can mount these boards in a tight grid (R, G, B) with possibly more than one board per color. The front of the board shows the LEDs, 4-chip "5W" packages, as well as a single lens/reflector I was testing:

    All the components on the back were reflow soldered on the skillet, then the LEDs and connectors were soldered on manually. The board seems to work as designed, with the exception of the footprint for the SMA connector - the corner mounting holes are too small.

    I don't know how I screwed this up - the square root of 2 is still around 1.414, right?? Anyway, rather than drill out the nice plated-though holes, I filed down the connector to make it fit.

    Measurements

    I tested the board at a number of different LED voltages - the flash controller board will have software-adjustable regulators for setting these, since the different color LEDs have different forward voltages, and the red LEDs appear to all be in parallel in the package, instead of the series/parallel arrangement of the green and blue.

    Here's the waveform across the 0.1-ohm resistor in series with one of the LEDs:

    The voltage is measured across a 0.1-ohm resistor with a 2x Z0 probe, so this pulse represents 14.9A of current through one of the 10 LEDs. The supply voltage was 18.5V for this pulse - the capacitors are rated 25V, so I could go somewhat higher. Since the LEDs are rated for 700 mA, this represents about a 21x overdrive. After several hundred pulses, I couldn't detect any changes in the LEDs, but obviously I need to test it a lot more.

    Design

    The nice shape of the waveform and minimal ringing is due in large part to some design hints I got from others here.

    The NCP81074 10A MOSFET gate driver was completely over-sized for a single MOSFET, but does well driving 10 of them. A 100-ohm resistor at each gate keeps the edges relatively slow preventing overshoot and ringing. The 2A Schottky diode across the LED protects it against the brief reverse-bias overshoot on the trailing edge. I included sites for AC-terminating the 50-ohm input, but haven't populated them. I'm going to drive the board from series-terminated sources, so I don't expect a problem, but they're there if needed. Bypass caps aren't shown.

    I included the R1 and R2 resistors right at the output of the driver in case series terminations were required to tame reflections on the gate drive line. The driver has edges of a few nanoseconds, and you can see a light ring/reflection after about a quarter of the rise time of the pulse above. I suspect the inductance of the long, branching gate drive trace on the PCB is to blame. I actually populated R1 and R2 with 0.1 ohm R's, so I can probe them and have a look at what's going on. Resistors of maybe 10 ohms there might help eliminate that one annoying ring. When I get a chance, I'll post a better scope trace of the offending ripple.

    Overall, this board looks like a success. It's bigger with less light output than I originally imagined, but seems pretty manageable and scalable - I can just use as many as I need. Next, I'll figure out which lenses make sense for a useful beam angle, and I can take some test photos.

    I've been working on a photogate design, too. I'll document that soon.

    EDIT - I just did the math. Assuming the forward voltage of the LEDs is around 10V at this current (probably conservative), the pulses dump about 1500W of power into the LEDs.

  • Flash & Pulse Hub Boards

    Ted Yapo11/28/2016 at 15:52 0 comments

    After some reading and thought over the holiday, I designed a PCB to hold 10x of the 4-chip 5W LEDs by Chanzon and others. This could alternately carry 1W or 3W LEDs.

    The front side of the board carries the LEDs and some inexpensive lens/reflectors:

    The lenses are available in a variety of beam angles; I have samples of a few different ones - not sure yet which will end up being most useful. What I do know is that the 120-degree angle of the bare LEDs makes it difficult to get light where you need it. Having lensed LEDs should make this much easier. The lenses press-fit on the LEDs - you can secure them with double-sided tape, but I think being able to change beam angles might come in handy.

    The back of the board has a local flash circuit for each LED:

    I went with aluminum polymer capacitors on this one - @K.C. Lee mentioned them as a possibility a while back, and on this board, I think they'll work out well. Specifically, with just two LED chips in series for each driver, I won't need more than about 20V of supply, maximum. I have some 25V caps selected - I tested a similar circuit with some 20V through-hole polymer caps I had on hand, and it seems to work very well. The low ESR of the cap allows lower voltage operation for the same current pulse, so higher-voltage caps aren't required. These capacitors are large enough (56 uF) that longer, lower-current pulses are also possible with this board - allowing more light for slower scenes. The capacitance doesn't drop with applied voltage like MLCCs :-)

    This board is a step back from my original plan of a few LEDs driven with very high currents. Over the holiday, I had a chance to read Willert, et al. thoroughly. When I initially skimmed this paper, I was impressed that they were able to drive their LEDs with up to 250A. Upon further reading, I saw that the LED they were using, the CBT-120 from Luminus Devices, is rated for 18A continuous current! This large-area (12 mm^2) single-chip LED is designed for LED projectors, and costs over $100 in single quantities (it's actually not recommended for new designs; the replacements are a little more affordable, but not much). So, they're only over-driving the LEDs by a factor of 250/18 ~ 14x. If I want to stick to the same overdrive for 700mA max LEDs, I should pulse them with no more than around 10A. Of course, I will need more LEDs, which is how I got to this board design.

    The other interesting point from the paper is that they claim fast rise-times are LED killers. In one passage, they claim that rise-times of 500ns or less at 250A can destroy their LEDs - although they don't describe the exact mechanism. In another place, they claim they drive LEDs with pulses as short as 100ns, though, so I'm not quite sure what to make of it. In any case, I have sites for MOSFET base resistors on the PCB to control the rise and fall times. While I'm waiting for these boards, I can do some experiments on the previous prototype to see if limiting the current pulse to around 14x overdrive and controlling the transition times extends the LED lifetime.

    In that paper, they were driving 12 mm^2 LED chips (for a different application). On one board, I'll have 10 LEDs with 4 30x30mil chips each, for a total area of 23.2 mm^2. You could also populate the board with 3W LEDs (45x45 mil chips) for 13 mm^2 total - if pulsing the series/parallel 5W LEDs is a problem, I can always fall back to these.

    One issue with the smaller current pulses is that I'll need more LEDs to get the required light output. I think that even 10 LEDs won't be enough, so I'm planning to be able to drive more of these boards as required - this will also make it easier to get light where it's needed, since each board can be independently positioned.

    Pulse Hub

    I thought about adding multiple outputs to the timer/controller board (still to be designed) to allow connection of multiple flash boards, but decided it would take up too much real estate on the board. Instead, I opted for an external "pulse...

    Read more »

  • First Eposure Test

    Ted Yapo11/23/2016 at 03:12 0 comments

    While I was sanity checking the flash timing, I figured I should make sure the light estimates were roughly in-line, too. I used the second prototype with a "5W" green LED (4 30x30 mil chips). The power supply I had on that bench limited me to 10V, so I could only run the LED with 4.4A pulses. Here's an exposure from a single 1.08 us flash from the LED:

    Sure, it's grainy, and could use a lot more light over a bigger area, but that's with a single $1.23 LED. It's also less than half the brightness I had achieved before with a 24V supply. According to my photodiode sensor, the 24V pulse was 2.23x as bright. I'll have to drag the other supply over there and test it out.

    I'm going to call it a success. There's plenty of room for improvement, but it's encouraging.

  • How fast does it have to be?

    Ted Yapo11/22/2016 at 17:09 0 comments

    I'm still working on the LED pulse circuit, but thought I would take a step back and figure out exactly how fast it needs to be. I did some early calculations to come up with a 1 us flash duration, but thought I should revisit the issue. To get a handle on things, I photographed a rule at the minimum focus distance for the lens I intend to use - about 36 cm away. I could add a macro spacer ring to allow closer focus, but I don't want to endanger the camera by getting it too close to the action. Here's the rule ( what's on the other side of rulers in metric-system countries? )

    The horizontal field of view is about 15cm - knowing this will come in handy later. Zooming in at the center of the image, we can measure the resolution in pixels/mm:

    There are about 20 pixels/mm - we can use this number to figure the required flash duration based on the projectile speed and allowed image blurring.

    My initial tests will be with a CO2-powered air rifle at about 600 fps - that's approximately 180 m/s. I would eventually like to photograph a supersonic projectile at around 350 m/s - spring piston rifles can do this. Based on these two data points, I came up with the following chart, which shows the blur length in pixels for a projectile at either speed photographed with various flash durations:

    Flash Duration
    Velocity (m/s) 100 ns 200 ns 500 ns 1 us 2 us 5 us 10 us
    180 0.36 0.72 1.8 3.6 7.2 18 36
    350 0.7 1.4 3.5 7 14 35 70

    An absolute razor-sharp image might require less than 0.5 pixel blur, but these speeds are probably unrealistic based on the amount of light required for the exposure. Wide open at f/1.8, the lens can't even manage a crystal-clear image at this resolution. To put these numbers in perspective, here's an image of the .22-caliber projectile:

    The pellet is approximately 7 mm long - 140 pixels in the original image. Based on the above table, if we wanted to photograph this pellet with no more than a 10% blur, we would need around a 4 us flash at 180 m/s, or 2 us at 350 m/s. The original target of a 1 us duration would provide around 2.6% blur at 180 m/s. On the other hand, extending the pulse to 10 us would produce 10x as much light, while blurring the pellet by 25% - probably not a great photograph, but interesting nonetheless.

  • Fried Green LEDs

    Ted Yapo11/20/2016 at 23:28 20 comments

    I knew it would happen at some point. I killed some 30x30 mil LED chips in this stock 10W green package. The remaining good ones still light off DC:

    Actually two others in the left string also appear at higher currents; before the "event," they all had similar forward voltages and would all light about equally at a few mA.

    What Happened?

    I built this new flash circuit using a NTD5867NL MOSFET driven by the NCP81074B gate driver IC. The circuit has the same topology as I used before - this time, I substituted a 100 milliohm 1206 for the current sense resistor, and started with the 40uF photoflash capacitor. The idea with this test was to see how high I could get the current at reasonable voltages. The MOSFET is rated for 60V Vdss, so I figured 50 might be a decent de-rating for tests.

    With the 40uF cap in the circuit, I tested the pulses up to 50V. This is the voltage across the 100-milliohm sense resistor as measured with my soldered-on 2x Z0 probe. I believe that ringing is really present in the circuit, since the Z0 probe terminates the coax at both ends, and has shown clean pulses before. Accounting for Rsense and the 2x probe, the cursor measurement is at around 23A. With a 50V supply, this isn't great.

    The optical pulse, as measured with my biased photodiode looks good, shape-wise:

    the cyan trace seems to confirm the ringing issue - the light is ringing, too! The optical pulse would be fine for a camera exposure, though, capturing a clean 1.086 us instant.

    I wasn't satisfied with 23A - that's less than 8A for each LED chip, and I had pumped 12 or so into the smaller ones before. I knew the 40uF capacitor had a high ESR limiting the current, so I replaced it with a 100uF photoflash unit, expecting a smaller ESR but perhaps a larger ESL. With the 100 uF capacitor in place, I turned up the voltage, eventually reaching the 50V mark. Before I could measure the current or take a screenshot on the scope, though, the current waveform began to droop - pulse by pulse (about 1Hz), the waveform fell little by little until it came to rest at less than half of what it had been. At the same time, some of the LEDs stopped working.

    The Cure?

    My suspicion is that the LEDs were killed by overstress transients caused by the ringing. I had recently found the paper Pulsed operation of high-power light emitting diodes for imaging flow velocimetry by Willert, et al. In their driver circuit, using a similar MOSFET/capacitor arrangement, they place a BYT 01-400 rectifier diode reversed across the LED. They state that:

    Diode D1 protects the LED from potentially damaging reverse currents that arise during the rapid switching transients of the circuit.

    sounds like what I've just experienced. I'm not sure about their choice of diode, though - that rectifier diode has a reverse recovery time of 55ns, which sounds too slow. Maybe the LED-killing transients are at the end of the pulse? You can see the red curve above spike negative when the LED is turned off. At the end of the pulse, you don't care about the trr of the protection diode.

    My next step is to replace this LED with a fresh one and add a protection diode - but which one? Jack Smith has done some great measurements on forward and reverse recovery time in various diodes. His studies indicate that even the lumbering 1N4007 with it's 3us trr switches on in a few nanoseconds to eat transients. Luckily, I have more 1N4007s than I will ever use.

    I am a little concerned by the long bond wires in this LED package, though. Maybe it would be better to go with the 5W LEDs that have (4) 30x30 mil chips in a smaller package? I'll have to try some things out.


    Part Two

    I replaced the first LED and added a 1N4007 diode. This one lasted long enough to make some interesting measurements before failing in the same way after about 400 flashes. After failure, some of the LED chips only partly glow. Notice the ones in the lower left:

    While it was still working, I was able to grab some data about the crazy transients in...

    Read more »

View all 23 project logs

Enjoy this project?

Share

Discussions

sakupiec wrote 11/20/2016 at 03:35 point

Very Neat. Having done quite a bit of high speed work with LEDs and cameras you might want to look at some options. 

You may want to look at the LT3743 driver chip. there is an excellent DC1470A evaluation module that should hit 1 us out of the box. At these speeds you can appreciably higher currents than the DC rated values. I run a 4A 38kHz 10% duty cycle without breaking a sweat. These can drive some pretty insane LEDs like the Phatlight series. Just make sure to power up the DC1470A AFTER your logic boards come up. 

You may also want to consider Fluttershutter modulation which can considerably reduce blurring while increasing exposure:

http://web.media.mit.edu/~raskar/deblur/

https://www.researchgate.net/publication/276513450_Motion_deblurring_with_temporally_coded_illumination_in_an_LED_array_microscope

  Are you sure? yes | no

Ted Yapo wrote 11/20/2016 at 05:39 point

Thanks for the tips!

I had seen the LT3743 discussed in the new Art of Electronics - Messrs. Horowitz and Hill are impressed with it, too.  I'll have a closer look, but back-of-the-envelope calculations put me in the 100A range (which I supposedly can get away with in the microsecond regime).  Capacitors and MOSFETs are looking good at this point, but who knows.

The flutter shutter paper is interesting - I think I skimmed it a while back.  It seems like a good technique for moving objects which don't change appearance much over the total exposure time - i.e. good for reducing classic motion blur.  For objects with rapidly changing appearance, maybe not so much.  I hope to capture some objects whose appearance changes rapidly :-)  There might be something in there, though.  I'll definitely give it a thorough read...

  Are you sure? yes | no

David H Haffner Sr wrote 11/17/2016 at 08:35 point

Congrat's on begin featured on the front page!

  Are you sure? yes | no

Ted Yapo wrote 11/17/2016 at 15:07 point

Thank you! 

  Are you sure? yes | no

Yann Guidon / YGDES wrote 11/11/2016 at 06:45 point

Oh, that explains the custom RGB LED assembly story...

  Are you sure? yes | no

Ted Yapo wrote 11/11/2016 at 13:34 point

Yep.  I didn't mean to make it sound mysterious before, but there's a lot of context.

We'll see how the LEDs work out.  My first idea was to use Luxeon Z LEDs, which you could pack onto an arbitrarily large PCB at an amazing density (and at amazing cost).  Unfortunately, these LEDs appear to have zener ESD protection chips wired into the package.  My concern is that the zeners would conduct during the brief high-current (and necessarily high voltage pulses) I'd need.

I think you mentioned similar issues with previous generation Luxeons and their built-in protection devices.  "Real Engineers" add such protection themselves, if it's required...I don't need LED manufacturers making these decisions for me.  Not that I'm a real engineer :-)

  Are you sure? yes | no

Yann Guidon / YGDES wrote 11/11/2016 at 14:29 point

amen......

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates