Arduino Chronograph. General guidance with hardware capabilities.

Using Arduino Project Guidance
#1

EDIT: Using the Due now. Adding a WeatherShield, accelerometer, magnetometer, thin film thermistor and TFT touchscreen and the software is spinning out of control. yay! Moving targets and design specs should not be the same thing.

I'm a novice in that I haven't done this stuff in 20 years and forgot a lot of it and what I did do was pretty simple stuff. Almost all of it has faded to one degree or another but the theory is still there and I'm still deeply involved in general computing in a professional capacity so I should be a quick study.

EDITED TOPIC

The emitter/sensor pack is going to prove troublesome due to a couple factors. 1, the distance between sensors cannot exceed 2.5" so the detection speed capability of those components will need to be very high. The sensor pack sits in a shaded area of very limited diameter and modest length (1/2" x 5") so interference from ambient sources should be minimal. The sensor/emitter pack also needs to be fairly blast/heat resistant. I have a way of shielding the components directly but the more blast shielding there is the more I have to limit sizes of the detector and emitter elements. They'll need to operate with high precision. The sensors will have about 5us of signal interruption to trip on and the time of flight between sensors could be as small as 5us depending on how far I end up having to space them, I'm trying to put them smack dab next to each other at abou 3/16" sensor-sensor distance. Ideally I'd like to be able to use 3 sensors total so that more complex functions like ballistic coefficient calculations can be done. That also requires either external data input or that I put temperature, pressure and humidity sensors on board and program for those which I don't plan on, so we'll stick with the idea of the 3rd sensor as an option not a requirement.

Another issue is which arduino to use. I bought the Due because I wanted to fiddle with it anyway but it's going to be a bit big for the final product unless I break it out into a wired up separate module. The electronics package for the final version has to be small, tiny, itty bitty. I'm wondering if the arduino nano might be capable of handling the requirements but from my math I don't know that it has the ability to run that fast.

The display seems to be an easy enough affair to deal with other than taking so many bloody inputs. Suggestions for minimizing that would be neat. I have a 20x4 standard backlit 44780 display that will be wire connected (about 3ft) to the controller. The controller will ideally reside in a housing that looks a lot like the evil child of a sound suppressor (silencer) and a muzzle brake which will also contain the sensors. It won't be a suppressor, it'll actually make the rifle seem louder. That said, if I can't get the nano size controller to work then it'll have to be done with a larger unit connected to the sensor housing via a cable (probably mini or micro USB or something similar).

I've bought several types of PIC microcontrollers and all sorts of bits and pieces and breadboards and have been toying around building blinking lights boards and other junk to get used to working with the stuff again. I've also seen lots of chronographs based on PIC's and that was my first option but I wanted to try it out with the arduino's as well... might be easier to package since I don't do PCB fab and would otherwise have had to have one made.

So, thoughts on component selections, microcontroller/board options, etc... Code isn't a worry for right now. I have a long feature list to build so I'll deal with that separately.

The velocities it'll have to measure will be anything from 5fps to 5000fps with a projectile from .4" to 2.5" in length of which 90% or greater is sufficient in size to obscure the emitter from the sensor as packed in the intended housing.

#2

I would start with links to your emitter/sensor pack. A short calculation shows that the fastest bullet needs about 40µs for the 2.5" of the measuring distance. If the accuracy doesn't have to be very high a Nano should be able to measure that, given the sensors are emitting a digital signal already and using the external interrupt input pins.

#3

You can reduce the display signal pin count to 2, either by using an I2C display such as http://uk.farnell.com/midas/mccog42005a6w-bnmlwi/lcd-cog-20x4-i2c-bstn-white-on/dp/2218946 or by using an ST7920-based graph display such as http://www.ebay.com/itm/128x64-LCD-Display-Module-ST7920-Blue-Backlight-Free-Shipping-/251245246537?pt=LH_DefaultDomain_0&hash=item3a7f623849.

To get the most accurate timing, I suggest you OR the outputs of the sensors together and feed the resulting signal to the ICP1 pin. Then you can capture the count in timer/counter 1 when the bullet passes each sensor, using an interrupt to read the first value before the second is captured. This gives you a resolution of 62.5ns using a standard 16MHz clock, or 50ns if you use a 20MHz clock.

#4

so far I've been hoping to be able use the Omron ee-sx1140 which I have a handful of on hand. I also have some random IR sensors and IR leds that came with an old kit for I don't even remember what. The form factor of the 1140's is ideal for the housing but I'm not sure they themselves are.

#5

The datasheet for those sensors gives rise and fall time of 4us with 100 ohm load. This is going to limit the timing accuracy. For more accurate results, you need a sensor with faster rise and fall times, which you can get from a sensor with a photodiode output instead of phototransistor output.

#6

PS - to get faster response, I think you will need to use a separate IR LED along with a photodiode-based detector such as this http://uk.farnell.com/optek-technology/opl551/photodiode-logic-o-p/dp/3167525, instead of an all-in-one unit.

EDIT: I just noticed that although that device has good rise and fall times, it has a long propagation delay, so it will still not be accurate. Better to use a PIN photodiode followed by a transistor or two to amplify the signal.

#7

Many thanks. I was afraid of that but it is exactly the info I needed. I'll have to order a handful of LED's and photodiode's and dive back into SketchUp and re-work the housing layout. The photodiode you pointed out is actually a lot more rugged than the omron deal so that's helpful too.

I'm looking at the BPW34. Whatcha think about that one?

#8

That photodiode has rather large rise and fall times (100ns), although it's measured with a higher load resistance (1K) than the usual 50 or 100 ohms. It might be faster with a lower load resistance. It's also a wide-angle device (130 degrees full angle) - is that what you want? I would have thought a narrow angle diode would be better for that application. Maybe something like http://www.farnell.com/datasheets/391095.pdf which has 4ns rise/fall times @ 50 ohms and 30 degrees full angle.

#9

Might want to look at the projectile sensor used with the Camera Axe for help. The sensor it uses has a 15ns fall time so looks like dc42's is even better.

#10

Where, on this forum, should I register my objection to it being used to discuss projects involving weapons?

...R

#11

Robin2:
Where, on this forum, should I register my objection to it being used to discuss projects involving weapons?

...R

..how about you DON'T try to force your agenda on others seeking technical advice?
His project is all about measuring the speed at which an object moves, it could be a rife, airsoft gun (oh no! a weapon!) or jelly beans thrown really hard. Why not just let people discuss technical issues without trying to force your "objections" on others and limit the conversations?

#12

Because too many people have been killed by stuff that has emerged from "scientists" pursuing interesting "technical issues" without bothering to consider that greedy, selfish and unscrupulous members of the human race (unfortunately there are a lot of them) later use to abuse the rights of their fellow humans.

...R

nd42x:
Why not just let people discuss technical issues without trying to force your "objections" on others and limit the conversations?

#13

Robin2:
Because too many people have been killed by stuff that has emerged from "scientists" pursuing interesting "technical issues" without bothering to consider that greedy, selfish and unscrupulous members of the human race (unfortunately there are a lot of them) later use to abuse the rights of their fellow humans.

...R

...sigh... nobody is talking about building an Arduino controlled gas chamber or anything here....
..anyway, it's obviously pointless to continue to discuss this issue with you so let's just drop it and we'll both hold our tongues.

BACK TO THE TOPIC AT HAND

So, back to the chronograph-- I myself have a Shooting Chrony (which is critical when you are interested in airgun tuning and customizations) and am interested in seeing how cheaply I can reproduce it's functionality and maybe increase it's functionality too-- it seems a bluetooth module and a iPhone or Android app as a remote display would be an ideal match.
..something like an "OpenChronograph" project sounds like a great idea.

#14

@OP: What accuracy/resolution do you expect from the device? The difference of a 15ns or 4ns raise/fall time is irrelevant if we're talking about an Arduino (even a Due) doing the measurement. You get an accuracy of up to about 1‰ of your speed range (with the 84MHz of a Due, about 1% with a Nano).

#15

Chagrin:
Might want to look at the projectile sensor used with the Camera Axe for help. The sensor it uses has a 15ns fall time so looks like dc42's is even better.

Thank you very much. 15ns isn't hideously long. If I'm doing my math right I should be looking for a sensor with a fall time under 8ns (that would provide me with .1% accuracy @5000fps with a sensor distance of .5". I'm happy to extend it to 1" (yes, 1 inch and I know I'm making it very very very small, for a reason) which will allow 16ns to make spec. The 4ns fall of the sensor dc42 recommended is exactly what I was looking for though as it will allow for accuracy exactly of the nature I need without getting into exotic components.

here's a bit of technical info: I need to have the sensors within extremely close proximity of each other so that muzzle flash and blast doesn't interfere with sensor readings in a way I can't filter out in software. Since the projectile path/tube is not substantially bigger in diameter than the projectile itself I am hopeful that the projectile itself will obstruct the photodiode with sufficient vigor as to trip the sensor for many ns and the flash and blast won't confuse it afterward. At 5000fps with a 1" long projectile, 1 inch sensor distance, and again if I'm doing the math right and not buggering up a decimal, I should get as much as 8300ns of sensor obstruction per sensor (wow there's a lot in a billion) which is plenty to measure against with high precision in a compact package provided the rise/fall times are super duper fast at 4ns. I should still get better than 1% accuracy, and since I'm shooting for .1% or better this is good.

I've ordered a handful of photodiodes as recommended by dc42. Thanks there.

I've also expanded the prototype phase of this to accomplish more of the ultimate design goal. I'm looking at incorporating a weathershield and a touchscreen so I can rid myself of a number of buttons and enhance the military applicability and overall packaging. The final version will use ballistics calculations to predict, store and trend shot data and using the onboard weather information and an externally read wind input to help put rounds on target and to track the way the rifle responds to wear and tear (using proprietary transfer functions developed over years) as well as ambient weather conditions. I need to work out one more analog thermal sensor which will detect barrel temperature and that'll be that as far as the sensors go.

I've spent the 70 bucks, 20 of which is shipping, on the Weather Shield for Arduino-   Shield for Arduino to measure and display on the.

Could anyone tell me if http://dx.com/p/arduino-compatible-2-4-tft-lcd-screen-touch-sensor-module-with-touch-pen-blue-145082 is compatible. I've been reading so much online about people having problems with 2.4" TFT ts's and I don't want to spend twice on too many more parts for the prototype. Also so far all of the touch screen's I've seen hang off the edge of the arduino instead of sitting directly over it. I'll need it to sit directly over the arduino otherwise the whole packaging aspect will fail and I'll have to externalize the display from the compute chassis and have 3 major pieces to the setup instead of just 2.

Moderator edit: I cleaned this up. Next time, it goes in the bin. AWOL

#16

Keep it civil people.
You can (aka "will") go back and edit your posts, or the whole lot goes in the bin

#17

I would also like to incporporate https://www.loveelectronics.co.uk/products/140/3-axis-magnetometer---hmc5883-breakout-board and https://www.loveelectronics.co.uk/products/217/3-axis-accelerometer---adxl345-breakout-board-v2

#18

5000 feet/sec = 416.67 in/sec x 1sec/1,000,000,000nS x 62.5nS/clock cycle = 0.26microinch/clock cycle.
Or, flipping that over, 38,400 clock cycles/inch.
Seems like enough cycles to do something.

#19

CrossRoads:
5000 feet/sec = 416.67 in/sec x 1sec/1,000,000,000nS x 62.5nS/clock cycle = 0.26microinch/clock cycle.
Or, flipping that over, 38,400 clock cycles/inch.
Seems like enough cycles to do something.

416 inches in 5000 feet? Goofy :slight_smile:

5000 feet/sec = 60000 in/sec x 1sec/1,000,000,000nS x 62.5nS/clock cycle = .00375 inch/clock cycle or 266 clock cycles/inch.

#20

Ack, you're right, divided by 12 instead of multiplied by 12.
Well, that's a few less clock cycles to play with.