Just call me the "King of Visio" because all of the drawings in this blog -- including the block diagrams, schematics, and especially the ones of the breadboards -- were lovingly created by yours truly.
I'll go along with that Max, awesome diagrams. I'm still woefully inadequate at Visio.
One thing that occurs to me here, especially after watching the video of your LEDs flickering away. True VU displays - and the LM3915 - have a logarithmic response, whereas MCU ADCs are linear. What does the MSCEQ7 do - the datasheet says the DC output for each band is just an amplified peak detected amplitude of the input - but is it linear or logarithmic? As it does not say, I'm assuming linear, and the way your LEDs are flashing I think goes along with this.
If it is linear, you could do a log conversion in software, either mathematically or via a look-up table. I seem to remember this was touched on in a previous blog - am I right?
Max, another query - the MSGEQ7 timings in your article are all given as "minimum". I assume that as long as you stick to these minimum timings you can extend them a bit (for example if your MCU is busy doing something else, or if it takes a long time to do the ADC conversion) without problems? And as long as you read the ouput at least to (settling time) after the strobe goes low (and before the next strobe pulse) you are ok - I notice the minimum strobe pulse width is less (18us) than the settling time (36us) - which implies you can read the data even if the strobe has gone back high? (ie you could actually read data during the purple times in your diagram?)
I'm curious if you could actually push the MSGEQ7 functionality into the arduino itself. The max frequency is 16KHz, so you could probably get away with a 3~4x oversampling ADC and pushing it through digital filters running in firmware.
There doesn't seem to be a lot of information on the filter charactersitcs on the datasheet so I'm guessing a 2 or 3-tap IIR should do it which will amount to somewhere around 30 cycles(if there's a hardware multiply, sadly not at all familiar with Arduino cores) for each bandpass. That will amount to 8*30 which is 240 cycles roughly for all the 8 parallel bandpasses to run. Plus some latency for the ADC interrupt to run and grab, but that happens only once every cycle so lets put another 20 cycles for that. Since the actual processor is running at 80MHz, you should still be able to have something around 1200 cycles(assuming a 4x oversampled ADC so it gets a new sample at 64ksps) to work with which should leave plenty of processing room to spare for the PWM's to dim according to the filtered output.
2 channels could may be fit in too but I'm presuming too much at this stage :)
@David: ...True VU displays - and the LM3915 - have a logarithmic response, whereas MCU ADCs are linear. What does the MSCEQ7 do...
The data sheet doesn't say -- the vertical frequency response axis is simply annotated 0 at the bottomn and 20 at the top.
Actually, thsi is something I can test using my frequency generator -- I can put in a 0.5V peak-to-peak signal, 1.0V pk-pk, 1.5V pk-pk, and 2.0V pk-pk and see what I get -- I'll do that this coming weekend and report back.
@David: I notice the minimum strobe pulse width is less (18us) than the settling time (36us) - which implies you can read the data even if the strobe has gone back high? (ie you could actually read data during the purple times in your diagram?)
As you say, the minimum strobe pulse of 18us is less rthan the outpout settling time of 36us, so I too assume that you can read the data even afgter the strobe has gone back high (although in my software I delay 40us after the strobe goes low before doing the read).
However, you can't read data during the purple times in my diagram because the minimum tss (strobe-to-strobe delay) is 72us.
Hmmm -- looking at my original diagram (which I re-drew from the one in the data sheet), I see what you mean -- that original diagram implies that the data goes invalid on the rising edge of the strobe.
Maybe the following depiction is better -- what do you think?
@mithrandir: I'm curious if you could actually push the MSGEQ7 functionality into the Arduino itself.
I'm sure you could achieve somethging like thsi in the Arduino -- I've seen software DSP versions of spectrum analyzers running on Arduinos. My problem is that this is going to be part of my BADASS Display, so I'll be using my Arduino to drive the display itself.
I'm actually running this on a chipKIT MAX32, which is more than capable of running sophisticated DSP algorithms in software -- that's the longer term plan -- it was just that when I was introduced to these MSGEQ7 chips I thought I'd give them a whirl.
My interest is piqued now. I'll see if I can get just the front end filtering running on my Pioneer kit. Alas I don't seem to have many LED's with me right now so time hunt down, scrounge or steal a few!
@mithrandir: I'll see if I can get just the front end filtering running on my Pioneer kit.
Is that a PSoC 4 Pioneer kit, or are you talking about something else?
Alas I don't seem to have many LED's with me right now
I buy bags of them at a time because I seem to use them in so many things.
Weekend project, here I come :)
Have a great time, email me to tell me how you get on (email@example.com and firstname.lastname@example.org), keep notes and take pictures -- maybe you could even write your experiments up as a column for me to post here on EETimes