July 2007

You are currently browsing the monthly archive for July 2007.

Time to put the whole in a (I hope) great experimentation…

The first step is to validate the theory and the algorithm and its configuration. So first expected results is to determine ifwe’re able to know if the sound if coming from left, or right. In a second step, we’ll try to precisely know the angle.

1. Hardware

So, we first need to build two sound sensors. These are just LM386 base pre-amp for electret microphone. Here’s a little picture. It has been deisgned to be as smaller as possible. I’ll later add the complete diagrams and build instruction directly within the SirBot Project.

The sound sensors are connected to the mainboard, through a bread board. Not shown here, but during the experimentation, the mics are about 15cm distant from each other. Since we’re not going to measure angle, we don’t have to worry being inaccurate, what is important is this distance is greater than 2.75cm (see theory).

2. Software

The Jal program, as describe in part 2 (algorithm), will count the delay occurring when the sound will hit the first mic, then the second. It handles timeout if no sound could be detected with the second mic. Note there’s a delay occurring when data is available. Without this delay (see first experiment), there’s too much data, inconsistent and useless. The program is available here.

3. Attempt #1

The first experiment consists in:
  1. knocking 3 times near the left mic
  2. knocking 3 times between the mics
  3. knocking 3 times near the right mic
  4. knocking 3 times between the mics
  5. knocking 3 times near the left mic
In this experiment, no delay is occurring when data is available (sound localized). Plotting what the first and the second mic have received (shift with delay), this clearly shows all the expected peaks.

Looking deeply into the data also show there’s no consistent results. Given one peak, the program alternatively detects the sound coming from left, right, left, etc… Kind of saturation…This can be shown when plotting the delay: if the delay is positive, the sound is coming from the left, if negative, it’s coming from the right. We’re thus expecting a clear distribution above and below 0 (and a mix when the sound is centered). The following figure shows this distribution is far from what we’re expecting…

While I first thought about a bug in the jal program, worse a bug in the theory/algorithm, I then tried to add the delay…

4. Attempt #2

If this case, as soon as the data is available, the program sends the result and wait a little time. Thus, most of the sound wave is ignored, except the very first point, which what we need. Note this experiment consists in:

  1. knocking 3 times near the left mic
  2. knocking 3 times near the right mic
  3. knocking 3 times near the left mic
  4. knocking 3 times near the right mic

We clearly see the delay is alternatively positive (left) and negative (right) (point with delay = 0 is an artifact and should be ignored).

Knocking near the mic has been done so the sound wave is very narrow (with plastic pieces). The delay is long enough so the next time we’re acquiring data, that’ll be for the next knock. Now, with the same delay, knocking a glass (sound is resonating) doesn’t give the same results… (knocking 2 times near the left mic, then 2 times near the right one).

There’re still something to say… The two first peaks seems to come from the left (ignoring null delays), but for the two last peaks, it’s hard to say, even if the delay is more important when negative than when positive…

So… This costs me a *lot* of time, but results are interesting: if we’re waiting enough (but not too long) between data acquistions, we’re able to localize sound quite nicely… This delay is clearly important and depends on the type of sound waves we’re listening to.

Next, I’ll try to determine where the sound comes from, computing the angle.

In the previous part, we’ve been able to find a way to theoretically localize a sound in space: “the delay between the two mics gives a distance x, which is correlated to the angle the sound comes from, as x = d.sin(ß)”.OK. Now it’s time to get back to reality, and apply this. Several problems can occur:

  • the acquisition time may be too long
  • we cannot predict which microphone the sound will hit first
  • the delay between the mics may be too long… or too short
  • for some reason, one of the microphone may not record the sound

1. ADC acquisition time

We’re trying to measure (quite) precisely the delay which occur when a sound hits a microphone, then another. Since the speed of sound is ~ 343m/s @20°C, this delay can be very short. The distance between the microphone is obviously involved, but so is the analog-to-digital conversion acquisition time. We’ll name it tacq so it looks like a complicated variable, meaning we’re probably smart people.So, tacq corresponds to:

  •  the time the PIC uses to setup the ADC. With a 20MHz Xtal, that’s about 4.8µs (setup) + 10µs (delay) ~ 15µs
  • the ADC itself. We’re using low resolution ADC (8 bits) but let’s compute it for high resolution (10 bits), so we’ll get a max value. With a 20MHz Xtal, it costs 1.6µs per bit, so 10 * 1.6µs = 16µs. There’s also a need to wait a little time (Tad time, see specs) after the acquisition. It costs 1µs.
So the total is 15 + 16 + 1 = 32µs. Because we’re a little bit paranoid, we’re round this value to 40µs. So:
tacq ~ 40µs

2. Minimal distance between the microphones

In a “classic” scenario, a wave sound hits the first microphone, then the second. Neglecting the code managing this sequence, we need at least 2 * tacq = 80µs. That is,  the distance between the mics cannot be less than what gives this delay. But… in this scenario, we’re waiting the sound for hitting the first mic, but we actually don’t know what is the first, since the sound can come from anywhere. So:
  1. if a microphone detect a sound, we must check the second. The delay will give the distance, so the angle of the sound
  2. if a microphone didn’t detect any sound, we must switch the mics, and retry to step one.
From 1., this means, we’ll need 2 * tacq = 80µs. Using the speed of sound, this value corresponds to 80.10-6 * 343 = 0.02744m = 2.75cm. So the minimal distance between the microphones is:
dmin ~ 2.75cm
From 2., this means in the worst case, the witdh of sound wave must be at least:
Wmin ~ 80µs

3. Measuring the delay

Measuring the delay occuring when the sound hits the first microphone, then the second, can be done using PIC timers. The PIC 16F88 has several available timers. One interesting is timer1, which is a 16bits counter, the larger this PIC can offer. Using the internal clock as reference, the timer is incremented at Fosc/4 = 20MHz / 4 = 5MHz (every 2.10-7s = 0.2µs). Since it’s a 16bits timer, it can count 65536 * 0.2µs = 13107µs, which corresponds to ~ 4.5m.
dmax = 4.5m
2.75cm < d < 450cm

4. Borderline cases

Mostly due to the acquisition time, data and information can be loss. Particularly, beeing able to detect sound depends on the wave width:
  1. The wave’s width is large enough so acquisition can be done at least one time during the wave.
  2. The peak is too narrow, due to a too long acquisition time, we skip the information.
Note in case 1, the same information (“there is sound right now”) may be sent several times. Results may require an aggregation over a given period of time (need to define what is a peak).Assuming the width is large enough, there may also be problems while the sound hits the second microphone. Actually, the second one may even not receive a signal at all:

This case is closed the first one, and is related to the minimal width. Another case which could why the second mic didn’t receive a signal is related to the treshold. If mic1′s signal is closed to the threshold value, mic2 may not receive the signal as it could be considered as background noise:
So let’s summarize the whole:
  • the acquisition time is an important factor the get reliable results. Must use a max-speed Xtal, that is 20MHz.
  • the distance between the microphones can’t be randomly chosen. It’s between 3cm and 450cm. 10 or 15cm is good. If too long, the sound level may be to low when hitting the second mic.
  • there may be cases where information can be lost, due to the wave form (too narrow), to the fact we can’t know which mic the sound will hit first (this increase the required acquisition time since we may need to get 3 acquisition to get a result). Note, a possible optimization would say: “there’s a high probability that when a sound hits micA, the next sound may also hit the micA. So if micA is the first, keep it as the first for the next sound dectection”.
Those different points have to be tested and experienced in a “real-world” context. That’s what the next post will talk about…