Bullet Speed Sensors

I have seen some arduino code for measuring bullet speed, but haven't seen much on behalf of the sensor(s) used.

I was thinking of a pair of sensors that are spaced by a known distance. I figure the further the distance, the better the accuracy of the device. Anyways, I would measure the time of flight between the two sensors and derive speed using time, distance, speed relationships. The goal is to measure up to 4000 feet per second within +/- 2 feet per second. (I don't know if that is feasible???)

I was wondering if I should use a photo sensor or maybe some type of barometer/ pressure sensor that measures the sonic wave....

Any ideas appreciated. Not really worried about the coding yet, just if the sensor and arduino are up to the task...

4000 feet per second

1 ft = 1/4000 = 0.000250 seconds = 250uS

Arduino 16MHz is typically quoted at 4uS resolution without resorting to assembler code. There is instruction overhead but I see no particular reason you could not use an Arduino.

For sensor, I prefer broken wire... Very small magnet wire woven in a back-n-forth loop and glued to paper or acetate projection sheets. It's a little work to build each sensor and you need two, but the issue of accuracy becomes that if distance displacement before the wire continuity is compromised. By keeping both sensors identically, the distortion/displacement effect should nearly cancel. Using embroidery frames or hoops is an ideal holder.

Ray

http://www.cameraaxe.com/wiki/index.php?title=Sensors#Projectile_Sensor

I like the idea if the wire mesh, but I would like the system to be repetable. I also came across the camera thing. That is pretty awesome. The design I am seeking is something that I could put a couple of down range. With the camera thing, I would bet many of these chronys would get damaged down range.

I think I will end up with the typical chrony hoop design, but I was thinking a pressure sensor would give me quite some flexibility and allow the bullet to pass up to several feet above the sensors minimizing the chance the projectile hits the sensors.

So I have found an implementation of this idea:

http://www.steinertsensingsystems.com/product/superchrono-standard/

They seem to use a pair of ultrasound microphones.

A shock wave passing a point has a characteristic type n-wave:

http://images.lingvistika.org/w/images/thumb/5/55/N-waveFig911.png/250px-N-waveFig911.png

My thought is that I need to create some type of circuit that produces a high TTL signal, or positive pulse, on a particular +pressure threshold. Too low of a threshold and the muzzle blast will give you a false trigger or pickup an alternate lane's bullets. Too high and you wont pick up the bullet. As long as the two sensor circuits are identical, the arduino clock should be a good use.

I feel like two analogRead() would take much more time than pulsein() between two pulses....

Any ideas how to create a circuit like that?

They seem to use a pair of ultrasound microphones.
A shock wave passing a point has a characteristic type n-wave

My guess is

In analog listening mode would be a start.

A storage oscilloscope would be helpful as would an inside shooting range! ]

Ray

you think a piezo, audible, or ultrasonic would be a good sensor to start out with?

you think a piezo, audible, or ultrasonic would be a good sensor to start out with?

Commercial unit uses ultrasonic... My guess is there was a good reason.
May want to do some googling on the various ultrasonic sensors... Maybe even try one of the $4 ultrasonic pingers (canabilize it) for the sensor and an IC opAmp to use as a high-pass filter feeding the Arduino.

If the patent for the commercial device is obtainable, you will have great background on the specifics that may JumpStart your effort.

Ray

Most commercial muzzle velocity sensors use. Pin diodes breaking a light beam.
For accuracy i think i would use a hardware oscilator / counter which could then be read by the arduino.

Sound sensors , no idea, i would expect them to be dependant on a supersonicc bullet but do not know.

If a wide area possibly several pin diodes to form a curtain, some processing to extract the signal though.

Not clear what you are trying to measure though ?

Velocity at a specific point ?

The goal is to get drag information about a projectile. I don't know how much you know about fluid dynamics or ballistics, but the drag force of a bullet changes over its trajectory; it is not constant. Manufacturers give the shooter 1 ballistic coefficient to calculate bullet drop that they have to apply to a one curve fits all solution. This curve can not be accurate for multiple projectile shapes. Naturally, as I think anybody on this forum, I would like to collect more data over all bullet speeds. I would like this design to be somewhat cheap and accurate. I would like 5 - 10 of these chronometers to place over the ballistic trajectory. (10 of these would be $3,500) I think I could load less powder in the projectile to shoot a slower bullet to get an expanded curve on a shorter range. Maybe a string of these sensors would be pretty awesome for collecting data...

Is an ultrasonic sensor typically an active "ping" design? The superchrony does not work after transition to subsonic. I am assuming they are "passive"? I really am not interested in data through the transonic range (yet). So the sonic cone is what I am listening to. I am assuming the sonic cone is not changing much over the two sensors separation.

I was planing on using the arduino's crystal as the hardware oscillator and the pulsein() function. If I needed a really accurate solution I could check the arduino's crystal somehow... I could also use a 20 khz crystal and see 20% gain in precision?

Is an ultrasonic sensor ...

Honestly, I do not know. I have bunches of these laying around:

and

suggests these are

Basic Ultrasonic Sensors, interchangeable, suitable for both transmit and receive.

So I am guessing you can take a dual-element ping sensor from China and cannibalize it for 2 sensors. Or just buy what you think you need... better, beg for samples and test. You are going to need to run a long series of tests to 'profile' the bullet supersonic waveform and design the appropriate filtering circuit (or software.) This is where a storage oscilloscope would be useful.

Based upon the diagrams from the commercial manufacturer and their vague write-ups of their patented methodology, I suspect this entire project is more to do about digital signal conditioning and processing than the selection of the specific sensors. But, who knows?

The Arduino will need to be programmed, IMO, outside the use of pulsein() function. There are plenty of examples around the forum for things like FFT and frequency counters, etc. As I recall, pulsein() is a blocking command. As far as issues with pulsein() try the advance forum search on "plusein overhead" and do some reading.

This is a rather advanced project simply because

• Little commercial specifics
• Little published data
• Use of sensors outside typical design use
• Lack of working Arduino code

None of the stuff to build a model is terribly expensive, maybe you just need to sit in your workshop and fire a few blank load and see what kind of voltage you get from the sensor. You will definitely need to partner with someone that has a storage scope if you do not have one personally. Most major cities have Arduino clubs and many RC hobbyists have microcontroller experience and test equipment. I just do not see this being a really viable forum discussion until someone qualifies the sensor as you wish to use it and then reports back on what the pulse looks like with specific measurements.

With enough Web searching, you may be able to find a university, company, individual that has performed similar experiments and posted the data. I have found that published senior projects and thesis from some colleges are posted online... they make for fascinating reading! Example: http://www.media.mit.edu/research/groups/high-low-tech
Or: Senior Design for Clients | H. Milton Stewart School of Industrial and Systems Engineering

I think I could load less powder in the projectile to shoot a slower bullet to get an expanded curve on a shorter range.

Personally, I was awarded a Marksmanship Ribbon in the USAF back when I was young and could see the targets. From my prospective, I always wanted that magazine loaded with a full-load of powder... no freaky pink cartridges for me ]

Ray

Gotta love the power... I am doing this project to model a projectile for the purpose of a ballistic calculator. But garbage in = garbage out.

I did a little searching, but forgive me, I am not a programmer. Can you explain the limitations of pulsein() and perhaps purpose an alternate function or method? Should I avoid an interrupt?

Read the code comments. Also note this code "blocks" all other code from running... Big pregnant pause!

/* Measures the length (in microseconds) of a pulse on the pin; state is HIGH 
 * or LOW, the type of pulse to measure.  Works on pulses from 2-3 microseconds 
 * to 3 minutes in length, but must be called at least a few dozen microseconds 
 * before the start of the pulse. */ 
unsigned long pulseIn(uint8_t pin, uint8_t state, unsigned long timeout) 
{ 
   // cache the port and bit of the pin in order to speed up the 
   // pulse width measuring loop and achieve finer resolution.  calling 
   // digitalRead() instead yields much coarser resolution. 
   uint8_t bit = digitalPinToBitMask(pin); 
   uint8_t port = digitalPinToPort(pin); 
   uint8_t stateMask = (state ? bit : 0); 
   unsigned long width = 0; // keep initialization out of time critical area 
    
   // convert the timeout from microseconds to a number of times through 
   // the initial loop; it takes 16 clock cycles per iteration. 
   unsigned long numloops = 0; 
   unsigned long maxloops = microsecondsToClockCycles(timeout) / 16; 
    
   // wait for any previous pulse to end 
   while ((*portInputRegister(port) & bit) == stateMask) 
      if (numloops++ == maxloops) 
         return 0; 
    
   // wait for the pulse to start 
   while ((*portInputRegister(port) & bit) != stateMask) 
      if (numloops++ == maxloops) 
         return 0; 
    
   // wait for the pulse to stop 
   while ((*portInputRegister(port) & bit) == stateMask) { 
      if (numloops++ == maxloops) 
         return 0; 
      width++; 
   } 

   // convert the reading to microseconds. The loop has been determined 
   // to be 20 clock cycles long and have about 16 clocks between the edge 
   // and the start of the loop. There will be some error introduced by 
   // the interrupt handlers. 
   return clockCyclesToMicroseconds(width * 21 + 16); 
}

Interesting.... is "overhead" the description of the code that follows?

I guess any "while" statement is "blocking" statement until the condition statement becomes false and moves on? I don't see that being a huge deal for the time between the two sensors.

The clocks thing seems to be interesting. I guess it refers to 1 us of time. Interesting the comments say 20 uS but the equation has 21 uS in it. How is the arduino able to operate that fast? Wouldn't it be stuck at 1/16 kHz per line of code or 62.5 uS? I know you said 4 uS in an earlier comment. Where does that come from?

If you set timer1, say, clocking at full speed you can read its value in an interrupt routine to
note the current time in units of 62.5ns. It will be overflowing every 4ms but the difference
between two readings less than 4ms apart will be nice and accurate.

You'd also need to disable the timer0 interrupt since that has priority. timer1 is used
because its a full 16 bit, not just 8 bit.

The problem with ultrasonic sensors is that you have to compensate for the exact
trajectory (3 or 4 sensors needed at each sense-point), and the velocity affects the
geometry of the shock wave cone. broken-foil or broken-wire or optical sensing is
inherently more accurate (but requires accurate alignment).

Anyway you problem is not to read the velocity at each point, but the arrival time
at each point (many widely spaced sensors) so the time accuracy is less cricital, but
you will need to maintain synchronous clocks at each observation station (or send
the signals down long wires).

don't you mean 62.5 uS? seems like you are off by an order of 3...

Two sensors spaced moderately apart (1 ft - 1 meter) could assume that the bullets trajectory is parallel. It would also assume that the bullet speed is relatively constant and that the shock wave is the same... I would imagine a pairs of sensors approximately 1 ft apart separated at 10, 25, 50, or 100 yard intervals. Each sensor pair would have its own atmel chip and timing crystal and then it would relay the data, hopefully wirelessly, to my laptop for processing. Maybe a good use of xbee...

I just realized the chip is operating at 16 mHZ not 16 kHz. You were right.

Here is a good article I found on sonic booms:

I was thinking that most of the signal processing would be done from the sensor and output a TTL signal. I was thinking that an amplifier and filter with a zener diode and a rheostat and a transistor would be all I need to "clip" an acoustic pulse. From there I would be just looking at the times of the pulses.

I think the trick is detecting the bullet and not every other noise in the vicinity.

bronco9588:
don't you mean 62.5 uS? seems like you are off by an order of 3...

1 clock tick / 16 000 000 clock ticks per second * 1 000 000 000 nanoseconds per second = 62.5 nanoseconds

Yea... I corrected myself on the following post ;). I was assuming clock of 16 kHz.

I am still looking into this pulsein() function...

1. What is the sourcecode for this: clockCyclesToMicroseconds(width * 21 + 16)
2. How do they know that it is 21 clocks per the loop? If you look at the comments it says 20. Timing it really important and this would make me off by about 5%...