Encoder digitalRead being weird

Hi,

So I've made a few controllers recently. I made my own basic code for incremental encoders. not too bore you too much I;ve ran into a problem whereby its not reading the encoder positions as I would expect. If i digital read the inputs of the encoder on my old design it reads

00, 10, 11, 01

My code then simply reads the first pin value and if they are not equal when it cycles 01,10 then its clockwise and if they read 11,00 when it cycles then its anticlockwise. but ive made a new device. same encoders and this one reads.

00,11,01

just those 3. no fourth set and I'm very confused. I can write new code of course but id like to understand why this is happening. As its the same encoders, same concept.

Encoder Datasheet
schematic.pdf (142.3 KB)

Give a link to the encoder that you are having issues with.

@LarryD added to the original post

If this is the encoder waveform, You should get 4 different states.

00 10 11 01 etc.


Always show us a good schematic of your proposed circuit.
Show us a good image of your ‘actual’ wiring.


Typical wiring:

@LarryD Here you go. I made it with kicad6. Plot pdf and jpeg of board


Plot.pdf (145.4 KB)

Encoders connected to the controller via a multiplexer is not a good mix.

It’s all about speed in reading the encoder that is important.

Do not see pull ups on the encoders :thinking: .

Do not see bounce suppression capacitor s on the encoders :thinking: .

@LarryD Multiplexing encoders is a fairly standard thing and this has worked on other controllers I made ? I'm using the pullup resisters on the pro micro on the mux channels. I don't have bounce suppression capacitors. do you think these could be affecting the read of the encoders. it doesn't really explain why on one design it works perfectly and on the other it doesn't. they are almost identical concepts

This is really strange, if you only get 3 states it's not working according to the "Quadrature Output Table (with a focus on the "quad" meaning 4 states) in the datasheet. I'd add 0.1uF caps, one between pins A and B, then another between C and B just as a starting point. Maybe you received a part that doesn't have the same mechanical tolerances as the other parts you received and your code is just too specific to the tolerances of the older parts. I had code that worked fine most of the time but missed counts when turning too fast depending on the particular encoder, and using caps helped make all the encoders act the same. I had to use an oscilloscope to debug this though and it's what ultimately forced me to add those capacitors.

@dparson and the weirdest bit is it's happening to all the encoders on the board. Not just 1.

@mrmatthewfelton What about the identification of the A, B, and C pins on the schematic symbol vs the physical pins on the encoder? Looking at the schematic, is it possible the B and C are reversed? I'm not sure of the resulting states if this happened but it would be easy to test. The schematic symbol looks to me like the pin labeled as B could actually be the common pin while the datasheet shows a different order of physical pins. The board layout looks good though so maybe another red herring.

Hi,

What have you changed on your new PCB?
Are you running the same code?

If so, then look for open or shorted tracks.
Get the DMM out and trace your major control tracks.

Did you check your nets on the PCB CAD?
Can you please post some images of your PCB.

Thanks.. Tom... :smiley: :coffee: :+1: :australia:

No it is not a standard thing with encoders. Yes you see them on all sorts of circuits, mainly for gaming button boxes, but this is the internet and you see all sorts of rubbish, especially stuff by gamers, because most do not have a clue about what they are doing.

The big problem with encoders in a scanning matrix is that you have relatively long periods when the encoder is simply not being looked at. The worst case timing might not be easy to see and so testing of this sort of thing is just left to the "well it appearers to work so it must be alright" sort of mentality.

These are not strong enough, many switch based encoders have mechanical problems where the wiper leaves contact with the PCB track inside causing a brief time of a floating input. Using a stronger pull up resistor than the ill defined internal ones (they can be anything from about 30K to 50K).

Yes depending on the sort and speed of the processor. When using the Pico 2040 processor I find that rotary encoders will not work at all without capacitors.

Well this is because while you might use the same concepts, the actual implementation of those concepts are showing you that the concepts were not very sound in the first place.

That is a very flaky way of reading an encoder. You need to have a state machine that you follow. This will produce a self correcting code. This is the state machine I use.

Ideally changes in either two pins should trigger an interrupt which will advance the state machine. It should not be part of a scanning matrix.

1 Like

@dparson Im pretty certain i have the correct ground pin as im using these same encoders on another board and it works... unless that assumption is flawed in some way :slight_smile:

@TomGeorge

The new PCB has gnd vias placed all over the board and via beading around the edge where the old one does not. the layouts are different. the code is fundamentally identical apart from some arrays that tell the sketch how to read the multiplexers. I just made some test code reading the 1st position of the mux and applied to both pcb designs. thats how I got the digitalRead info.

void setup(void) {
  SerialUSB.begin(9600);
  pinMode(6, INPUT_PULLUP);
  pinMode(7, INPUT_PULLUP); 
}

void loop(void) {

  SerialUSB.print(digitalRead(6)),SerialUSB.println(digitalRead(7));

}

Just running this code gives me the weirdness. so its defo related to the design in some way. the old design runs as expected but the new one shows. 00,11,01, then a pause as if the encoder position is correct but pro micro isnt reading it and the back to 00.

My nets and cad are all 100% correcxt im sure. cant check shorted tracks but i cant see how that would effect only one read of the quad

@Grumpy_Mike

So you think that because I'm not using correct pullup resisters and de-bounce capacitors that this could be the reason why only 3 states of the 4 on my 20 rotary encoders might not be being read only on one design, where it works fine on another. Just to confirm ? I guess the issue is I'm trying to understand why 1 state wouldn't be read only. any insight ?

@LarryD In the picture you posted does it show a pullup resister of 27k or 2.7k. I've been reading that I should use something in the range of 1-10k.

Does your encoder have the Detent option or not? The data sheet you posted is for many different types of encoder. Which one do you actually have?

The reason for your missing code output will be mainly down to the frequency you are able to read each encoder. This is much harder on a Detent encoder because the states change much faster.

The other stuff like pull up resistors help with getting a good signal because high values do not meet a switche's minimum current requirement. Capacitors on a Detent encoder can cause an encoder to miss but also can help with fast debounce which results in dirty edges.

But the main problem is getting round 20 switches fast enough.

You have posted no code nor any schematics to help us on this problem.

@Grumpy_Mike

Its the 0 detent option. Its not the scanning speed as I reduced the code to scan just one encoder and it still does it. Also, the other design has double the encoders and still scans well. I am 100% certain that the code is definitely fast enough for the job. Also, even when turning the encoders extremely slowly it still misses one of the quadrature values. so that rules out scanning speed. is there some sort of scenario where a GND loop, power issue or something might cause that one value to cancel each other out or something. its happing on every single encoder. which leads me to believe its related to the multiplexer power or grounding or something. also posted some basic code earlier in the message where it was still doing it. so its defo design related.

Could be, but as you have not posted the schematic or all the code who knows?

@Grumpy_Mike

The schematic was posted in one of the first replies. I assumed you had seen it considering you were replying about not having pullup resisters ? ill add the schematic etc to the main post to help.