@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?
@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.
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 :)
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'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?
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.
Drones are, in essence, flying autonomous vehicles. Pros and cons surrounding drones today might well foreshadow the debate over the development of self-driving cars. In the context of a strongly regulated aviation industry, "self-flying" drones pose a fresh challenge. How safe is it to fly drones in different environments? Should drones be required for visual line of sight – as are piloted airplanes? Join EE Times' Junko Yoshida as she moderates a panel of drone experts.