Time difference between multi microphones


I am looking for a method to find the time difference between multiple microphones.

I must have time difference close down to 1x microsecond. (soundrange 0.3 mm)

It is used in a sound ranging – where is the sound coming from and hove far ago.

My experiments provide a time stem in a loop is not sufficiently – it gives me wrong reading from 60 microsecond and up. Those methods do not detect the rising ramp who I think will give a better sufficiently.

The code that you have the red arrow leading from does not produce the output that the red arrow points to.

Post ALL of your code AS TEXT and your serial output AS TEXT.

I have to wonder why you are timing how long it takes to read anywhere from 3 to 6 digital pins, when what is connected to them are analog devices.

What's your input device and test signal (ping, sine)?

I'd suggest some cross-correlation algorithm, but an Arduino and its ADC may be too slow for that job.

Unfortunately you can't get 1µs resolution from the micros() command. It counts in 4µs 'ticks'.


My code is not finish yet – so it will not give the completed understanding – and all comment is in Norwegian. But you can get it if it is interesting.

I know a UNO at 16MHz give 4 µs ticks – but if I use an DUE at 84 MHz ore whit code for low-level reading.

My problem is how to read all microphones at the same time and give timestamp when the sound is coming to it – I wile like to looking for raising ramp instead to do sjeck in a loop.

My problem is how to read all microphones at the same time and give timestamp when the sound is coming to it -

There are [u]port commands[/u] but I'm not sure how they work on the Due. (I assume you can read a 32-bit port on the Due in assembly/machine language).

I wile like to looking for raising ramp instead to do sjeck in a loop.

There is only one multiplexed ADC so I don't think you can really read multiple analog pins at the same time (unless there's an analog sample-and-hold).

You can use a multiple input ADC to capture 8 mic's at once, and go from there: http://www.digikey.com/product-detail/en/analog-devices-inc/AD7761BSTZ/AD7761BSTZ-ND/6072261

What is your project? Microphones with a response beyond 1MHz are not common - and the arduino's A/D is far too slow.

The only sonic application I can think of needing such technology is ultrasonic crack detection - and they use an excitation signal of many MHz, and special piezo microphones.

If that's the area, the arduino can't help you - you need much faster custom hardware to do it.




My project is detection of a hit point from a gun by using sound from the bullet.

It is a “electronic target system” – just for hobbies.

When i place 3 (or more) microphones in line with known distains – i can mathematical find the hit point. I need exactly timestamp when the sound hits those tree microphones.

If I can read rising ramp from microphone with less than 3 microsecond – I find the hit point with 1 mm preciseness – and this is enough.

And I think it is better to use digital input for microphones – it is much faster.

If you want to determine the position of the gun, from the bang of the shot, this will be possible. But for the hit point, what sound do you expect from the flying bullet, and from the target?

I think your maths is out of whack…and concept for that matter.

You will need a “mast” of these in a X configuration.

The microphones could not tell if shot was from infront or behind them…it would be a mirror image.

You need to lines crossing to determine the actual location as opposed to the displacement.

Which gun fired the shot? Could three microphones tell?


Having a third z axis will allow absolute positioning.



Most of bullet has speed higher then sound – therefore is der a subsonic sound around a bullet.

How I am calculating the hit point (in Norwegian)

Eksempel på beregning

I dette eksemplet måler vi lydbølgen først på M2.
Dernest treffer lydbølgen M3 og til slutt M1.
For å finne en ∆ kan vi benytte følgende formel
∆ = asin⁡〖(A-B)/b〗
(b er avstand mellom M2 og M3 = 300 mm)
Dersom lydtid: (c = 340 m/s = 0.34 mm/ys)
M2 = 0 (den første mic som lyden treffer)
M3 = 180 ys => 60 mm
M1 = 510 ys => 170 mm

Vi får følgende ligning for vinkelen i N1 og N2.
∆N1 = asin(M1-M2)/((Lm1-m2) ) = asin170/300 = 34,5 ̊
(Dette er vinkelen mot den loddrette linjen over N1. For å finne vinkel mot bunnlinjen må denne summeres med 90 som er en rett vinkel)
∆N2 = asin(M2-M3)/(Lm2-m3) = asin(-60)/300 = - 11,5 ̊
∆M2 = asin(M1-M3)/(Lm1-m3) = asin110/600 = 10,5 ̊

Virtuell trekant
Nå har vi en trekant (N1 – N2 – T) hvor linjen N1 – N2 er kjent (300 mm).
På samme måte er vinklene i N1 og N2 kjente.
Foreløpig har vi funnet vinkelen mot en loddrett strek hvor positiv vinkel er på høyre side. Nå skal vinkelen N1 og N2 endres til å være inni den virtuelle trekanten vi har konstruert.

∆N1v = 90 - ∆N1 = 90 – 34,5 = 55,5 ̊
∆N2v = 90 + ∆N2 = 90 + (-11,5) = 78,5 ̊
∆M2v = 90 + ∆M2 = 90 - 10,5 = 79,5 ̊

∆Tv = 180-∆N1v-∆N2v = 180 – 55,5 – 78,5 = 46 ̊
∆T mot M2 vil være ∆Tv/2 = 23 ̊

Nå vil avstanden M2 – T (r) framkomme gjennom formelen.
r/(Sin N2v) = (Ln2-m2)/(Sin T) = (Lt-n2)/(Sin M2v)

r = ((Ln2-m2)Sin N2v)/(Sin T) = (150Sin 78,5)/(Sin 23) = (150* 0,9799)/0,390 = 376,88 med mer

Yes...this is wonderful but comes with 2 prerequisites...

  1. The gun is shot in a parallel plane to the sensor array (the same height as).
  2. The gun is always shot on one side of the array.


  • dose microphone most bee on one side of a target.

  • It is not necessary to bi in same plan.

Now – hove can I find the best timestamp for those microphones?

I wouldn't think that much more would be required of this project than a few piezo discs (Knock tutorial) and and a Due since it's capable of interrupts on more than two pins. I'd only expect a little bit of tweaking of the resistor used with the piezo would be required.

I'm interested in this problem, too, since a friend wants to build an electronic biathlon scoring system.

Chagrin: piezo discs...and a Due since it's capable of interrupts on more than two pins...

This seems like a promising approach. But wouldn't the approximately 4 us interrupt latency per ISR call possibly cause some interrupts to be missed, unless the PIOA_Handler is re-written? I guess that might depend on the time signature of the piezos - how long they stay high.

The problem and a possible solution, from post #1 here:

The problem is that this routine always loops over all 32 pins of the PORT which actually keeps the processor busy for about 4us (measured) every time an interrupt on a pin is triggered. The delay for the ISR to be called actually depends on which position the pin is on the corresponding PORT. For example your chosen pin number 6 is on PORT C at position 24. This means that the loop scans over pins 1 to 23 first before "finding" your interrupt. The according latency is about 24/32 * 4us = 3us, consistent with what you have measured.

If you want to speed up the latency you can simply use a pin that is at a lower position of any of the PORTs A,B,C or D of the DUE. By choosing for example pin 26 (corresponding to position 1 of PORT D) your latency will be as small as about 150ns. However this will not circumvent the problem that your processor will be busy for 4us without being able of handling other interrupts. If this is a problem for your application you have to recode the part in the "WInterrupts.c" to make it more efficient (for example getting rid of the loop over all pins and only looping over those you have already defined an interrupt for).

A related post with code that might work.

Possibly an even better/faster solution with a Teensy.

Maybe having an op amp with sample-and-hold for each input could eliminate missed interrupts. Still might have up to 4 us per sensor error...which could put the bullet location off more than 1 mm.

You seem to start at the wrong end of the rope. Take a digital scope sample of a shot, containing the (assumed) sound of the bullet, and the sound of the shot. Then find out about the sampling and post processing of this signal, before you start computing positions.