Go Down

Topic: MSGEQ7 function without delay statments (Read 938 times) previous topic - next topic


Jan 14, 2013, 10:50 am Last Edit: Jan 14, 2013, 01:34 pm by EVP Reason: 1
After reading the post on BPM this morning i decided to post a function for the MSGEQ7. The example that most people first try has lots of Delay statements in it, this is ok for the demo but you will probably not want them there when you integrate it into your existing project.
I don't know if this is the best way to do it but i think it's probably easy to understand for beginners like me.

Basically you just keep calling EQScan after 14 call's it will have filled spectrumValue[] with the data. Instead of using Delay you are doing the other stuff in your program instead to cause the delay

Code: [Select]

 EQ with no delay


byte spectrumValue[7];

void setup() {                
 pinMode(A3, INPUT); //analogPin
 pinMode(A2, OUTPUT); //strobePin
 pinMode(A1, OUTPUT); //resetPin

 digitalWrite(A1, LOW); //  reset
 digitalWrite(A2, HIGH);//    

void loop() {

 // what ever you want to do, i think it would be best to do somr thing or put in a delay


void EQScan(void){

 static boolean ReadStrobe=0;
 static byte Count=0;

    digitalWrite(A1, HIGH); // reset
   digitalWrite(A1, LOW);

 if(ReadStrobe==0){   /// if ReadStrobe==0 then set the strobe and return else read analog input
   digitalWrite(A2, LOW);
   spectrumValue[Count] = analogRead(A3); /// 
   digitalWrite(A2, HIGH);


The delays matter because the MSGEQ7 decays the stored values a certain amount each time you strobe through. If your other code takes varying times to run, then your results from the MSGEQ7 will not be consistent.
Unique RGB LED Modules and Arduino shields: http://www.macetech.com/store


True. I think the time it takes to run is quite consistent for what i used it for so it seemed to work well enogh. But i didnt think about how inconsistent delay times would affect it.

Go Up