I want to speed up the MSGEQ7 reading on an AVR.

Archive FastLED Archive
1

I want to speed up the MSGEQ7 reading on an AVR. So i think about manipulating the prescaler as described here: http://www.microsmart.co.za/technical/2014/03/01/advanced-arduino-adc/
Would this action affect any FastLED functions?

The Datasheet says (last page at the very end) reading of one band can be done in 72µs (tss) plus 3*18 µs for the 3 strobe pulse periods (ts) = 126 µs to read the first band (63Hz) only…
https://plus.google.com/communities/109127054924227823508
http://www.microsmart.co.za/technical/2014/03/01/advanced-arduino-adc

2

I’d say go for it- FastLED should work fine as long as the main clock speed is unchanged. I think! Let us know!

Also: some other ideas to avoid doing 8 slow analogRead’s every time through your loop():

  • only read the eq every Nth time through your loop, or every N milliseconds. Store the previous values in an array and just use them. Thinking about it some more, this is probably simplest. Decide how many samples per second you want (eg, 30? 100?), thus how many ms ‘old’ you’re willing to let a reading be (eg 33ms and 10ms respectively), and just keep cached readings with a timestamp. When they get too old, read new ones.
  • Instead of reading all eight values from the msgeq7 data every time, only read ‘C’ channels of the msgeq’s data each time through the loop (and keep an array in memory of the most-recently read values from each channel). If ‘C’ is four, read the top 4 channels the first time through, then the bottom 4 channels, and presto: you’ve cut your analogRead time per loop in half. You could probably even try just reading ONE channel each time through the loop!

Basically, in addition to your suggestion to “do work faster”, these are suggestions to “do less work” each time though the loop.

Let us know what you try and what the tradeoffs are!

3

Are you still looking for a fast analog read on Arduino?
This takes 16µsec per reading:
http://forum.arduino.cc/index.php?topic=6549.0

I haven’t used it together with FastLED and don’t know whether it messes with the timings in the library.
On the other hand what do you want with the heap of data?
Every 46µsec you get one value; every 0.322 milliseconds a complete set of 7 values. This is every second 3100 sets …
Cheers!

4

Hi, it turned out that the main problem is the unsettled MSGEQ7 signal itself. I tryed several methods to speed up the sampling, but with anything faster than 20 µs (between strobe and read) the results become more and more random. Not sure if this is caused by the MSGEQ7 design or by wire impendance and capacity itself.
The idea behind the fast sampling was, that it would be possible to get new audio data WHILE calculating one frame (not just one data set per frame) and react by this way faster to audio events, because the update rate would not be limited by the fps anymore… So the short answer to “why?” is “get even more snappy animations”.

5

have a look at the signal timing of the MSGEQ7

At 20µs the signal has just reached its peak. If you try to sample faster the results must become random.
The bottleneck is analogRead; this takes around 110µs and in that time no other code can be processed.

Try FastAnalogRead and if you experience still noise use analogReference(INTERNAL)
That gives you an internal reference voltage of 1.1V
More details here:
http://meettechniek.info/embedded/arduino-analog.html

Now you can go really snappy!