microphone array

what I have done is so far is getting e max and min voltage and also e average voltage of the right microphone and also the left.on top of that, i have also implement an interrupt so when my led is turn on, it rises and e timer start counting and fall when my led turns off so will e timer stop. is it possible to get e distance with e value of the timer. I used this functions to get my distance but It doesn’t seem precise…so what should implement to get the distance .?or issit my time which is wrong.?i’m not sure.need some help, thank you for all ur help.im trying to get e distance so that I can get the imaginary and real to calculate the phase.this is wat I am trying to achieve.thank you again for e great help.

You are working on a time critical problem, the time of arrival difference between sounds on the left and right microphone. Yet you are using ‘tardy’ code at several places.

First, you are using floating point calculations almost everywhere. I don’t know which microprocessor you are using here, but it is likely that is doesn’t have an FPU in it. So it needs to do the extra code emulation work with integer based calculations. Since the timers and ADC values are integer based anyway, why not do all intermediate calculations in the integer domain, and only convert to floating point representation at the final moment. If you really need it to be shown as what seems to be voltages (I suspect due to the numerous 3.3 references.)

Second, each call to right (and max is > 1.8 ) or to left (for left: min <1.65 condition printf is commented out) you perform a printf statement . I don’t know exactly where you are outputting this to, but I suspect it works out as a quite long delay for your program. Especially if this turns out to be a serial port. Byte duration = 10/baud seconds. Just multiply it by the number of bytes sent.

Valen:
You are working on a time critical problem, the time of arrival difference between sounds on the left and right microphone. Yet you are using ‘tardy’ code at several places.

First, you are using floating point calculations almost everywhere. I don’t know which microprocessor you are using here, but it is likely that is doesn’t have an FPU in it. So it needs to do the extra code emulation work with integer based calculations. Since the timers and ADC values are integer based anyway, why not do all intermediate calculations in the integer domain, and only convert to floating point representation at the final moment. If you really need it to be shown as what seems to be voltages (I suspect due to the numerous 3.3 references.)

Second, each call to right (and max is > 1.8 ) or to left (for left: min <1.65 condition printf is commented out) you perform a printf statement . I don’t know exactly where you are outputting this to, but I suspect it works out as a quite long delay for your program. Especially if this turns out to be a serial port. Byte duration = 10/baud seconds. Just multiply it by the number of bytes sent.

yes definitely true it is a time critical problem.i’m having problems with that, my time is bigger than expected.sorry about the tardy code,i’ll take that as an advice.i’m using lpc1768 mbed. i am using an led as my interrupt.i connect an external led with resistor and connect it to their interrupt pin.the adc input is always jumping up and down to very low noises.so i put a condition where if it is above a certain value than the led will be on.so that means if my voice is larger than 1.8v than it will interrupt.so how do i improve the timing.?and i don’t understand what u meant by the byte duration.

farisabdat:

i’m using lpc1768 mbed.

so how do i improve the timing.?and i don’t understand what u meant by the byte duration.

Ok, so that lpc1768 mbed is just a Arm Cortex processor on a pcb. It doesn’t have a screen output, or some form of file-storage on sd card or whatever. But it does have a USB connection so those printf statements are probably going to a serial port. Though I do not see any code statements setting up the serial connection. Is this perhaps done automatically in other included files?

Whatever you have the baudrate set to, this means that the serial data is sent at a certain bitrate. The baudsetting= bits per second. As each character you send is a byte in size (8 bits), and each byte also has a start-bit in front and a stop bit at the end, it takes 10 bits to send a byte over the serial port. (more if parity bit and 2nd stop bit is enabled) So that is why I said sending a byte over serial means it takes at least the time equal to baudrate/10 bits. If you also send a carriage-return and a line-feed symbol with the printf statements, the \n\r (equivalent to hitting the Enter-key) this adds 2 extra bytes to the string of text you want to send. So count the number of bytes you are sending. Multiply by 10/baudrate and you have time in seconds that it takes to send the string with printf. This is then the delay caused by sending over serial that your program has to wait for it to finish.

I had another look at your code. Aside from what I already said about delays, you have a bigger issue. Your left and right functions are processing chunks of analog samples after each other. First right is sampling 100 times, then does some calculations on it and sends the result with printf statement. Then left does the same. But those are not taken at approximately the same time. So you cannot compare the soundlevels of incomming pulses that way. You must find a way to do this sampling in semi-parallel, one sample at a time for each after the other side. Since your left and right functions are basically checking for the maximum, minimum and calculates some sort of average value from it you can do this incrementally with each new sample. No need to do this in large chunks. For the average you might want to consider using exponential moving average. Then you only need the current sample and the last value of the average.

http://en.wikipedia.org/wiki/Moving_average

Valen:

farisabdat:

Whatever you have the baudrate set to, this means that the serial data is sent at a certain bitrate. The baudsetting= bits per second. As each character you send is a byte in size (8 bits), and each byte also has a start-bit in front and a stop bit at the end, it takes 10 bits to send a byte over the serial port. (more if parity bit and 2nd stop bit is enabled) So that is why I said sending a byte over serial means it takes at least the time equal to baudrate/10 bits. If you also send a carriage-return and a line-feed symbol with the printf statements, the \n\r (equivalent to hitting the Enter-key) this adds 2 extra bytes to the string of text you want to send. So count the number of bytes you are sending. Multiply by 10/baudrate and you have time in seconds that it takes to send the string with printf. This is then the delay caused by sending over serial that your program has to wait for it to finish.

I had another look at your code. Aside from what I already said about delays, you have a bigger issue. Your left and right functions are processing chunks of analog samples after each other. First right is sampling 100 times, then does some calculations on it and sends the result with printf statement. Then left does the same. But those are not taken at approximately the same time. So you cannot compare the soundlevels of incomming pulses that way. You must find a way to do this sampling in semi-parallel, one sample at a time for each after the other side. Since your left and right functions are basically checking for the maximum, minimum and calculates some sort of average value from it you can do this incrementally with each new sample. No need to do this in large chunks. For the average you might want to consider using exponential moving average. Then you only need the current sample and the last value of the average.

i didn't set any baudrate at all.i assume its the default.so i take the t.read() minus e time it takes to send the string.am i right?when u said semi parallel did u mean i have to run right function first den the left function.?and my last question is, i have to do my right and left function so it will only return the max and min only right.?

farisabdat:
i didn’t set any baudrate at all.i assume its the default.

Ok, time to find out what it is. Did you see these prints on a serial terminal somehow? If so, then that also would have needed to be set up with the same baudrate settings. Even if it is default it is easy to check.

Then so i take the t.read() minus e time it takes to send the string.

No you are missing the point. Don’t correct the timing value! It’s not important, I just want to show you that it is like an age and a century from the point of view of the microcontroller. Make sure you are recording the pulses on the left and right at the same time. The ADC probably can only sample one input at a time, so you need to alternate between left and right. You are missing the pulse on the other side because the micro is doing the chunk recording, float computation and serial printf stuff instead. What the latest-called function is recording is some other audio pulse thing than what the first called function was recording. Echos maybe. It’s from a entirely different time period.

when u said semi parallel did u mean i have to run right function first den the left function.?and my last question is, i have to do my right and left function so it will only return the max and min only right.?

You are already running the left function after the right function, and followed by right again due to the while loop. That is the problem. You have to come up with a function to do both things at the same time. Or as close as ‘at the same time’ as possible, alternate per sample. Which means first a sample of left, then of right, and left again, with as short delays as possible. I don’t know if that microprocessor can do multithreading or has multiple cores, but for a beginner that would be too complex anyway. So you have to do as minimal computations as possible per sample.

Have you even done some preliminary calculations on how much the sound pulse should arrive later at the other microphone? Maybe it is helpful if you first make a program that simply makes a recording of both the left and right channel microphone and stores this into an array and maybe dump this to the pc so you can look at it. Or maybe with an oscilloscope if you have it. See if this pulse delay actually shows in the data. Then you also get an idea if the samplerate and sample period is regular enough. (currently your sampling period is dependant on interupt delays and how long the max/min if-statements take) Then you have a timeline of data with which you can put yourself into the shoes of your microcontroller and process it yourself in the way the microcontroller sees it.

Valen:

farisabdat:
i didn’t set any baudrate at all.i assume its the default.

Ok, time to find out what it is. Did you see these prints on a serial terminal somehow? If so, then that also would have needed to be set up with the same baudrate settings. Even if it is default it is easy to check.

Then so i take the t.read() minus e time it takes to send the string.

No you are missing the point. Don’t correct the timing value! It’s not important, I just want to show you that it is like an age and a century from the point of view of the microcontroller. Make sure you are recording the pulses on the left and right at the same time. The ADC probably can only sample one input at a time, so you need to alternate between left and right. You are missing the pulse on the other side because the micro is doing the chunk recording, float computation and serial printf stuff instead. What the latest-called function is recording is some other audio pulse thing than what the first called function was recording. Echos maybe. It’s from a entirely different time period.

when u said semi parallel did u mean i have to run right function first den the left function.?and my last question is, i have to do my right and left function so it will only return the max and min only right.?

You are already running the left function after the right function, and followed by right again due to the while loop. That is the problem. You have to come up with a function to do both things at the same time. Or as close as ‘at the same time’ as possible, alternate per sample. Which means first a sample of left, then of right, and left again, with as short delays as possible. I don’t know if that microprocessor can do multithreading or has multiple cores, but for a beginner that would be too complex anyway. So you have to do as minimal computations as possible per sample.

Have you even done some preliminary calculations on how much the sound pulse should arrive later at the other microphone? Maybe it is helpful if you first make a program that simply makes a recording of both the left and right channel microphone and stores this into an array and maybe dump this to the pc so you can look at it. Or maybe with an oscilloscope if you have it. See if this pulse delay actually shows in the data. Then you also get an idea if the samplerate and sample period is regular enough. (currently your sampling period is dependant on interupt delays and how long the max/min if-statements take) Then you have a timeline of data with which you can put yourself into the shoes of your microcontroller and process it yourself in the way the microcontroller sees it.

yes.i have check its 9600.i guess i understand what u mean.so i have done some improvement.i haven done any preminary calculation on how much the sound pulse arrive..but my program to get the time is to check the time diff..eg. start timer when recieve sound on the right and stop when receive sound on the left.vice versa.can u roughly tell me how do i get the phase of the person.how the flow of the program should be like.thank you

farisabdat:
yes.i have check its 9600.

So that is 960 bytes per second. Or about a millisecond per byte or character. The sound travels about 34cm in this time. (twice the distance between your microphones if I understood your code correctly) Do you see now how this can cause major slowdowns in your code? Try to increase the baudrate. But it won’t solve your problems.

i guess i understand what u mean.so i have done some improvement.

I can see you have tried to regulate the sampling periods with the t timer. But you synchronise the sampling of left and right with a 60 milisecond sampling period (based on counting timer t). That comes down to 16.66 samples per second. That is far to slow to detect short sound pulse peaks. Wouldn’t you have more timing resolution with the read_us method to time in microseconds?

Here is a major bug in your code:

You are also setting and resetting the timer with the interrupt routines for left and right AND in the while loop. This is going to cause major chaos in the regularity of counting of the timer and any calculations that you derive from it, whenever an interrupt is triggered. You really need to use separate timers for those different kinds of timing. Your results will not make sense until you do.

And you are still making heavy use of floating point variables and calculations. Consider using the integer results of the FastAnalogIn and Timer classes,the max and min variables and left/right_results arrays. Only convert to float just before sending it with printf to the serial port.

And i haven done any preminary calculation on how much the sound pulse arrive…but my program to get the time is to check the time diff…eg. start timer when recieve sound on the right and stop when receive sound on the left.vice versa.

How can you know if the time difference that the program gives you is the correct one, and not due to some bug in your program?

can u roughly tell me how do i get the phase of the person.how the flow of the program should be like.thank you

I don’t know how a person relates to this sound pulse you are trying to record. You haven’t said anything about how the sound is detected or generated. Only that an interrupt triggers by a led somehow, and that this is representative of a voltage going above a certain volume level. You need to be more clear about the hardware side and how it interacts with the environment physically. Pictures, drawings, schematics please.

And I do not know what you mean with ‘a phase of a person’. Sine-waves of a certain frequency have a phase if they are starting before or after the moment which is considered t=0. But your sound pulses are a bunch of different frequencies comming in together. Each will have their own phase angle at a certain time. I don’t understand what you want in this context.

Valen:

farisabdat:
yes.i have check its 9600.

So that is 960 bytes per second. Or about a millisecond per byte or character. The sound travels about 34cm in this time. (twice the distance between your microphones if I understood your code correctly) Do you see now how this can cause major slowdowns in your code? Try to increase the baudrate. But it won’t solve your problems.

i guess i understand what u mean.so i have done some improvement.

I can see you have tried to regulate the sampling periods with the t timer. But you synchronise the sampling of left and right with a 60 milisecond sampling period (based on counting timer t). That comes down to 16.66 samples per second. That is far to slow to detect short sound pulse peaks. Wouldn’t you have more timing resolution with the read_us method to time in microseconds?

Here is a major bug in your code:

You are also setting and resetting the timer with the interrupt routines for left and right AND in the while loop. This is going to cause major chaos in the regularity of counting of the timer and any calculations that you derive from it, whenever an interrupt is triggered. You really need to use separate timers for those different kinds of timing. Your results will not make sense until you do.

And you are still making heavy use of floating point variables and calculations. Consider using the integer results of the FastAnalogIn and Timer classes,the max and min variables and left/right_results arrays. Only convert to float just before sending it with printf to the serial port.

And i haven done any preminary calculation on how much the sound pulse arrive…but my program to get the time is to check the time diff…eg. start timer when recieve sound on the right and stop when receive sound on the left.vice versa.

How can you know if the time difference that the program gives you is the correct one, and not due to some bug in your program?

can u roughly tell me how do i get the phase of the person.how the flow of the program should be like.thank you

I don’t know how a person relates to this sound pulse you are trying to record. You haven’t said anything about how the sound is detected or generated. Only that an interrupt triggers by a led somehow, and that this is representative of a voltage going above a certain volume level. You need to be more clear about the hardware side and how it interacts with the environment physically. Pictures, drawings, schematics please.

And I do not know what you mean with ‘a phase of a person’. Sine-waves of a certain frequency have a phase if they are starting before or after the moment which is considered t=0. But your sound pulses are a bunch of different frequencies comming in together. Each will have their own phase angle at a certain time. I don’t understand what you want in this context.

it seems impossible to get the sound localization with just two microphone. i've read some content and it seems like what i should be doing is to cross correlate the two signals.and signal should be as close as possible.please don't mind my while loop.it was on purpose.just trying with distance and sound max & min.but my correlate seems like i've done something wrong.hope u don't mind looking at it and tell me my error.i tried doing what u said regarding sample read_ms, but read_us is too small.what i am doing is basically, when someone speaks , the mic will receive a input and will calculate the angle of the speaker taking the centre as my 0 degree.here is the image of my project and the code.thank you

https://www.icloud.com/sharedalbum/#B0TGWZuqD0szF3H