It stated there that: 1 mile per hour is equal to 1600 revolutions per hour.
My Sensor:
1 pulse per rotation, 2.5 mph per Hz
I wondering if somebody can help me change the code to fit my Sensor.
#include <math.h>
#define WindSensorPin (2) // The pin location of the anemometer sensor
volatile unsigned long Rotations; // cup rotation counter used in interrupt routine
volatile unsigned long ContactBounceTime; // Timer to avoid contact bounce in interrupt routine
float WindSpeed; // speed miles per hour
void setup() {
Serial.begin(9600);
pinMode(WindSensorPin, INPUT);
attachInterrupt(digitalPinToInterrupt(WindSensorPin), isr_rotation, FALLING);
Serial.println("Davis Wind Speed Test");
Serial.println("Rotations\tMPH");
}
void loop() {
Rotations = 0; // Set Rotations count to 0 ready for calculations
sei(); // Enables interrupts
delay (3000); // Wait 3 seconds to average
cli(); // Disable interrupts
// convert to mp/h using the formula V=P(2.25/T)
// V = P(2.25/3) = P * 0.75
WindSpeed = Rotations * 0.75;
Serial.print(Rotations); Serial.print("\t\t");
Serial.println(WindSpeed);
}
// This is the function that the interrupt calls to increment the rotation count
void isr_rotation () {
if ((millis() - ContactBounceTime) > 15 ) { // debounce the switch contact.
Rotations++;
ContactBounceTime = millis();
}
}
I have been adviced by people here to remove the hardware de-bounce and do it in code.
Did they explain why you should do that? What problems are you having with the hardware debounced code?
There are several problems with the cactus.io sketch. The use of a lockout period within the ISR is OK, but the collection of interrupt counts during a delay() period surrounded by sei() and cli() can create problems. There may be other parts of the code(like Serial printing) which rely on interrupts being enabled In a simple sketch this all might work, but it is really not very good coding practice.
Can you post the code you are currently using and a schematic of the hardware debounce.
I have read a logical explanation for not using hardware debounce for reed switches. It is that the tiny contacts can be damaged over tiime by the tiny arcs generated by the cap. That may be more important in an application like wind speed measuring (possibly many cycles per second).
My code for the hardware de-bounce is taken from here:
the only thing changed is the INPUT instead of input pullup.
But as I said, I am trying to get rid of the hardware de-bounce.
I got the new code workingwith these changes:
Rotations = 0; // Set Rotations count to 0 ready for calculations
attachInterrupt(digitalPinToInterrupt(WindSensorPin), isr_rotation, FALLING); //turn interrupt back on
delay (3000); // Wait 3 seconds to average
detachInterrupt(digitalPinToInterrupt(WindSensorPin)); //shut off wind speed measurement interrupt until done communication
WindSpeed = Rotations * 4.0/3.0
but it's not accurate in low speeds because it's counting full revolutions, somebody told me I should:
change the algorithm so that it determined the time for 1 complete revolution (in milliseconds), works out a rolling average over a number of samples and presents the result.
The problem with your debounce is the delay(). Google "arduino software debounce" and look for code that uses millis() instead. Like here. There are also libraries to help with software debounce. Like the Bounce2 library.
I believe that you are better modifying the code from ForceTronics you presently are using to add the debounce lock out to the interrupt service routine.
void anemometerISR() {
unsigned long cTime = millis(); //get current time
if (!start) //This is not the first pulse and we are not at 0 MPH so calculate time between pulses
{
// test = cTime - sTime;
if (ctime - sTime >= 15)//change lock out for debounce
{
pulseTime = (float)(cTime - sTime) / 1000;
culPulseTime += pulseTime; //add up pulse time measurements for averaging
avgWindCount++; //anemomter went around so record for calculating average wind speed
sTime = cTime; //store current time for next pulse time calculation
}
}
start = false; //we have our starting point for a wind speed measurement
}
groundFungus:
I have read a logical explanation for not using hardware debounce for reed switches. It is that the tiny contacts can be damaged over tiime by the tiny arcs generated by the cap. That may be more important in an application like wind speed measuring (possibly many cycles per second).
A small resistor to limit the cap's discharge current should stop that from happening. Indeed every time the contacts close the cap is shorted, creating a current spike.
@Bamanio: You making a mess by cross posting. The same topic is discussed here and you are starting to get the same answers. I have already supplied you something today in there which may solve the debounce problem:
