MSGEQ7 Periodic Noise

Other Hardware Audio
1

I have a circuit on a SMT board that is showing some rather odd noise issues. I don't think it is necessarily because of the Arduino, but I am curious if anyone else has seen this issue.

I am using the MSGEQ7 in a SMT package, and operating it using the typical example code. Everything looks great, but at random intervals, roughly 10-20 seconds apart, the values being read at the analog input spike from ~30-50 up to 100+.

When I look at my microphone on an oscilloscope, after my 20dB preamp, after the 0.1uF capacitor, directly on the input pin to the MSGEQ7, the signal looks fine. I see perhaps 2-3mV of noise, and can easily see speech or other sounds show up. Loud sounds show a peak to peak voltage of as much as a volt, so there is plenty of signal.

I heavily bypassed everything in the system; the microphone has both a 0.1uF and a 10uF capacitor on the power input, the preamp has a 10uF and a 0.1uF capacitor on the power input. The MSGEQ is not bypassed so thoroughly. Needless to say, my audio signal is quite clean, and the spikes showing up in my serial output of the received audio intensities does not seem to have any relationship to any events on my oscilloscope.

However, when I scope the output of the MSGEQ7 going to my arduino input pin, it shows the normal seven short pulses that you would expect. Usually these are jumping around a little bit, but not very much. However, when the arduino reports that the audio signal has gotten a lot louder, the output from the MSGEQ7 is noticeably jumping up as well.

Has anyone seen the MSGEQ7 misbehave in this way before? I have connected it up exactly as in its datasheet, and because this is all SMT work there aren't exactly any wire traces to pick up noise. I can't think of anything reasonable that could cause such bizarre behavior. I do have an ultrabright LED on my board, but this noise happens even when the LED is disabled. Even then, I put a 47uF capacitor to bypass the LED, and very carefully separated the supply voltage for the LED from all of the analog electronics.

It's quite frustrating, because when it is working "correctly", everything looks great and I can easily imagine implementing the algorithms I want. But it just periodically goes nuts, and I have no idea why. I tried lowpass filtering the audio inputs in software using an exponential rolloff, but I needed a time constant so long that the delay in detecting events made it unusable.

Hope someone out there has seen this before and has any ideas! Otherwise I'm off to call MSI tech support... although they've been horrible so far about actually picking up their phone =(

2

Small update; I bypassed the power line for the MSGEQ7 with a 1uF ceramic capacitor, and the behavior remains totally unchanged.

Is there something that the microcontroller could be doing that would make the MSGEQ7 unstable?

3

Have you had any luck?
I'm having issues with mine too.

All the channels seem to be about the same, it seems to get a signal, but it's not differentiating the low frequencies from the high.

I wish I had a scope to look into things further.

4

Yes, I "solved" the issue, but I don't know which of my solutions was the most important. I put a 1uF electrolytic and a 100nF ceramic capacitor on the reference voltage line going from my preamp to the mic power line to help make sure that was nice and stable, and I put a 10uF tantalum capacitor on the main power supply along with the 100nF ceramic. I should mention that I am using a 20dB fixed gain audio amplifier before the MSGEQ7 to try to help with noise, so I focused mostly on cleaning that side up to make sure there was a decent signal to the analysis chip. After that, checking it with an AC millivolt-scale fluke was sufficient to see significant changes in signal amplitude when speaking (5-50mV).

However, despite all of this fairly overkill analog stuff to clean things up, the MSGEQ7 did still report a quite high noise floor. On my system with the 1024 full scale 10-bit ADC or whatever (ATMEGA32U4/Leonardo), I was seeing typical DC amplitudes in all bands of around 50/1024. When I talked at the microphone, it would get in the 60-70 range, and yelling could get it over 100. But having a total signal to noise floor of only a factor of two is pretty odd, and I'm fairly sure it's internal to the MSGEQ7. I also personally found that the top two frequency bands were utterly useless; they were both too high to be interesting in most cases (i.e. music), and had so much random noise that I just ignored them in my code.

In order to make the MSGEQ7 do something useful, I basically implemented autogain and automatic noise floor detection. I haven't published the code formally yet since it's not well documented, but I have attached it here. It just takes the bottom band, allocates to red LED, next two go to green, and next two go to blue with the top two ignored. It also outputs the current values to the USB serial port for debugging, although I removed that in my more integrated version. This one was mostly just for testing the chip performance. It's all GPLv3, so feel free to borrow as you wish.

Honestly, I think that in my final version I will just get rid of the MSGEQ7 since it's an extra $3 part that doesn't really perform very well, sample the raw audio input, and use a FFT in software instead. I bet it will work way better, particularly if I just up the gain a bit on the input so that it's using closer to the full 5V ADC range. It will have finer resolution, better control, I don't think it's overwhelmingly computational intensive, and it will be cheaper (and probably higher quality). I haven't tried it yet though, so not entirely sure... I'll probably at least try bypassing the MSGEQ7 on my board first to see what happens when I use direct audio input.

audio_analysis_v2.ino (8.45 KB)