Audio Sensor Development Part 3: Theory Meets Reality

This article continues the development of an audio sensor device for the RGB Shades and LED Matrix Shades, starting with microphone calculations in Part 1.

We’re developing an add-on board to make the RGB Shades and LED Matrix Shades dance to music! Biggest news of this article is that you can try this out for yourself…we had a lot of extra prototype PCBs and hand-assembled a big batch. While the design needs some tweaking, by popular demand we put a bunch of the prototype version in the store. If you try it out, we’d love to hear your feedback!

In Part 2, the prototype device was constructed and tested. The initial tests were done without LEDs attached, and with high-level sound input at the microphone datasheet’s test frequency. This showed that the results agreed quite well with the design predictions, but that only gives an idea of how it will perform in the real application.

With the RGB Shades fully assembled and displaying some sound reactive patterns, there were some initial disappointments. The most noticeable problem was that the sound reactive patterns would sometimes react to themselves…patterns with a lot of bright LEDs would appear to feed back and generate even more input to the analog circuit. This would swamp out any incoming audio and reduce the usability of the system.

Digital noise creeping into analog circuits is a real problem for any circuit that combines the two. This is many times more likely for a high-power circuit that controls LEDs or motors. The Shades Audio Sensor microphone outputs millivolts, and must be amplified many times to become usable. Unfortunately this will also multiply any noise leaking into the system. The most common source of noise is the power supply rail, and we definitely had some significant power supply noise.

We have been including a very thin USB cable with the RGB Shades Kit…so thin, that on many computers it doesn’t work well for USB communication. The wires inside are extremely thin, and the cable overall is only 2mm in diameter. This is great for wearability, but sacrifices some current handle ability. This hasn’t been a huge problem since the RGB Shades controller and LEDs have been pretty tolerant of some noise on the 5V supply. However, the Shades Audio Sensor didn’t work well with the thin USB cable…it was nearly unusable except at very low brightness levels.

However, it worked very well when connected directly to a high current source of 5V with larger wires. So we realized that a better USB cable was needed: one that could supply far more current than our existing thin cable, and ideally more current than a normal USB cable. Yet it still needed to be thin, or it would not be easy to wear. The only way we could do this was to custom-manufacture a power-only USB cable with only two 24AWG wires inside.

The improved cable greatly reduced the power supply noise, but we still had a couple of other issues. There was still some LED noise leaking through the system; most of this was abated by adding an extra 22pF capacitor at the input to the MSGEQ7 to filter out some of the high frequency noise. We also increased the MSGEQ7’s virtual ground filtering capacitor from 0.1uF to 1.0uF.

The Shades Audio Sensor was now working quite well, but the microphone sensitivity seemed a bit low. The gain calculations looked great on paper, but in practice the Shades weren’t reacting much to typical sound levels.

Reviewing the microphone datasheet, we found a possible mistake. The test circuit is specified at 3.0V with a 2.2K load resistor, but the RGB Shades use a 5.0V supply. We were guilty of just plugging in a value from the datasheet instead of thinking our own application through.

Some bench testing of the microphone element revealed that it typically drew about 0.2mA regardless of supply voltage and load resistor value. So with the datasheet’s 3.0V supply, the 2.2K resistor would drop about 0.44V and result in 2.56V on the positive terminal of the microphone. But with the same 2.2K resistor on a 5.0V supply, it would be 4.56V…far outside the implied test conditions of the microphone datasheet.

We picked a new resistor level keeping in mind that we want this to work on a 3.7V as well as 5.0V circuit. With a 7.5K resistor, the microphone voltage is 3.5V on a 5.0V supply and 2.2V on a 3.7V supply. These are closer to the test specifications, and in real-world testing does result in better response at lower sound levels.

One final tweak: we significantly increased the microphone gain to about 30.9. This may be too much for very loud concert environments, as according to the microphone calculations our usable range tops out around 96dB SPL.

Since a lot of people wrote in requesting info about Shades Audio Sensor availability, we decided to hand-assemble a big batch with the tweaks described above. They do work quite well and are a lot of fun, though we plan to do some more work on cleaning up the power supply for the microphone circuit. They are available in our online store now, and we’d love to hear your feedback and see the audio-responsive patterns you create!

Click to continue >> Audio Sensor Development Part 4: Taming the Transient Tiger

Submitted by Garrett on Mon, 01/18/2016 - 01:20.

These are boards are

These are boards are awesome, Garrett! Easy add-on!

I'm digging through the code and looking for a way to adjust frequency ranges into the EQs. Ideally, I'm thinking between 60 and 6000 Hz and to flag 10 "ranges" for those (e.g., 20-80, 100-200, 300-400, 500-800, 900-1200, 1300-1600, 1700-2400, 2500-3200, 3300-4400, 5000-6000). Right now, it looks like the spectrum only sees a max of 7 frequencies and with about 50% of that at 5000Hz or higher. I used the eqmapping of eqMapping[10] = {0, 0, 1, 1, 2, 2, 3, 3, 4, 4 for now - easy enough to shift the display that way but I'd really like to spread out the range to use all 10 columns instead of doubling up on the columns.

Does that mean the spectrumValues have to be adjusted somehow? Thoughts?

The MSGEQ7 handles all of

The MSGEQ7 handles all of the frequency filtering and only has seven hardware bins. Unfortunately code cannot be used to affect how the frequency ranges are configured.

How long till the new or

How long till the new or final version is released? Any other tweaks it might have to make it better than the beta?

Awesome work man and thanks

Awesome work man and thanks for sharing it!

Question: Have you tried them in a concert yet?
that's definitely where I'd wear them!

Sensors are sold out Do you

Sensors are sold out
Do you know when are you going to have them available again?