Re: [PiDP-11] Rotary Switches - Again!

[Oscar Vermeulen]

Tom,

On Sun, 15 Nov 2020 at 22:51, Tom Lake <toml...@gmail.com> wrote:

When I first installed my PiDP-11, the LEDs went in the same direction as the rotary knobs were turned - whichever direction that was. Recently, the LEDs started going in the opposite direction! I applied the fix listed in this group. Now the lights go clockwise when the knobs are turned clockwise but don't move at all when the knob is turned counterclockwise (anticlockwise for my UK friends!) Is this right? Why did the response change twice when I made no changes other than sudo apt update for the OS?

That is downright weird. There's nothing involving the OS in the rotary knobs' handling code. Just sampling of the switch signals straight on the GPIO. This hits both knobs' behaviour?

In a few days I can check if an apt update (I guess apt upgrade, right, apt update does nothing relevant to the OS?) triggers the same oddity the same on one of my 5 test machines.

The only thing I can imagine is that the speed of GPIO sampling has somehow increased or decreased in such a way that my simplified reading of the rotary signals no longer works 'in the same direction'. But how that is even possible is a puzzle.

It is a very interesting observation though: so far I had assumed that I somehow got batches of rotary switches delivered that, although nominally the same part number, were of subtly different subtypes. In that some read clockwise, others counterclockwise with my simple algorithm. Now your experience opens up the possibility that it is just some software/sample interval issue. I do read the rotation signals in a nonstandard way, one that can get away with less CPU cycles than the textbook algorithm. Or so I believe.

Hmm! Anyone else having this experience where the rotaries start to work the other way round? Or even stop working in one direction?!

For those who like to puzzle along:

line 383, void check_rotary_encoders(int switchscan),

in /opt/pidp11/src/11_pidp_server/pidp11/gpio.c

Kind regards,

Oscar.

[Tom Lake]

OK, One part of mystery solved. The refusal to work in both directions was my fault (big surprise!) I had commented out the counterclockwise code in preparation for copying it and modifying it. I usually don't modify a line of code. I just copy it to the line below, comment out the original and modify the copy. In this case I inserted the // before copying so I ended up with

// knobValue[i]--; // bugfix 20181225
// knobValue[i]++; // reverse direction of bugfix 20181225  

then I forgot to remove the // from the changed line. Arrgh!

I still don't know why the direction changed spontaneously, however.

[Tom Hunter]

Oscar,

 

Both my rotary switches originally where opposite to what the LEDs did.

You described the fix in a post on May 12 2019 with the title “Rotary encoder action” and it worked fine for me in gpio.c:

 

“knobValue[i]++;”  becomes “knobValue[i]—;” and vice versa.

 

After a rebuild it works as expected.

 

Best regards

Tom Hunter

 

--
You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/CAJAwMc0Jm82JtCiUAc%2BiTw3QYG3jaRJpTdkbsE%3DfHwy2BXax4A%40mail.gmail.com.

[Neal G.]

Oscar,

Yes, I also encounter strange behavior. As I turn either of the knobs clockwise, the active LED will occasionally not advance, sometimes it will advance twice, sometimes it will advance then move back to the previous position.  If I turn the knobs counter-clockwise, similar problems can occur, sometimes the active LED does not change, sometimes the knob has to be turned past several indents before the active LED changes.

The problem seems to occur more frequently the longer the PiDP-11 has been active; after running for perhaps 12 hours or more.

I had though it might, in some strange way, be related to the history buffer issue. I appled that fix, and now am able to keep the PiDP-11 running for many days (35 so far); but the strange rotary behavior still occurs.

- Neal G.

[Stephen Casner]

I suspect that the inconsistent behavior of the rotary switches is
just a matter of timing relative to contact bouncing. It doesn't make
any sense that there would be different batches of the encoder with
opposite sequences. There could be variations in the contact bouncing
from one unit to another and variations in the Pi or in the
construction of the PiDP that affect the timing.

-- Steve

[emt377]

Is this the 21st century version of "wagon wheels revolving backwards in movies"?

Which is to say, the particular combination of signal impulse and sample rate makes it look like the motion is in the opposite direction.

(Caveat: clearly I have little clue what I am talking about)

[Stephen Casner]

On Mon, 16 Nov 2020, 'emt377' via [PiDP-11] wrote:

> Is this the 21st century version of "wagon wheels revolving backwards in
> movies"?

That's called aliasing.

> Which is to say, the particular combination of signal impulse and sample
> rate makes it look like the motion is in the opposite direction.

The direction uncertainty should be avoided because in one direction
the two pins sequence 11 -> 01 -> 00 -> 10 -> 11 and in the other
direction 11 -> 10 -> 00 -> 01 -> 11. But if the sliding contacts in
the encoder are bouncing so that sometimes a 1 reads as 0 (or vice
versa), that could cause false motion. But I acknowlege that effect
should be more random than consistently backwards.

-- Steve

[Johnny Billquist]

On 2020-11-17 02:10, Stephen Casner wrote:
> On Mon, 16 Nov 2020, 'emt377' via [PiDP-11] wrote:
>
>> Is this the 21st century version of "wagon wheels revolving backwards in
>> movies"?
>
> That's called aliasing.

Right. And that's something completely different.

>> Which is to say, the particular combination of signal impulse and sample
>> rate makes it look like the motion is in the opposite direction.
>
> The direction uncertainty should be avoided because in one direction
> the two pins sequence 11 -> 01 -> 00 -> 10 -> 11 and in the other
> direction 11 -> 10 -> 00 -> 01 -> 11. But if the sliding contacts in
> the encoder are bouncing so that sometimes a 1 reads as 0 (or vice
> versa), that could cause false motion. But I acknowlege that effect
> should be more random than consistently backwards.

Uh. So we're talking about gray encoding. In which case, signal bouncing
should not make any difference. While debouncing is nice, even without
it, you should not be able to get things going backward. Essentially,
with gray encoding, only one bit ever changes at any point, and if it
bounces, you will essentially just experience a moving back and forth
over that point. So you should not be able to think you're in the end
moving in the wrong direction. Should not be possible, simply.

Johnny

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol

[Stephen Casner]

On Tue, 17 Nov 2020, Johnny Billquist wrote:

> Uh. So we're talking about gray encoding. In which case, signal bouncing
> should not make any difference. While debouncing is nice, even without it, you
> should not be able to get things going backward. Essentially, with gray
> encoding, only one bit ever changes at any point, and if it bounces, you will
> essentially just experience a moving back and forth over that point. So you
> should not be able to think you're in the end moving in the wrong direction.
> Should not be possible, simply.

I agree, it should work correctly. But perhaps the sampling is such
that some states are missed completely. Clearly something in the path
between the hardware switch and the software is not behaving as
expected.

-- Steve

[Johnny Billquist]

In order to miss a whole state, it would require missing a lot of
samples. It seems very unlikely, unless there is some kind of bug somewhere.

[Oscar Vermeulen]

Stephen, Johnny,

On Tue, 17 Nov 2020 at 02:43, Stephen Casner <cas...@acm.org> wrote:

On Tue, 17 Nov 2020, Johnny Billquist wrote:

> Uh. So we're talking about gray encoding. In which case, signal bouncing
> should not make any difference.

I agree, it should work correctly.  But perhaps the sampling is such
that some states are missed completely.

That was my original thought - but people have reported that the knob rotation is *consistently* clockwise or consistently counterclockwise, so it does not seem a matter of missing some states. That would only make for erratic behaviour.

For two years I have believed it's just a subtle hardware difference between the batches of EC11 rotary switches I received. There are indeed quite a few subtypes with subtly different encodings.

But the report of the knobs reversing their rotation direction after a Raspbian SW update, that much intrigued me - it would make this a software bug. Which makes more sense, given who wrote the code.

I'll dig into it, but as it does not impact PDP-11 operation and the fix is trivially simple, I'm not so bothered by it. Figuring out the root problem probably will involve multiple Pis, multiple OSes and many different rotary switches plugged in.

Kind regards,

Oscar.

[Johnny Billquist]

The problem with missed samples are that with Gray encoding, in order to
read the rotation in reverse, you need to constantly miss a whole lot of
sampling, since you need to miss two states before you get to the one
indicating the other direction. Not to mention that you then need to
skip two states again, to continue going in the backward direction. So
essentially, you need to consistently do every third state.
This seems more than a little unlikely...

Do you know how many times the patterns repeat in one revolution?

Johnny

[Sytse van Slooten]

The thing to understand is that in rotary switches, the states are not equal - it is not Gray encoding because that would imply that the states are equal, but that is not the case at all. Only one state is stable, and the others are transient. And the timing between stable and transient states is really different, and it is not straight forward to filter out glitches and still reliably pick up legitimate state changes.

At least in my understanding of things, proper handling of a rotary switch needs debouncing in hardware and even then will be somewhat dependent on the timing of the sampling - and yes, PDP2011 also has its issues with this. And not just because I got a couple CCW switches for my test board. If you turn the knobs at just the right, ehh, wrong speed...

> --
> You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/69f7f21e-0f67-08d6-bb37-a2e2c89c4e30%40softjar.se.

[Johnny Billquist]

Hum. Are you really saying that you have rotary encoders that don't use
Gray encoding? That would be pretty horrible.

What you are describing is exactly why you want to use Gray encoding...

Johnny

[Sytse van Slooten]

Well it’s two signals and 4 states, it would be plain stupid to come up with something that didn’t resemble Gray.

But the thing is that the transient states are not equal to the stable state in timing. So there is a window that you need to find - avoiding glitches, but also catching the transient states. It is definitely not trivial, and if it is an exact science, I don’t see how. There’s also a limit on how and how fast we can sample the switches - they’re just multiplexed along with a lot of other things. We can’t detect edges, just sample. And, of course, rotaries glitch like nothing you would like to know about - and all batches seem to be different.

So, in short, no - Gray is really not the answer. That would work if it was un-multiplexed logic without any timing to it, with edge detection, and proper debouncing in hardware. But we don’t have that. The average direction is something that should be doable - even with the software sampling speeds that you can get from a Pi. But there’s no way that I see you can get the things to be be completely, repeatably accurate across batches of subtly or totally different switches.

my 2 c ;-)

Cheers
Sytse

[Garry A Lockyer]

Quite possibly not relevant to this specific discussion but . . .

There are lots of rotary encoders that don’t use Gray Codes. Many use 2 signals in quadrature. The signals can be decoded by sampling two GPIO pins or using a dedicated decoder chip. They often have an index signal that could be used to determine the shaft’s absolute position but maintaining knowledge of that position across power cycles would be difficult.

Regards,

Garry Lockyer
C: +1.250.689.0686
E: Ga...@Lockyer.ca


> On Nov 18, 2020, at 15:21, Sytse van Slooten <sy...@sytse.net> wrote:
>
> Well it’s two signals and 4 states, it would be plain stupid to come up with something that didn’t resemble Gray.

> To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/C96B8E12-A76B-4CCC-BCDC-298614036992%40sytse.net.

[Geert Rolf]

I do know the frontpanels of 11/45, /50, /55 differ from the 11/70 *), but I'm sure the rotary switches work zig-zag on the 45 etc.

*) I had to search for the DEP switch the first time.

[Johnny Billquist]

Yeah, the switches moved around a little between the 11/45 and 11/70.

But as far as the rotary switch goes, it's a completely different
concept/design on the DEC machines compared to the PiDP-11. The DEC
machines use a rotary selector. Essentially you have 9 pins on it. One
is the common pin, and then you have 8 select positions. One of them
will short to the common pin, and the other 7 are floating. And turning
the knob just moves the grounding to another pin. So it's an absolute
selector, and it has one pin per position.

The rotary selector for the PiDP-11 is done in a different way, which
just tells you which direction you are moving in, and you can tell how
much, but it don't tell you in which direction the selector actually is
pointing.

And it's encoded with just two bits/pins, and a common. You can
illustrate is as ON and OFF on each pin, in relation to the common pin.
And doing them as 0 and 1, you'll have one sequence going clockwise, and
another sequence going counterclockwise.

Basically, either:
00 -> 01 -> 11 -> 10 -> 00
or
00 -> 10 -> 11 -> 01 -> 00

And this is plain gray code. And while debouncing is always nice (and
it's really simple to do debouncing in software), if you don't have
debouncing with gray code, it don't really cause any issues in the
overall picture. It will just make the movement to appear to be going
back and forth at transition points. Possibly annoying, but not causing
anything to start acting in "reverse".


Could people try this patch, and see if it makes life any better?

=============
*** gpio.c.old 2020-11-22 01:30:22.898411675 +0100
--- gpio.c 2020-11-22 01:53:58.114274430 +0100
***************
*** 320,325 ****
--- 320,327 ----

code[0] = (switchscan & 0x300) >> 8;
code[1] = (switchscan & 0xC00) >> 10;
+
+ #if 0
switchscan = switchscan & 0xff; // set the 4 bits to zero

//printf("code 0 = %d, code 1 = %d\n", code[0], code[1]);
***************
*** 363,368 ****
--- 365,381 ----
// if (knobValue[1]<0)
// knobValue[1] = 3;

+ #else
+ for (i=0; i<2; ++i) {
+ if (lastCode[i] != code[i]) {
+ if ((code[i] == 0) && (lastCode[i] == 1))
++knobValue[i];
+ if ((code[i] == 1) && (lastCode[i] == 0))
--knobValue[i];
+ lastCode[i] = code[i];
+ }
+ }
+ #endif
+
+
knobValue[0] = knobValue[0] & 7;
knobValue[1] = knobValue[1] & 3;

=============

It works on my machine, but my sources might be a little out of date.
But a context diff usually gets through pretty ok. It also won't delete
any changes to the lines others have talked about before, but just makes
them inactive. If you want to revert back to your current code, just
change the #if 0 to an #if 1 in the code after you have applied the patch.

I'm attaching it as a file as well, so people don't have to try and cut
and paste... :-)

And in case people don't know how to apply context diff patches:

save the content between the "======" lines into a file. Let's call it
gpio.patch

Move that file into /opt/pidp11/src/11_pidp_server/pidp11

run: patch < gpio.patch

Hopefully, you should see:

raspberrypi:11_pidp_server/pidp11# patch < gpio.patch
patching file gpio.c
raspberrypi:11_pidp_server/pidp11#

Then rebuild as usual, in /opt/pidp11/src, run makeserver.sh

Reboot/restart/whatever, and see if it still works the same. If the
encoders really are of two different kinds, then this code cannot help
at all, but I just figured I could at least make the code a little
cleaner, and easier to follow (well, at least I think it is... :-) ).

I should also point out that this patch does not include any debouncing,
and I didn't spot any elsewhere in the code either. But at least on my
front panel, there are no visible issues with bouncing anyhow, so at the
moment I don't even bother.

Johnny

On 2020-11-21 16:57, Geert Rolf wrote:
> I do know the frontpanels of 11/45, /50, /55 differ from the 11/70 *),
> but I'm sure the rotary switches work zig-zag on the 45 etc.
>
> *) I had to search for the DEP switch the first time.
> On Thursday, November 19, 2020 at 12:35:44 AM UTC+1 garrya...@gmail.com
> wrote:
>
> Quite possibly not relevant to this specific discussion but . . .
>
> There are lots of rotary encoders that don’t use Gray Codes. Many
> use 2 signals in quadrature. The signals can be decoded by sampling
> two GPIO pins or using a dedicated decoder chip. They often have an
> index signal that could be used to determine the shaft’s absolute
> position but maintaining knowledge of that position across power
> cycles would be difficult.
>
> Regards,
>
> Garry Lockyer

> C: +1.250.689.0686 <tel:(250)%20689-0686>

> <https://groups.google.com/d/msgid/pidp-11/69f7f21e-0f67-08d6-bb37-a2e2c89c4e30%40softjar.se>.

>
> >>
> >> --
> >> Johnny Billquist || "I'm on a bus
> >> || on a psychedelic trip
> >> email: b...@softjar.se || Reading murder books
> >> pdp is alive! || tryin' to stay hip" - B. Idol
> >
> > --
> > You received this message because you are subscribed to the
> Google Groups "[PiDP-11]" group.
> > To unsubscribe from this group and stop receiving emails from it,
> send an email to pidp-11+u...@googlegroups.com.
> > To view this discussion on the web visit

> https://groups.google.com/d/msgid/pidp-11/C96B8E12-A76B-4CCC-BCDC-298614036992%40sytse.net
> <https://groups.google.com/d/msgid/pidp-11/C96B8E12-A76B-4CCC-BCDC-298614036992%40sytse.net>.

>
>
> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com

> <mailto:pidp-11+u...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pidp-11/2f6bc5e5-b664-407a-b083-adfc1aed3c53n%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/2f6bc5e5-b664-407a-b083-adfc1aed3c53n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Oscar Vermeulen]

Johnny,

Brilliant! I will test in 2 weeks' time when I get some time again (I'm in one of my Night Nurse On Duty periods right now...).

Indeed, no debouncing anywhere in the code. It was removed after prototype #1 in fact: in practice, at the sample frequencies of the PiDP circuit, it simply proved unnecessary. Only adds CPU cycles that could be spent more productively. This might trigger some inspired replies from people with way more electronics skills than I have: I know debouncing is a big topic for proper EEs. Consider 'no debouncing' a fetish I get away with as an improper one!

I indeed originally thought of using rotary switches instead of rotary encoders. But proper 8-position rotary switches are bulky, and the affordable ones all were of less than satisfactory quality IMO. Properly sourced ones are surprisingly expensive. The only consequence is that the position of the rotary knobs is set to a default position at boot-up.

Thanks!

Oscar.

[Oscar Vermeulen]

Geert,

On Sat, 21 Nov 2020 at 16:57, Geert Rolf <geer...@gmail.com> wrote:

I do know the frontpanels of 11/45, /50, /55 differ from the 11/70 *), but I'm sure the rotary switches work zig-zag on the 45 etc.

Indeed! But the rotary rather than zigzag behaviour is true to the real 11/70. We checked on the LCM's Miss Piggy.

To be honest, credit for front panel verification goes to Joerg Hoppe and Mike Hill, I mostly just held the camera steady when we went through a test script with lots of edge cases where the documentation did not explain precise behaviour.

Kind regards,

Oscar.

[Johnny Billquist]

On 2020-11-22 14:59, Oscar Vermeulen wrote:
> Geert,
>
> On Sat, 21 Nov 2020 at 16:57, Geert Rolf <geer...@gmail.com
> <mailto:geer...@gmail.com>> wrote:
>
> I do know the frontpanels of 11/45, /50, /55 differ from the 11/70
> *), but I'm sure the rotary switches work zig-zag on the 45 etc.
>
>
> Indeed! But the rotary rather than zigzag behaviour is true to the real
> 11/70. We checked on the LCM's Miss Piggy.

I can confirm that this is how the rotary selectors work on real 11/70
machines.

But it's also rather easy to check the 11/45. The circuit drawings for
the 11/45 are on bitsavers.
http://www.bitsavers.org/pdf/dec/pdp11/1155/MP00039_1155vol1_Mar76.pdf

And if you check sheet 16, you'll find the rotary selectors there.

And for the data, the cycle is:
Data paths
Bus register
uADDR
Display register

And for address:
USER I
USER D
SUPER I
SUPER D
KERNEL I
KERNEL D
PROGRAM PHY
CONSOLE PHY


Which indeed is a different order than the 11/70.
(The 11/70 can be checked at
http://www.bitsavers.org/pdf/dec/pdp11/1170/MP0KB11-C0_1170engDrw_Nov75.pdf,
sheet 54).


And obviously, the switches on the right hand side shuffled around and
changed with the 11/70 as well, since it needed 4 more switches on the
left end for addresses...

Johnny

[Steven A. Falco]

I tried your patch. My lights now rotate in the wrong direction when turning the switches. That is not surprising, because I previously had to change the code to make them rotate correctly.

Here is a modified version of your code that works for me - basically change the -- to ++ and vice versa:

for (i=0; i<2; ++i) {

if (lastCode[i] != code[i]) {

if ((code[i] == 0) && (lastCode[i] == 1)) --knobValue[i];
if ((code[i] == 1) && (lastCode[i] == 0)) ++knobValue[i];

lastCode[i] = code[i];
}
}

I think there should be an ifdef and #define to make it easy for people to select the direction they need. Or better yet, a conf file, so people don't have to recompile. But it is easy enough as is.

Steve

[Johnny Billquist]

Thanks for the feedback. Very interesting.

Actually, for people who would like to help, I'll produce a patch later
tonight that will help confirm if this is actually different switches,
or some other issue.

By the way, could you tell me what model of Pi you are running on?

Johnny

[Steven A. Falco]

Glad to help test. I'd like to get to the bottom of this too.

My system has a 3B+, running 32-bit Raspbian.

Steve

[Neal G.]

Thanks Johnny,

I tried your patch. Your source must be too different, directly applying the patch fails,

pi@raspberrypi:/opt/pidp11/src/11_pidp_server/pidp11 $ sudo patch <gpio.patch
patching file gpio.c
Hunk #1 FAILED at 320.
Hunk #2 FAILED at 363.
2 out of 2 hunks FAILED -- saving rejects to file gpio.c.rej

I was successful in making the changes manualy. Operation is improved but still glitches fairly often.

Inspired by the improved behavior I made a change that verifies the next expected grey code in the sequence before updating the knobValue. With this revision glitches are very infrequent and only skip an expected movement. Unexpected reverse movement does not occur. Here's the code with my changes:

void check_rotary_encoders(int switchscan)
{
        // 2 rotary encoders. Each has two switch pins. Normally, both are 0 - no rotation.
        // encoder 1: row1, bits 8,9. Encoder 2: row1, bits 10,11
        // Gray encoding: rotate up sequence   = 11 -> 01 -> 00 -> 10 -> 11
        // Gray encoding: rotate down sequence = 11 -> 10 -> 00 -> 01 -> 11

        static int  lastCode[2] = {3,3};
        static int  isMoving[2] = {0,0};
        int code[2];
        int i;

        code[0] = (switchscan & 0x300) >> 8;
        code[1] = (switchscan & 0xC00) >> 10;

        for (i=0;i<2;i++)
        {

           if (lastCode[i] != code[i])
           {

              switch(isMoving[i])
              {
                 case 0: // not currently moving
                 {
                    if ((code[i] == 1) && (lastCode[i] == 3)) isMoving[i] =  1;
                    if ((code[i] == 2) && (lastCode[i] == 3)) isMoving[i] = -1;
                    break;
                 };
                 case 1: // up movement in progress
                 {

                    if ((code[i] == 0) && (lastCode[i] == 1)) --knobValue[i];

                    isMoving[i] = 0;
                    break;
                 };
                 case -1: // down movement in progress
                 {
                    if ((code[i] == 0) && (lastCode[i] == 2)) ++knobValue[i];
                    isMoving[i] = 0;
                    break;
                 };
              }

              lastCode[i]=code[i];

           }
        }

        knobValue[0] = knobValue[0] & 7;
        knobValue[1] = knobValue[1] & 3;
}

To be clear about the behavior we're discussing, I've attached some small video clips; original behavior, Johnny's revision, and my revision.

I think Sytse has a good point, movement at just the "wrong" pace is part of the problem. I noted that with the original code, if I wait several seconds before rotating the know the LED movement is correct nearly all of the time.

Perhaps the timing on the Pi-2 is a bit slower than average? Perhaps the specific lot of encoders is more sensitive to the lower supply voltages with which the Pi-2 has no issues?

- Neal G.

[matt...@ep1.rub.de]

Hi Neal,

for me your version works perfectly. So far I did not see any glitches. I'm using a Pi 3B+.

Greetings,

 Matthias

[Hans-Ake Lund]

Hi, the code from Neal works for me too. Before changing the code, the LEDs were going in the opposite direction when turning the knobs. https://github.com/hansake/My_PiDP-11

/Hans-Åke

[Robin Hodgson]

That code works for me too on a Pi4. LEDs now track the direction of the knob's rotation, no weird behavior as the knobs turn. Many thanks!