next topic »

[on:]

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

[Reply #1 on:]

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.

[Reply #2 on:]

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.

http://arduino.cc/en/Reference/PulseIn

[Reply #3 on:]

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

[Reply #4 on:]

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.

[Reply #5 on:]

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

[Reply #6 on:]

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.)

[Reply #7 on:]

you might consider an encoder with two outputs:
- one that pulse once per revolution  => RPM
- one that pulses X times per revolution => ANGLE

some code to get started - http://www.arduino.cc/en/Reference/AttachInterrupt

Code:

#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
}

[Reply #8 on:]

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

[Reply #9 on:]

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.

[Reply #10 on:]

A nice presentation about encoders - http://products.cui.com/CUI_AMT103-V_Product_Training_Presentations.pdf?fileID=6203

[Reply #11 on:]

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?

[Reply #12 on:]

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

[Reply #13 on:]

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.

[Reply #14 on:]

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%