Arduino Chronograph v.2.0 (Breakwire)

[mark.f]

So, being an Arduino detractor for quite some time (at least for simple circuits which can be done with other components), I finally built something with a cheap Micro model.

This is a chronograph that works using two pieces of magnet wire that snap when shot. This is a "downgrade" from version 1 (at least for the moment), but results in accurate readings. So what was version 1?



(Yes, that's a stick and duct tape.)

Version one used a pair of phototransistors, spaced 20 cm apart (pretty short). It suffered repeat measurements for some strange reason, probably the small distance between sensors. It measured between rise time to rise time... future versions will use storage and measure peak to peak. It also communicated the velocity over serial, which means that you needed a laptop on the range.

So, version two is much simplified and works well. If flashes the measured velocity on a pair of LED's. Here's the code. SF's "code" tag likes to snip out parts for some reason, and it's easier to read this post as well on pastebin. :p

And a simple circuit diagram:



Finally, here's a short video of the operation. No cannon to test it with at the moment, and trying to break the wire with a pellet gun is pretty tough, so I wired a couple of toggle switches to where the breakwires would be wired in the real circuit.

Here lies a dead YouTube video

In the video, it measured a "velocity" of 29 ft/s. Placing the "jumper" on the rightmost pins of the "jumper block" would display the "velocity" in m/s, and the next set of pins in mi/hr.

Questions? Comments? lol.

I eventually want a self-contained solution that can chrono anything from pellets to watermelons... we'll see how that works. :p

[Technician1002]

Time sample size could be an issue with software based timing circuit. I am not up to speed on this processor. If it runs an interpreter, such as basic, some of the timing clock cycles are used to run internal code. If it runs machine language without an interpreter, then machine code can be very compact and depending on the clock speed can have pretty tight time measurements.

If running machine code, attention must be paid to real time operation. A tight loop polling the ports for events should exclude branches for other interrupts such as polling the clock as pauses in the execution of the loop can cause delays in detecting a wire break.

If the code is interrupt driven, the other code must branch to the interrupt with minimal clock cycles to get an accurate event time stamp.

I have not messed code in forever and a day, so I can't help with the source code, but a quick glance at it does show you are using interrupts and not polling the ports. In most cases this means that the running code will finish to a branch point of unknown number of remaining clock cycles, then branch and service the interrupt. This can cause significant random delays on capturing the interrupt event time stamp. Check with your manual to see how interrupts are handled.

The code is not machine language, so I know it has to be compiled, which unfortunately for real time operation is often far from optimal as you have no control over the number of clock cycles that pass between an interrupt and the routine execution.

The compiler makes writing source code much easier, but the resulting machine code may not be optimal for real time measurements.

To test your firmware, pick up a CMOS decade counter, the 4017. Using a 555 timer or other stable clock source, clock it at a rate of about 1KHZ. Hold the chip with the enable pin and reset the chip. Start your chronograph, then enable the 4017 so two of the outputs sequence the chronograph. Using output 2 and 3 for example will give a 1 MS sample and using 2 and 6 gives a 3 MS sample. This gives a calibration source to test your chronograph. I use a 1KHZ clock crystal with one for reference signals.

Check your manual. You want to disable any keybounce software that is used for mechanical switches as this takes many clock cycles to detect a valid keypress.

Code that samples the ports on a regular interval (like a sound card) and continues until the second wire is broken may be able to provide tighter timing measurements. The number of clock cycles between the first wire break and the branch at the 2nd wire break can capture the number of clock cycles between the first and second break.

[mark.f]

Funny you mention the 4017, one of my future ideas was to use a chain to time between wire breaks using a clock signal of a few MHz.

There are indeed some inaccuracies in using Arduino for this. I'll definitely pick up a few decade counters and crystal to check what those are.

[jimmy101]

Disabling key debounce software (or hardware) might not be needed since both detectors would have the same debounce technology and the debounce delay should cancel out.

Tech's other points though are spot on.You might consider not timing with the micro at all. Have the breakwires enable then disable charging a cap then use the micro to read the final voltage. How the micro works interrupts or timings no longer matters.

For the digital counter approach you can just use the micro's onboard clock to drive the counter. For a binary counter you would need 20 bits to get a one second interval at 1 MHz. 16 bits (2 counters) would probably be enough for a 1 MHz clock and would give one microsecond resolution up to a duration of about 60 milliseconds.

[Technician1002]

Break wires can be used to Start/Stop a binary counter running 1 MHZ or faster and use the processor to convert the binary to decimal and convert microseconds to FPS for display. With the 20 bit resolution mentioned in the above post, a counter with a serial shift register would use minimal pin count. Since you don't need a full second count, you could possibly get by with a 16 bit counter as mentioned above.

Remember your output resolution is only 3 or 4 decimal digits. You only need to sample your binary counter string for enough resolution to provide your desired output resolution. 8 bits gives 256, 9 bits 512, 10 bits 1024, 11 bits 2048. There is no reason to need more than 12 or so bits of binary resolution. 2 8 bit or one 16bit counter should provide plenty of resolution. Music CD players only use 16 bit A/D conversion.

First break would release the reset pin, starting the counter and the second latch the output holding the current count and triggering the Arduino to read the value. This would give accurate times with minimal external components. Accuracy would be immune to clock cycles on the processor as it is no longer real time critical.

BCD counters can be used if you don't wish to convert from binary to decimal counts and not use the microprocessor. Cascaded counters directly driving a BCD to 7 segment display can provide a direct reading of the count whether Milliseconds, NanoSeconds, or MicroSeconds.