I'm cooking up a project that involves using 4 microphones in a circular pattern to determine sound directionality. I've got the microphone amp circuit set up so that when it detects a noise above a pre-defined level, it produces a HIGH signal to the Arduino and remains high until reset by the controller. When the first high signal is detected, the Arduino times how long it takes for the other microphones to go high and then calculates the bearing of the sound based on that.
My calcs indicate that I need resolution of around 1us. The Atmega238 documentation says that the response time for interrupts is 4 clock ticks, which 250ns@16MHz, right about where I need it. But Googling around, people are saying it's actually more like 2-3us with software tweaking (15-20us without it). What causes the discrepancy and is it possible to run this project on my Uno?
I suspect you need to think beyond the simple response time of one interrupt. Presumably you need to do something when the interrupt occurs - such as record the time.
The value of micros() only increments in steps of 4 µsecs.
And even if you devise a more precise time system noting the time will itself take some time and that cannot be deferred until after the next interrupt happens.
I reckon you can get a response within 4 clock ticks for one interrupt, but not for a succession of them unless there is sufficient time between them to do the necessary time recording.
Raddy13:
My calcs indicate that I need resolution of around 1us.
That sounds fast. Speed of sound is about 340 m/s, or 34 cm per ms, or 0.034 cm per uS. Are your microphones really less than a millimetre apart? Is the response time of the microphones themselves consistent enough?
If you calculations are correct you'll need something faster than a Uno.
I wanted the sound bearing calculation to be accurate to within 1 degree, and there's only a 2.59us difference of the sound transit time at 89 degrees vs 90 degrees. I don't know if the microphones are fast enough to respond either (most datasheets don't include any transient response info), but the latched comparators I was looking at have a response in the range of 50ns.
Anyway, thank you for the responses, I'll have to see what else I can find out there. Thanks!
An arduino DUE is clocked at 84 Mhz, thus one tick = 11.9 ns. There is a timer called SysTick which counts down from 84000 to 0 in 1 ms and reloads repeatedly. You can get the actual count(time) with SysTick->VAL.
If you trigger a different interrupt for each of the 4 microphones (see attachinterrupt function), and you record time with SysTick->VAL in each interrupt, I suspect that you are done. You can also reduce the time you spend in an interrupt by using the attribute ((naked)) with very few assembler instructions.
I guess that a more sophisticated approach would be to use the Timer Counter Capture feature of the Timer Counter controller.
An Arduino Mega has a couple of timers, which can capture the time of an input signal at the processor clock frequency resolution. It only may become somewhat tricky to start all 4 timers at the same time, so that the captured times can be compared. For that purpose the common prescaler can be stopped until all counters are cleared, but this will also affect the system time keeping (T0). See description of the GTCCR register.
DrDiettrich:
The maximum signal frequency is limited by the code, that reads the captured times. If that code takes too long, it may miss signal transitions.
Hardware Input Capture eliminates any random delay, caused otherwise by polling or interrupt latency. This will become important with 4 independent signal sources, which otherwise can be handled only sequentially.
I don't know if this should be posted into a new thread, but I was thinking about it and I came up with a new strategy. Instead of having the Arduino count the time, what if each microphone/amp/comparator group also had an n-bit counter and clock? So when the microphone and comparator detect a noise above a certain threshold, it latches high and enables the counter. The counter records the clock ticks until all four comparators are latched high, and then a 4-input AND gate generates a reset signal to the comparators, which would stop the counters. The Arduino then reads the values from the counters (through a shift register?) and makes its calculation based on that, and then resets the counters. I've never used counters before so I'm not sure this is the proper application, but the datasheet indicates they would be fast enough for what I'm doing.
@DrDiettrich, thank you for that. I had never noticed it. And it seems to exist in the Atmega 328 as well - though it has only one Timer that works like that.
It's always nice to learn something new over breakfast.
If a sketch did back to back port reads for some period then data for all pins could be collected sub-microsecond until you ran out of ram to store it. With minimal processing you could start saving only after the first data arrives.
With interrupts, each one after the first has to wait until the one before is finished to be acted upon. Check the time it takes an interrupt that only collects micros() to actually run, it's a lot more than 4 cycles (interrupt overhead alone is more like 20 cycles) and that micros() delivers time with 4 usec granularity.
Sound moves at 340 m/s at standard temperature. It's slower in cooler air. You are trying for high accuracy, right?
340 m/s is 340 mm/ms is 0.34 mm/us. How far apart you set your mics goes a long way to how close you need to measure time differences.
If you set your mics in a line across the general direction the sound moves, the wavefront will strike some before others. That was used along with light data in WWII and since to determine where artillery fired at night was. I knew guys who did that in 1978 (more than 25 years ago, Classified runs out at 25 years) while my job collected different data, I'm not pulling this out of my butt or some book/magazine/blog. Those guys set up more than a couple of meters apart (I won't say how many except not close.) and they had light data to work with as well, but their electronics were not what you have today so hey you probably have a good chance with a meters wide mic array to get direction only. What you want is smaller scale but the speed of sound does not scale down with the distances.
The task might be easier with a fast circuit external to the controller board.
As light travels at 300,000km/s, the required circuitry for light is quite different from the one used for sound. But it's feasible, as GPS demonstrates nowadays with RF frequencies.
A phase shift between signals also can be detected by mixing the signals, and comparing the amplitudes. In case of a 180° (half period) shift the result will be zero (subtraction, extinction), and without a shift twice the input level (addition). But this approach requires a sharp filter, that lets pass only a single frequency, and that frequency must be part of the sound, of course. Else a mix of frequencies will cause headaches in the interpretation of the mixed signal levels.
Thanks for the calculations of the distances. With a 16MHz time base the measured time granularity will be about 62ns, so that differences of 5µm of distance can be detected. Provided that the amplifiers have such a precise phase linearity, and the comparators also react at the same levels. But this can be verified only after a prototype has been built and coded.
Light travels 300 meters per microsecond. What kind of resolution would you hope for?
At short range or slower timing it can be regarded as instant. A short flash can be used to effectively synchronize separated sound sensors.
Radio is just low frequency light.
But it should be possible to use light frequency to find distance with monochromatic light and a double-slit. The distance between bright bands along with light frequency and slit separation can back-calculate the distance from the double slit. Ask any physics teacher. A red led should do for light source, we used incandescent light with a red transparency sheet filter in class in 1973 and it worked fine.
Come to think of it, the same technique should work well with high frequency sound and wider slits.... or 1 slit with either light or sound and detect brightness or loudness of the diffused output.
