Rotary Encoder and Raspberry Pi 5

Question

I am using Raspberry Pi 5 And have connected a Pro Range 600 PPR Encoder(It is longer lasting and supposed to have better accuracy). However, when I rotate the encoder shaft, the values in the Raspberry Pi 5 fluctuate very rapidly and the clockwise/anticlockwise sensing isn't accurate either. So what should be the solution for accurate reading? I am considering adding an ESP32 module in the middle to better sense the encoder values which it would then pass onto the Raspberry Pi but I suspect there exists better alternatives. Surely others have faced similar issues with the rotary encoder, right?

Edit: Can anyone suggest a better Rotary Encoder suitable for these types of work? Provided that it interfaces with the Raspberry Pi.

Sincerely this is a real problem I am facing and would appreciate a good-faith response, thank you!

The connections are the following:

ENC A (White) Channel A Signal GPIO 17 (Pin 11) 1.2 kΩ pull-up to 3.3 V.

ENC B (Green) Channel B Signal GPIO 27 (Pin 13) 1.2 kΩ pull-up to 3.3 V.

The red wire is the Vcc (connecting to the 5-volt pin).

The black wire is the common ground pin.
rotary encoder I am using

The set-up:

edit2: the old , more detailed datasheet: enter image description here

• Voltage Spike: Comments have been moved to chat; please do not continue the discussion here. Before posting a comment below this one, please review the purposes of comments. Comments that do not request clarification or suggest improvements usually belong as an answer, on Electrical Engineering Meta, or in Electrical Engineering Chat. Comments continuing discussion may be removed.

Answer 1

The Youtube link you provided has a splash screen that is just plain wrong. The resistors drawn there do not pull-up. They are in series with the data line. A pull-up resistor would connect between data line and a supply line, and it does not do that in the splash screen. It does not match what ia written in data sheet how the resistors should be connected. It will not work, not reliably even if you enable internal pull-ups in software.

Do not assume that everything you see on Youtube is correct, they likely just made the video for subs and likes and may not even know or realize it's wrong or how it should be done. Never do a project without double-checking what is true, you might end up being trolled and damage your Pi or your PC if you make random connections.

Pull-up resistors should pull up, to a supply, which is why they are called based on their role to pull up the voltage. But not to 5V as RPI IO cannot tolerate 5V. The resistors must go betweeen 3.3V supply and data wire.

Having said that, the actual video does show that the resistors are connected as pull-ups, from data line and the 5V supply. But that is wrong as RPi IO pins do not tolerate being pulled up above 3.3V, so the video is just full of mistakes that should not be done when using the parts correctly.

• PiD: No, perhaps You dont realise ENC A (White) Channel A Signal GPIO 17 (Pin 11) 1.2kΩ pull-up to 3.3V ENC B (Green) Channel B Signal GPIO 27 (Pin 13) 1.2kΩ pull-up to 3.3V The Red one is the live wire, VCC (Red) Power Supply 5V The black one is the ground pin. The resistors arent connected to 5 volt.
• Justme: @PiD The white wire from encoder goes to resistor. Other end of the resistor goes to GPIO pin. If so, it is not a pull up resistor, it does not pull up to any voltage, it's just in series and wrong like in Youtube video still you posted. You have no resistors pulling up to 3.3V, you have nothing connected to 3.3V.
• PiD: Okay Sir. Would try it and let You know if this works.
• Justme: @PiD So the connections shown in the actual video are wired as pull-ups, the resistors are just incorrectly connected to pull-up to 5V which the Raspberry Pi does not tolerate, so it also is a bad circuit. But the "splash screen" for the video is definitely not drawn as pull-ups. So in general, this video shows two ways to do it wrong. One does not work and other makes slow long term degradation and damage. Provide 5V power and ground to encoder. Connect the data wires directly to IO pins. Pull IO pins high to 3.3V. Or, enable internal pull-ups in software, it might work but they may be weak.
• PiD: would rearrange the circuits tomorrow. Would be able to report the outcome.

Answer 2

Doesn't the Raspberry Pi 5 have an IO voltage of 3.3 volts?

According to the data sheet you linked, the minimum operating voltage of the encoder is 5 volts: -

enter image description here

I mean, it might be OK but the data sheet is very limited on what it says.

• PiD: Yes. They updated the datasheet. Previously it used to be way more detailed. I will upload the old one if I can find it.
• Drew: He is supplying it 5V, and the encoder has NPN output so he just has to pull up the outputs to 3.3V and that problem is solved.
• Andy aka: @Drew you might be right and we shall see when PiD introduces the old (and more detailed) data sheet. If it happens to be right then I shall withdraw the suggestions above.
• Drew: @Andyaka It says npn output right in the picture you posted.
• TonyM: @Drew, it's termed an open collector output, rather than an NPN output. The datasheet says NPN to indicate the typical 'on' voltage drop (0.3V, unlike mV for MOSFET) but 'open collector' is the relevant part.

Answer 3

You may find that this encoder never works accurately with the raspberry pi.

Reading encoders is trickier than it sounds. You have to sample the inputs at a significant higher rate than the step frequency, and you need a non-trivial algorithm to make sense of the results.

The raspberry pi will have a VERY hard time sampling at a high rate without interruptions over a long period of time.

It will be much more reliable to have the encoder connected to a dedicated ic, or even just an arduino. Then you can have the raspberry pi read position from that at it's leisure.

• PiD: Yes. Thats why I am thinking of an ESP 32 , which is Arduino based. Do You think it would work?
• PiD: Also I wonder if this is a sufficiently good debounce algorithm? electronics.stackexchange.com/questions/632802/…
• PiD: Do You know of any encoder which would detect the rotation better with raspberry pi5?
• Drew: You don't need something as sophisticated as the ESP32 but I suppose that would work. The encoder isn't the problem, although there may be some with a built in processor.
• Jens: I used LS7366R as dedicated decoder with SPI interface.

Answer 4

You've now posted the relevant datasheet for your part. You'd also posted a link to this YouTube video, which is very much a well-intentioned and generous amateur somewhat sketchily showing how they'd got it working for Thonny.

This diagram from the video recommends connecting 1 kΩ series resistors to the RPi5 GPIO, while contradicting itself by labelling them pull-up resistors. I wouldn't go by that.

enter image description here

For the record, things like motor encoders with open collector outputs often include series resistors as protection, to limit the output's sink current in case of an accidental connection to a supply or just too low a pull-up resistor. Maybe that's the video's misguided intention but it's not what it's doing.

---

Moving on to your encoder...

As the below diagram from your question's datasheet shows, each of the encoder 'NPN' open-collector outputs has a series protection resistor in its emitter path. So you just need pull-up resistors and the right sampling rate.

enter image description here

For the pull-up resistors, the datasheet diagram states the max. encoder sink current is 35 mA. Using 3 mA will give a sharp rise even with the longer wires. Therefore a 1 kΩ pull-up to 3.3 V on encoder A and B outputs will be a good value.

The datasheet also specifies an encoder Z output, which is a home position pulse asserted once per revolution. It depends on your application as to whether you want to connect that or not. Generally, do connect it so that only software has to be changed in future to use it or not.

For the sampling rate, the datasheet states a motor speed of 5000 RPM max. and 600 PPR (Pulses Per Revolution).

So the pulse rate is (600 x 5000 / 60) = 50,000 PPS (Pulses Per Second) max.

Making the pulse interval 20 μs min.

For a 50:50 square wave with no noise, 2x oversampling would detect both phases correctly. The minimum sampling rate would then be 10 μs.

• The video uses 1 ms sampling so it can only keep up with speeds below about 50 RPM, which produce 2 ms pulses. That may explain your original problems reading the speed.

It would be better to:

1. Oversample much faster so the speed can be reliably measured and acted on, not just be detected. Oversampling at 10x would give you good values for speed variance control. That depends on your max. speeds used. At max. motor speed, it needs 1 μs sampling which would either swamp or overload your RPi5, stopping it doing much else.

2. Use a RPi5 GPIO with counter/timer capability to measure the pulse widths and average them in software to produce speed measurements. Again, this gives a lot for your RPi5 to do as the max. speed goes up. Note that the optical encoder edges will not contain noise that needs debouncing. It may happen at very low speeds but it's unlikely with a 600 PPR encoder in practical use.

Your suggestion of another MCU board doing encoder measurement only, using either method, would appear worthwhile if running at the motor's higher speeds.

Myself, I'd say a CPLD/FPGA would be a better choice than MCU as they're more suited to this sort of task (processing fast parallel streams of continuous data) and would deal with the max. speeds with ease. However, if you're using Thonny because you're not experienced enough in Python, you're unlikely to be skilled in VHDL/Verilog to do this. As an aside, it's well worth learning to do so in future, though.

• PiD: the website provides a sample code for sampling although that's for arduino. Checking in on this.