I want to datalog some rpm pulses from a motor. The motor may run up to 50,000 rpm.
I want to have more than one pulse per revolution. I wanted to know how many pulses per revolution i could use.
100 pulses per rev would give me high accuracy.
If the processor speed is 16 million cycles per second then the arduino should have no problems?
Any advice welcome
Yes at 100 pulses per second the arduino should have no problem.
It might be best to look at using interrupts to read the time between the pulses.
Grumpy_Mike:
Yes at 100 pulses per second the arduino should have no problem.
It might be best to look at using interrupts to read the time between the pulses.
I am no expert but wouldn't using the PulseIn() function be better and easer.
And with it being able to read 1pulse per 10microseconds that would be exactly what you needed.
Let's see....50,000 RPM is 834 rotations per second, multiplied by 100 pulses/rotation gives 83,400 pulses/second. That's about 12 microseconds between pulses.
That's definitely "fast" but probably doable as long as your code doesn't have plans to do much of anything else.
A speed of 16 MHz for the Arduino sounds high but it takes several instructions to handle an incoming pulse, then you have to save it somewhere, and each instruction takes 2-3 clock cycles (on average) so it is not as high as it seems in practice.
--
The Rugged Circuits Yellowjacket: 802.11 WiFi module with ATmega328P microcontroller, only 1.6" x 1.2", bootloader
I am no expert but wouldn't using the PulseIn() function be better and easer.
No because while you use that function the arduino is not doing anything else. By using interrupts you free up that time to do something with the data you are getting.
Grumpy_Mike:
I am no expert but wouldn't using the PulseIn() function be better and easer.
No because while you use that function the arduino is not doing anything else. By using interrupts you free up that time to do something with the data you are getting.
Ahh
Last time I played with microseconds, they came in units of 4, so don't expect very good resolution down at the 12microsecond range of things.
(It counted: 4, 8, 12, 16, etc.)
you might consider an encoder with two outputs:
some code to get started - http://www.arduino.cc/en/Reference/AttachInterrupt
#define PPR 120 // angle 3°
volatile unsigned long count_rpm = 0;
volatile unsigned uint8_t count_angle = 0; // byte can hold 0..255 so a PPR of 240 (2°) is theoretically possible
void setup()
{
attachInterrupt(0, IRQ_RPM, RAISING);
attachInterrupt(1, IRQ_ANGLE, FALLING);
}
void loop()
{
// process the counters, act, display etc
}
void IRQ_RPM()
{
count_rpm++;
}
void IRQ_ANGLE()
{
count_angle++;
if (count_angle >= PPR) count_angle = 0; // count_angle will always be between 0.. PPR-1
}
Thanks for the advice guys
i will look at going for 60 pulses per rev
= (50,000 / 60) * 60
= 50,000 cycles per sec
= 20 micro seconds
the 50,000 rpm is worst case senario most motors will turn at much lower speeds
the advice on the encoder is a very good idea
the only down side is the cost of an encoder against a hall effect sensor
Thanks to my (slightly stupid) question, I found you can get rottary encoders that work well out of old "deskjet" type printers.
http://arduino.cc/forum/index.php/topic,63448.0.html
most also come with a few standalone that do not have the engine attached but do have the sensor and (what do you call it anyway) plus the ones with the engine to.
A nice presentation about encoders - http://products.cui.com/CUI_AMT103-V_Product_Training_Presentations.pdf?fileID=6203
i will look at going for 60 pulses per rev
Do you need that degree of control? You are only making life more difficult for going for more pulses per rev. What about just 8?
the more pulses the better
however it is less important on the 50,000 engines - i could actually use one pulse per rev at those rpms in retrospec due to the nature of the motor
so its probably best to have two options and allow the use to select the type of triggerwheel
very interesting that you can get a shaft encoder from an old printer !
i know you can also get good optical sensors from an old mouse
Gadget999:
the more pulses the better
What is the basis of that statement? What are you doing with the RPM value and what kind of resolution do you need on the RPMs to effectively accomplish whatever it is you are doing with the value? Any resolution beyond what is necessary to accomplish the task is not only simply wasted, but adds complexity, time, and cost to a project with no benefit. So, just enough pulses to accomplish the task is the best and any more than that is in fact, not better.
i was recommended 100 pulses per rev by a guy who has been doing this stuff since the 1960's
I too share your concerns, but trust this guy 100%
The question still remains, what are you doing with the value that requires that kind of resolution?
How about adaptivity?
Have not thoughed about how to build that (sort of digital gearbox I guess)
the number is used to determine the firing angle of an engines injectors
the engines that rev to 50,000 rpm use carbs so the angle is not important
KE7GKP:
i was recommended 100 pulses per rev by a guy who has been doing this stuff since the 1960's
the number is used to determine the firing angle of an engines injectorsSo how did he do this back before Arduino (or micro-controllers, or even computers, for that matter)?
hmm barcodes, atms, apalo 11, avionics
sry there was some of it at least
AND THE FIRST WORKING LASER
jraskell:
The question still remains, what are you doing with the value that requires that kind of resolution?
It's quite hard to offer sensible suggestions without having this answered