Chronograph

As part of the PEST project, a chronograph was built to measure projectile speed. Here are the details:

Schematic (all parts available from Digi-Key)

Flashable HEX file (rename suffix back to .HEX and program the PIC16F676's flash using the US$30 PICKIT-1 eval. board or some other programmer)

The chronograph works in the normal way, by timing how long it takes a projectile to break two infrared beams spaced 3 inches apart in the tube. The spacing is critical as any offset will result in a measurement error. I used my Sherline 5400 mill which has hand wheel graduations of 0.001" to drill the holes and mill the flats for the sensor mount.

The minimum measurable projectile speed is approximately 38.1 ft/sec. This causes the internal counter to hit the design maximum of 32767 which results in a percent error due to counter resolution of .003% With a projectile speed of 3000 fps, the internal timer hits a count of 416 which results in an error due to counter resolution of about 0.24%. Higher speeds are possible but the internal counter will count to proportionally lower values, resulting in a larger percent error.

The neat thing about this chronograph is the display. Instead of using a 5x7 LCD module or a 7-segment LED, it uses a digital multimeter (DMM) that can measure frequency as the display. The measured velocity from the PIC is output as a 50% duty cycle square wave whose frequency value in Hz corresponds to the projectile speed in ft/sec (i.e. if the DMM shows 550 Hz on the output pin, the measured velocity is 550 ft/sec. This approach is nice because it only needs a single I/O pin for output. These days, even a cheap $20 DMM from a US discount tool shop like Harbor Freight can measure frequency, so the effort to add a display with its associated wiring and software did not seem worthwhile. Outputting the speed as a frequency has another important advantage - the software is greatly simplified. There is no need to take the reciprocal of the time interval to get velocity. The software only needs to scale the measured delay to get the desired output square wave period. The processor clock speed and separation between sensors was chosen so that scaling the measured time to the desired square wave period only required a single binary left shift (trivial to do in assembly code). The entire chronograph code is less than 200 words out of 1024 available words in the PIC's flash memory.

If you want to do some quick chronograph testing by dropping ball bearings from a few inches and measuring the speed, the HEX file above will not work, since the speeds you need to measure will be below 10 ft/sec. Flash the HEX file below and you can measure speeds from 2.4 ft/sec (percent error due to count is about 0.1%) to about 19 ft/sec (percent error due to counter resolution is about 0.8%). Note that the DMM frequency output is scaled up by 128 in this case to get frequencies that are easy for the DMM to measure. (i.e. 520 Hz on the DMM means a speed measurement of 520/128 = 4.06 ft/sec). I recommend dropping the ball bearing about 2 inches above the first sensor. If you do a quick calculation you'll find the minimum height needed to exceed the minimum speed of 2.4 ft/sec. Note that the beam width is fairly narrow so you need to drop the ball bearings fairly accurately to break both beams.

Flashable HEX file for low-speed chronograph (rename suffix back to .HEX and program the PIC16F676's flash using the US$30 PICKIT-1 eval. board or some other programmer)

One important note is that if the projectile misses one IR beam, the chronograph will timeout after 13.1 msec (milliseconds). (low speed chronograph timeout = 0.104 sec) and wait for the next valid shot. If both beams are broken within the timeout period, the shot is considered valid and the data is stored. After a valid shot there must be a delay of at least 12 usec (microseconds) to scale/store the data, update flags, etc. before the next shot can occur. To be safe, the rate of fire for valid chronograph readings should be limited to a maximum of 76 shots per second (9 shots per second for low speed chronograph). This is more than enough to measure the speed of every shot in a burst of the PEST launcher (rate of fire of around 3-5 shots per second).

How to Use

When the chronograph is first powered, the three LED's D1/D2/D3 will flash on/off twice indicating that it is ready to measure velocities. You can then fire a projectile through the chronograph. If the first shot triggered both sensors within the timeout interval, the speed will be stored in an internal buffer and the LED's will show binary 001. The next valid shot will cause the LED's to show binary 010 etc., up until binary 111 (7 is the maximum size of the buffer). To read the speeds, press/release the "Playback" button (SW1). This will exit the normal measuring mode immediately, show binary 001 on the LED's and the DMM output will have the frequency corresponding to the speed of the first shot. Hitting the "Playback" button again will advance the count to binary 010 and show the speed for the 2nd shot, etc. To exit this mode, press/release the "Reset" button (SW2) - this will reset the processor, clear the shot memory and flash D1/D2/D3 twice. You can now measure the speed of more shots. If less than 7 shots were fired before hitting the "Playback" button, then all the LED's will turn off once all the stored data has been shown. You have to press/release "Playback" button a few more times until the internal count rolls over from 7 to get the speed of shot #1 again. If you fire more than 7 shots, only the last 7 will be stored/displayed.

Technical Issues for the Curious

Some readers might be wondering why I didn't just buy a chronograph? They are, after all relatively cheap at US$100. One issue is that you need to use most commercial chronographs outdoors unless you buy an indoor lighting kit (they don't work well due to 60Hz noise from fluorescent bulbs). The chronograph also needs to measure projectile velocity for bursts of 3-5 projectiles per second. I could not find data on whether a commercial chronograph could handle that. I decided to build my own since it is much cheaper and much more fun. The parts cost was less than $5 for the PIC and sensor pairs - the rest of the parts came from my inventory of parts (essentially "free"). Another nice thing about this design is that it can be mounted directly to the muzzle of the PEST launcher. That means I can do velocity testing in the field without hassling with a tripod, etc to mount a normal chronograph. Note that this chronograph will not work well with normal firearms since the chronograph opening is only ~1.5" You have to be a durned good shot - doubly so since the chronograph must be placed far enough away to avoid muzzle blast errors. For low firing signature launchers like the PEST, coilguns, or airsoft guns, this design will work well.

Building an accurate chronograph requires taking into account several factors. The required timing resolution depends on the expected velocity of the projectiles. In this case, intervals in the order of 3"/12/500 fps = ~500 usec. needed to be measured. To get say, a 1% error maximum, all the timing errors must be less than about 5 usec. This is quite easy to do with some care and the final chronograph probably has an error below 0.5%. Some of the design issues are shown below along with some FAQ-like Q&A

Sensor selection - many homemade chronographs use a phototransistor for the sensor. Depending on the type chosen, they can be very slow, with response times up to 10uS-50uS. I decided to use Fairchild QSE157 Opto-logic sensors since they are cheap (US$1 each) and combine a photodiode, voltage regulator, amplifier and Schmidt trigger output buffer in a single unit that gives a TTL compatible output. The data sheet shows a typical propagation time from light pulse to digital out of 6 usec. I measured a few units and they are faster in practice, with a propagation delay time of around 2 usec. The PEST launcher fires .3125" diameter spheres, so each photosensor is blocked for a typical duration of .3125"/12/500 fps = 52 usec. So these Opto-logic sensors are fast enough to detect that. A slow, 50 usec rise time phototransistor probably will only show an attenuated pulse in response to a .3125" projectile traveling at 500 fps. The only disadvantage of this sensor is that it has a "side looker" type of package that requires some flats to be milled in the mounting tube instead of drilling a simple hole.
Matching between the sensor pairs - due to manufacturing tolerances, one photosensor may respond faster/slower than the other to the IR light pulse when the projectile crosses the beam. This causes a mismatch between sensors and a small error in the measured time delay. The two IRLED's may also have slightly different output intensities for the same current, resulting in a slightly different trip point of the photosensors, again causing a small error in time measurement. I measured the two sensor pairs in the chronograph and found the output was mismatched by ~400 nsec. This difference results in an error of about 0.08% at a projectile speed of 500 fps and can be safely ignored.
Why are the LED's connected to GPIO and not powered directly from 5V? During testing, I wrote some simple code to flash both IRLED's simultaneously at a 20 kHz rate. I looked at the output of Q1/Q2 on a digital scope to see how well matched the outputs were. A digital scope screen capture showing the ~400 ns offset between Q1/Q2 is shown here. That's how I got the data mentioned in the above "bullet". During operation, the IRLED's are not pulsed but are kept on. In "Playback" mode, the IRLED's are turned off to save a bit of power. If you want to build this chronograph and don't have access to a 'scope, just wire the IRLED's to the regulated 5V output and you can probably ignore this source of error.
Software issues - the software must time the delay between two pulses. Each photosensor was wired to a PIC interrupt pin to avoid polling loops in the code. By avoiding polling we can guarantee that the PIC responds between 3-4 instruction cycles to the sensor interrupt. Since each sensor has the 3-4 cycle latency, the overall uncertainty in timing measurement is +/- 1 instruction cycle (200 ns or 0.04% error at a speed of 500 fps). When the pulse frequency is being output, the PIC needs to reload the timers continuously, and take care of other housekeeping to get the 50% square wave output - this takes a very small amount of time time (26 instruction cycles or 5.2 uSec) - this small amount of overhead does not cause any additional error, since this delay is deducted from the measured time to compensate for the overhead. Note that the 5.2 uSec delay includes the time needed to add the correction factor itself.
Why did you use an external oscillator in the schematic and not a crystal? I used the ECS-100A-20MHz external oscillator simply because I did not have a 20MHz crystal in my parts box. :( This results in higher power consumption than using a 20MHz crystal but that is not so critical in this application. The external oscillator has an accuracy of 100 ppm (0.01%) - negligible compared to the error due to the timer's finite register width.

Note that combining all the known timing errors results in a max timing error of ~0.13% at a measured speed of 500 fps - more than enough accuracy for this application. Even at a speed of 3000 fps (centerfire rifle class), the timing error is below 1%. The true test would be to compare the measured velocity from this chronograph with a high quality commercial unit. Barring that, this chronograph should still be rather accurate since a lot of factors were considered in its design (I hope!)

More Pictures

Please use My Yahoo Photo Album to see more pictures of the PIC chronograph. The image descriptions are below:

chrono1.jpg - 1.5" schedule 40 PVC pipe used for the chronograph tube. Note flats machined for QSE157 mounting
chrono2.jpg - same pipe showing IRLED mounting holes and launcher mount holes.
chrono3.jpg - some old Li-ion batteries I am using to power the chronograph. Each battery is 3.7V at 600mAH
chrono4.jpg - assembled chronograph. Note IRLED and sensor holes
chrono5.jpg - another view of the assembled chronograph
chrono6.jpg - closeout of the circuit. battery connectors are on the left. two copper loops on the upper right are for the multimeter
chrono7.jpg - side view showing aluminum standoffs to mount the board (epoxied in place)