EmbeddedRelated.com
Forums
The 2024 Embedded Online Conference

C code for microphone in msp430?

Started by speedofsound1 May 3, 2015
Hey you guys, so I am working on a basic home security system and
basically constructing a home security system which will communicate with
an app with 4 sensors, sound (amplified microphone), movement(motion
sensor), door movement (accelerometer) and temperature (internally
attached in the msp430). Can you help me in incorporating the sound
detection with the microphone using adc? I used acc for the accelerometer
but I don't know if the code is the same for the sound detector. Can
anyone send me a sample code as to how to make the microphone detect the
sound and convert it to digital signal in order to trigger for sounds in a
close range?


---------------------------------------
Posted through http://www.EmbeddedRelated.com
On 5/3/2015 7:30 AM, speedofsound1 wrote:
> Hey you guys, so I am working on a basic home security system and > basically constructing a home security system which will communicate with > an app with 4 sensors, sound (amplified microphone), movement(motion > sensor), door movement (accelerometer) and temperature (internally > attached in the msp430). Can you help me in incorporating the sound > detection with the microphone using adc? I used acc for the accelerometer > but I don't know if the code is the same for the sound detector. Can > anyone send me a sample code as to how to make the microphone detect the > sound and convert it to digital signal in order to trigger for sounds in a > close range?
You have to decide the characteristic(s) of the sound in which you are interested. I.e., it is unlikely that the presence of *any* sound should result in an alarm indication -- there's always some background "noise", etc. Are you looking for *loudness* to be indicative of a problem? Or, very high pitch (like glass shattering)? Or, short, percussive (something breaking -- vs. a truck driving by)? etc. Unlike an accelerometer where you can assume "any motion above some low threshold" constitutes an "anomalous condition", you *expect* sound in your environment (unless you are locating the microphone INSIDE a large (essentially soundproof) *safe*!
>You have to decide the characteristic(s) of the sound in which you are >interested. > >I.e., it is unlikely that the presence of *any* sound should result in >an alarm indication -- there's always some background "noise", etc. >Are you looking for *loudness* to be indicative of a problem? Or, >very high pitch (like glass shattering)? Or, short, percussive >(something breaking -- vs. a truck driving by)? etc. > >Unlike an accelerometer where you can assume "any motion above some >low threshold" constitutes an "anomalous condition", you *expect* >sound in your environment (unless you are locating the microphone >INSIDE a large (essentially soundproof) *safe*!
Yes! the microphone will be situated inside a 3D printed plastic case (not soundproof though) I know about the background noise which was one of my main concerns, but let's say I want noises like incoming footsteps, door knocking, or door unbudge. I was thinking about this earlier too and I think it would be more convenient to make a program that records when someone breaks into the door and sends that recording to a third-party application, which would save me all the trouble about the background noise. Unfortunately, I got a microphone sensor without the specs and only a circuitry schematic, which will make it difficult to program my ADC registers. --------------------------------------- Posted through http://www.EmbeddedRelated.com
> Yes! the microphone will be situated inside a 3D printed plastic case (not > soundproof though) I know about the background noise which was one of my > main concerns, but let's say I want noises like incoming footsteps, door > knocking, or door unbudge. I was thinking about this earlier too and I > think it would be more convenient to make a program that records when > someone breaks into the door and sends that recording to a third-party > application, which would save me all the trouble about the background > noise. Unfortunately, I got a microphone sensor without the specs and only > a circuitry schematic, which will make it difficult to program my ADC > registers.
A mic is usually a sound energy to voltage transducer. I'll assume it is for my reply. The ADC will sample the mic voltage at a rate that can accurately reconstruct the sound environment based on your requirements (constant 8K SPS or higher I would imagine). You can use DSP to filter, enhance, compress, extract interesting features, etc. Ambient sound is usually complex and noisy. Finding the signal in the soundscape is challenging. Sending the recording upstream is simpler. JJS
On 5/6/2015 2:00 PM, speedofsound1 wrote:
>> You have to decide the characteristic(s) of the sound in which you are >> interested. >> >> I.e., it is unlikely that the presence of *any* sound should result in >> an alarm indication -- there's always some background "noise", etc. >> Are you looking for *loudness* to be indicative of a problem? Or, >> very high pitch (like glass shattering)? Or, short, percussive >> (something breaking -- vs. a truck driving by)? etc. >> >> Unlike an accelerometer where you can assume "any motion above some >> low threshold" constitutes an "anomalous condition", you *expect* >> sound in your environment (unless you are locating the microphone >> INSIDE a large (essentially soundproof) *safe*! > > Yes! the microphone will be situated inside a 3D printed plastic case (not > soundproof though) I know about the background noise which was one of my > main concerns, but let's say I want noises like incoming footsteps, door > knocking, or door unbudge. I was thinking about this earlier too and I > think it would be more convenient to make a program that records when > someone breaks into the door and sends that recording to a third-party > application, which would save me all the trouble about the background > noise. Unfortunately, I got a microphone sensor without the specs and only > a circuitry schematic, which will make it difficult to program my ADC > registers.
The only thing you need to be concerned about with the ADC is the level of the mic and the sample rate which depends on the frequencies you wish to record. The mic will likely need an amplifier to give a large enough signal for the ADC to sample with enough resolution. Overrange is also a problem. This will only be dealt with by experimenting with your sound source. I am not clear on how a third party app would do any better job than your own code unless you can find a "security system" app. Is there such a thing? -- Rick
On Wed, 06 May 2015 13:00:52 -0500, "speedofsound1"
<105552@EmbeddedRelated> wrote:

>... the microphone will be situated inside a 3D printed plastic case (not >soundproof though) I know about the background noise which was one of my >main concerns, but let's say I want noises like incoming footsteps, door >knocking, or door unbudge.
Detecting footsteps is probably unrealistic. Door knocking is possible, but the sound of knuckles on wood (or whatever) is very different from, e.g., the sound of a brass knocker. Apart from sonar transducers, microphones per se aren't much used in professional systems - their only routine use is to detect glass breaking, which is a sharp transient that is relatively easy to pick out. George
On 5/6/2015 11:00 AM, speedofsound1 wrote:
>> You have to decide the characteristic(s) of the sound in which you are >> interested. >> >> I.e., it is unlikely that the presence of *any* sound should result in >> an alarm indication -- there's always some background "noise", etc. >> Are you looking for *loudness* to be indicative of a problem? Or, >> very high pitch (like glass shattering)? Or, short, percussive >> (something breaking -- vs. a truck driving by)? etc. >> >> Unlike an accelerometer where you can assume "any motion above some >> low threshold" constitutes an "anomalous condition", you *expect* >> sound in your environment (unless you are locating the microphone >> INSIDE a large (essentially soundproof) *safe*! > > Yes! the microphone will be situated inside a 3D printed plastic case (not > soundproof though) I know about the background noise which was one of my > main concerns, but let's say I want noises like incoming footsteps, door > knocking, or door unbudge. I was thinking about this earlier too and I > think it would be more convenient to make a program that records when > someone breaks into the door and sends that recording to a third-party > application, which would save me all the trouble about the background > noise. Unfortunately, I got a microphone sensor without the specs and only > a circuitry schematic, which will make it difficult to program my ADC > registers.
You're still ignoring the complex nature of "sound" and how amazingly discriminating abilities of our (animal) auditory systems! I had a pull-chain in each of the bathrooms, here. The thinking being that you could pull on the chain (attached to a switch) to call for assistance ("Help! I've fallen and I can't get up!") This proved ineffective: you need many of them to cover the case where a person has fallen onto the floor and *can't* get up (or crawl to the nearest chain -- e.g., falling in the *tub* vs. falling by the washbasin, etc.). Instead, I've opted for a ceiling-mounted speaker with a coaxial microphone (just because it's easier to mount in that configuration). As it's a bathroom, there is always "significant" background noise: running water in the sink or shower, toilet flushes, exhaust fan, etc. So, you can't just set an arbitrary "level" and use that as a trigger event ("loud noise means distress"?). Instead, I just use a crude level detection scheme in an attempt to gauge the *current* background noise (sound) level. Any increases of "significant duration" (i.e., longer than a f*rt get the software's attention. Yet, I still don't use this to unconditionally "call an ambulance" (etc.). Instead, the "occupant" is queried (remember the "speaker"??) as to whether or not they are *calling* for assistance. I don't have to recognize speech (what if the occupant is a visiting guest whose voice I've never encountered before?). All I have to do is prompt: "Are you in distress? Grunt once for YES, twice for NO" (or similar). If there *seems* to be cause for alarm, I can automatically shut of the water (silencing the sink, shower and toilet, in a matter of moments) and repeat the query. [Eventually, I'll be able to shut off power to the exhaust fan, as well, to remove that source of noise] But, in this case, the sound that I am trying to detect is COOPERATING WITH ME. You, OTOH, are trying to detect something that inherently does NOT want to be heard! I.e., you have to take extra measures to draw the potential signal from the noise.
Hi George,

[I survived the trip... just barely!  :< ]

On 5/6/2015 11:55 AM, George Neuner wrote:
> On Wed, 06 May 2015 13:00:52 -0500, "speedofsound1" > <105552@EmbeddedRelated> wrote: > >> ... the microphone will be situated inside a 3D printed plastic case (not >> soundproof though) I know about the background noise which was one of my >> main concerns, but let's say I want noises like incoming footsteps, door >> knocking, or door unbudge. > > Detecting footsteps is probably unrealistic. Door knocking is > possible, but the sound of knuckles on wood (or whatever) is very > different from, e.g., the sound of a brass knocker. > > Apart from sonar transducers, microphones per se aren't much used in > professional systems - their only routine use is to detect glass > breaking, which is a sharp transient that is relatively easy to pick > out.
Unless you can use some signaling event as a trigger to pass the *raw* signal (streamed) to something with enough intelligence to be able to understand if that's the sound of a branch scraping against a door, a pet walking near the pickup *or* a burglar rummaging through the drawers.
Update:

I worked on a code which should be lighting the LED at a specific noise, I
decided to not get picky on this one and use a simple ADC application on
the mic, due to my time constraints. Unfortunately, the littly blinky that
is supposed to happen is not happening at all... the light stays lit all
the time... can someone check this please and tell me what could be
wrong?


#include <msp430g2553.h>

unsigned int adcvalue = 0;

void configureADC(void);

int
main(void)
{
    WDTCTL = WDTPW + WDTHOLD;       //Stop the Watch dog

    P1DIR |= 0x41;                  //Enabled P1.0 and P1.6
    P1OUT = 0x41;

    BCSCTL1 = CALBC1_1MHZ;          //Set range
    BCSCTL2 &= CALBC1_1MHZ;         //SMCLK = DCO = 1MHz

    P1SEL |= BIT3;

    configureADC();
    __enable_interrupt();

    while(1) {
        __delay_cycles(20000);
        ADC10CTL0 |= ENC + ADC10SC;         //Sampling and conversion
start
        adcvalue = ADC10MEM;                //Read from the ADC

        if(adcvalue > 512)
            P1OUT = 0x40;
        else
            P1OUT = 0x01;

    }

    return 0;
}

void
configureADC(void)
{
    ADC10CTL1 = INCH_3 + ADC10DIV_3;
    ADC10CTL0 = SREF_0 + ADC10SHT_3 + ADC10ON + ADC10IE;
    ADC10AE0 |= BIT3;
}


---------------------------------------
Posted through http://www.EmbeddedRelated.com
It looks like you are enabling conversion complete interrupt but you 
don't have an interrupt handler.  That's a guaranteed lockup.  You've 
got more homework to do.


The 2024 Embedded Online Conference