Airsoft Sniper Forum banner

1 - 5 of 5 Posts

·
Registered
Joined
·
81 Posts
Discussion Starter · #1 ·
There have been many attempts to make chronographs for cheap (I originally didn't want to pay $80 for something I would use only a few times), but I have found a way to do and overdo the homemade chronograph.

After being inspired by Paintball/Ballistic Chronograph I decided to try and make my own chronograph and it was a lot more of an involved process that I expected, but I thought I might post this here if anyone wants to try and replicate this project (warning: this is a VERY involved process).

The first attempt I made involved 1" PVC pipe with rolled-up paper inside of it. I rolled the paper around an inner-barrel to better align the BB path with the sensor/emitter. Unfortunately, I have few pictures of this stage, but I used a set of IR photodiodes/LED's from Radioshack mounted to the PVC with hot glue. I drilled two holes as straight as possible through the PVC and paper tube (one for each sensor/emitter pair), but I would recommend putting a wooden dowel through the middle of the paper tube so it does not have such a bad exit hole. I wired up the sensors to a 3.5 mm audio jack (ground band to anodes, L & R to cathodes I think). Attach the IR led's up to a AA battery in parallel (most 5mm LED's take ~1.5 volts OK). Please note that this only works with a high-resolution audio recording device. Even a 192kHz-cabible audio port has an uncertainty of +/- 3fps @ 400 fps. This is a good method to get a ballpark for how hard your gun shoots, but it isn't great. Measure the distance (in audio samples) between the leading edge of the left and right spikes and, converting samples to seconds w/ sample number / samples per second (Hz), divide the distance between the two sensors by the time it takes to pass between them.


https://1drv.ms/i/s!Ale2EEp9AfB_8iIFggarzp4Ivxci

After not being satisfied with the amount of work required for each chrono reading and the precision issues, I decided to go one step deeper and hook the sensors up to an Arduino, but there's a problem with this (see tech Jargon #1)
The photodiode wouldn't work well as binary inputs because they weren't nearly fast enough so I moved onto another sensor option: Phototransistors.

At that time, I also decided to up the precision of the tube the sensors would be mounted on by 3d-printing it through Shapeways. This part would have tiny pin-holes for the sensors to look through and see the emitter and port holes so excess air volume would not accelerate the BB in the tube.

When I realised that I needed to use phototransistors, I found a really good IR LED/phototransistor pair that ran me about 40 cents a pair, much less than the 2.99 at radioshack per pair. I tested these sensors on a breadboard wired to an Arduino with my AEP and by golly, it worked! I hooked it up to an HD44780 display and got it to display the FPS after each shot.

I won't go in depth on how the code worked, but my only tip is to NOT try and count clock cycles of the assembly code, rather display the time between the front and rear sensor being broken and compare that with another timer (like a phone). Then, compare the two times and typically the Arduino timer will be VERY different from the other timer if it needs adjusting. Another tip is to use fast digital write explained here: https://www.arduino.cc/en/Reference/PortManipulation . (this directly uses the assembly instruction to access the pin state).

The next step was to ditch the breadboard and Arduino; I trusted that making my own PCB's using the toner transfer method would be a fairly straightforward endeavour. I could not have been more wrong. I was using a ski wax iron to transfer the toner at its highest temperature setting (it was at least 180°C) and could not get the toner to transfer properly. I could have purchased a laminator for this, but I decided to just find a service to make the PCB's for me. For about $20 total, I ordered 10 of my PCB's from Elecrow. The quality was great and shipping time was as expected. Here is where I actually have pictures (yay). Below is the fully assembled electrical design. For info on how to do use an Arduino microcontroller without the board it comes with, this is an intro guide: https://www.arduino.cc/en/Main/Standalone but keep in mind if you can use another Arduino to program the one on the breadboard like this: https://www.arduino.cc/en/Tutorial/ArduinoISP . For cost reasons, I went with the ATMEGA8A-AU. It is just like the Arduino, except with ¼ memory and a small package size. I would not recommend using ANY SMD/SMT components unless you have experience with them because it took me the better part of 2 hours to solder just the microcontroller on (pins that are .2mm wide).

Installing the bootloader and setting fuses to use the external 16MHz clock is a pain and is too much detail to get involved here, but make sure you do this or else you will have an inaccurate, imprecise chronograph.

There were several revisions to the tube design and a revision to the PCB design to deal with a fine-tune adjustment issue (see tech jargon #2) and the current device looks like this:


https://1drv.ms/i/s!Ale2EEp9AfB_8iQN_JY0PrBVm8jW


https://1drv.ms/i/s!Ale2EEp9AfB_8iOTds2Jrh_JWrme

HTML:
[MEDIA=youtube]DewLXf0vSS0[/MEDIA]
Note that the ROF mode is not working properly yet (30 RPS is kind of crazy for an AEP); Also, sorry for the bad lighting and focus. The camera was not cooperating very well.

Tech Jargon #1: Photodiodes work by building up a potential difference across the anode and cathode (effectively become a capacitor). This means to test if the sensor is tripped by a projectile, I must constantly be putting a potential difference across the sensor of 0V to charge the sensor. Afterwards, the sensor must be discharged by putting a potential difference of 1.5V across the pins and if current passes through and is sensed by the Digital IO of the Arduino, then the sensor is not tripped by a BB, otherwise, it is. This is not fast enough because the photodiode must be charged and discharged (which takes time).

Tech Jargon #2: A resistor setup in series with the two rheostat/LED lines in parallel causes issues. The reason for having the two rheostat/LED's in parallel is to allow fine tuning of the amount of light each sensor gets. These phototransistors build up a kind of "charge", so they should be getting just barely enough light for them to be tripped. If they get too much light, the BB will not break the light beam for long enough for the sensor to registered as tripped. The voltage drop across each leg in a parallel circuit must be equal to each other, and the voltage drop across the constant resistor follows Ohm's law (V=IR). So, if the current draw from one leg of the parallel circuit increases, the amount of current going through the resistor in series also goes up, and thus the voltage drop across it also goes up. This is a problem because the voltage drop across the whole circuit must be 5V and now the constant resistor's voltage drop is higher and the voltage drop across EACH parallel leg must be lower. The issues are seen when adjusting the rheostat on one leg affects the voltage across the other leg. Why have this resistor in series at all then? The answer is for safety. If the rheostat is set to ~0Ω, the LED would take the full 5V and burn out, but with this resistor, even if the rheostat is at ~0Ω, it won't be a huge problem. The key to not having the previous issue is to use a low resistance resistor (~50Ω is sufficiently low and still gives enough safety).

Overall, I am very happy with how this has turned out; there are still some issues to fix, but from a design standpoint, it is pretty good. I am still working on putting it in a proper enclosure because some of the connections are not super sturdy.

What do other people use for embedding video/pictures on this forum? Everything above is broken or not embedded! (Onedrive doesn't play nicely)
 

·
Registered
Joined
·
36 Posts
Honestly.. If you're in this deep.. Do everyone a favor and finish the last mile..
I would be super happy to get my hands on a chrono that offers more precision (+- 0.01 FPS) or even true +-0.1 fps (since all the commercial models leave me feeling like they just have that decimal point to seem precise, while being inaccurate), especially if it can be hooked to a PC via USB for outputting results (ie, make it super easy to input data to excel for numbers shenanigans). Mancraft had a beautiful chrono they use (seen in their v3 engine testing video) but the video has been taken down. :( Only info I got from them is its a custom made one for airgunners... super fast response, better accuracy...
 

·
Registered
Joined
·
81 Posts
Discussion Starter · #3 ·
I would love to make something that precise, but I am currently getting about +/- 1.5 FPS uncertainty and if I removed a timeout feature, I could get it down to about +/- 0.75 FPS uncertainty. Unfortunately, I would need a ~138MHz clock for +/-0.1 FPS uncertainty and 1.38GHz for +/- 0.01 uncertainty. I will explore other options for microcontrollers to try and find something with a higher clock speed ceiling, but beyond this point, I may also need to invest in better sensors and other components that are also quite expensive. I also have the issue of not having a rifle that shoots a super consistent FPS to test it on. All I have is the theoretical precision.

Right now, each unit BOM cost is about $30, but may decrease if I order in bulk. Some of these corners that I cut (like a low-resolution display and few features) were to keep the precision high and the cost low.

I'm not a veteran airsofter, so I don't know whether more than +/- .5 FPS Uncertainty is meaningful.
 

·
Registered
Joined
·
81 Posts
Discussion Starter · #4 ·
After doing a bit more math, I have determined that with the current hardware I have, I might be able to get down to a +/- 0.52 FPS uncertainty @500FPS. Note that uncertainty goes up as speed goes up, though.

If I switch to another microcontroller and redesign the circuit board slightly, I may be able to get uncertainty theoretically down to +/- 0.173 FPS @500FPS, but at this point, I do not know if the sensors' uncertainty will make this precision meaningless. Again, my rifle is not consistent enough to measure that precisely.
 

·
Registered
Joined
·
81 Posts
Discussion Starter · #5 ·
I tested the chronograph at different FPS's and it seems like 485 is the FPS cap right now. Anything faster will not register as a shot. I am looking into methods and sensors to improve this, but the timer currently has a resolution of 5x10^-7 seconds (+/-0.75 FPS @500 fps theoretical). I think the sensors will need to be upgraded for a higher cap since the theoretical cap is at least 6000 fps.
 
1 - 5 of 5 Posts
Top