High precision/resolution chrony

[Pand0ra]

[sniper1rfa]

they make them, i have one. its called a light gate timer (or a shooting chrony, i have one) ... :-)

as a matter of fact, the accuracy really depends on the speed of your chip. lets say its 2 khz, two cycles a ms.
that lets you be accurate (saying the gates are a foot apart) down to .09 fps, no better (not like youll need it).

unfortunately, if you are that accurate, your biggest problem will actually be maintaining the correct distance between gates. this aint no ruler measurement, at that speed a couple hundredths (youll be able to keep it that close) will make a noticable difference, say, 2 fps.

therefore, though the system can be more accurate, you probably wont get it within more than about 2 fps, no more accurate than a radar chrony. sorry. :)

[Redkey]

correct me if I'm wrong... but...

Assuming your gates are 1 foot apart and the ball travelling 300 fps... That means it takes the ball
(1 ft)/(300 ft/sec) = 0.0033 seconds to pass between the gates.

At a 2 khz sampling rate you are collecting a data point every 1/2000 or 0.0005 seconds In 0.0005 seconds the ball will travel (300 feet/sec) * (0.0005 seconds) = 0.15 feet. Some more calculations show that in 0.0033 seconds you will only have time to collect 6.667 samples at 2 khz. 0.0033 seconds between gates / 0.0005 seconds per sample = 6.667 samples

now... assuming the ball is travelling at a constant speed of 300 fps, ie no measurable decelleration inbetween the two gates.

after the first gate is tripped and the 2 Khz sample rate is started you will have the following

0 seconds gate is tripped
0.0005 sec ball has travelled 0.15 feet => sample 1
0.0010 sec ball has travelled 0.30 feet => sample 2
0.0015 sec ball has travelled 0.45 feet => sample 3
etc
0.0030 sec ball has travelled 0.90 feet => sample 6
0.0033 sec ball has travelled 1.0 feet

since you cannot collect a partial data point we'll round down to six samples. Sooo... in the time to collect 6 samples, 0.0030 seconds, the ball has travelled 1 foot = 1/.0030 = 333.33 feet/sec.

Now, lets say the ball was travelling a bit slower than 300 feet/sec and were were actually able to collect that 7th data point or, .0035 seconds worth of data 1 foot/.0035 seconds = 285 feet/sec. The slower velocity will cause slight changes in the previous calculations... But, it should be close enough, besides you're probably already bored after reading this far.

Therefor, the velocity difference between the 6th and 7th data point is about 47 feet/sec. Which, if i've done this correctly, is the min resolution of a 2khz sampling rate over a 1 foot wide gate system with a ball travelling 300 fps.

Sniper1rfa... I think your error comes from assuming you can use all 2000 samples in the velocity calculation. Which would be true if you could measure one full second worth of ball flight.

Again... if I'm wrong, could someone please correct my math?

[sniper1rfa]

i did it a much simpler way...

that may be wrong
actually, i think i surprised myself with that number, so its probably wrong...

err, how DID i get that number...?
oh, right, thats the maximum velocity flunctuation before the the timer registers it a diferent way. its also at maximum velocity that the chrono can measure (sample 1: gate one on, sample 2: both gates idle, sample 3: gate two on). oops.

your numbers are right. oh well, time to bust out the athlon 2.2 GHz processor and see what resolution we can get then...

[Redkey]

a solution...

Please bear with me on this... I have *NO* formal education or experience with electronics, so my ideas are based on a very rudamentary understanding of electronics.

With pandoras, oh excuse me, pandOras circuit... while the ball is inbetween gates the circuit outputs a 5v signal. Wouldn't it be possible to feed this voltage into something like a 555 timer chip and have it output something like a 200 khz series of pulses and then feed those pulses into a counter chip? Then, knowing the 555 chip output frequency, the number of pulses and the distance between the gates you should be able to calculate the velocity quite easily. I don't know the limits of a 555 but the higher the output freq... the better your accuracy.

As sniper1rfa said... the distance between your gates is pretty important. What I would do is to install the gates with as much space between them as possible and then... use a caliper with ball or similar plug on the end to measure the exact distance between the installed sensors.

lower the ball attached to the caliper down the barrel until the first sensor is tripped and then zero/record the reading. then pull or push the ball/plug towards the other sensor... when the second sensor is tripped record that measurement and figure the difference. Or you could do it with a piece of dowl and make marks on it when the sensors were tripped.

You'd have to have something like a pic or basic stamp to perform the calculation and display/record the data. It should be a pretty simple program to write.

Of course... if you were to break paint in the barrel your optical sensors would stop reading.

[sniper1rfa]

this is not for an on gun chrony, but a very accurate one. :)
as i said, the actual distance between gates as opposed to the programmed distance will be the key factor when it comes to accuracy.

[Gambit22]

If you want to make it cheap and accurate, use the popular 16F84 - 4mHz. Personally I use the 16F84A-20 with 20mHz. So potentially I can have 66000 samples, assuming the measuring distance of one foot. I'd say that's plenty accurate, eh?

[Redkey]

depends...

on how many instructions need to be executed during the counting process.

is there anything more than...

is signal high
add one to counter
loop


I'm not a pic person yet so I'm not sure how you would program this in ASM or pic C. Though I doubt if it would be more than just a couple lines of code.


I thought we were talking about instrumenting a barrel. If not, then you have a whole different set of issues to worry about.

[Gambit22]

That's pretty much what you would do. Start a timer when the input on one pin is high and end it when the input on the second pin is high.

[Pand0ra]

[Pand0ra]

Ah yes I forgot. To go on a barrel, the distance between the gates must be small, to avoid errors due to the acceleration of the ball.
I'm almost sure the ball doesn't accelerate anymore when it reaches the porting, but you never know :) .

@++

[joeyjoe367]

Re: correct me if I'm wrong... but...

Originally posted by Redkey
Assuming your gates are 1 foot apart and the ball travelling 300 fps... That means it takes the ball
(1 ft)/(300 ft/sec) = 0.0033 seconds to pass between the gates.

Actually, if you REALLY want to get accurate, I think it would be just a hair over .0033 seconds since as soon as the ball leaves the muzzle, it's going to be decelerating, if it hasn't already begun to decelerate in the barrel.

[Pand0ra]

Good point. You're right, of course.

It would need a third gate and some calculations to solve this problem.
With the two values it could be possible to determine the deceleration of the ball, and make the correction accordingly.

Interesting...

@++

[314159]

meh, how about just using 1 gate, and measuring the time that the beam is broken for.

-the paintball's deacceleration is neglagible for .68in (no calculus ^_^)
-you don't have to worry about maintaining the distance between the 2 sensors
-just step the sampeling rate up a little to achieve the same results
-would be verry small on the barrel (possibly send the beam through the last port on an unported barrel)
-cheaper

[Pand0ra]

Originally posted by 314159
meh, how about just using 1 gate, and measuring the time that the beam is broken for.

May I call you 16.arctg(1/5)-4.arctg(1/239) ?

That's a good idea. I'll see how we could do that.

I'm not sure it'll be less expensive. We'll have to multiply by 10 the sample frequency.
I can already see problems with the calibration also (the beam as a diameter not negligeable compared to the diameter of a paintball).

The good point is the simplification of the setup. It's definitely a good point.
The power supply can also be smaller.

@++