C code for microphone in msp430?

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.