One problem with using a position detector such as a photo beam to automatically capture a moving subject is the shutter lag - typically between 50 and 100ms for modern DSLRs. For a large or slow object this may be no big deal but smaller objects photographed up close may have moved out of the picture (or at least out of focus) in this time.
For an object that is moving predictable (e.g. falling under gravity) it may be practical to simply point the camera at where the object will be 100ms later - so long as the shutter lag is repeatable. Alternatively, you can hold the shutter open and use the detector to trigger a flash instead - but this requires working in the dark.
For insects in flight, neither is practical, and it seems the only route to success is to shorten the shutter lag. You might think that using mirror lockup or live-view there would be no reason for a long shutter lag on a modern DSLR but unfortunately it seems that there is still quite a lag. Another route - suggested by the excellent and inspiring work by Fotoopa at http://www.pbase.com/fotoopa - is to attach an external shutter in front of the lens - and this is the route I started playing with.
A couple of years ago, I bought an Ilex electronic shutter on eBay. Having worked out that it needed a 3ms pulse at 192v to open it (and then 24v to keep it open), and looked at the cost of controller boards that delivered such strange requirements, I set it aside for a while. It has been sitting on my shelf mocking me ever since.
Yesterday I decided to have another shot at it. The flash circuit from a disposable camera is perfect for delivering pulses at high voltage, it seemed to me, so I set about disassembling one (caution - the capacitor in a flash gun can hold a charge of 300V and may retain it for a long time after the battery is removed. DO NOT TOUCH any contacts - or the circuit board - without first ensuring that it is discharged using a screwdriver across the capacitor terminals).
I measured the voltage generated in the capacitor at about 300v - a bit more than the 192 I was after. The shutter's solenoid resistance is 130 ohms, and the capacitor was 120 uF, suggesting it would discharge in about 15 milliseconds. 300v for 15 ms didn't sound THAT much more than 192v for 4 milliseconds so I decided to try it anyway.
Success (of a sort) in that the shutter snapped open nicely, then shut again a little while later. However there was a disconcerting puff of smoke...
Fortunately it seems to have survived, but I think I need to dial down the voltage a bit and reduce the time (probably by adding a series resistor and reducing the capacitance, respectively).
Friday, September 18, 2009
Tuesday, September 8, 2009
Maybe not so bad...
Things improved. New multimeter just needed fuse changing it seems, and old one was reparable (with some effort, as I snapped the PCB while dismantling it to try to see what was wrong).
And I made some progress on an enclosure/case for the AVR butterfly. If it works I'll post a picture.
And I made some progress on an enclosure/case for the AVR butterfly. If it works I'll post a picture.
Not the best day...
The power is off today (tree trimming) making it hard to do any work. So I thought I'd take some pictures using the new timer. Hooked everything up, and found that the trigger had stopped working. Got out the multimeter to try to work out why, and found that it seems to have stopped working too. Went out and bought a new one, and discovered that is faulty too - but at least it worked well enough to work out why the sensor had stopped working (bridged a track while adding motor support to the timer board.
By the time I'd got all that sorted out I didn't have any energy left to take any pictures. And if I did, I'd probably find the camera was broken. Some days are just like that...
By the time I'd got all that sorted out I didn't have any energy left to take any pictures. And if I did, I'd probably find the camera was broken. Some days are just like that...
Monday, September 7, 2009
Phifact
I stumbled across an interesting project at http://www.phifact.com - interesting because it set out to solve pretty much exactly the same problem as I did when I started building my timer, and in more or less the same way.
I abandoned my initial version that used the Picaxe mainly because I couldn't get precise enough control of the timing (the Picaxe has an operating system sitting between your program and the hardware, which got in my way...), though in fact I'm not sure that I need quite the level of precision that I was aiming for. For milk-drop type photos, the nearest millisecond is close enough.
I abandoned my initial version that used the Picaxe mainly because I couldn't get precise enough control of the timing (the Picaxe has an operating system sitting between your program and the hardware, which got in my way...), though in fact I'm not sure that I need quite the level of precision that I was aiming for. For milk-drop type photos, the nearest millisecond is close enough.
Saturday, September 5, 2009
Light sensors revisited
Blew up two op-amps before I noticed I had the supply rails backwards (doh) but got a light change detector working using the circuit at http://www.ee.teihal.gr/labs/electronics/web/downloads/passive-optical.pdf
Thought perhaps it might be interesting to put the photodiode in front of the viewfinder of a camera pointed at a photogenic perch, to ave it fire of a burst of shots should a bird happen to land on it...
The detector seems sensitive enough that it might just work, though seemed to take a lot longer to turn off again than I expected.
I wonder if I swapped the inputs to the first op-amp, would it act as a slave flash trigger / lighning detector?
Thought perhaps it might be interesting to put the photodiode in front of the viewfinder of a camera pointed at a photogenic perch, to ave it fire of a burst of shots should a bird happen to land on it...
The detector seems sensitive enough that it might just work, though seemed to take a lot longer to turn off again than I expected.
I wonder if I swapped the inputs to the first op-amp, would it act as a slave flash trigger / lighning detector?
Friday, September 4, 2009
Timer circuit - the story so far
A few years ago I messed around a little with high-speed photography using a simple timer circuit to fire a flash a set time after a beam-detector spotted a drop of milk falling past it. It was quite fun, and I got some results that I quite liked, but there were a number of limitations with the approach, which led me to start a second project using a microcontroller for more accurate (and more repeatable) timings. I got as far as getting a prototype working, then the project stalled for a while due to an international move... When I tried to come back to it I couldn't remember how any of the wires fitted together - some had fallen out, and I had lost the source code.
A few days ago I started the project up again, this time taking a bit of care to build circuits that would stand (slightly) rougher handling and (hopefully) still be useable even after sitting in a drawer for a few months. I recreated the source, better this time.
The basic idea of the timer circuit is to have a number of inputs (well, one at the moment, but I will add more at some point), and a nummber of outputs (3 at the moment - 2 for the half and full press of a shutter and one to trigger a flash), and a simple editable program to control how they interact.
The "program" consists of up to 10 statements - each of which can be any of the following:
Beep
Goto
Millisecond delay
Output
Quit
Restart
Second delay
uSec delay
Wait (for input)
Most commands can have a parameter in the range 0-9999. Output takes a 4-bit bitmask indicating which outputs are to be turned on or off.
So for example a program to take pictures of milk drops might look like this:
1W
2O1100
3M0297
4O1110
5M0050
6O0000
7R
This will press the shutter as soon as a drop is detected using a photogate on the input, and fire the flash 297 milliseconds later just as it hits the surface of the saucer of milk below it. 50 milliseconds later all outputs are reset to 0 closing the shutter and resetting the flash, and the program restarts ready for the next drop.
A few days ago I started the project up again, this time taking a bit of care to build circuits that would stand (slightly) rougher handling and (hopefully) still be useable even after sitting in a drawer for a few months. I recreated the source, better this time.
The basic idea of the timer circuit is to have a number of inputs (well, one at the moment, but I will add more at some point), and a nummber of outputs (3 at the moment - 2 for the half and full press of a shutter and one to trigger a flash), and a simple editable program to control how they interact.
The "program" consists of up to 10 statements - each of which can be any of the following:
Beep
Goto
Millisecond delay
Output
Quit
Restart
Second delay
uSec delay
Wait (for input)
Most commands can have a parameter in the range 0-9999. Output takes a 4-bit bitmask indicating which outputs are to be turned on or off.
So for example a program to take pictures of milk drops might look like this:
1W
2O1100
3M0297
4O1110
5M0050
6O0000
7R
This will press the shutter as soon as a drop is detected using a photogate on the input, and fire the flash 297 milliseconds later just as it hits the surface of the saucer of milk below it. 50 milliseconds later all outputs are reset to 0 closing the shutter and resetting the flash, and the program restarts ready for the next drop.
Using winavr with visual studio
I've been using winavr gcc port together with Atmel's AVR studio 4 for developing the code for a AVR butterfly board, but I've been finding the editor a bit frustrating. Since I use Visual Studio 2008 for the day job I wondered whether I could easily integrate my project into that instead.
A quick and dirty solution was to create a "makefile project" in Visual Studio and point it at the temporary makefile that gets generated by AVR Studio each time you build. Seems to work...
One gotcha was that the error positions were not working as the error message format was not what VC2008 expected. A quick batch file @avr-gcc.exe %* 2>&1 | sed "s/:\([0-9]*\):/(\1):/" 1>&2 took care of that.
A quick and dirty solution was to create a "makefile project" in Visual Studio and point it at the temporary makefile that gets generated by AVR Studio each time you build. Seems to work...
One gotcha was that the error positions were not working as the error message format was not what VC2008 expected. A quick batch file @avr-gcc.exe %* 2>&1 | sed "s/:\([0-9]*\):/(\1):/" 1>&2 took care of that.
Subscribe to:
Posts (Atom)