Software output interpretation automation? Help with software interface.

[brewha]

OK, I really have no idea how to concisely ask this question as a title. So, hopefully what I got is enough to get the right people to open this thread. So, here’s the long version of the question:

I have a computer program that can analyze the sound of a passing object and use the doppler effect to determine the speed of the object. Basically (as I understand it), the sound of an object as it approaches is travelling at the speed of the object plus the speed of sound. The sound as it departs is travelling at the speed of sound minus the speed of the object. By analyzing the frequencies, you can get the speed of the object. Using this program, you open a 5-6 sec .wav file of the object approaching and departing, and the frequencies are outputted to a graph.

Well, here’s the problem. The approach and departure frequencies are displayed as a series of “S” shaped lines on a graph. The user must left click on the vertical point on the left side of any S and right click on the vertical point on the right side of the S. Then, the speed is displayed. Here’s what it looks like:
Screenshot

However, the lines are several pixels wide. Depending on where the user clicks on the lines, the speed can be off by several mph.

We’ve been using this software to determine the top speed of RC airplanes. And, during competitions, used it to determine the fastest plane. The problem is that analyzing the program takes time and the accuracy of the speed is very subject to human error.

The program is freeware and available to download on several websites, so I don’t believe that there is a copyright issue.

So, after all that, here’s my question. Is there anyway to automate the speed calculation. Is there someway to use this program to analyze the sound and another program to analyze the output?

If anyone is interested in messing with this, I can email you a copy of the file - just PM me.

Any thoughts? Answers? Questions?

[si_blakely]

I don’t do signal analysis, so this is a bit of a first approximation, but …

it is a tricky problem, and not easy to automate. You couldn’t use the software supplied, as far as I can see.

What the graph supplies is a frequency vs time analysis. The midpoints of each frequency shift should be the base frequency (as the source passes directly over the microphone, so no doppler effect). By selecting the Fa (frequency of approach) and Fr (frequency recede) you can calculate

Vm = Vs*(Fa-Fr)/(Fa+Fr) (Vs = velocity of sound)

To isolate Fa and Fr from a source file, find the midpoint (maximum input amplitude)
use a FFT on the midpoint to find the strongest amplitude frequency component
work in both directions from the midpoint to track the changing frequency (using FFT) until the minimum variations (Fa and Fr) are reached. I would probably use a moving average to do this.
pick your best Fa and Fr (around the midpoint) and calculate Vm. Remember that Vs is dependent on temperature and altitude etc.

Something like SciPy, SciLab or GNU Octave could probably do it pretty easily, with varying degrees of interactivity and output prettyness.

Si

[Napier]

I agree with si_blakely, mostly. There is another approach to consider: first, assume the frequencies are the most different at the ends of the sound, if the plane flies straight when it passes the microphone, because the angle between its path and its line of sight to the microphone is smallest at these times, and there is a cosine multiplier in there on the angle. And, try shifting a sample of these two sounds in time and time factor - that is, growing or shrinking one of them to match the other as well as shifting it earlier and later. This eliminates the need for fourier transforms and a middle sample, and works fine for a sound with lots of harmonics. I also suggest you don’t use FFT even if you do Fourier analysis. The Fast Fourier Transform is a calculation trick that saves steps but requires your sample length be an integer power of two, and computation is so fast today that regular Fourier transforms are practically as useable as the Fast algorithm.

About the lines - well, how about a step with WinDig or some other curve tracing program? These do things like figure a midpoint in the little road of dark pixels.

I use SAS for many things and would probably try it first, though whatever you’re used to is probably best.

[si_blakely]

@Napier

I agree with si_blakely, mostly.

Thanks. I hoped I was on the right track. I did think of finding the strongest frequency at the midpoint, applying a filter with Q set to a suitable range (you know how fast the planes are expected to go), then determining the midpoint from the frequency graph (point of inflection). Plenty of ways to skin a cat. But I didn’t think of

@Napier

… And, try shifting a sample of these two sounds in time and time factor - that is, growing or shrinking one of them to match the other as well as shifting it earlier and later. This eliminates the need for fourier transforms and a middle sample, and works fine for a sound with lots of harmonics.

Without finding the midpoint how can you be sure you have grabbed Fa and Fr at the same delta-time from the midpoint? (the math requires this to be true, and the waterfall graph shown makes it sort-of easy). Actually, I don’t know why the software does not let you select the midpoint, then dial in a width, sampling the frequency at both sides of the midline - it would be somewhat easier and maybe more accurate.

@Napier

I also suggest you don’t use FFT even if you do Fourier analysis. The Fast Fourier Transform is a calculation trick that saves steps but requires your sample length be an integer power of two, and computation is so fast today that regular Fourier transforms are practically as useable as the Fast algorithm.

Wiki disagrees on the sample size issue

@Wikipedia

The most well known FFT algorithms depend upon the factorization of N, but (contrary to popular misconception) there are FFTs with O(N log N) complexity for all N, even for prime N

so the speed advantage should be justified (compared to O(N[sup]2[/sup]) for FT). And the numerical analysis packages used above all support FFT, as opposed to FT, for speed.

@Napier

I use SAS for many things and would probably try it first, though whatever you’re used to is probably best.

Mathochist
using a piledriver to split a lentil is what I would call it.

Si

[Napier]

>Without finding the midpoint how can you be sure you have grabbed Fa and Fr at the same delta-time from the midpoint? (the math requires this to be true, and the waterfall graph shown makes it sort-of easy).
Why would samples equidistant from the midpoint be optimal? I think the further you could get from the midpoint and still hear the sound accurately, the better the sample, regardless of symmetry. Doesn’t the math speak more to the end limits, anyway?
I might be wrong about the Fast versus other algorithms on speed, but I do know that some packages build your dataset into the next larger 2^n dataset by appending zeros so as to use Fast, and I think that isn’t what most people intend. It seems a dumb way to do it, to me.

>using a piledriver to split a lentil

You wouldn’t be using Windows to write a few hundred words here, by any chance, would you? heh heh heh…

[si_blakely]

@Napier

Why would samples equidistant from the midpoint be optimal? I think the further you could get from the midpoint and still hear the sound accurately, the better the sample, regardless of symmetry. Doesn’t the math speak more to the end limits, anyway?

It took me a bit to think about this initially. In the simple equation I used above, the velocity terms are radial velocity. If the constant velocity source could pass directly through the microphone, the frequency/time graph would be discontinuous about the midpoint, with vertical lines for Fa and Fr. Of course, in the real world, the microphone will be on the ground and possibly offset, so there is a cos(theta) term. The further the source is from the microphone, the lower the impact of this term, getting near to 1, thus the near-vertical track with the curve at the midpoint. By choosing Fa and Fr round the midpoint (the source is at the same angle to the receiver coming and going), you assume that the cos(theta) terms are the same, and thus cancel out (of course, this is probably not true, but…). That is my theory, anyway.

@Napier

I might be wrong about the Fast versus other algorithms on speed, but I do know that some packages build your dataset into the next larger 2^n dataset by appending zeros so as to use Fast, and I think that isn’t what most people intend. It seems a dumb way to do it, to me.

I agree, padding data to fit the algorithm would be wrong. I guess if you are providing a fast routine as opposed to a general one you might do that, though.

@Napier

You wouldn’t be using Windows to write a few hundred words here, by any chance, would you? heh heh heh…

Yeah, I should just use a bootstrap keypad to poke ascii into a hand assembled tcp packet …

Si

[BigT]

if only your software were open source. It has to be making the calculation you need, just not displaying it in a form you want, right?

[Napier]

@si_blakely

…you assume that the cos(theta) terms are the same, and thus cancel out…

They won’t cancel, will they? In the limit where the plane is making a short flight perpendicular to your line of sight (and hearing), far away from you, the cos terms are zero, and there’s no Doppler shift at all. I think each cos term multiplies the frequency shift the same way, and it’s more like the abs(cos()) values get added together and then multiply your Doppler shift.

[brewha]

I thought this question had just faded off to pages unknown. Good thing I checked back. I don’t have the time to read the responses and (try to) intelligently respond right now. I just wanted you guys to know that I hadn’t abandoned the thread.

I’ll be back when I get a few minutes. Thanks for the responses.