High precision/resolution chrony

[Pand0ra]

I figured someone could be interested by what I designed a few days ago.

Here included is the schematics of a high precision/resolution chrony, yet very simple in design.

I won't do any support to this. If you want to build this you've to know what you do, and have a good knowledge in electronics/programmation.
The cost is very low, a few bucks at most.

There's nothing ready to make the measure of the pulse right now, you'll have to use something like a computer or a µC to do the processing.

If the distance between the two sensors is 10cm, you can easily reach a resolution of 0.1fps. The precision is also a lot better than the other designs, way below 1%.

Applications are numerous, you can calibrate another chrony, check the real rate of fire, or the best, check the velocity of each balls, in full auto at 20 bps :) .
This is a nice tool to check if there's really shootdown at high rate of fire. You can also check the real rate of fire, and so on...

The principle of the chrony is simple:
Two light barriers are used.
When the paintball cross the first barrier, the output of the photodiode changes, which triggers IC1a.
This send a pulse to the monostable IC1c/IC1d, and set the output at 5V.

A few ms later, the paintball cross the other barrier, which clears the output.

To avoid troubles with the sun, I use the variation of the luminosity to detect the ball, hence C4 and C5 inside the circuit.
They acts with the other components as a filter, which makes the board react only to very quick variations of the luminosity.
It works amazingly well, I can even detect a ball just under a TL tube without any shielding of the photodiodes. It works also very well in the sun.

The lenght of the pulse is the inverse ratio of the ball's speed.
It depends also on the distance between the barrier.
The highest the distance, the highest the resolution you'll get. The way you'll measure the lenght of the pulse will also have an impact.
As we're dealing with ms here, you should make the measure with at least a resolution of 1µs if you want to reach the 0.1fps.

There's also an input coming from a µP. I did this to reset the board.
If for whatever reason the ball didn't cross the second barrier, it will make sure the board is ready for the next ball.


When I've time I'll install this on a barrel, using smd components and a home made micro datalogger.
This way I'll get all the infos of velocity, rate of fire, peak rof, shootdown and so on during a match. It'll be interesting I think.
It would be even more interesting with a pressure sensor connected to µC, like the one on the AIR laying near me ;) .
Who wants to measure the real efficiency of a marker?

Btw you could put everything with the µC on a board of 2cm².

PS: Sorry for the quality of the pic. If there's some interest I can redo it a lot better.

[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]

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]

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... :D

[Redkey]

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]

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]

Here's how I did myself:

The space between the two gates is 10cm.
Knowing the average speed of the ball is 300fps, it means the ball travels 91,44m per second.

The relation between the distance, the speed and the time is the following one:
D=t*0.3048*v
where D is the distance between the gates [m]
t is the time [s]
and v the speed of the ball [ft/s]

From there you can see it takes 1,093ms to the ball to travel 10 cm.
For 299fps t=1,09727ms

You can see here also you've to go down to the µS to get a good resolution. So you've to sample the pulse at at least 1MHz.

A 555 could work, but at a lower resolution.
I know for sure the output stage of the 555 goes up to 2MHz from my experience, but the oscillator is limited to something like 250kHz if I remember well.
A simple oscillator with a quartz at 1MHz is a better solution here, and you just need a AND gate and a counter.

Myself I'll be using a 8051 (well a 87C750, 51 or 52 to be exact) to solve the problem. Or maybe a pic, I'll see depending on my stock hehe.

On the 8051 family it's very easy to do:
Setup the internal counter so it counts the pulses comming from the clock. It's the frequency of the quartz divided by 12 in this case.
With a quartz at 12MHz it'll give pulses of 1µS.
If you set up the flags so it counts only when the trigger input is high, you'll directly measure the length of the pulse.
A few other lines to do the conversion to the speed, reset the board in case of, control a LCD display, and you're done.

It's less than 1 hour to do this.

As I said on my previous post, it's a very small package here. It'll go easily on a barrel.
If I can put my hand on a front piece for a Freak, I'll build everything and show you. The AA front is the best in this case.

@++

[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]

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) ? :D

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.

@++

[314159]

Originally posted by Pand0ra
May I call you 16.arctg(1/5)-4.arctg(1/239) ? :D


as long as you are buying the parts ;)