Cash for Code

Electronics Computer Programming Q&A
User avatar
jwax
Posts: 2234
Joined: Mon Feb 09, 2004 1:01 am
Location: NY
Contact:

Cash for Code

Post by jwax »

I'm looking for somebody to write code for an Arduino/DigitShield project.
Ever notice some people write it like it was English, and some people (me), stumble around with it, never learning enough of it to write a program? Thus, this offer.
I have a project, and after hearing how simple it is, let me know how much cash it will take for creating a rather simple program to do what I need.
Please, serious coders only! PM me for the details.
Moderator may move this if it is in the wrong Discussion Area.
Thanks!
John
WA2RBA
cae2100
Posts: 67
Joined: Tue Dec 18, 2012 4:40 pm
Contact:

Re: Cash for Code

Post by cae2100 »

why not just post what your after and someone will probably just post the code up for you, no needing to pay, or they will help you out to point you in the right direction.
User avatar
jwax
Posts: 2234
Joined: Mon Feb 09, 2004 1:01 am
Location: NY
Contact:

Re: Cash for Code

Post by jwax »

OK, here goes:
AUDIO CHRONOMETER-
(Based on an Arduino Uno and the DigitShield)*
This device displays the velocity of a projectile from its acoustic signature of firing and hitting an audible target. There are two sound pulses; the shot, and the sound of the target hit. The Chronometers microphone is placed equidistant between the shooter and the target. It detects the two sounds, and converts them to “HIGH” (5 volts) signal pulses to the Arduino Uno. Then the processor computes, from the speed of sound and the known distances, the velocity of the projectile. This velocity is displayed for ten seconds, at which time, the system automatically resets.
It is essentially, an Up Counter. The first pulse (the shot) starts a timer and the second pulse (the target hit) stops the timer. From the elapsed time, the program computes and displays the velocity.
For velocities of 100 ft/sec to 1,000 ft/sec., an expected time interval range would be 0.030 sec to 0.330 second. Using the speed of sound as 1126 ft/sec (343.2 meters/sec).
The program should be written such that distances can be easily changed for different applications, but let’s start with 10 meters gun-to-target distance.
(Microphone placed at the 5 meter mark)

*Arduino Uno info: https://www.arduino.cc/en/Main/ArduinoBoardUno
Digit Shield info: https://nootropicdesign.com/digitshield/

Glad to answer any questions, or listen to comments/ideas on this project!
Thanks!
John
WA2RBA
cae2100
Posts: 67
Joined: Tue Dec 18, 2012 4:40 pm
Contact:

Re: Cash for Code

Post by cae2100 »

just a quick glance on google, I saw a bunch of projects for the little cars and such, just use thier code but modify it slightly so the new numbers that it normally displays, just subtract the two and multiply it by 1126 to get speed in ft/sec or 343.2 m/s. Here's an example of the projects:
http://www.instructables.com/id/Arduino ... r-Racing-/
here is some more info on how to obtain timing and such.
http://tronixstuff.com/2011/06/22/tutor ... th-millis/

Another thing to look into, try looking at the code for arduino and the SR04 module, which is ultrasonic module. It works off of sending a pulse and counting in microseconds to recieve a pulse back, so those type of projects would help a bit on trying to figure out how to set up timing critical applications like your trying to achieve. Just modify it so the code triggers a timer when the first pulse is recieved, then count till second pulse, then rest is just simple math and displaying it on a screen.
User avatar
jwax
Posts: 2234
Joined: Mon Feb 09, 2004 1:01 am
Location: NY
Contact:

Re: Cash for Code

Post by jwax »

Thanks for that info, but pursuing the "how to" of coding and making it work for me is the laborious part of what I was trying to avoid. Call me lazy, but I'm hoping to have a programmer do that for me. I'm looking for a finished product here, and not so much as an educational project.
Appreciate your help, because I may just end up digging in here deeper than I intended!
WA2RBA
dyarker
Posts: 1917
Joined: Fri Aug 22, 2003 1:01 am
Location: Izmir, Turkiye; from Rochester, NY
Contact:

Re: Cash for Code

Post by dyarker »

I think the microphone does not need to be centered between shooting position and target position, but it makes the math easier. (A known distance from one end is needed.)

Quite a speed range. 100 ft/sec is like a baseball. A weak handgun around 700ft/sec, shotguns around 1200ft/sec, rifles 3000 ft/sec or more. What are you measuring under 1000 ft/sec?

Cheers,
Dale Y
User avatar
jwax
Posts: 2234
Joined: Mon Feb 09, 2004 1:01 am
Location: NY
Contact:

Re: Cash for Code

Post by jwax »

Yes dyarker, "easier" is what I'm all about! :)
The projectile in question is a pellet from an airgun. There's a number of reasons why the pellet velocity drops, and is sometimes unknown until after many shots have been made with a defective gun. Some are compressed air powered, some liquid carbon dioxide, so a defective (leaky) seal may result in pellet velocity becoming erratic, or slowly decreasing without the shooter being aware of it.
A passive chronometer will allow the shooter to see the velocity of each shot and detect problems early.
WA2RBA
User avatar
CeaSaR
Posts: 1949
Joined: Sat Nov 08, 2003 1:01 am
Location: Phoenixville, PA USA
Contact:

Re: Cash for Code

Post by CeaSaR »

John,

1 thing to think about when using audio pickups as a source for a trigger is the spurious sound from the environment can initiate false positives, making the event start and stop times suspect. Using just one microphone placed equidistant means that it would have to be fairly sensitive in order to hear the muzzle report and the target hit unless you develop a software sound envelope filter that is restrictive enough yet broad enough to reliably capture both sounds. I know it can be done, but don't ask me how.

My solution would be a two microphone setup, one at each end, with equal length cables. You could feed them into a small adjustable preamp that would set the sensitivity of the microphones. You only need one output that would then feed the "counter" the pulses needed. This way, the hardware can perform the filtering and all the software needs to do is calculate and display.

But that's just me. :grin:

CeaSaR
Hey, what do I know?
User avatar
jwax
Posts: 2234
Joined: Mon Feb 09, 2004 1:01 am
Location: NY
Contact:

Re: Cash for Code

Post by jwax »

True CeaSaR, but in the normal training environment, sounds are usually just the shot and the clang.
It's boringly quiet, or should be anyway.
To your point, the conversion of analog pulse to digital pulse is not trivial. There may be some triggering issues down the road that won't show up until the prototype is operational.
Thanks!
John
WA2RBA
User avatar
Lenp
Posts: 1529
Joined: Thu Oct 26, 2006 8:11 pm
Location: Maryland
Contact:

Dropping my dime in the hat! / Cash for Code

Post by Lenp »

Keep in mind, this is a round trip ticket. With a single mic, at the shooters location, the shot fired, is the outbound trip, then the returned sound of the target hit is the trip back. Each part of the trip will be at different speeds; the return trip time, because of the known speed of sound is calculated once, based on the distance, only needing change if the distance or physics changes!

The shot time is what is of interest but because only the whole trip is being measured, the sound return time must be deducted from the overall time. What is left then is the shot time, and that velocity can be calculated since we now know the distance and time.

A mid-point microphone requires all the above, but there is now one extra trip. The trip, from the fired shot to the microphone must be considered and then all the rest must still be done. Is there profit in that? I think not except perhaps some microphone sensitivity changes because they are midway.

Along with the possible incidental noise, wind, other environmental issues could bring a wider margin of error and reliability into the mix.

Ideally, two microphones, one at the shooter location and one at the target, practically eliminates the sound delays since the proximity of the microphones makes this a small error. One measurement for the time, from the sound of the shot fired until the target is hit, plus the calculation yields the velocity. The microphone's wire length is also unimportant since I still believe the speed of the electrical signals is still a bit faster than the fired shot.

In addition, the two microphones, being closer to their sound sources would allow amplification with less gain, reducing incident noise issues. All the processor needs from the two microphones is a simple logic signal, for the timer start/stop. Converting that audio signal to a digital input should be as simple as a transistor switch!

And If I'm wrong....please let me know :sad:
Len

“To invent, you need a good imagination and a big pile of junk.” (T. Edison)
"I must be on the way to success since I already have the junk". (Me)
User avatar
CeaSaR
Posts: 1949
Joined: Sat Nov 08, 2003 1:01 am
Location: Phoenixville, PA USA
Contact:

Re: Cash for Code

Post by CeaSaR »

So this would be an indoor setup for "air rifles / pellet guns". That can make a single mic setup possible. The only concern I would have is that the muzzle report can vary widely with makes and models, and even sometimes within the same batch of model. It is possible to fashion a sound director to help focus the muzzle report toward the microphone. You could do the same for the target area, but if the targets are metallic, even a light hit should give a decent "ring".

While Len has a valid point, when you break it down, all you need to do is measure the time between report and ring if the mic is equidistant. This is because though there are theoretically 3 equal distances involved, only 2 count since the 1st initial distance from muzzle to mic gets partially cancelled out due to the return trip from the target (ie, only 2/3 of the total out and back distance is used).

So, the muzzle report starts the timing, and when the ring stops the timer, you'd need to disable the inputs immediately for a short duration (10 seconds? ) to do the calcs and display. That greatly reduces the chance for spurious noise affecting the timer.

Of course, you could verify that with a 2 mic setup.

The only reason I mentioned equal length cables is to keep wire resistance similar so that the mics would perform relatively equal unto themselves.

CeaSaR
Hey, what do I know?
User avatar
jwax
Posts: 2234
Joined: Mon Feb 09, 2004 1:01 am
Location: NY
Contact:

Re: Cash for Code

Post by jwax »

Agreed CeaSaR.
I have a simple analog circuit which produces a short 5 volt square pulse for every analog pulse from the microphone to trigger the Arduino. That consistency will help establish clean trigger start/stop times for measuring the transit time.
I can check the actual displayed velocity with an optical chronometer (the industry standard), and modify the code, if necessary.
Thanks!
WA2RBA
User avatar
jwax
Posts: 2234
Joined: Mon Feb 09, 2004 1:01 am
Location: NY
Contact:

Re: Cash for Code

Post by jwax »

Done deal. Had some help, and the new code works as desired! Thanks for all the inputs, guys!
WA2RBA
User avatar
CeaSaR
Posts: 1949
Joined: Sat Nov 08, 2003 1:01 am
Location: Phoenixville, PA USA
Contact:

Re: Cash for Code

Post by CeaSaR »

So, how does it compare to the chronograph? Real close I bet.

CeaSaR
Hey, what do I know?
User avatar
jwax
Posts: 2234
Joined: Mon Feb 09, 2004 1:01 am
Location: NY
Contact:

Re: Cash for Code

Post by jwax »

Have to mate it with the audio amp/pulse generator, and figure out gain and some pulse processing.
Acoustics are not as easy as it "sounds"! (see what I did there?) :grin:
WA2RBA
Post Reply

Who is online

Users browsing this forum: Ahrefs [Bot] and 6 guests