Low-Cost High-Speed Photography - Part 1

Find this and other photos HERE.

Project Features

• Produces white light flashes for high-speed photography and multiple exposures
• High flexibility / reconfigurability (menu controlled)
• Low cost (no flash unit needed, mostly cheap parts)
• Simple hardware
• No recharging time as for conventional flash lights

Introduction
Some of the ideas I have take years until I actually put them into practice - be it because there are other, more interesting things to do, be it because I can't find some of the parts or be it because I can't solve some of the problems involved with it. The LED stroboscope was one such project. I had no idea whether a power LED would be bright enough for what I planned. And power LEDs were just too expensive for trying.

The basic idea was to use bright white LEDs to build a flash unit for photography. This could be used to take high-speed photographs (just generate one short flash when triggered by a sensor) or to take multiple exposures by generating a train of flashes. In principle, it is a very simple project, and a microcontroller is almost an overkill. It can probably be done with an NE555. The one advantage a controller has is that it is very flexible. So you can change timings with little effort.


Principle of Operation
For high speed photography, normally a little trick is applied. Every camera, especially a digital camera, has a delay between pressing the button and actually taking the picture. In many situations, e.g. breaking glass this means that by the time the camera actually takes the picture, the event is long over. The solution to this problem for about 70 years has been to use a trigger which activates a flash light. It goes like this: Your whole set-up is in a completely dark room. The camera is set to long-term exposure. Flash lights have no mechanical parts and they do not need to calculate anything. So they can be activated rather quickly. You start the long term exposure (e.g. for four seconds), initiate the high speed event (e.g. generate a drop). The scene gets illuminated for a fraction of a second. You then stop the exposure manually (if needed). Since it is dark in the room, the speed of your camera shutter doesn’t matter. As an additional advantage, you do not need to modify the camera in any way.

But there are at least two requirements that the camera has to fulfil. First, it has to have the long-term exposure mode. Second, your camera should have a manual focussing mode. Many compact cameras have this feature. Mine does. What it doesn't have - like most compact cameras - is high sensitivity. But this is the compromise, I guess if you don't want to spend money for a DSLR.

The LED
While looking for a cheap supply of a larger amount of LEDs on the internet, I discovered a rather good offer for a power LED, mounted on a star PCB. It was only 4€ including shipping and it promised 100 lumen at 1 Amp. So I thought I'd give it a try. I did expect 100 lumen to be insufficient and with no manufacturer given, it was probably bad quality. But at least that LED could be used for a "proof of concept" and if working, could be "upgraded" to something brighter, more expensive. Which is just what happened in the end.


Controller and Software
The controller chosen is an Atmel ATtiny15L. I know that they are out of production. But I had these lying around and this was a good opportunity to do something useful with them. Also, it should not be too difficult to port the firmware to a newer part like the tiny25.

First I thought that in order to get perfect timing I should use a timer and an interrupt routine. But after fiddling around for some time I decided that it's not worth the effort. Now I produce my timing with simple delay loops. No timers or interrupts are used. This is an advantage, because the ATtiny15L has no RAM. So the stack is only a three-level hardware-stack. Having no interrupt means that you can use an extra layer of subroutines.

As mentioned, the core software is very simple. Just initialise the hardware, wait for an input signal and then switch on the output for some time.

The Hardware - Step one
The Hardware is also nothing to get excited about. Take the tiny controller, supply it with 5 Volts (no voltage regulator, but a regulated lab power supply in my case). Add a button to connect the trigger input port with ground (use the controller’s internal pull-up resistor). And finally drive the LED. Mine was rated for a maximum current of 1 amp. The tiny15L can’t deliver that of course. So a driver was needed.

I found an n-channel MOSFET transistor in my junk box, a BUZ-73 which can easily drive the 1 amp. Its gate is connected to a standard I/O port on the controller. And just so I sleep better there is also a pull-down on this port pin to make sure the transistor doesn't conduct as long as the controller is in reset or in High-Z state for any reason. The LED of course was connected between 5V and the drain pin of the MOSFET - in series with a 1.33 Ohm resistor. To avoid problems with the power supply I added a 470µF capacitor. More would be better, but I didn't have a bigger one.



For development, that was it. Material costs were probably about 6 or 7 €. Wait, no, I also added a reset button and a pull-up on the reset port pin. But I didn't really need that initially. I don't need to mention the 100nF capacitor, which just has to be there, right?

Power Dissipation
Everywhere you buy power LEDs you are warned to provide sufficient cooling. Since I wanted to produce repeated pulses at perhaps 10 Hz (100ms) with a pulse length of 1ms this means that the LED is switched off at least 99% of the time. So the LED sees only 1% of the power that it is designed for. For that reason, no cooling is needed. The star PCB will provide enough surface to disperse the heat. In my various tests I never noticed the LED getting even warm. But keep this in mind if you plan to write your own software! If e.g. it crashes with the LED activated, it may die due to overheating.

CPU Clock
The tiny15L hasn't got any provisions for a crystal oscillator. It produces its on clock through an internal RC oscillator at 1.6 Mhz. In order to get good accuracy, the controller should be run at a constant 5 Volt supply and the OSCCAL value from the individual device should be adjusted as recommended by Atmel. I did that and I think that this gives me enough accuracy for the task at hand.

First try
Initial software was written that just generated a sequence of 1ms-flashes as long as the trigger button was pressed. The LED does produce very bright white light. So I tried to take a few of those multiple exposures. With my compact digital camera on a tripod and set to long-term exposure, I waved my hand in front of it and triggered the stroboscope.



The results were not too encouraging. Clearly, the image is too dark. Only with the help of image editing software something became visible, at the cost of a lot of noise. A bit disappointing. But I was always aware that here was the big question mark in my set-up. And I still had the second mode of operation to explore.

A bit later I discovered that there was a bug in my first software that caused the flash pulse length to be less than one 1ms. Very likely this was part of the problem.

Automatic Triggering
Since it was clear that I needed more light for multiple exposures I wanted to try the high-speed part of the project. So I needed a sensor to trigger the device. For taking pictures of drops there are several options. You could use a photo sensor that "sees" the falling drop, you could use a microphone that "hears" the splash or you could use a pressure sensor that "feels" the impact. I did the latter.

I took one of these cheap piezo transducers that you get e.g. with musical greeting cards and I put it under a glass of water. On a scope i measured voltages of around 0.2 Volts for a falling drop - depending on where exactly I put the piezo and how far the drop fell. This was promising. I had expected much less.


So all I needed was to detect the voltage on the piezo going over a certain threshold. Job done. The device that does this is called a comparator. And believe it or not, there is one of them in the tiny15L...

The trigger circuit only needs the sensor itself, a DC shifting circuit (consisting of a voltage divider and a decoupling capacitor) and a reference voltage to compare the sensor voltage to. This is a second voltage divider. It should be adjustable over a certain range so that the sensitivity is right.

The whole interface is implemented in such a way, that the trigger switch can still be used. It is simply connected to the sensor in parallel.

Initial results on drops
My set-up worked immediately. The LED was fired when a drop of water hit the glass bowl that I used, So I was very keen to take photos. The first two photos were taken with clear water. And on those - there is nothing to see. It seemed that the LED light just went through the water without reflecting anything back to the camera. And perhaps the camera wasn't focussed correctly. But when I saw this, I realised why most people use milk instead of water - milk is white! So it reflects the light much better. And when I got milk, I did actually get images.

They were still very dark. But the splashes were there. With the help of some image enhancement, the drops were visible.



Success! Well, sort of. Now that I knew it could be done and that money for a better LED would not be wasted, I decided to go ahead and get it. I chose to buy a Cree XM-L T6 on a star PCB. It is rated with almost 1000 lumen at 3 amps. This is about ten times more light than my first LED was rated at. And possibly, the first LED being unbranded didn't even deliver those100 lumen. Very promising.
See part 2 for the final set-up.