A theoretical idea

oracacle

Senior Member
As some of you know I have built a high flash trigger for high speed photography. As it currently stands I have the sound detector, a simple light gate and moisture detector that system uses fantastically. However as time goes by I think about the use of something a little more powerful than a sharp object or a hammer. I took a trip to a small shop that sells air rifles and air pistols and found that the low end models have a muzzle velocity of around 300-350 feet-per-second.
I thought this was great, it will make a noise to activate the detector or maybe break a light beam to activate the system. When I told him about my plan and why I needed to know the muzzle velocity (he looked kind of puzzled when I asked him) I found that it can vary depending on air pressure and a likes.

now I could use trial and error, the error getting bigger as air pressure went down I thought that must be a better way. enter the gun chronograph, two gates the projectile must pass through with the time taken being measured. at 64MHz and the gate being 4cm apart and the provision of the hard ware the projectile cold be going as fast as 64000m/s (0.04m/0.000000625s) on the pulsin command. once the time is known and the distance which will be known anyway from equipment setup the time for the projectile to arrive at the target can be calculated and a successful image captured (tall order I know)

other than coding issues with the distance time calculations (time here will be a factor as it will only take around 9ms to travel 1 meter) I am struggle with a design for the detecting small projectiles. and cant immediately see a way of using the pulsin for 2 gates.
I would be willing for the system to spit out a number and manually set the time for a second shot, difference should be minimal

it would be ideal if I could not use an extra picaxe as the system already has a 28x2 that runs at 64mhz for detection loop (and has 3 spare programme slots) but receives signal from the sensors through the ADC comparator - i know the adc pins can be used as digital so would be ideal if I can use those instead of adding extra hardware pins but i will not totally reject the idea of using extra pins as hardware interrupt pins are still free.

more info of controller
http://www.picaxeforum.co.uk/showthread.php?26768-High-speed-photography

here's a balloon shot I did with a 70ms delay after sound detection. I never realise that talc glitter and static electricity could make such wonderful images.
Talced-balloon by f2268d215cc925918731918f4efa0289, on Flickr

if you guys think this isn't going to be possible I may drop it and just use trial and error. but this would be something that would be pretty darn cool to have
 

hippy

Technical Support
Staff member
According to Wikipedia, muzzle velocity for an air rifle will be a maximum of around 400metres per second -

400m = 1s
400m = 1000000us
1m = 2500us
1cm = 25us
4cm = 100us

You are not going to get great resolution by measuring such a short pulse with PULSIN but that would be longer if muzzle velocity is lower.

You could use the gated timer method and count high frequency clock pulses. Take a look at -

http://www.picaxeforum.co.uk/showthread.php?14517-High-Accuracy-Timer

To get the gating pulse simply use a flip-flop, set as the projectile passes the first sensor, cleared as it passes the second.

There has been some past discussion on measuring projectile speed on the forum.
 

Buzby

Senior Member
If you hadn't told us that was a picture of a balloon, I'd have thought it was from Hubble !.

Great work !.

Buzby
 

oracacle

Senior Member
Never used a flip flop, thanks for the tip I shall explore that avenue .

I did start to think about suing timer 3 with the first input activating it and the second input deactivating it and then reading the result from timer3 variable.

I am going to make some dinner and have a think, I think.
 

techElder

Well-known member
oracacle, from past experiments, I determined that the best way is with an interface to an external hardware timer.

BTW, you need to be able to measure up to 2000 fps.
 

oracacle

Senior Member
why 2000fps, that would be 609.6m/s (speed of sound is around 340m/s) , I am not doing high velocity fire arms.

I will further into hardware timer too, but not sure how I would get the line to pulse from the to gates. using a NAND type flip flop and pulsin on a.0 or a.1 should function fine as far as I can theorise.
I will order some gates and bits for light gates (I open for advisement on these components) and try and run some tests.

also so you know the 4cm was chosen so that there was little chance of timer overflow at 64mhz, changes if thought appropriate can be made to that as nothing has been set into stone
 

oracacle

Senior Member
yes that is very helpful in particular to the screens. I can't see any reference to a limit of the smallest size projectile that can be detected but its definitely something too look at, quite like the adage of the LED for indication of detection.
I also found this: http://www.instructables.com/id/PaintballBallistic-Chronograph/?ALLSTEPS
it uses one input to start the timer and the second to stop it, was thinking about way that I can make this work with timer 3 but if I ma honest I am leaning towards hippys flip flop idea combined with the nuts and volts article screens
 

hippy

Technical Support
Staff member
It is unlikely a PICAXE program will be able to handle determining the speed and being able to trigger the flash before things are all over and done, with the bullet heading for the horizon.

What surprised me with the balloon was how slowly it explodes giving plenty of time to detect, pause, trigger, and flash. A bullet travels extremely fast and covers a considerable distance in a very short time.
 

techElder

Well-known member
Also, oracacle, you don't NEED 2 inputs (START, STOP) for your simple screen. you can wire them in parallel and use a CLOCK input. Has worked for me in a mockup.

BTW, they are called "screens" because in the old days, they literally were screens separated by a gap. The bullet was the conductor that connected the two sides. That was fun.
 

oracacle

Senior Member
We are talking fairly slow moving projectiles here, no more than about 110m/s. However the maths can't be fine really in picaxe. After running some number I found that at 100m/s 4cm takes 0.0004s which gives a pulsin value of 640 if I have my maths correct. 640*0.000000625=0.00004s, so you can see are getting into numbers well beyond what can be done in the 0.009s it would take to move 1m st least with picaxe
 

nekomatic

Member
Sounds like something you could solve adequately with a little bit of analogue circuitry, not a PICAXE. When the bullet passes point 1 begin charging a capacitor at rate x, when it passes point 2 start discharging it again at rate y, when capacitor voltage gets back to where it started trigger the flash - the ratio between x and y determines the distance travelled before the flash gets fired.

You could do this with a couple of op-amp current sources, but you might even be able to get adequate results using a simple RC setup (fixed R to charge, variable R to discharge). If you're interested but need further explanation I could throw a quick circuit diagram together...
 

oracacle

Senior Member
See post #5 ... :rolleyes:
post 5 is neither here or there. if I move to measure the speed of actual fire arms (although in the UK air pistol/rifle comes under arms laws) I will get a little more concerned and start learning to use raw pic or something, as hippy already stated max air riffle velocity is around 400m/s (1312.335958 f/s).

In theory there is not reason why I cant have the system capture the data, calculate what is needed and run the second shot with the numbers generated. heck if I increase the distance to 2 meters I cold in theory use an FPU to get the numbers, take into account the processing time and come up with a pause duration to capture what I need - heck this would be even more viable with if I increase the distance still further (may increase safety too). this will work fine providing I take into account the speed on the projectile and increase its distance accordingly (IE I will need at around 15ms to get everything done).

at this point everything is pure speculation due to the face that I don't even own the proposed air pistol yet - I do own a home built pencil crossbow though which could be used for testing.
 

techElder

Well-known member
I don't want to be a pedant, but I have been into photography all my life. The same can be said about electronics and guns. So, what you are doing interests me greatly, and some of it I have experimented with before myself. Please do continue with the dialog. I'll jump in when I have questions.

You don't really need a chronograph; you're just intrigued by the possibility of dialing in the exact time-to-target for flash syncing. In operation, you are still going to make adjustments to that time, because you are going to want a photo sooner or later from the point of impact.

All you really NEED is to detect the projectile leaving the "gun" and an adjustable delay. You've already made that statement in your original post. You don't need an actual COUNT showing velocity etc.

So, build hardware (Hippy suggested a flip-flop; I suggested external hardware) to generate a GATE that will be a reasonable width. You might have to go with a longer spacing on your screens. Heck, it could be hardware that is attached to the barrel of your air rifle.

In the real world, you aren't really interested in the START of the gate (especially with an air rifle that has no particles coming out with the bullet). The gate start can be any fixed point in the cycle; trigger pull, for instance.

What you really want to detect is the END of the gate. . . .
 

oracacle

Senior Member
its funny you mention the attached to the barrel, I keep switching between a tube type design and the screens. part of me lean towards screen as it can be used for capturing falling as well then.
it would be very easy to have the system trigger from the trigger with a simple micro switch or alikes - or using the sound detector that I already have.
The primary reason I have been thinking about the chronograph is to figure out the time delay instead of just guessing - I hate guessing at things like this, its just takes too long, even if its a starting point for something unknown.
I have a light gate on an elastic powered pencil crossbow and it was still a bit of guess work to figure out when it was going to pass by a certain point as the speed varied depending on how far it was pulled back - it took nearly 4 hours to get the shot I was looking for.

Mouser have pretty much all the hardware needed to replicate the screen in the nuts and volts article although the power feed for the IR LEDs seems a little weird. it take power from 9.6 volts and runs through an lm317 in a configuration I haven't seen before. The LEDs used have a Fv of 1.7v and a Fi of 100mA.
 

nekomatic

Member
the power feed for the IR LEDs seems a little weird. it take power from 9.6 volts and runs through an lm317 in a configuration I haven't seen before. The LEDs used have a Fv of 1.7v and a Fi of 100mA.
That's a current source. Iout = 1.25 V / R, so about 50 mA with 27 ohms as shown.
 

oracacle

Senior Member
I presume that is to keep LED brightness constant as the battery voltage dropped. as it stands my system will be design to run from the 5v supply in the current controller - 4 AA batteries with a switching regulator.
 

techElder

Well-known member
Actually, the current source is there because LEDs are individually different when driven by a voltage regulated source, but you probably wouldn't notice it in your application anyway.
 

tmfkam

Senior Member
In dry air at 20 °C (68 °F), the speed of sound is 343.2 metres per second (1,126 ft/s). [Source: Wikipedia]

In that case, simply moving the sound detector closer to, or further away from the sound source could allow you to time your flash accurately?

Assuming the speed of the air rifle pellet is 400 m/S and the speed of sound is assumed to be 340 m/S, placing the sound detector at 85% of distance travelled would give something close to synchronicity.
 

Reloadron

Senior Member
This is a really good thread. While I can't speak much for BB or Pellet rifles I have done some ballistics with rimfire and center fire rifles. Two things are a given. When a projectile leaves the muzzle it begins to slow down and it begins to drop, arguably it begins to slow down even before it leaves the muzzle but here nor there. If the target is a few meters down range it matters not unless the velocity rate of decay is really great. However, it may be something to think about depending on distance muzzle to target. Especially since you want to initiate a flash at just the right moment in time. Knowing the actual muzzle velocity would be useful if you knew the rate of velocity decay.

For example when measuring actual muzzle velocity I measure about 3 meters in front of my muzzle. I can tell you that a 150 grain full metal jacket boat tail 7.62mm projectile with a muzzle velocity of about 859.536 m/s will be traveling along at 791.870 m/s at a distance of 91.44 meters. Additionally with a pellet rifle if you shoot a five shot group of shots I would venture you will see a velocity spread from the same rifle shooting the same pellets. You will get a min and a max velocity. Generally close but is close good enough when you fire a flash? I generally shoot 5 or 10 shot groups and then average my velocity for a given load. Works fine for my purposes but not so sure about photography?

My chronograph is an older pre PIC version using only a 4.0 MHz oscillator for 0.25 microsecond time resolution. This gets me an uncertainty of +/- 4 FPS (Foot Per Second) @ 3000 FPS with my screens spread 4 ft.

The trick with all of these things is the sensors and their ability to start and stop a counter scheme with a fast traveling projectile.

What distance muzzle to target did you have in mind?

Ron
 

tmfkam

Senior Member
tmfkam, so how would you predict the moment to trigger the flash with this knowledge?
Based on the two assumptions I mentioned, I'd place the sound sensor part (microphone) at 80% distance and trigger the flash as soon as the detection occurred. Then adjust the distance to fine tune the required results, depending on the time the flash takes to illuminate and so on.
 

tmfkam

Senior Member
The prediction is based on the assumption that the speed of the air rifle. Or I'm other words a guess
Yes. Though if the manufacturer of the air rifle publishes figures we have to presume they have some relevance.

The problem is that even if you knew the precise speed of the projectile, as it passed, you couldn't be certain that the distance to the target remained exactly consistent. You couldn't be certain that the projectile continued on a perfectly straight path. You couldn't be certain that the projectile had the same profile as the first and so was travelling with the same deceleration as the first one. You couldn't be certain that the dimension of the target was precisely identical to the last. You couldn't be certain that the air pressure and temperature was exactly the same as it was in a test firing.

At some point you assume that some of these will be 'constant' otherwise you just escalate the complexity of the design to an unworkable level.
 

oracacle

Senior Member
reloardron, at the minute the plan is to check to see what parts I have, order what I don't have and build a couple of screens. activation of the timer is currently planned to using a flip flop and pulsing to time the duration between the screens.
as for velocity decay, I was hoping to be able to make use of the chronograph to calculate this if needed, the object will most likely be 2-3 meters from the muzzle. this distance is subject to alteration and increasing the distance will give the system more time if I want to calculate the delay time on the fly. these calculation cant be done in picaxe as floating point would be needed, I may have to offload these to a slower FPU - this should take no more than about 15ms in all and is the reason I left the I2C pins free on the original design.

tmfkam, the idea is to try and remove some uncertainty, and its sounds like a fun thing to do. there is a plan a foot to actually compare the 2 systems and find which is most reliable. heck I could a lot simpler than calculating the distance to place the sound detector by adding a micro switch to the trigger of the weapon and then taking some guesses as to how long the time will be between the trigger action the projectile arriving at the target.

some assumptions will be made there is no mystery about that but the idea of being able to calculate where a projectile will land is nothing new

http://en.wikipedia.org/wiki/Trajectory_of_a_projectile

everything can be calculated to some margin of error but you still need a way of collecting the data - in its simplest form that all this is, a way of collecting the data and calculating to achieve the best results within reason. Also unworkable level? where's the imagination in that. we aren't shooting a moving target on a windy plane in some desert some where. we are shooting balloons, water balloons and maybe the odd bottle in my back yard - halve dozen test shots to start with so that data for that shoot can be acquired and the maths run and off we go.

however with all that there is one that come out on top of all this - its a cool project to do - simples
 

Reloadron

Senior Member
Can you just place a balloon directly in front of the target balloon and pickup the pop of the first balloon to trigger the flash? Just a few feet of wire to run out.

Ron
 

oracacle

Senior Member
that is how I have done other balloon shots using a pin to burst it - this is fine for the balloon that which requires a relatively large 70mms delay to capture the sort of shots I am after. I have had issues with using this technique for water balloons, its can be a little hit and miss with things like where you puncture the balloon weather the sound is detected and the fact the everything is covered in bags muffling the noise due to water flying about everywhere.

and as vein as this may sound, its kind of unsightly have the destructive item in the shot, they look better if that item cannot be seen. In the balloon shot in the first post the balloon was hang from black thread and the needle on its slider mechanism was also black which made it easy to remove it remnants in Photoshop after wards. I did try the same technique for water balloons but I could not get a reliable puncture do to the differing shape and thickness of the ball0on its self.

the 15ms is a guess that needs to be verified before final decisions are made. the uM FPU only 10ms to do its thing and providing the rest of the code is written correctly there should be no issue getting at least close to that mark.
 

Reloadron

Senior Member
reloardron, at the minute the plan is to check to see what parts I have, order what I don't have and build a couple of screens. activation of the timer is currently planned to using a flip flop and pulsing to time the duration between the screens.
as for velocity decay, I was hoping to be able to make use of the chronograph to calculate this if needed, the object will most likely be 2-3 meters from the muzzle. this distance is subject to alteration and increasing the distance will give the system more time if I want to calculate the delay time on the fly. these calculation cant be done in picaxe as floating point would be needed, I may have to offload these to a slower FPU - this should take no more than about 15ms in all and is the reason I left the I2C pins free on the original design.
I agree and see it as a really cool project. Heck, you are working with a short distance which is great. The following may be of some help. Working the screens will be tricky. Also if you do the screens and work the Velocity = Distance / Time formula just keep in mind the screen spacing gets pretty critical. I really want to see how this goes. Really a cool project.

Trajectory.png Velocity Vs Range.png
 

oracacle

Senior Member
those charts maybe handy, however they both exceed the quoted velocity of the weapons I am thinking about - although mathematically speaking the system should be able to detect and the speed calculated. as for screen distance being accurate, its one of my main concerns on the physical build side of things, I may see if I can call in a favour or two and get something laser cuts for mounting it all together

unless you have another option that can be used
 

Reloadron

Senior Member
those charts maybe handy, however they both exceed the quoted velocity of the weapons I am thinking about - although mathematically speaking the system should be able to detect and the speed calculated. as for screen distance being accurate, its one of my main concerns on the physical build side of things, I may see if I can call in a favour or two and get something laser cuts for mounting it all together

unless you have another option that can be used
The charts were merely to give an idea of how quickly velocity drops off. I saw where you were looking at 300 - 350 FPS air guns. They are also for a .177 caliber pellet and only a specific pellet from a specific gun. Again, the idea was only to illustrate how quickly the velocity drops off, not to be taken as gospel numbers. :)

Just play around with it till you find a combination that works.

Ron
 

techElder

Well-known member
I cobbled this arrangement together many long years ago before microcomputers were around, but I had a bunch of 7400 chips from surplus. I used a counter / oscillator. The idea was to reposition the screen in the middle after the first measurement and add in a divide-by-2 (or was it take out a divide-by-2? :) Sorry, up all night.)

Didn't have so much trial and error (we used REAL film then!), and the screen got out of the way for the photograph. I could fiddle with the second position to move the shot forward or backward.

Thought that might trigger something in your mind. ;)

Chronograph.png
 

techElder

Well-known member
BTW, consider this question ...

Why do you need 2 screens?

Seems to me for any given gun/bow/bullet/arrow that the start is just a fixed offset (for your purposes, anyway.)
 

oracacle

Senior Member
I am actually trying to do exactly that, the first screen is to detect the projectile and start the timer (you haven't mention how you detect this), the second to stop the timer - there is no reason that once the initial shot has been taken why one screen cant be removed if the everything remains the same.

I now have a fairly complete order list but it want be finalised until I have come to a decision on the flip side of things.
 

techElder

Well-known member
I suppose I'm suggesting that anything can START the timer ... as long as it consistently starts the timer. You can "dial out" this offset.

Perhaps this will simplify the timing within the PICAXE without you having to build two screens. Heck, I don't know, with your set up.

I am actually trying to do exactly that, the first screen is to detect the projectile and start the timer (you haven't mention how you detect this), the second to stop the timer - there is no reason that once the initial shot has been taken why one screen cant be removed if the everything remains the same.

I now have a fairly complete order list but it want be finalised until I have come to a decision on the flip side of things.
 

oracacle

Senior Member
right, I understand now. the suggestion being that you detect say the trigger pull, measure the time to target, divide by 2 move the screen to start timing for the second shot - but then the screen would not be needed for the second shot because the time of flight would be known and the timing could be started by the trigger switch.

so if time of flight inclusive of release time of bolt/gas/whatever was 1ms the sequence would be trigger>pause 1>fire flash, after an initial test shot which is going to be needed no matter what system is used. the only thing this doesn't solve is the initial timing to find the amount time needed for the pause which besides the maths is one of the more challenging aspects. it will still also require a flip flop for generating the initial signal for the timing, either for pulsin or count of an external clock signal.
 
Top