Arduino + Electret Microphone

Last week, I ordered a whole bunch of Electret microphones from Sparkfun.  I thought I could add some cool noise sensors around the rover I've been building.  They come in and I start researching how to use them when I realize that I've made quite the mistake.  These little microphones are way too weak for the Arduino to read anything from.  What I should have purchased was this breakout board since it has a 100x opamp that amplifies the signal for the Arduino.  The damage was done though and I wanted to see if there was anything I could do to make these things work.

After much research online and toying around, I found this circuit and tried it to see if it would work.

Here it is on the breadboard:

When I first set it up, it didn't work and I couldn't figure out why.  I then realized that I just didn't have power going to the board.  Nice and simple mistake.  After fixing that, it seemed to return some value of 850.  Trying a different microphone gave me a different start value.  I set up my program so that it would get the ambient noise average before it started so I didn't have to worry about setting a value for each microphone.  After I got that setup, I simply check if the sound is higher than the ambient noise and flash an LED if it is.  That all seemed to work, so I went ahead and created a more portable version of it for my little rover.

The 3 pins are Signal, +5v, Ground.

Once that was done (and tested to make sure it still worked (it did)), it was Dremel time.

Now you can see why I added 3 pins :]

All tested and working well.  Here's a little video that shows it in action.

http://www.youtube.com/watch?v=ZHyVWfwPMOs

I still don't think it's quite right.  It should have a much larger range than it does, but this will do for now.  I can toy with this until I find a better circuit to use or just order the breakout board that Sparkfun sells.

Converting NUnit to MSTest

At my normal job, I was recently put in charge of converting our NUnit tests to MSTest.  After much researching online and reading lots of posts, here is the method that seemed to work for me.

1. Remove dll references to NUnit.Core & NUnit.Framework.
2. Add a reference to Microsoft.VisualStudio.TestTools.UnitTesting.
3. In the code, find and replace:
1. using NUnit.Framework; → using Microsoft.VisualStudio.TestTools.UnitTesting;
2. [TestFixture] → [TestClass]
3. [Test] → [TestMethod]
4. [SetUp] → [TestInitialize]
5. [TearDown] → [TestCleanup]
6. [TestFixtureSetUp] → [ClassInitialize]
7. [TestFixtureTearDown] → [ClassCleanup]
8. (TestFixtureAttribute) → (TestClassAttribute)
9. (TestFixtureSetUpAttribute) → (TestInitializeAttribute)
10. (TestFixtureTearDownAttribute) → (TestCleanupAttribute)
11. (TestAttribute) → (TestMethodAttribute)
4. Update all of the Assert calls.
5. The 'hidden' part. In your project file, locate <PropertyGroup> (not the one specifying debug|release settings), and add the following to it under <ProjectGuid>…</ProjectGuid>:
1. <ProjectTypeGuids>{3AC096D0-A1C2-E12C-1390-A8335801FDAB};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>
2. Do not change the GUID.  Visual Studio uses that exact GUID set to identify all Unit Test projects.
6. In Visual Studio, go to the "Test View" and confirm that your tests are listed.
7. If needed, change setup()→ public static void setup(TestContext context)
8. If needed, change teardown()→ public static void teardown()

I'm posting this here for historical purposes.  UnitTests can come in handy for all kinds of development and Visual Studio's built in testing makes it extremely easy to do.  I know I'm guilty of not having many unit tests for my game, but as code becomes more and more mature, unit testing can make sure that we're not doing something we shouldn't.  It's also a good way to make sure the build you're about to release to your players isn't going to destroy something vital, like Saved Games or existing map data.