DIY Airsoft Chrono [PC-based]

Chrono or Chronograph, the term used by Airsofter and Paintball players to refer to the device that measures the muzzle velocity of firearms. This is also called MVMD, short for Muzzle Velocity Measuring Device by the British Army. Muzzle Velocity is the velocity of the bullet as it exits the barrel of the firearm.

A year ago I was an active Airsofter in Iligan who's more interested in modifying and improvising AEGs (Automatic Electric Gun) rather than playing airsoft. I have made my AEG susceptible to high current burns by using locally available MOSFETs. I have improved velocity by replacing cylinder gaskets and spring. I have increased the rounds per minute by altering the armature windings of the drive motor. And most of all, I have made my own cheap alternative PC-based Chrono.

I have posted an artivle before that details the development of my chrono but unfortunately the online forum was hacked/deleted by webmaster of proboards.com due to some violation in the contents. So, I'm re-posting it here now. ...thinking... (dont know how to start).

Okay, the idea started when I read about Jim's Homemade Chrono on the internet plus the desire to know how my AEG is doing in terms of muzzle velocity. Measuring the velocity is elementary physics. We measure velocity in terms of time and we measure time in terms of velocity. Think... think... think... Maybe this is the reason they call this device chrono (latin for Time).

The chrono i made was PC-based, meaning it requires a Personal Computer to work. It cost me about only 2.00$ for the components. Its basically a LPT port (Printer port) device which makes use of 2 infrared photo transistors and 2 infrared LED as bullet sensors, and a junk umbrella. What this device does is measure the amount of time it takes for the bullet to complete a travel to a definite distance, in this case (4 inches).

Tools

Soldering Iron, Mini Drill (for boring circuit board holes), Multi-tester, Circuit board, a couple of beers for the brain and of course, an Airsoft Gun (AEG).

I also used a universal printed circuit board to save time etching some copper clad for a very simple circuit like this.
How it works?
The schematic is pretty simple. It is composed of a pair of basic transistor switching circuit. The purpose of this two switch circuit is to tell the computer the a bullet has passed/detected at this location at a very specific time. Below is the schematic diagram of a single swithing circuit i used.

 I designed the circuit ingenously so that it will not require external power source. The whole circuit gets its power from the PC's parallel port output pins. Sweet...
The IR Photo Diode emits an infrared light which will be received by the IR Photo transistor which serves as bullet sensor. Both are positioned in a way that when a bullet passes in between, the Phototransistor stops receiving IR signal for a bit by blocking the IR light. It then switches ON one pin of the parallel port making that specific BIT set to 1.

Materials

I got my IR Photo transistor and IR Photo Diode from an old junked wheel mouse. Wheel mouse has two pairs of this. One for the X and one for the Y axis so the wheel mouse is the perfect donor.




The barrel that serves as guide for speeding BB bullets was got from another junk. An umbrella stem. I decide to use the length 6 inches so that the conputation for Feet per second will be simpler and accurate. I then drilled two holes for the two pairs of IR tansistor and IR emiter as a bullet sensor position 4 inches apart form each other. This will make computation for feet per second easier because 4 is a factor of 12 inches (1 foot).

I then bought a couple of general purpose small power transistors to serve as the final switching element as it is indicated in my schematic. The lucky transistor is the C9013, an NPN small power transitor which is very common in local electronic shops.
Hardware Assembly
Connecting the components together in a circuit board as it is in the schematic diagram above, the result is a cute weird device. I reserved a space for the barrel at the center of the circuit board. The C9013 transistors are positioned in the image as the small black half-round pegs. I made use of hookup wires to connect the components together.

I then positioned the drilled barrel (umbrella stem) in the circuit board in a way that the phototransistor and photo diode will see each other thru the side wholes of the barrel. Then i soldered the barrel in to the board.

Then by attatching the printer cable using the correct pins to the base pins of the C9013 transistors, you now get the complete hardware part of the project. The speeding bullet sensor.

The Software
The software was written in C# over .NET framework 1.1 and is using a native library inpout32.dll which was written in C++. What this software does is to listen to the sensor for any signals. There are two type of signal that the hardware will send. One will tell the software that the bullet has passed thru the first sensor and the other one will tell the software the the bullet has passed thru the second sensor. The software will then record the exact time(in microseconds) these particular signals are received and do the velocity calculation.
From the unit itself we can already derive the formula. The unit is Feet per second which derive to the formula Velocity=Distance/Time. In my case the distance is fixed which is always 4 inches. The only variable we need is the time which can be derived by subtracting the particular time sensor 2 was triggered from the exact time sensor 1 was triggered.
Easy right, but the trick is how to make your software very fast enough to captre the presence of a speeding bullet to upto 600 feet per second. If i can stil remember, i made use of the .NET's performance counter to do this. This utility is designed to measure performance of your code but this i made it as part of the function itself.
The software was first witten as a .NET console application for the sake of simplicity. Or maybe i was just too excited to test that i cannot wait for a user interface to delay the development. :)
Testing the Project
I tested the project with a non-modified(stock) china made AK47 so that the resulting velocity is expected. And bingo! This is the result:

Although this software is running on an AMD K6-2 500 MHz with a 1GB RAM, it still performed like it was designed. But I did a few calculations and determined that with this machine (500MHz), only about 600 to 700 FPS is the maximum detectable speed. So what, everyone has a Pentium 4 anyway at the time I made this project. And also, with gearbox v2 or v3 you cannot make your airsoft gun go beyond 1000 fps anyway. How much more now with processors like ADM Turion or Intel Core 2?

After I have proven that it was possible to make a personal chrono for less than 2$, i then made a windows -based version of the application to enahnce the level of user friendliness. The only user of this sofware is just me anyway.

Even though I don't have this device with me now, coz i left it to a friend in iligan after i relocated here in Manila, you're still free to leave suggestions for improvement. I might make a better one someday...

Handcuffs

It's been almost a year now since I've been writing Java codes since I was deployed to my current project. I used to write .NET C# codes for almost 4 years back in the academic world. Just yesterday, I was given a change to apply my .NET skills again to solve a real-world problem and fix a bug in a special browser application. In my experience in Java, I have been using "throws" keyword when writing a library to require the caller to catch exceptions that could possibly occur in the library. This feature is called "Checked Exceptions". But, I was surprised to find out that C# does not support this feature. So, i did a few searches on why did'nt Anders Hejlsberg, the lead designer of C# Language, didn't include this when in fact I find it useful when I was writing in Java. Then I found this interesting link which describes the reason behind this.

The converstation in the article state clearly that the designer decided not to include checked exceptions in C#. I like the lines Anders said when he was asked if there was disagreement in the C# design team about checked exceptions.

Anders Hejlsberg: No, I think there was fairly broad agreement in our design group.

C# is basically silent on the checked exceptions issue. Once a better solution is known—and trust me we continue to think about it—we can go back and actually put something in place. I'm a strong believer that if you don't have anything right to say, or anything that moves the art forward, then you'd better just be completely silent and neutral, as opposed to trying to lay out a framework.

If you ask beginning programmers to write a calendar control, they often think to themselves, "Oh, I'm going to write the world's best calendar control! It's going to be polymorphic with respect to the kind of calendar. It will have displayers, and mungers, and this, that, and the other." They need to ship a calendar application in two months. They put all this infrastructure into place in the control, and then spend two days writing a crappy calendar application on top of it. They'll think, "In the next version of the application, I'm going to do so much more."

Once they start thinking about how they're actually going to implement all of these other concretizations of their abstract design, however, it turns out that their design is completely wrong. And now they've painted themself into a corner, and they have to throw the whole thing out. I have seen that over and over. I'm a strong believer in being minimalistic. Unless you actually are going to solve the general problem, don't try and put in place a framework for solving a specific one, because you don't know what that framework should look like.

Bruce Eckel: The Extreme Programmers say, "Do the simplest thing that could possibly work."

Anders Hejlsberg: Yeah, well, Einstein said that, "Do the simplest thing possible, but no simpler." The concern I have about checked exceptions is the handcuffs they put on programmers. You see programmers picking up new APIs that have all these throws clauses, and then you see how convoluted their code gets, and you realize the checked exceptions aren't helping them any. It is sort of these dictatorial API designers telling you how to do your exception handling. They should not be doing that.

I have a total agreement on the handcuffs thing. I didn't realize that until I read this. I used to think that checked exception is very useful, well.. maybe it is in some ways like reminding the programmer to always catch such exceptions.. like what i did in my previous Java codes. But I also had these feeling of having no choice when the compiler tells you what to do specially when you call a method in a compiled library that throws more than 5 exceptions. What if you call 50 methods in this library and each throws 3 different kinds of exceptions? Hmm... all I can say is that I felt the handcuffs Anders was referring too. You don't want to put handcuffs to other programmer/users of your library, don't you?

Check this interesting argument: http://bytes.com/forum/thread259125.html