Limits and averages

To find the levels of sound in the immediate environment, we have a sound sensor attached to LEDs to pinpoint when you have reached a level of sound in your environment that will become hazardous with extended exposure.

But what determines those levels is a (relative) understanding of how the sound meter relates to decibels.

This is a bit of a problem, because I am incredibly sucky at maths, but should be fairly simple to get a basic understanding of.

143
133
29
61
53
66
2
109
165
22
79
38
33

Omitting the 0 readouts, this is what the sensor gives us over a couple of seconds. The numbers are highly varied and show no clear graduation between low to high sound, perfectly indicative of how sound works, the sudden, incidental and unexpected is much documented in these readings, emphasised to a degree by having the sensor on its highest setting.

Translating these numbers is (at least for silly me) no small task, given that the power for each sound is increased for every three decibels. However, for the sake of time, I’ve left algebra for the most part to the side and worked out what the numbers mean against an android sound sensor with a decibel readout.

270 – 90dB

230 – 85dB

200 – 80 dB

140 – 70dB

80 – 60dB

These numbers are roughly accurate, and allow us to make better sense of what the sensor is giving us.

Considering decibels, we know that  85 decibels is safe for eight hour exposure per day times, and that with 91 decibels we are looking at a safe exposure time of only two hours. Referencing what we know of the three decibel incremental value, for every three added decibels the safe listening time is cut in half. That means 82 decibels has a safe exposure time of 16 hours, and 79 has a safe time of 32hrs. As such, we can work out that a round figure of 80 dB has a safe daily exposure limit without risking premature NIHL.

In addition, if we wanted to find out what the accumulative exposure to a level of sound would be for a twenty four hour period, we can also roughly work it out.

For 80dB, an accumulative reading per minute from the sensor would total 288,000 at the end of a 24 hour period. For 85dB, it would be 331,200, for 90dB, 388,800.

With this information we can read the sensor data, interpret it and tell the LEDs how to respond in a manner that represents the immediate environment.

Achievement reached!

We set ourselves goals to reach, so at each stage we would have something we could hand in, before we moved on to add the next part in. And today, finally, we reached our first goal, to read the sound data, and visualize it in a way to give instant feedback to the wearer.

The problem is, our sound sensor is still being a bit dodgy, so I’ve had to rig the code a little bit for testing purposes, but I still have the true science bit in (commented out) in case anybody asks!

Here’s the code:

int sensorPin = A0;
int ledPin[] = {3,4,5};

//int warningLevels[] = {200, 230, 270};
int warningLevels[] = {20, 50, 100};

int sensorValue = 0;

int accumSound = 0;
int readCount = 0;
int aveSound = 0;

int ledLit = 0;

void setup()
{
  Serial.begin(9600);
  //set up LEDs
  for (int i = 0; i<(sizeof(ledPin)/2); i++){
   pinMode(ledPin[i], OUTPUT); 
  }
}

void loop()
{
  //turn the lights off
  for (int i = 0; i<(sizeof(ledPin)/2); i++){
   digitalWrite(ledPin[i], LOW); 
  }
  ledLit = 0;

  //read sensor
  sensorValue = analogRead(sensorPin);
  //remove errors
  while(sensorValue == 0 || sensorValue > 350){
   Serial.println("reread...");
   sensorValue = analogRead(sensorPin); 
  }
  //trace
  Serial.print("sensorValue: ");
  Serial.println(sensorValue);

  //add to accumulative sound
  accumSound += sensorValue;
  //trace
  Serial.print("Accumulative Sound: ");
  Serial.println(accumSound);

  //add to readCount
  readCount++;

  //work out average sound per minute
  aveSound = accumSound/readCount;
  //trace
  Serial.print("Average Sound per min: ");
  Serial.println(aveSound);

  //check against our set levels
  for (int i=0; i<(sizeof(warningLevels)/2); i++){
   if (aveSound > warningLevels[i]){
    ledLit = i+1;
    Serial.print("Warning level breached: ");
    Serial.println(i);
   } 
  }

  ///light correct amount of LEDs
  for (int i=0; i<ledLit; i++){
   digitalWrite(ledPin[i], HIGH); 
  }

  Serial.println("------------------------------------------");

  //wait for 1 minute
  delay(30000);
}

I’ve done my best to comment it well, but incase you can’t work out what it does, basically it reads the sound every 30 secs, adds this to a accumulative score, works out the average sound you’ve been subjected to per minute from that, and lights the LEDs if you’ve had over the recommended limit per minute.

 

I’ll let Karla explain the science behind the recommended limits she came up with, but they’re basically 80,85 and 90 decibels, which we think should correspond to 200, 230, 270 from our sensor. However, these values are never hit, even if the sound sensor on Karla’s phone says we’re above those decibels, so I’ve added random levels in for testing.

 

I’ve currently been running it, with the wifly board in but not working, on battery for seven minutes and it’s still going strong.

Next up, we have a break for a dissertation seminar, then we’ll get the wifly working. We have a vague idea of sending the data to twitter, and pulling the feed from it to visualize it, but we’ll see how we go. At least now we have something to show if all else fails.

A mess of wires

This is the current state of our set up – a mixture of sensor, wifly, wires (more organised than they look) and LEDs.

Our project has developed through the limitations and freedoms of our discoveries, between finding ways and incompatibilities with different parts of kit and thinking new ways to do things to improve upon the original concept. We’d like to give the final result a more immediate response to the data it is discovering, and we’ve removed the idea of using GPS due to the want to completely avoid any privacy concerns. Thus, we’ve rearranged our ideas for output and as such expect that the hat-scarf-bear will have three “claws” on one paw comprised of three LEDs, two green – for good and manageable levels of sound – and one red, for determining and warning of dangerous levels of sound or noise in the immediate area.
We’re also intrigued by the idea of linking the bear up to a twitter feed, so that we can not only share/broadcast this information but encourage other people to find ways of using the data, as well as ourselves. The purpose of the decibear is to raise awareness after all, and while the awareness in concept may be unique to the individual wearer, online it can become the awareness of many more, even if in a secondary state.

Suddenly Sound

I figured out what was causing us so much trouble with the sound sensor – we’d been pinning it up wrongly the whole time! Where in the diagram that we had been following it showed us to connect it in a certain way, I found that exchanging the ground and sensor made it work, whereas previously we were connecting to the sensor but it wasn’t responding to loud sounds.

Similarly, we later discovered what the problem with the Wifly shield was as well – that it wasn’t compatible with my Mega 2560 Arduino board. Solving the issue turned out to be rather simple, a case of wiring four pins of the shield to a different part of the board.

20130219_125734

Time is running out….

Realtime is finally over, and I can now focus entirely on Everyware, although I’ve got the post-deadline illnesses as usual to fight through now!

We’re working on getting the scarf part set up today, I’d like to have the system take a reading from the sound sensor every 3 minutes, add this to the accumulative sound score, and light up LEDs if this score goes above certain levels.

I’ve started by looking into how to put the arduino into some sort of idle mode so it uses as little power as possible while it isn’t required to sense anything. Helpfully though, the arduino website is down until at least 3pm today, so I’m having to try and find clues on other websites.

I found this one on RocketScream which looks really promising, and really easy to use. I worked on top of their ‘powerDownWakePeriodically’ script to write my functionality, but I am still yet to get it to compile with the powerDown code in there. I guess we could do periodic readings with a delay or something, but it would be good to have lower power usage as we’re running off battery.

Karla and I have chosen some ‘safe’ accumulative sound levels to compare our readings to, so we plan to light up a red warning LED if you’ve been exposed to over 85db over an 8 hour period, because that’s really bad for your health, and then we’ll light up a few green ones at various stages on the way to that (probably 45db and 65db, seems nice and even!)

We need to do two things to this though, we need to work out how to translate the sounds we’ve taken over a certain time period to the 8hr time period for comparison, and work out how the sound numbers we’re getting from our sensor compare to decibels.

Karla has a sound app on her phone which works in decibels, so we’re comparing readings from that to work it out.

WiFly-ing high

We’d been having trouble with the WiFly shield for weeks, it was just hanging at the SPI UART begin function, which meant that it was unable to connect to the WiFly bit through the shield. We knew this, but after the mess up with the sound sensor (we had it wired wrongly!) we didn’t want to be the bad workmen blaming our tools again!

But this time, it turned out it was the tools; the WiFly shield isn’t compatible with the Arduino Mega. Damn.

Thankfully it was a relatively simple fix, although I think I’m in danger of death-by-Saunders, as I’ve had to bend the pins from the shield 😉

All you have to do is reroute the pins that are in different positions on the Mega, I followed this helpful tutorial (I know it’s for ethernet, but it worked just the same) http://mcukits.com/2009/04/06/arduino-ethernet-shield-mega-hack/

And this now means we can move one more step forward on our lovely project 🙂

Power to the people!

We just tried powering blink from a battery because we’ve never done it before, and as we hoped it was a simple matter of just plugging it in!

IMAG0751

This means we can go ahead later and test how well the battery supports the GPS, sound sensor and everything else we’re going to use for this project.

 

Mormor Ingrid

I was researching to see what other cool projects people have done using arduino sound sensors, and I couldn’t find that many to be honest, it seems sound isn’t an area that’s too well explored.

I found one project though, called Mormor Ingrid, that was just too creepy not to share!

The website says it combines ‘the classic arts of sculpted busts and sketchbook drawings’ with projection mapping, and adds it’s interactivity through slapping a surface monitored by an arduino sound sensor. The sound input then controls which sketchbook style drawings are projection-mapped onto the bust, and the effect is really freaky. Watch the video for yourself really, see what I mean:

here

I’m not sure if there’s really anything we can draw from this project for inspiration, we’re taking ambient background sound, and this project uses sound as an interaction method, but I was really drawn into the project, so I thought I would share it, and see if maybe we can take any aspects from it to make people equally drawn into ours?

Slow progress, but progress non-the-less!

We spent all of Friday morning on the project, as we were finally able to get some kit! We had already decided to work in a modular fashion, getting one step complete and working before moving on to the next, and so we started with the sound sensor, being the basis of our project!

We worked out how to wire the thing up with the help of this diagram from the parallax site (our sensor isn’t parallax, but it worked the same!) Wiring up is my worst thing with arduino, so I wanted to know I was doing it right and wouldn’t damage anything, and we were determined not to use a breadboard to keep it as portable as possible.

SoundImpact_Wiring

We then just opened the example analog input sketch, adapted it to show the output in the serial monitor, and uploaded it to see what we got.

Which unfortunately, was not a lot. We were definitely getting values from the sensor, because they changed when we unplugged it, but none of the values actually made much sense, as there was no response to anything we did to the sound sensor. We came to the conclusion that the sensor we were given was probably broken, thought we would check with Mike in the next session, and moved on to the next stage.

We found a really useful tutorial video from Jeremy Blum to help us work out the GPS module, in which he referred us to the TinyGPS arduino library which we found lovely to use. With the help of Jeremy, and the example sketches with the library, we had the GPS module working pretty quickly. We actually weren’t getting any data through, but this was because we couldn’t get a signal to the satellites inside Babbage, and decided we would take the arduino for a walk connected to Karla’s laptop on a day when it wasn’t raining quite as much as it was on Friday!

As we had a little time left over on our Friday session, we decided to move onto next week’s work of playing with the Wifly shield, and found another useful tutorial and library with example sketches to help. However, we couldn’t get it to connect to the SPI UART, so we couldn’t get much further than the start. As this wasn’t work for this week though, we weren’t to bothered by it.

It felt as though we hadn’t really achieved much in our days work, but when we looked back we had the sound sensor code working (and learnt how to plug it in!) even if the sound sensor was potentially dodgy, and we had the GPS going too, so we pretty much did achieve our goal for the day.

Lilypad problems

We finally got our lilypad from Chris who had been off sick for a while, which delayed our targeted progress by a few days, but no matter, we still had 3 weeks.

We laid out all the kit and looked through everything, as Karla hasn’t used much arduino at all before, and I am pretty solid on the coding side, but always get confused by how to physically plug the things in (I’m always terrified of blowing things up!)

One thing became obvious pretty quickly, we were going to have problems with the lilypad. Firstly we didn’t have the right USB cable to connect it, but that was’t a big deal, the main problem was the amount of wires that would have to come off the thing to connect everything up. Even with soldering, that amount of connections would not be very portable at all, and we were also having trouble trying to work out how to connect the GPS module to it, although we knew it must have been done before as the point of the lilypad was to be portable.

In the end, just for progress sake, we started out using Karla’s Mega, we thought it a good idea because we could make the connections stronger as we could use proper wires rather than conductive thread, with soldering or just electrical tape if necessary too. Her board also came with a lovely little plastic box to keep it in, so we thought that would help with portability as well. To be honest though, the main reason was just so we could get the ball rolling and start getting something done!!