Encoders not working


I am connecting 4 DC Motors with magnetic encoders (hall sensors) to a Core2-Ros. The schematic of the connection for each motor is visualized below:
Electrical Wiring (1) (1)

The code that I used to test the encoders is the following: encoderstest.cpp (1.9 KB)

When I use this code, only hMot.B gets encoder ticks.While the rest stay at 0 ticks.
I switched the hMot.B encoder pins (Enc_A, Enc_B GND and 5V) with the other encoders of the motors just to check if the encoders of the motors are working and each motor was getting ticks.
This suggests that the pins Enc_A and Enc_B from hMot.A, hMot.C and hMot.D are not working properly.

Any suggestions on what I can do?


do your motors have pull-up resistors on encoder outputs? If not, it is possible that encoders on hMot.B works only accidentally. CORE2 does not have pull-up resistors for the encoder inputs.

Hi Radek,

These functions are in the hMotor part of the hFramework:

void hMotor::setEncoderPu()
void hMotor::setEncoderPd()

If the CORE2 does not have pull-up resistors for the endocer inputs, what do these functions do then?



The functions you mentioned set the pull-ups that are integrated into the microcontroller and their value is about 50k.
It is a good idea to try with these pull-ups if you have not tried this yet.
In the previous post I was thinking about real pull-up resistors to 3V3 or 5V :slight_smile: about 10k on each encoder interface.
Both ways should work but the lower value gives better immunity to interferences.

You can also try to check the signals by multimeter. If the motor is turning slowly enough (reaaaalllyyy slowly) you will be able to observe the signal levels for LOW and HIGH, and check if they are OK - below 0,5V and above 2,5V, respectively. In that way it will be possible to check the hardware.

These are my only ideas for this moment. What motors/encoders do you use? I think I know this from another topic but please confirm :slight_smile:

Thanks for your reply, I’m now reading your comment but @n_jak figured it out yesterday with an external pull-up resistor and that worked. So your suggestion was right.

It could be that you know this from another topic, we are working on the same project. I don’t have the exact specs of the DC motors and encoders.

Hello Radeknh,

Thank you for your suggestion. We are using 4 DC Motors (DSMP420-24-0061-BFE) with magnetic encoders (hall sensors). Attached is the data sheet (https://produktinfo.conrad.com/datenblaetter/175000-199999/191821-da-01-en-PLANETENGETRIEBEMOTOR_DSMP420_24_061_BFE.pdf)
I used 1k Ohm pull up resistors on the encoder outputs. 3 out of 4 of the encoders work. The forth one is only changing from 0 to -1 ticks when I set the motor to rotate clockwise.

I also find it strange that then I set the power to be positive the encoder ticks are negative, however, when the power is negative the encoder ticks are positive. Is this because the A and B channels are reversed ?

The encoder counting direction depends on the physical motor rotation direction, not the “power” value.
If you change the power from -500 to 500 and swap the motor terminals (not encoder), the motor rotation direction will be still the same and also the encoder counting direction will not be changed.
Also, there is no standard for polarity and for each motor type you have to check if the direction is correct.

Do you still have problems with one of encoders? Have you tried swapping? Please check the connections one more time.

When I connect a motor to the hMotD encoder input I do not receive any encoder ticks for the motor connected to hMotD. I also tried with another CORE2-ROS and get the same problem.

However, for the same wiring connection and same motor on another hMot port the encoder ticks work. The encoders of each motor are working. I am not sure what is causing this problem?

Kind regards

Is the encoder port not working from the beginning or has it stopped working during your development activities?

It has been like that from the beginning, I also tried with the other CORE2-ROS we have and the same thing happened. Therefore, I do not think it is the encoder port… But I do not know what else it can be…