Sound Sensing & Timing Node

[papa]

        Preparing for an RFM Sound Sensing Node,

            Thoughts about Use

                   Sensor Used

Like a vibration sensor, a sound sensor node could monitor a variety of things, including things with motors (a pump, a furnace, a clothes dryer, etc), & report status via OpenHAB.  One might use a sound sensor node as part of a presence sensor.  If sound is detected, node or OpenHAB programming might turn on a light for a certain length of time.  If the light goes off too soon, a clap or other noise could turn on another duration of light.  A sustained period of sound might toggle a light on or off.

I bought a MIC Sound Sensor Board like this (hereafter called "Sound Sensor" or "Sensor") because it can be powered by 3.3 volts that is good for the RFM69 radio I will add later. The Sound Sensor has only digital output (high or low) & no analog output (varies by loudness of the sound).

  

The following thread comes from my work with a sound sensor's digital output.

        Next, Wiring a Sound Sensor with Digital Output

[papa]

        Wiring a Sound Sensor with Digital Output

 I use a Buono Uno Arduino compatible switched to 3.3v mode because an RFM69 radio will be added later. A regular Arduino that runs on 5 volts & sends 5 volts through the digital pins (D2, etc) will damage an RFM69 radio.

      <<  Forum members (free registration), click on pic for larger view.

  Follow this ^^ schematic, building on a 3.3 volt Arduino compatible.

As shown in the above schematic, connect sensor VCC to Arduino D4 which will be set high to power the sensor with 3.3 volts.  Connect sensor GND to Arduino GND, & sensor out to Arduino D5. I use (color-coded?) male to female dupont cables.

        Next, A Sketch to Test a Sound Sensor

[papa]

        A Sketch to Test a Sound Sensor

    Sound_Sensor_Henry3.ino (2.15 KB)  << Forum members (free registration), download this sketch I adapted from this location.

        ^^ updated Nov. 16, 2018 with more comments & changed variable names to help us understand the sketch.

Using the Arduino IDE, upload the sketch to the 3.3 volt Arduino compatible.

With the Arduino compatible still connected to the computer's USB, turn the sensor board's potentiometer screw clockwise just enough for one LED to go off.

The above sketch can help you test your sensors. (See the next post about what to expect.) Out of 6 sensors I bought, 2 did not work. I suspect those sensors' potentiometers because when I turned the pot clockwise just enough for one LED to go off, sound would never trigger the sensor.

        Next, Serial Monitor Results from the Henry Sound Sensor Sketch

[papa]

        Serial Monitor Results from the Henry Sound Sensor Sketch

Further use & examination of the above sketch gives some sense of a sound sensor's possibilities.

Open the Arduino IDE's Serial Monitor at 115200 baud. 1) See what happens when you clap your hands once near the sensor's microphone & wait. 2) Also clap your hands continuously for a while. 3) Also make softer noises near the mic. 4) Perhaps with your voice, make a steady sound.

Watch the Serial Monitor (my comments in blue text).

When you do 1) you should see something like this:
         The off LED turns or flashes on
Sound Detected Val: 0 S O U N D
Sound Detected Val: 1 quiet                 The one LED turns off

When you do 2) & probably 3) & 4 you should see:
     The off LED turns or flashes on         (steady sound = steady LED)
Sound Detected Val: 0 S O U N D
       [ ^^ until you stop making sound then ...]
Sound Detected Val: 1 quiet              The one LED turns off

When you do 3) & 4) with potentiometer set as above, results should be like 2) just above. If you do 3) & 4) with potentiometer screw turned a little more clockwise (1/4 turn ??), softer sounds will not be detected.

From the above, we see that a detected sound that passes the sensor's pot set sensitivity level sends a LOW or 0 to Arduino D5. Quiet sends a HIGH or 1 to Arduino D5.

        Next, Further Insights from Sound_Sensor_Henry.ino

[papa]

        Further Insights from Sound_Sensor_Henry.ino

From above results, the sound sensor seems easy enough to use.

However, from experimenting with other code, I learned that even when we generate a seemly steady sound, the state of the one LED & the state of Sound & quite rapidly alternate. I guess the sensor's mic is sensitive enough to catch the brief silences in our supposedly steady sounds, which complicates using the sensor.

Look closely at the Sound_Sensor_Henry sketch to which I added comments. In essence, it sets a SOUND status when (after quiet,) the sensor first hears a sound. During a SOUND status, if quiet is detected AND it's been more than 1/2 second since the last sound was detected, a quiet status is set.  This hints at working around the sensor's quirks.

        Next, Towards an RFM69 Sound Sensor Node
                Insights from Eric Tsai's Laundry.ino

[papa]

        Towards a Sound Sensor Node
     Insights from Eric Tsai's Laundry.ino

I remembered that Eric Tsai's Uber Home Automation Instructable included use of a sound sensor to monitor a clothes dryer.

Caution:  The Instructable contains useful code.  However, it's data & radio transmission structure differs from what we use on the forum now so the code must be adapted.

In adapting, I separated the Laundry code from code for other sensors & for data structure & transmission. This code takes a number of samples from the sound sensor & if a set number of those samples hold sound then a SOUND status was set. Otherwise a quiet status was set.

   Sound_Sensor_Tsai_Laundry7.ino (5.61 KB)  << Upload this sketch to the same 3.3 volt Arduino compatible & sound sensor wiring as above. Open the Arduino IDE's Serial Monitor at 115200 baud. Watch the Serial Monitor as you generate periods of sound & quiet. As shown in the next post, you should see info from 6 samples & an evaluation of results: 2 or more samples out of 6 with sound evaluate as [Sound running].  Less than 2  samples with sound evaluate as [quiet]. Also displayed are changes of state between SOUND & quiet.

The Henry-derived or Tsai-derived code will be used below for an RFM69 node that transmits sound sensor data to OpenHAB.

        Next, Sound_Sensor_Tsai_Laundry7.ino, Serial Monitor Results

[papa]

    Sound_Sensor_Tsai_Laundry7.ino, Serial Monitor Results

          Added Comments in Blue Text:

Key to result lines:  [number of samples showing sound] out of [number of samples]

     [ last state as number] [current state]  [current state in words]

Sound_Sensor_Tsai_Laundry7

0 out of 1 last= 0 state= 0 no sound detected
0 out of 2 last= 0 state= 0 no sound detected
0 out of 3 last= 0 state= 0 no sound detected
0 out of 4 last= 0 state= 0 no sound detected
0 out of 5 last= 0 state= 0 no sound detected
0 out of 6 last= 0 state= 0 no sound detected
    sensor samples results: quiet !!                     < no sounds detected = quiet

0 out of 1 last= 0 state= 0 no sound detected
0 out of 2 last= 0 state= 0 no sound detected
0 out of 3 last= 0 state= 0 no sound detected
1 out of 4 last= 0 state= 0 sound detected
2 out of 5 last= 0 state= 0 sound detected
3 out of 6 last= 0 state= 0 sound detected
    sensor samples results: sound running!     < sounds detected in 3 samples = running

   ## State Changed ##                   < state changed from quiet to sound
1 out of 1 last= 0 state= 1 sound detected
2 out of 2 last= 0 state= 1 sound detected
2 out of 3 last= 0 state= 1 no sound detected
2 out of 4 last= 0 state= 1 no sound detected
2 out of 5 last= 0 state= 1 no sound detected
2 out of 6 last= 0 state= 1 no sound detected
   sensor samples results: sound running!     < sounds detected in 2 samples = still running

0 out of 1 last= 1 state= 1 no sound detected
0 out of 2 last= 1 state= 1 no sound detected
0 out of 3 last= 1 state= 1 no sound detected
0 out of 4 last= 1 state= 1 no sound detected
0 out of 5 last= 1 state= 1 no sound detected
0 out of 6 last= 1 state= 1 no sound detected
   sensor samples results: quiet !!

   ## State Changed ##                < state changed from sound to quiet
0 out of 1 last= 1 state= 0 no sound detected
0 out of 2 last= 1 state= 0 no sound detected
0 out of 3 last= 1 state= 0 no sound detected
0 out of 4 last= 1 state= 0 no sound detected
0 out of 5 last= 1 state= 0 no sound detected
0 out of 6 last= 1 state= 0 no sound detected
   sensor samples results: quiet !!

        Next, Preparing for an RFM69 Sound Sensor Node

[papa]

        Arduino Sketch for Timing Sounds

                NOT a Node

    Sound_Sensor_Henry5.ino (2.73 KB)  <<  For this sketch version, I added more to the program I found at this location.  To help us understand, I added more comments & changed variable names. I also added code to time the duration of sounds.

For this sketch, use the same wiring in the schematic diagram above.

 In my experience, this sketch successfully timed the duration of sounds, accurate to one second.

I was able later to get the Henry approach to work in an RFM69 Sensor Node.  However, I felt that the Tsai code version worked slightly better & its accuracy within 2 seconds was adequate.

    Next, Preparing for an RFM69 Sound Sensor Node

[papa]

    Preparing for an RFM69 Sound Sensor Node

In order to communicate with OpenHAB, this node needs you to have built & programmed a separate RFM69 Gateway. You also need experience achieving an RFM69 network. The Building an RFM69 Home Automation Network thread & the linked Gateway thread will lead you step by step (with troubleshooting hints) to achieve your first network.

In that RFM69 Network thread, work your way through making the RFM69 Bare Bones End Node & getting it communicating with the RFM69 Gateway. That is, you can follow the thread & stop after achieving this post. Then you can add the vibration sensor breakout board to the Bare Bones End Node (schematic below) with a high likelihood of success.

Skip this step if you already have a working Gateway & node. If you do NOT have a working Gateway & node yet, do NOT skip this step because it is probably the most challenging aspect of the project.

    Next, Schematic for An RFM69 Sound Sensor Node

[papa]

        Schematic for An RFM69 Sound Sensor Node

Be kind to yourself & do NOT build this node until you have created your RFM69 Gateway & a least one previous node (See previous post).

      << Forum members, click on pic for larger view

added parts: 3 (color-coded ?) dupont male to female cables to connect the Arduino sockets to the sensors' pins.

Note 1: In this schematic, its important to use an Arduino compatible (like a Buono Uno) that sends 3.3 volts through its digital pins (like D2). A 5 volt Arduino would damage the RFM69 radio. The Building an RFM69 Home Automation Network thread & the linked Gateway thread gives more about this.

Note 2: The Sound Sensor's VCC is powered by 3.3 volts from Arduino D4, not from Arduino's 3.3 volt socket. The sketch below will set Arduino D4 HIGH so it can power the sensor.

Note 3: Make the connections according to the labels of the pins. The pins' locations in the schematic diagram do NOT match their actual locations.

        Next, Program an RFM69 Sound Sensor Node

[papa]

        Program an RFM69 Sound Sensing / Timing Node

             Updated Dec. 8, 2018

     GO HERE to download the latest node choices sketch & achieve initial customization.

The sketch uses the ...Launry7.ino code in a MIC_tsai option. I changed Laundry7.ino code to 4 samples (not 6) per cycle. So 2 or more sample s out of 4 with sound evaluate as [Sound running.] Zero or 1 samples with sound evaluate as [quiet].

The above sketch can be used to program many other types of nodes.  In this post, see a list of possible nodes whose entries are linked to instructions.

In the sketch, I generalized variable names & comments & within a sample_tsai option, I included code for MIC_tsai & also for VIBR_tsai, a better vibration sensing/timing option. MIC_tsai moved from device 69 to device 71. Do NOT use MIC_tsai & VIBR_tsai on the same node.

This approach catches sound well & is able to time sound duration within 1 or 2 seconds.

If you want to see how the sound sensor code fits into the node programming, search the sketch in the post for "sample_tsai" & "MIC_tsai"

    Next, Customizing the Node Choices Sketch for a Sound Sensor Node

[papa]

    Customize the Node Choices Sketch for a Sound Sensor Node

                        Updated Dec. 16, 2018

        Find this line & UNcomment these TWO lines (delete // at their start):

// #define sample_tsai

// #define MIC_tsai

        Optional, for more Serial Monitor detail, UNcomment this line:

// #define sampleReport

#define NODEID 05 << change 05 to a unique number in your RFM69 network
       (For this sound sensor node, I suggest you use NODEID 110 as I will below.)

#define ENCRYPTKEY "xxxxxxxxxxxxxxxx"
       ^^ change xxx... to the same 16 character key you gave your Gateway

#define DEBUG << make sure this line is UNcommented (no // at the start)

        UNcomment only one of these lines based on your RFM69 radios' frequency:
// #define FREQUENCY RF69_433MHZ
// #define FREQUENCY RF69_868MHZ
// #define FREQUENCY RF69_915MHZ

    UNcomment this line if your RFM69's radio has an "H" in its part number:
// #define IS_RFM69HW

Connect the node to your computer's USB. Using the Arduino IDE, upload the customized sketch to the Sound Sensor End Node. Open the Arduino IDE's Serial Monitor at 115200 baud.

        Next, Sound Sensor End Node, Serial Monitor Results

[papa]

    RFM69 Sound Sensor End Node, Serial Monitor Results

            (sampleReport option  is commented out)

        My comments are in blue text:

Node 110 Version MhF9p MICtsai GW2.5.1 < [NODEID, sketch version, MIC_tsai option, Gateway version]

    Transmitting at 915 Mhz... < RFM69 radio frequency
Node: 110 dev: 99 cmd: 0 Ival: 0 Fval: 0.00 RSSI: -59 < device 99: wakeup

Node: 110 dev: 2 cmd: 0 Ival: 0 Fval: 0.00 RSSI: -60 < device 2: RSSI, radio signal strength
Node: 110 dev: 4 cmd: 0 Ival: 0 Fval: 3.28 RSSI: -61 < device 4: node voltage
Node: 110 dev: 9 cmd: 0 Ival: 1 Fval: 3.28 RSSI: -60 < device 9: # of transmit attempts (only 1)
Node: 110 dev: 71 cmd: 0 Ival: 0 Fval: 3.28 RSSI: -59
    quiet !! < Periods of quiet

    quiet !!

    signal running, secs: 0 < start period of SOUND
Node: 110 dev: 71 cmd: 0 Ival: 0 Fval: 0.00 RSSI: -61 < device 69: seconds of sound (0 = sound just started)
    signal running, secs: 3
    signal running, secs: 6

    total seconds of signal: 9 < device 69: seconds of sound (9)

        quiet !!

Node: 110 dev: 71 cmd: 0 Ival: -9 Fval: 0.00 RSSI: -59

                      ^^ device 69 = -9 (negative 9 = 9 secs of sound ended)

    Next, Sound Sensor Node, Configuring for OpenHAB 2 Results

[papa]

    Sound Sensor Node, Configuring for OpenHAB 2 Results

            Updated Nov. 26, 2018

(Note: the following assumes NODEID 110 (see customizing above) & installation of OpenHAB 2, MQTT binding, & Mosquitto.)

   Snd_Sense_digi110.items (817 B)  << Download & save to OpenHAB 2's \conf\items folder
This file contains items for Node 110 radio signal strength, voltage, sound state, sound seconds, & sound state change timestamp.  The file now uses device 71 (not 69) for sound seconds.

  Snd_Sense_digi110.rules (974 B)  << Download & save to OpenHAB 2's \conf\rules folder
This file contains a "Snd_Digi_Sensor_110" rule that converts soundSecs values to SOUND or quiet in the item Node110SndDigiState. It also timestamps the change in sound state. The rule "When_Sound_State_changes" demonstrates using the sound state as a rule trigger.

  ear.svg (1.58 KB)  << Download & save to OpenHAB 2's \conf\icons\classic folder

   ^^ Warning: Such custom icons seem to take a long time before they show in a user interface. Quicker display may result by using one of OpenHAB's built-in icons.  For those, see & hover over images at this site.

Add these lines to your xxx.sitemap file in OpenHAB 2's \conf\sitemaps folder:
    Text item=Node110SndDigiState
    Text item=sound_digi_time110

    Text item=Node110SndVal

        Next, Sound Sensor Node, OpenHAB Results    

[papa]

        Sound Sensor Node, OpenHAB Results

If you look into OpenHAB's log file or use the log:tail command on the Karafe console, you can see Node110SndDigiState change states between quiet & sound soon after changes occur. When quiet ends a sound, OpenHAB usually soon receives the number of soundSecs (as a negative number to indicate their end). When a sound duration starts & also when it ends, the sound change timestamp will display soon afterward.

           < forum members, click on pics for larger view.

    ^^ User Interface when sound starts

       

     ^^ User Interface when sound stops after about 4 seconds.

Again, the rule "When_Sound_State_changes" demonstates using the sound state as a rule trigger. Node110SndVal (seconds of sound) & Node110SndDigiState should be readily available for other OpenHAB rules to use as a condition.

As shown in the Serial Monitor results above, device 69 shows as zero when a sound duration starts. When the sound duration ends, device 69 shows as a negative version of the number of sound seconds.

The sketch's TXinterval variable sets the node to send soundSecs to OpenHAB's SndDigiState110 item
every 60 seconds. The User Interface will display zero when SOUND
starts & (negative) seconds of sound duration when quiet resumes.
For longer sounds, no more than 60 seconds after SOUND starts & then
again every 60 seconds, the SndDigiState110 item will update in the User Interface.

        Enjoy !

[papa]

    A Different Approach to the Node Choices Sketch ??

The Multi-Choice Node sketch is getting large. I can & will delete or move some commentary in the sketch. The sketch's having many node options is good, but size probably makes it hard to read & learn from.

I've considered how to address the Node Choice Sketch's size & readability. This post will begin one possibility & it will use the Sound Sensor Node code as a trial example.

1) This approach uses one main .ino file that includes variables & code used by ALL options or at least more than one option. 2) For each node option, this approach would also uses a .h header file that contains variables & code specific to ONLY ONE option.

    The Sound Sensor Node as a Trial Example

[papa]

    A Different Approach to the Node Choices Sketch ??

    Using the Sound Sensor Node as an Test Example

        Code Files Updated Nov. 24, 2018

Again, 1) This approach uses one main .ino file that includes variables & code used by ALL options or at least more than one option. 2) For each node option, this approach would also uses a .h header file that contains variables & code specific to ONLY ONE option.

    computourist_node_v2.2NhF9m_pub.ino (10.5 KB)  < Download this file & save it to your Arduino IDE's default sketch folder. It is a stripped version of the main sketch's variables & code that is ready to supplement with the MIC_tsai.h specific variables & code.

Open this .ino file, so the IDE will move the sketch to its own folder (find where that folder is). Close the Arduino IDE.

    MIC_tsai.h (6.03 KB)  < Download this .h header file & save it to the folder where the Arduino IDE moved the main sketch. It is a file of MIC_tsai specific variables & code.

Re-open the main .ino sketch in the Arduino IDE. You should see not only the main sketch in a tab, but also the MIC_tsai.h file in another IDE tab.

In the main sketch, customize the same lines as you did in this post above. Except, so far here there is no "// #define sample_tsai" to uncomment.

Upload & see that this Sound Sensor node works the same as with the approach above.

 If this different approach is pursued with other node options, there would be many smallish .h header files to cover the options.

What do you think of this different way to organize the Node Choices sketch & the node options?

[brump]

Papa,

This approach is great for viewing code, especially for beginners.
Congratulations on the beautiful work done!

Tomorrow, I'm going to test your code and report the results.

[papa]

Thanks, brump. I look forward to hearing your results.

In this first attempt, I mostly included main sketch code that sends integer data from the node to Gateway/OpenHAB. If this approach is continued, I'll need to include code for handling other data types & for commands sent from OpenHAB/Gateway to a node.