Incorrect Encoder tick counts using Raspberry Pi

Question

Hi I have a DC motor with encoder which has a PPR count of 990 (No load RPM = 107). However, I tried to read the number of ticks (on a Raspberry Pi 3B) by rotating the wheel 1 turn and I get a PPR count way too low, let's say 200 (It varies each time). The following is my Python code.

import RPi.GPIO as GPIO
from time import sleep

GPIO.setmode(GPIO.BCM) 

enc_L = 4; tick_L = 0;  # Left motor encoder pin

sleep(1)

def my_callback_L(channel):
    global tick_L
    tick_L+=1
    print(tick_L)

GPIO.setup(enc_L, GPIO.IN, pull_up_down=GPIO.PUD_UP)

GPIO.add_event_detect(enc_L, GPIO.RISING,callback=my_callback_L)

Now I tried to do the same thing on an Arduino Nano and to my surprise, the Nano gave exactly 990 PPR. The following is my Arduino code.

const int enc_pin1 = 2;

volatile long ticks1 = 0;

int tpr = 990;     

void setup() {
  // put your setup code here, to run once:

  Serial.begin(9600);

  pinMode(enc_pin1, INPUT_PULLUP);

  attachInterrupt(digitalPinToInterrupt(enc_pin1),countTicks1, RISING); 

}

void loop() {
  // put your main code here, to run repeatedly:

}

void countTicks1(){
  ticks1++;
  Serial.println(ticks1);

}

So my question is why is the Pi missing encoder counts? Is it due to bouncetime? Or is there some other issue?, and how do I get the correct tick values? I need it so that I can calculate motor RPM.

Answer 1

Bouncetime may be part of the problem. Do you expect pulses to be received at a rate of more than one per bouncetime? I don't know what the default is.

An encoder normally has two outputs. You appear to only use one.

If you actually have an encoder try

http://abyz.me.uk/rpi/pigpio/examples.html#Python_rotary_encoder_py

If you are only interested in RPM try

http://abyz.me.uk/rpi/pigpio/examples.html#Python_read_RPM_py

---

There are at least two other factors to consider.

1. The Arduino program is (compiled) C++, the Pi program is (interpreted) Python. A compiled program is likely to be more responsive and faster than an interpreted program.
2. Linux is a multi-user, multi-process, multi-tasking operating system with many activities acting in parallel. The Arduino is neither multi-user, multi-process, nor multi-tasking. The one Arduino script has total control of the CPU.

Answer 2

Bouncing means you have extra edges in the signal, so the error you get from it can only be a higher count, not lower.

De-bouncing means your software ignores the edges which come faster than expected, so it can remove those extra edges, or, if the de-bounce time is too high, ignore legitimate edges, leading to a lower count. As far as I can tell there is no de-bounce present in your code.

Since Arduino counts the edges correctly, I'd say that bouncing is not a problem here. Your Python code is simply too slow to count the pulses, so it misses most of them.

Using both A and B inputs is necessary if you need to detect rotation direction in addition to speed. If your code is already too slow to process one input, trying to use two inputs will only make things worse.

Answer 3

I will only cover one issue (that is not covered is existing answer).

You are only looking at one of the outputs of the encoder. This output can bounce, therefore you have a bounce filter. This filter can cause you to miss edges, and get a low count.

If you take into consideration both outputs, then you can let it bounce (you need no filter). You may get a little back and forth jitter, but that is all. You will want to put on a bounce filter to remove very high frequencies, so as to reduce load on the software (not too many events to process). However when you use only one output, then no value for the bounce filter can ever be good enough ( e.g. a stopped motor, can easily produce an oscillating output that looks like a high RPM).

Design filter value, so that it works if motor is going at some good margin faster than maximum.