Here’s an update on where I am with the water droplet project …
I have now rigged the Arduino board up with my black box and the 12v solenoid valve in what I hope will be something like the finished arrangement. This is how it looks …
The valve is clamped to the arm of a retort stand – the sort of thing I struggled with in the chemistry lab at school ( it’s funny how these things come back to haunt you) …
… with a bowl of water underneath where, hopefully, the water will fall and those elusive collisions will occur.
To the top of the retort stand is clamped a 20ml syringe – my reservoir of water to feed the valve and produce the droplets …
The rubber tube connects the syringe to the inlet side of the valve. So far, so good.
Water droplets are produced by opening and closing the solenoid valve for just long enough for water to flow through the valve. Leave the valve open for too long and you get a dribble of water, or several drops; don’t leave it open long enough – and nothing happens: the solenoid clicks, but no water appears. So the first task is to find out how long the valve has to be open to produce a decent droplet.
There is a small program that you have to upload onto the Arduino board that does all the clever stuff – like opening and closing the valve, and how long it stays open is determined by the value of a number that you write into the program! ( We are talking in thousandths of a second here – this all happens very fast, something which I’ll come back to in a minute! ) So each time you need to adjust the length of time that the valve stays open you have to edit the program, do some magic which ‘they’ call ‘compiling’ and then upload the result to the board. It’s a sort of iterative process, continually adjusting the number until you get it right.
I should add here that more sophisticated equipment – the sort you have to pay real money for – does this adjustment in a much more efficient, intuitive and user-friendly way. As already stated, this setup is absolutely basic – there are no bells or whistles attached.
Anyway, I spent a cold afternoon in my garage finding the length of time the valve has to be held open to produce a droplet. And I did get there – or thereabouts. ( I’ll give you a run down of the values I’m using when I get closer to a more refined setup. )
But you will remember that what I am really after is the collision of two water droplets. And, as you may guess, that introduces another issue. Having produced the first droplet, I then want the program to wait for some fraction of a second before producing a second droplet that will fall towards the bowl of water and crash into the first droplet which has, by then, bounced off the water and is traveling upwards to meet the down-comimg second droplet! Of course, this delay is also dependent on the distance between the outlet nozzle on the valve and the surface of the water in the bowl.
And all of this is happening so fast that you can’t see what is happening. But I happen to have a Nikon Coolpix 100 camera that will record video at 240 frames per sec ( fps ) and then play it back at 30 fps, 16 times slower. It was a matter of videoing the two droplets, replaying the recording, trying to work out what was happening and then adjusting the delay value in the program. After two more hours in the garage ( and nine recording / replays and a couple of adjustments of the drop height ) I had worked out the delay to give the required collision.
But I now have those values embedded in the program – the length of time the valve has to be open to produce the droplets – and the delay between the two droplets that is needed to cause the collision, given the drop from the valve to the bowl.
Next step, try and get some initial shots of the collisions. This will probably involve my PhotoTrigger box, a laser trigger, three or four strobe lights and shooting in the dark.