[Spork] over on the Netduino forums wanted to push the limits of what his little board could do. He put together a chronometer to measure the velocity of rifle rounds and Nerf darts using an Arduino-compatable CPLD shield.
The project is built around a pair of commercial CED M2 chronograph sensors; because people have the tendency to shoot through these sensors, they’re available as replacement units for much less than the cost of a complete chronograph setup. [Spork] couldn’t figure out a way for his Arduino clone to read pins with a resolution of 1 microsecond, so a Amani GTX CLPD shield was added to the build. This programmable logic chip takes the output from a chronometer sensor, starts a timer, waits for the second sensor to trigger, and stops the timer. From that, the velocity of just about any projectile can be calculated.
Of course, [Spork] needed to test his new device, so he took it out to the range and fired 25 rifle rounds through his chronometer. The result was a very nice, normal distribution centered around 2400 feet per second, exactly as would be expected. Although [Spork] didn’t test out low-velocity projectiles such as Nerf darts, we expect the same reliable results.
via majolsurf
I’ve been looking for a good explanation about how the (skyscreen) sensors work. It’s probably just LEDs and silicon based light detectors, along with some reflector tape, but I’ve yet to meet anyone who let me take one apart. Photos would be nice.
I would guess that you could probably do the processing of two channels with a sound card, probably manually at first using something like Audacity.
You are more than likely going to want to use a computer to calculate standard deviation, as well as to log temperature, humidity, elevation, timestamps etc.
If the soundcard works, you could also use a USB dongle based soundcard for 4 channels. That would let you use 3 skyscreens (hooking the center sensor to both soundcards) to verify that both reading agreed.
I have 2 skyscreen sensors sitting in my room right now. The original chronograph is not functioning properly. I have tried to look a little at how they work. I will take a couple of pictures inside the sensor (its SUPER simple, 1 component) and inside the chronograph and make a thread in the forum. Keep an eye out for GoBO207. I would love to make an AVR drop in. Get in touch with me through the message system in the forum.
http://forums.hackaday.com/viewtopic.php?f=4&t=2234
Check that link. THe title is “Oehler Skyscreen III to AVR”
Not to bash on his achievements, but it’s kind of a shame that he felt it was easier to buy a CPLD shield than use the Atmel chip itself.
I’m all for the quick prototype-ability of Arduino and its brethren, but it would be so much better if the friendly environments also allowed for easy bare-metal programming of the micro. (and encouraged it/provided tuition)
I haven’t dug into what pins are broken out on the netduino, but by looking at the chip’s datasheet, it has a 16-bit timer counter with 3 channels with external clock inputs. These could be used to give a resolution plenty high enough for what he’s doing.
Spork here… When I started this project, my original intent was to build it on the Atmel features you mention. After many discussions in the Netduino forums, I decided that it just wouldn’t be practical. Like you said, it would be nice “if the friendly environments also allowed for easy bare-metal programming of the micro.”
I didn’t have any interest in porting the work I’d already done from Netduino to Arduino, but I was very interested in dabbling in digital design. So dropping a CPLD on top of my Netduino seemed like the perfect solution.
Learning some of the basics of digital design, CPLDs, and Verilog has been half the fun of this particular approach. Now that I’ve got the basics down, I’m sure there will be other problems I’ll solve with CPLDs or FPGAs. And some of those solutions probably won’t require a micro controller at all.
Verilog is a *ton* of fun, and the C-like syntax makes is a lot easier to learn for anyone with C experience than, ohhh sayyy VHDL (which looks like an alien language to me.) Just be sure to make a testbench and simulate your designs to check for logic errors :)
Fair enough :)
No such thing as bad learning
This may be of no use, but….
I once needed to measure pulse width at high resolution on a very slow microcontroller. Total period was guaranteed to be less than 1000 uSec, but no budget for CTC chips.
The ghetto pulse measurement:
if pin 1 is high, loop to self
followed by 1200 sequential copies of:
if pin 2 is low, jump to Xn
(where Xn was a routine to load the matching time period into the result, then jump to the calculate results section.
It wastes a lot of code space, but you can accurately measure pulses at whatever the system clock speed is.
In addition, I wish to suggest an analog solution if you can devise a calibration method, which I will leave as a not-very difficult exercise for the builder.
By moving the sensors even more closely together, and using a little knowledge of RC curves, you could certainly use the pulse width to charge a small capacitor. Measuring the voltage prior to charge event (the pulse) and after will provide a voltage that gives you a number that will have a resolution in line with your a/d converter.
The math used to derive velocity from voltage is a simple quadratic (for calibration purposes) and the conversion won’t be too hard.
I suppose the math and the need for temperature correction might present an insurmountable obstacle for many of experimenters, but pulling out fps accurate to +/- 10 fps is quite doable, and +/- 5 fps should be achievable.
Not bad for $3 worth of parts.
Hmm. The AVR actually has CTCs with a capture-option: it’ll capture the current timer value into a register when a pin goes high or low. If he has two of them, he can measure sub-uS-timings without a CPLD.
Yeah this is what I was getting at – you can actually use just one of them I think. The first trigger signal can be used to start the timer, and the second to copy the value
Only caveat is that the pulses have to be at least as long as the timer’s clock cycle in order to register. No idea how long the pulses from the sensors are
You can definitely just use one of them – I did this to measure the fuel injector pulse times in my car. I think the Arduinos have a 16MHz clock, so you could have excellent resolution, 0.0625 microseconds.
I should add that starting the timer isn’t as accurate as capturing the timer value. The best way to do it is to have the timer running continuously, and the start of the pulse triggers the capture interrupt. In the interrupt, immediately set up the timer to capture on the end of the pulse, then store the captured timer count. Then when the capture interrupt triggers again, store the second captured value somewhere. In addition to all that, the timer overflow interrupt is counting how many times the timer overflowed in between the timer capture interrupts. Combining the three values gives you all the information you need to work out exactly how long the pulse was. I hope that made sense.
The Mega has 2 ICPs broken out and they can measure down to the crystal frequency (60nS). The Seeed studio version has 4 available. I forget if there is just one counter, or if you just use the gtccr to shut counting off, write zeroes, then restart, but syncing them is trivial. I use these as a poor man’s logic analyzer and even can decode uart data.
Where can I find the pinout of the CED M2 sensors ?
Jack connector.
Regards
Alfredo.