3
\$\begingroup\$

As i found so far there are two types of incremental encoders for rotational position/speed calculation/detection application.

1)magnetic incremental encoder ICs eg:- SSI, SPI or I2C interface , 8bit to 16bit resolution up to 30000rpm, also these are programmable.

2)Absolute or incremental encoder mechanical type eg:- 10000rpm 2500ppr

which type is better ? in terms of performance, reliable, life time, error % at higher rpm (higher frequencies)?

I am going to use encoder to measure speed and crank angular position of an engine at 10000rpm using FPGA

\$\endgroup\$
  • \$\begingroup\$ How much resolution into 'rotational position' do you actually need? Do you seriously need it divided into 2500 ppr? Or could you use half that? Or? (A project I worked on once was about instrumenting the sparkplugs with sapphire lightpipes so that the internal combustion flame-front could be observed in real-time.) Do you need a "home pulse" once per rev, also? P.S. I can see you are thinking closely here, as you talk about "% error at higher RPM" and that will be an issue -- good catch. \$\endgroup\$ – jonk Jun 7 '17 at 16:33
  • \$\begingroup\$ @jonk i am working on project where i need to plot combustion pressure against to crack angular position. as in magnetic encoder ICs 16bit angular position can go for 360/65536 = 0.000593 something. also there are 30000rpm ones.in mechanical type Quadrature encoder 2500ppr-->10000ppr 360/10000 = 0.036 . which type is better? cost has considerable difference IC will be cost 8$ while mechanical type encoder costs around 300$ \$\endgroup\$ – gobsa89 Jun 7 '17 at 16:55
  • \$\begingroup\$ If by "$8 IC" you mean that optical interrupter, it won't get you there. I gather you need performance on the order of \$\approx 1\:\textrm{MHz}\$ pulse rates (and perhaps even an order more.) That certainly brings in the issue of transducer speed as RPMs get higher. The question may turn less on the delay itself than on your ability to predict that delay (it's variability moment to moment.) I think you really need to spend more time writing out lots more detail about exactly what you hope to achieve. Why are you plotting one against the other, for example? What are you actually doing? \$\endgroup\$ – jonk Jun 7 '17 at 17:14
1
\$\begingroup\$

Which technology, and cost involved, really depends on more than just performance.

If this is for automotive and is intended to be used for operational use, i.e. not just testing, you should stay clear of optical or mechanical encoders.

Optical will be hard to keep sealed and clean in the grunge that is an engine compartment, and mechanical encoders are basically just a rotary switch which are also easily contaminated and have wear issues.

Magnetic is probably your best bet.

However, rather than using a complete encoder, using a hall effect sensor to detect the cogs on your engines flywheel, assuming that gives you enough angular resolution, with another somewhere to detect once per revolution, would be a simpler approach.

Actually, if your engine is fairly modern it may already have such sensors already installed.

\$\endgroup\$
0
\$\begingroup\$

There are also optical encoders- which you left out of your analysis.

In any case, for what you're talking about, you wouldn't use an encoder. You would use something that can provide a pulse-per-revolution signal. At 10000rpm, you don't really care about the position of a shaft, just how long it takes the shaft to spin around.

I recomment some sort of reflective optical interruptor, with a piece of reflective tape on the shaft. Something like http://www.mouser.com/ProductDetail/Honeywell/HOA1406-001/?qs=sGAEpiMZZMugITGdVIKd7kxlQJ2OO9ByTTSvC%2f%2fB7cY%3d enter image description here

There is an LED which will reflect off the tape, and activate a photosensitive element. Some have analog outs, some digital. In any case, you would use some sort of capture peripheral/timer to time rising edges, and use that interval to calculate shaft speed.

If you REALLY need an encoder -- you may have trouble keeping up with a quadrature encoder at those rates (though you will have an easier time because you're using an FPGA). You should be considering some sort of absolute encoder, preferably with a latch, where you can poll it for position.

\$\endgroup\$
  • \$\begingroup\$ i need both position and speed. which one is better? those ICs are aound 8$ . but a mechanical type encoder is around 300$. is mechanical type encoder better? \$\endgroup\$ – gobsa89 Jun 7 '17 at 16:15
  • \$\begingroup\$ I honestly need to know a whole bunch more about your specific application to address the position and speed thing. It would help to know exactly why you need position and what you're trying to accomplish. At 10000 rpm, its hard to believe that the exact position of the shaft is a key issue. In fact, if you have a reliable PPR, you know the position with some certainty once per rev, and you can extapolate position from the speed. "Better" makes no sense without a better description. \$\endgroup\$ – Scott Seidman Jun 7 '17 at 16:43
  • \$\begingroup\$ @gobsa89 -also, figure out what your speed requirements are and figure out if your busses will be able to keep up. \$\endgroup\$ – Scott Seidman Jun 7 '17 at 16:44
  • \$\begingroup\$ @gobsa89 take a peek at my edit, concerning the diff between absolute and relative encoders. \$\endgroup\$ – Scott Seidman Jun 7 '17 at 17:06
  • \$\begingroup\$ Also, How well do you need position? You can even use 4 of these reflective devices, and that will give you quadrant info with OK interpolation in between. \$\endgroup\$ – Scott Seidman Jun 7 '17 at 17:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.