will be much more accurate because the period will be measured to an accuracy of 62.5 nS.
62.5 ns is true if you use HW timers, if you use micros() the accuracy goes in steps of 4 micros().
Putting all the timing math in the IRQ gives something like this. Note I removed the counter in the IRQ routine to get max update frequency.
Drawback of this method seems to be that you cannot measure an RPM of zero. => additional code needed to check this.
In general low (<60) RPM's will result in a low (> 1s) update frequency ==> more pulses per rotation needed [for every measure method]
//
// FILE: rpm4.pde
// AUTHOR:
// DATE: 21-oct-2012
//
// PUPROSE: updates rpm after every pulse
//
volatile boolean newRpm = false;
volatile unsigned int rpm = 0; // assuming not above 65535
volatile unsigned long time = 0;
volatile unsigned long timeold = 0;
void setup()
{
Serial.begin(115200);
attachInterrupt(0, rpm_fun, FALLING);
}
void loop()
{
if (newRpm)
{
newRpm = false;
Serial.print(millis());
Serial.print(", ");
Serial.println(rpm);
}
}
// every pulse a new rpm value,
void rpm_fun()
{
time = micros();
unsigned long duration = time - timeold;
rpm = 60000000UL/duration;
timeold = time;
newRpm = true;
}
If the baudrate influences the RPM it might be that the wires influence each other.
You could check if you have the same problems if you take IRQ1 (pin 3)
================
What is strange is that the numbers are much higher than you expect [about 5000]. Is this correct?
Do you have a datasheet of the reed switch used?
What is its upper switch frequency?
First thank you for all the replies as a newbie I really appreciate this forum.
Glad the HW ok
Re baud rate I changed to IRQ1 (pin 3), this work fine on 9600 but on 115200 the readings are all over the place??
Re reed switch I cant find data sheet but what I have done is change the switch for another and this is the result and is no more than 1% different to the electronic tacho.
rpm37
rpm4363
rpm4332
rpm4363
rpm4347
rpm4347
rpm4580 ^^^^^^^^ Here
rpm4332
rpm4363
rpm4332
rpm4363
rpm4363
rpm4562 ^^^^^^^^^ Here
rpm4347
rpm4347
rpm4347
rpm4363
rpm4347
rpm4347
rpm4562 ^^^^^^^^^^ Here
rpm4347
rpm4347
rpm4580 ^^^^^^^^^^^ Here
rpm4347
rpm4347
rpm4347
rpm4347
rpm4347
rpm4363
Just the few disparities marked. Also tried at lower speeds and slightly higher, the results were as good.
Serial output uses interrupts, and at a higher baud rate it will use more of them.
But a string of the same length will generate the same amount of interrupts, independent of the baudrate? Or did I miss something in class?
Assuming the same amount of characters per second, BTW
I'm from Argentina, I am working with Hall sensors, at an advanced level, I care about your ideas. I am new to the forum arduino over time I will learn to use it well. Four years ago I started working with arduino
care with the baud rate when one wants to measure many rpm, speed serial port of the microprocessor removes arduino speed
That are quite smooth readings esp compared to the previous ones. You can smooth these readings even more in the loop() e.g. by only adjusting for 25% of the new rpm value;
loop()
{
if (newRpm)
{
newRpm = false;
int smoothrpm = (3*smoothrpm + rpm)/4; // weighted average
Serial.print(millis());
Serial.print(", ");
Serial.print(rpm );
Serial.print(", ");
Serial.println(smoothrpm );
}
}
robtillaart:
That are quite smooth readings esp compared to the previous ones. You can smooth these readings even more in the loop() e.g. by only adjusting for 25% of the new rpm value;
loop()
{
if (newRpm)
{
newRpm = false;
int smoothrpm = (3*smoothrpm + rpm)/4; // weighted average
Serial.print(millis());
Serial.print(", ");
Serial.print(rpm );
Serial.print(", ");
Serial.println(smoothrpm );
}
}
int smoothrpm = (3*smoothrpm + rpm)/4; // weighted average
I changed to
int smoothrpm = ((3*smoothrpm + rpm)/4)*4; // weighted average
Serial output uses interrupts, and at a higher baud rate it will use more of them.
But a string of the same length will generate the same amount of interrupts, independent of the baudrate? Or did I miss something in class?
Assuming the same amount of characters per second, BTW
Er, yes you are right. I was wrong to say it will use more of them (assuming you are printing the same string, per second). If you are printing non-stop you would use more per second.
I would suggest though, that at a higher baud rate, to empty the serial buffer of the string you have put there would involve a lot of interrupts in quick succession. Once the serial interrupt starts, the higher-priority external interrupt has to wait. This is likely to throw out the timing it takes. Even at a lower baud rate this would be a problem, it's just less likely the interrupts would coincide.
maybe a smarter solution then using a reed switsch(problem contact bouncing at higher speed) is using a Single-Chip-Encoder, like the iC-MH/MH8, and measure the change between two absolute position readings from the magnetic rotary encoder, or the time between two zero pulse. You might look at this two application: http://www.ichaus.biz/wp2_simple_measurement and http://www.ichaus.biz/wp_boost_performance .
Hey,
I suggest that you do not use the attach interrupt function at all,try using the pulseIn function,as what you want the is the pulse,whenever the magnetic fields react with the sensor.
jay2012:
Hey,
I suggest that you do not use the attach interrupt function at all,try using the pulseIn function,as what you want the is the pulse,whenever the magnetic fields react with the sensor.
What do others think?
Is it possible to add another interrupt function, again RPM but for a slow shaft speed (circa 50 to 100 rpm)?
I actually made one rpm sensor for my CVT using a pulse in function and it gives very exact values,..i can help you out wit it,..pulse in does give you the duration,all you do is take the duration for the "on" time and the "off" time,..this will give you the sampling time.Now you have time,so you can get frequency,and then rpm.
The driver side of my side has an idling speed of about 1800 rpm,and i get the value at 1805 rpm ,constant till i throttle the engine,and gives a value of 3760 rpm ,for a max theoritical value of 3800 rpm.
so i can tell you that pulseIn works for sure
Pulsein() works very well I know but as I stated above it has some drawbacks, most important it blocks the code, and to lesser extend you will not necessary get all pulses. This latter may or may not be important. Example if you only want to have speed it does not matter much. If you also want to have the distance measured you need every pulse.