I have no idea if that is actually what these things are called, but I made a device for my gun which allows me to see the speed in milliseconds per foot. This can be converted into feet per second just by taking the inverse (I didn't want to figure out how to do that automatically for a weekend project).
I know I haven't posted here in a long time and I haven't posted much (when spudtech died I moved to theopia), but this seems like a good place to post this. I started this yesterday as a weekend project and I completed it early this morning. I was able to complete it for under $10, but I also have alot of parts lying around. I would estimate that in total it would probably cost $30 at the most if you are cautious about pricing on parts. THIS ENTIRE THING (aside from one part which can be changed out for one that can) CAN BE BUILT FROM PARTS AT YOUR HARDWARE STORE AND RADIOSHACK. It can theoretically measure up to 1,000,000fps, but I doubt this actually can because its using cheap radio shack parts and the wiring isn't exact.
Anyway, I hope you guys find this useful. It clocked my gun at 185fps with a c-size battery@90psi (I have a pneumatic, but I would think this would work for a combustion too).
Link: http://cuznersoft.com/wordpress/?p=54
Picture: http://cuznersoft.com/wordpress/wp-cont ... 24x768.jpg
HOWTO: Cheap Chronometer
-
Los Frijoles
- Private 2
- Posts: 38
- Joined: Mon Dec 12, 2005 7:22 pm
That's impressive, I definitely don't have the electronics skills to make that kind of thing. Really cheap too, I just bit the bullet and laid out the cash for a chrony on eBay.
As I understand it, the infrared detectors measure the time required for the projectile to pass from x = 0 to x = 1 foot. You then divide the distance by the time to get the speed of the projectile (or a mathematically equivalent operation). However, consider that the projectile is being accelerated over this entire interval by the air pressure and is not moving at a constant speed. What you will obtain by this method is the AVERAGE speed. Your muzzle velocity will actually be considerably higher than this average speed. But then its nice to miss something and find that you're actually doing better than you thought.
As I understand it, the infrared detectors measure the time required for the projectile to pass from x = 0 to x = 1 foot. You then divide the distance by the time to get the speed of the projectile (or a mathematically equivalent operation). However, consider that the projectile is being accelerated over this entire interval by the air pressure and is not moving at a constant speed. What you will obtain by this method is the AVERAGE speed. Your muzzle velocity will actually be considerably higher than this average speed. But then its nice to miss something and find that you're actually doing better than you thought.
-
Technician1002
- Captain
- Posts: 5189
- Joined: Sat Apr 04, 2009 11:10 am
The device is simply called a timer. Your inputs start and stop it. The time for the event is recorded. A shooting chronograph works this way. It takes the delta time and computes 1/X to invert time to speed.Los Frijoles wrote:I have no idea if that is actually what these things are called, but I made a device for my gun which allows me to see the speed in milliseconds per foot. This can be converted into feet per second just by taking the inverse (I didn't want to figure out how to do that automatically for a weekend project).
I know I haven't posted here in a long time and I haven't posted much, but this seems like a good place to post this. I started this yesterday as a weekend project and I completed it early this morning. I was able to complete it for under $10, but I also have alot of parts lying around. I would estimate that in total it would probably cost $30 at the most if you are cautious about pricing on parts. THIS ENTIRE THING (aside from one part which can be changed out for one that can) CAN BE BUILT FROM PARTS AT YOUR HARDWARE STORE AND RADIOSHACK. It can theoretically measure up to 1,000,000fps, but I doubt this actually can because its using cheap radio shack parts and the wiring isn't exact.
Anyway, I hope you guys find this useful. It clocked my gun at 185fps with a c-size battery@90psi (I have a pneumatic, but I would think this would work for a combustion too).
Link: http://cuznersoft.com/wordpress/?p=54
Picture: http://cuznersoft.com/wordpress/wp-cont ... 24x768.jpg
As stated above, your event is not speed, but an average speed for the distance measured. For example my car can go from 0 to 60 in 12 seconds. If I do the time it takes to go that distance, my average speed is considerably slower in that interval.
Nice speed on a C battery if the first sensor is near 0 FPS.
Rebuilding the sensor so it is entirely off the barrel would give a better indication of steady flight speed after it left the barrel.Check the rise time response of your selected photo detectors. Many of them do not respond well to a 1 Megacycle signal. Lead capacitance and other signal degradations also limit your usable bandwidth of the sensors.
Risetime on the R/S detectors is not stated in the specs. They are listed as a Phototransistor. I have some other photo transistors that are so slow I can not detect high speed marshmallows. The dwell time over a sensor is too short to detect. The risetime is very slow.
I just dug through my camera card downloads. Sorry no rise time photos.
-
jimmy101
- Sergeant Major
- Posts: 3198
- Joined: Wed Mar 28, 2007 9:48 am
- Location: Greenwood, Indiana
- Has thanked: 5 times
- Been thanked: 15 times
- Contact:
Nice job Los Frijoles, it adds another technique to the ones already posted.
Couple minor points, it won't really read to 1 million FPS since that is 1/(timer step size). At that speed it would be able to tell the difference between 1MFPS, 0.5MFPS, 0.3MFPS... with errors of 100%, 50%, 33% ... The actual limit is whatever you decide the accuracy needs to be. To get a sampling error of no more than 1% then you need 100 samples between the gates. For a 1ft gate separation that limits the maximum speed to 10,000FPS (~MACH 9). That should be adequate for most uses.
I think an open detector is easier and introduces less uncertainty as to the affects the detector has on the projectiles flight. Slice the detector pipe in half and just use ambient light (sunlight preferably) as the light source. This is how I did it (the green tube is the barrel, the gray thing is the clip on detector).
From here. Since the detector is mounted on the barrel the alignment is easy (just like yours), but that does mean that the detector recoils with the gun and the measured time will be a bit short. It will actually give the sum of the ammo and gun's speeds. Most of that error can be removed by bench firing or putting the breech of the gun on the ground and firing up so that the gun can't recoil significantly.
I wouldn't worry that the recorded time gives you the average speed. As far as I know that is what all shooting chronys do. Putting the gates closer together will reduce the affect of averaging the speed but it probably isn't necessary unless the round is actually touching the gate holder. A 1 foot or so gate separation is pretty standard on shooting chronys.
As to the rise time of the detectors. I've never seen phototransistors so slow that they would be a problem at any reasonable ammo velocity, say up to MACH 1 or so. (I've always used direct sunlight or bright sky as the light source.) The response time of the detectors isn't really critical as long as they do respond and are reasonable well matched. Even generic off the shelf ones should be well enough matched so that their rise times are within a few tens of microseconds. That much difference won't make a significant difference with things moving at MACH 1 or below. The actual rise time doesn't matter at all, as long as it gives a signal, if the two detectors are similar the rise times cancel each other out.
You don't even need a rise time that is less then the ammo's shadow time over a detector. Generally, rise (and fall) times are quoted as something like the time it takes the detector to go from 10% to 90% response to a step change in the light level. Since you don't actually need full response from the detector you can get by measuring much shorter events, down to a 10%, or even less, detector response time. The brighter the light source, and the more of the light that is blocked by the projectile, then the more robust your detector response will be. Your IR LEDs should be more than bright enough. With my setup, 0.177" BBs at 300 FPS are easily detected even though the shadow time per detector is just ~50uS (20KHz).
The accuracy of the detector is mostly controlled by how many time steps you get between the two gate events. The detector response time is a fairly minor issue. There are some detectors that are probably too slow, for example solar cells and cadmium sulfide (CDS) cells are probably too slow to give a suitable signal.
Using a PC soundcard as the data logger the sample rate is limited to 48KHz, which is adequate for a heck of lot of things, all the way to a typical rifle. Your 1MHz clock is probably overkill but what the heck, it uses the clock that the PIC needs anyway.
It would be great if you could add the display and do the 1/time calculation.
Couple minor points, it won't really read to 1 million FPS since that is 1/(timer step size). At that speed it would be able to tell the difference between 1MFPS, 0.5MFPS, 0.3MFPS... with errors of 100%, 50%, 33% ... The actual limit is whatever you decide the accuracy needs to be. To get a sampling error of no more than 1% then you need 100 samples between the gates. For a 1ft gate separation that limits the maximum speed to 10,000FPS (~MACH 9). That should be adequate for most uses.
I think an open detector is easier and introduces less uncertainty as to the affects the detector has on the projectiles flight. Slice the detector pipe in half and just use ambient light (sunlight preferably) as the light source. This is how I did it (the green tube is the barrel, the gray thing is the clip on detector).
From here. Since the detector is mounted on the barrel the alignment is easy (just like yours), but that does mean that the detector recoils with the gun and the measured time will be a bit short. It will actually give the sum of the ammo and gun's speeds. Most of that error can be removed by bench firing or putting the breech of the gun on the ground and firing up so that the gun can't recoil significantly.
I wouldn't worry that the recorded time gives you the average speed. As far as I know that is what all shooting chronys do. Putting the gates closer together will reduce the affect of averaging the speed but it probably isn't necessary unless the round is actually touching the gate holder. A 1 foot or so gate separation is pretty standard on shooting chronys.
As to the rise time of the detectors. I've never seen phototransistors so slow that they would be a problem at any reasonable ammo velocity, say up to MACH 1 or so. (I've always used direct sunlight or bright sky as the light source.) The response time of the detectors isn't really critical as long as they do respond and are reasonable well matched. Even generic off the shelf ones should be well enough matched so that their rise times are within a few tens of microseconds. That much difference won't make a significant difference with things moving at MACH 1 or below. The actual rise time doesn't matter at all, as long as it gives a signal, if the two detectors are similar the rise times cancel each other out.
You don't even need a rise time that is less then the ammo's shadow time over a detector. Generally, rise (and fall) times are quoted as something like the time it takes the detector to go from 10% to 90% response to a step change in the light level. Since you don't actually need full response from the detector you can get by measuring much shorter events, down to a 10%, or even less, detector response time. The brighter the light source, and the more of the light that is blocked by the projectile, then the more robust your detector response will be. Your IR LEDs should be more than bright enough. With my setup, 0.177" BBs at 300 FPS are easily detected even though the shadow time per detector is just ~50uS (20KHz).
The accuracy of the detector is mostly controlled by how many time steps you get between the two gate events. The detector response time is a fairly minor issue. There are some detectors that are probably too slow, for example solar cells and cadmium sulfide (CDS) cells are probably too slow to give a suitable signal.
Using a PC soundcard as the data logger the sample rate is limited to 48KHz, which is adequate for a heck of lot of things, all the way to a typical rifle. Your 1MHz clock is probably overkill but what the heck, it uses the clock that the PIC needs anyway.
It would be great if you could add the display and do the 1/time calculation.
It is true that shooting chronys do measure the average speed across a given interval. However, the important difference here is that between measuring over an interval that is in the barrel or past the end of the barrel. In the barrel, the projectile is being accelerated by a strong force and thus its velocity cannot be approximated as constant with any reasonable accuracy. Therefore the average velocity over this interval will be significantly lower than the muzzle velocity. With shooting chronys (and the 3D model above), the interval is outside the barrel when the projectile is no longer being accelerated. The deceleration due to air resistance is so weak in comparison to the firing force that it is far more reasonable to say that the velocity across the interval is essentially constant, and if the chrony is near the muzzle (which it always is) then the projectile will not have slowed significantly from its muzzle velocity.
As to the electronics I am not qualified to offer an opinion.
As to the electronics I am not qualified to offer an opinion.
-
Technician1002
- Captain
- Posts: 5189
- Joined: Sat Apr 04, 2009 11:10 am
I may have to try direct sunlight. The rise time of the photo transistors I have with LED lighting in a beam break configuration is giving me less than enough rise to detect anything. The objects have too little dwell time to detect. Even a 5% rise would be nice.jimmy101 wrote: I think an open detector is easier and introduces less uncertainty as to the affects the detector has on the projectiles flight. Slice the detector pipe in half and just use ambient light (sunlight preferably) as the light source. This is how I did it (the green tube is the barrel, the gray thing is the clip on detector).
As to the rise time of the detectors. I've never seen phototransistors so slow that they would be a problem at any reasonable ammo velocity, say up to MACH 1 or so. (I've always used direct sunlight or bright sky as the light source.)
The actual rise time doesn't matter at all, as long as it gives a signal, if the two detectors are similar the rise times cancel each other out.
You don't even need a rise time that is less then the ammo's shadow time over a detector.
It would be great if you could add the display and do the 1/time calculation.
Rise times matter if they are not matched and over a magnitude of the dwell time. Kinda like timing a shot with 2 guys with stopwatches. Dwell and rise time matters. A rise time somewhat near 5X the shadow time or shorter is nice. My rise time is longer and requires a long dwell (shadow) time.
I am planning on picking up some faster parts soon.
-
Los Frijoles
- Private 2
- Posts: 38
- Joined: Mon Dec 12, 2005 7:22 pm
Hey, thanks for the comments. I am in the process of adding a display and I am trying to figure out an easy way to do the 1/x without losing too much precision. This will make it alot easier to use. If anyone happens to have any assembly routines or algorithms for this I would appreciate it (but this is probably the wrong place to ask...I would guess people here are better at PV=nRT than binary math)
I will check the rise time of my phototransistors. I suspect it isn't that fast since for some reason a tin foil ball only registered on one end of the meter.
I originally considered the split in half design, but then I realized a closed design would require less sawing and could be more securely attached to the barrel. I only have a crapsman drill and a hacksaw to work with here (table saw is somewhere taken apart), so easier was best for me.
I will check the rise time of my phototransistors. I suspect it isn't that fast since for some reason a tin foil ball only registered on one end of the meter.
I originally considered the split in half design, but then I realized a closed design would require less sawing and could be more securely attached to the barrel. I only have a crapsman drill and a hacksaw to work with here (table saw is somewhere taken apart), so easier was best for me.
-
Technician1002
- Captain
- Posts: 5189
- Joined: Sat Apr 04, 2009 11:10 am
It's why I mentioned it. In an attempt at supersonic marshmallows, they were not seen at all by either sensor.Los Frijoles wrote:
I will check the rise time of my phototransistors. I suspect it isn't that fast since for some reason a tin foil ball only registered on one end of the meter.
-
jimmy101
- Sergeant Major
- Posts: 3198
- Joined: Wed Mar 28, 2007 9:48 am
- Location: Greenwood, Indiana
- Has thanked: 5 times
- Been thanked: 15 times
- Contact:
Tech: I'm surprised you are having problems with slow response from phototransitors, though you seem to be measuring very high velocity projectiles. Any idea what the part numbers is? Looking at typical PT response curves rise times are typically less than 10uS. I wonder if you just have unusually slow, really unusually slow, PTs or if it is light brightness, source voltage or output load that is causing the problem?
Below is the data from an 0.177" BB at about 280 FPS using a sound card, a pair of photoransitors 4" apart, power supplied by the MIC input to a PC sound card (~2.5V at 1mA). (Ignore the red boxed data points, that's for something else.)
(from here.)
The BB is 0.177", figure the PT is 0.125" across, WAG that the transit time is the time the BB takes to move 0.177"+0.125" at 280 FPS, gives about 90uS. Both peaks have 7 data points significantly off the baseline (sampled at 44KHz IIRC). Looks like a faster event, perhaps 5x faster, would be detectable. Puts the minimum detection time down around 20uS or so. The actual peak widths are about 20uS at the base, roughly 25% what is expected. (Perhaps partly due to the assumption that the PT is 0.125" across.)
A 1/2" mini marshmallow at 1100 FPS would give a peak width of about 40uS. Derate by 75% gives a 10uS peak width which is probably just below the detection limit. A 1" standard marshmallow at 1100 FPS should be detectable.
In the graph, the data is the raw WAV file and the vertical axis is unscalled. It was 16-bit samples so the data range is +/-32K. The actual peaks are only ~25 (5 bits) tall so the signal is fairly weak. The signal to noise looks pretty good (given the simplicity of the setup), the base line "wiggle" is less than +/- 1 so the SN is 25 or so. So even with the weak signal the BB is easy to detect.
Below is the data from an 0.177" BB at about 280 FPS using a sound card, a pair of photoransitors 4" apart, power supplied by the MIC input to a PC sound card (~2.5V at 1mA). (Ignore the red boxed data points, that's for something else.)
(from here.)
The BB is 0.177", figure the PT is 0.125" across, WAG that the transit time is the time the BB takes to move 0.177"+0.125" at 280 FPS, gives about 90uS. Both peaks have 7 data points significantly off the baseline (sampled at 44KHz IIRC). Looks like a faster event, perhaps 5x faster, would be detectable. Puts the minimum detection time down around 20uS or so. The actual peak widths are about 20uS at the base, roughly 25% what is expected. (Perhaps partly due to the assumption that the PT is 0.125" across.)
A 1/2" mini marshmallow at 1100 FPS would give a peak width of about 40uS. Derate by 75% gives a 10uS peak width which is probably just below the detection limit. A 1" standard marshmallow at 1100 FPS should be detectable.
In the graph, the data is the raw WAV file and the vertical axis is unscalled. It was 16-bit samples so the data range is +/-32K. The actual peaks are only ~25 (5 bits) tall so the signal is fairly weak. The signal to noise looks pretty good (given the simplicity of the setup), the base line "wiggle" is less than +/- 1 so the SN is 25 or so. So even with the weak signal the BB is easy to detect.
-
Technician1002
- Captain
- Posts: 5189
- Joined: Sat Apr 04, 2009 11:10 am
I gotta be honest here. The transistors I have are pretty ancient. I picked them up years ago at a Hamfest in 1979. They are OK as VCR clear leader detection, but not very fast. I'll need to get some faster parts. I have some photodiodes from TV IR remotes. They are fast enough. They require more support circuitry to use them.
-
boyntonstu
- Sergeant
- Posts: 1039
- Joined: Sun Jun 28, 2009 8:59 am
Why don't you use the sound card and a mic as the chrono?jimmy101 wrote:Tech: I'm surprised you are having problems with slow response from phototransitors, though you seem to be measuring very high velocity projectiles. Any idea what the part numbers is? Looking at typical PT response curves rise times are typically less than 10uS. I wonder if you just have unusually slow, really unusually slow, PTs or if it is light brightness, source voltage or output load that is causing the problem?
Below is the data from an 0.177" BB at about 280 FPS using a sound card, a pair of photoransitors 4" apart, power supplied by the MIC input to a PC sound card (~2.5V at 1mA). (Ignore the red boxed data points, that's for something else.)
(from here.)
The BB is 0.177", figure the PT is 0.125" across, WAG that the transit time is the time the BB takes to move 0.177"+0.125" at 280 FPS, gives about 90uS. Both peaks have 7 data points significantly off the baseline (sampled at 44KHz IIRC). Looks like a faster event, perhaps 5x faster, would be detectable. Puts the minimum detection time down around 20uS or so. The actual peak widths are about 20uS at the base, roughly 25% what is expected. (Perhaps partly due to the assumption that the PT is 0.125" across.)
A 1/2" mini marshmallow at 1100 FPS would give a peak width of about 40uS. Derate by 75% gives a 10uS peak width which is probably just below the detection limit. A 1" standard marshmallow at 1100 FPS should be detectable.
In the graph, the data is the raw WAV file and the vertical axis is unscalled. It was 16-bit samples so the data range is +/-32K. The actual peaks are only ~25 (5 bits) tall so the signal is fairly weak. The signal to noise looks pretty good (given the simplicity of the setup), the base line "wiggle" is less than +/- 1 so the SN is 25 or so. So even with the weak signal the BB is easy to detect.
A bang and a thud.
Analyze the audio.
Done!
(You could place the mic midway between the muzzle and the target to automatically compensate for the speed of sound.
Not a perfect measurement, not exactly muzzle velocity, but good enough?
BoyntonStu
-
Technician1002
- Captain
- Posts: 5189
- Joined: Sat Apr 04, 2009 11:10 am
You either need a very long distance between the muzzle and target, or you need a very slow projectile.boyntonstu wrote: Why don't you use the sound card and a mic as the chrono?
A bang and a thud.
Analyze the audio.
Done!
(You could place the mic midway between the muzzle and the target to automatically compensate for the speed of sound.
Not a perfect measurement, not exactly muzzle velocity, but good enough?
BoyntonStu
A long distance only give the average speed, not the muzzle speed. Getting a marshmallow to fly over 150 feet is difficult. They lose speed very quickly. I'm aiming for supersonic.
If I use brighter light and bias the transistors as a class A amplifier, I should pick up some response time. I was using white LED's, which are not the best to use for this project. The phototransistors are most sensitive to the near IR spectrum. I will make changes and try again. My original rise times were in the 10 ms range. A 40ns light shadow pulse was invisible.
-
boyntonstu
- Sergeant
- Posts: 1039
- Joined: Sun Jun 28, 2009 8:59 am
http://arxiv.org/ftp/physics/papers/0601/0601102.pdfTechnician1002 wrote:You either need a very long distance between the muzzle and target, or you need a very slow projectile.boyntonstu wrote: Why don't you use the sound card and a mic as the chrono?
A bang and a thud.
Analyze the audio.
Done!
(You could place the mic midway between the muzzle and the target to automatically compensate for the speed of sound.
Not a perfect measurement, not exactly muzzle velocity, but good enough?
BoyntonStu
A long distance only give the average speed, not the muzzle speed. Getting a marshmallow to fly over 150 feet is difficult. They lose speed very quickly. I'm aiming for supersonic.
If I use brighter light and bias the transistors as a class A amplifier, I should pick up some response time. I was using white LED's, which are not the best to use for this project. The phototransistors are most sensitive to the near IR spectrum. I will make changes and try again. My original rise times were in the 10 ms range. A 40ns light shadow pulse was invisible.
The average velocity of the bullet over the distance of 50 yards is then
Vbullet = d / tbullet = 150 ft/ (0.0559 s) = 2684 ft/s.
For comparison, the velocity measured on an Oehler Model 35 optical chronograph placed 6 feet in front of the muzzle is 2763 ft/s. At first glance, these measurements do not seem to agree, but it is important to note that our acoustic method measures the average velocity between the bullet and the target. This average velocity is slightly slower than the muzzle velocity because the bullet slows down in flight as a result of air
resistance.
This method seems O.K. to me and the target could have been closer.
BoyntonStu
@BoyntonStu: That's a very dense and aerodynamic bullet, it is not much of what we fire, which is neither dense nor aerodynamic. In this case, the "sound chrony" is not good enough.
Sound chronies are also a fairly poor choice for supersonic projectiles, for obvious reasons - the sonic shockwave from the projectile can arrive before the muzzle blast and confuse things.
The aim with the photo transistor method is to get a reading with much less "noise", so that the distance over which it is measured can be much shorter.
That said, I am using something that's something of a combination of the two methods - both photo transistors to get a muzzle velocity, and target further downrange to measure the time taken to travel X metres, which allows the calculation of ballistic coefficient, important for long range predictions.
However, the target downrange is wired in electrically, not by sound.
Sound chronies are also a fairly poor choice for supersonic projectiles, for obvious reasons - the sonic shockwave from the projectile can arrive before the muzzle blast and confuse things.
The aim with the photo transistor method is to get a reading with much less "noise", so that the distance over which it is measured can be much shorter.
That said, I am using something that's something of a combination of the two methods - both photo transistors to get a muzzle velocity, and target further downrange to measure the time taken to travel X metres, which allows the calculation of ballistic coefficient, important for long range predictions.
However, the target downrange is wired in electrically, not by sound.
Does that thing kinda look like a big cat to you?
-
boyntonstu
- Sergeant
- Posts: 1039
- Joined: Sun Jun 28, 2009 8:59 am
The average velocity of the bullet over the distance of 50 yards is thenRagnarok wrote:@BoyntonStu: That's a very dense and aerodynamic bullet, it is not much of what we fire, which is neither dense nor aerodynamic. In this case, the "sound chrony" is not good enough.
Sound chronies are also a fairly poor choice for supersonic projectiles, for obvious reasons - the sonic shockwave from the projectile can arrive before the muzzle blast and confuse things.
The aim with the photo transistor method is to get a reading with much less "noise", so that the distance over which it is measured can be much shorter.
That said, I am using something that's something of a combination of the two methods - both photo transistors to get a muzzle velocity, and target further downrange to measure the time taken to travel X metres, which allows the calculation of ballistic coefficient, important for long range predictions.
However, the target downrange is wired in electrically, not by sound.
Vbullet = d / tbullet = 150 ft/ (0.0559 s) = 2684 ft/s.
For comparison, the velocity measured on an Oehler Model 35 optical chronograph placed 6 feet in front of the muzzle is 2763 ft/s.
Supersonic results.
Not too shabby.
For subsonic need, darn good.
BoyntonStu