PiDP11 rotary switch issues

[Michael Katzmann]

The rotary encoder on the PiDP11 does not always give a consistent action.

i.e. rotating clockwise and then anti-clockwise n positions does not necessarily return the indicator to the same spot. Also, it's possible to partially move the control (not a full click) and get a change in indicator but when the switch falls back to its detent, the indicator doesn't change back.

Looking at the server code gpio.c, there does not seem to be any switch debounce (although perhaps this happens elsewhere).

Before I spend time testing ...Has anyone looked at this code to improve the reliability of the rotary switch action? 

Also what is the procedure to restart the server program without rebooting?

Michael

--

   |\      _,,,---,,_             Michael Katzmann
   /,`.-'`'    -.  ;-;;,_         NV3Z / VK2BEA / G4NYV
  |,4-  ) )-,_. ,\ (  `'-'
 '---''(_/--'  `-'\_)

[Johnny Billquist]

There is definitely debouncing. Or at least there was when I looked in
the past.

However, any correlation to a "click" feedback is weak. The encoding is
a separate bit to the click generation. That's just how the encoders are
built. Nothing you can do about that.

Moving back and forth, however, should be impossible to do without
getting back to the same state, if you really get the encoder back to
the same exact position, as it's a grey encoder.

But I think people have been poking at this code multiple times,
especially since I think someone did some work on making it configurable
to define in which rotary direction the encoding goes. So maybe the
debouncing was lost? Check... Also, without debouncing, it should still
work out fine when moving back and forth in the end. You could possibly
just see more of a flickering back and forth at the transitions. (Unless
someone seriously misunderstood the code and the grey encoding. But it
was fine when I looked a few years ago.)

Johnny

> --
> 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 visit https://groups.google.com/d/msgid/pidp-11/
> CAMyt5ORXv400OXAfsvQeYuuRB3uPAL9ihdkZqf1Vw5TK7MpuAA%40mail.gmail.com
> <https://groups.google.com/d/msgid/pidp-11/
> CAMyt5ORXv400OXAfsvQeYuuRB3uPAL9ihdkZqf1Vw5TK7MpuAA%40mail.gmail.com?
> utm_medium=email&utm_source=footer>.

[Michael Katzmann]

Thre reading of the switches is done her.

   https://github.com/obsolescence/pidp11/blob/26d20beda0c6b5a1d3a5cb3d7a4dd494e02bff75/src/11_pidp_server/pidp11/gpio.c#L227

and I see no debounce.

After reading the switch row containing the rotary encoders, it calles check_rotary_encoders(switchscan) and I can't see any debouncing code here (although it's a little hard to follow).

It's possible that my switches are bad/noisy. If no one else has noticed a problem, maybe I need to replace these.

Michael

To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pidp-11/fde91d74-3561-4f26-ad46-2f2e01c3574f%40softjar.se.

[Johnny Billquist]

Hmm. I htink I must have remembered wrong. Can't see any debounce in the
old code either.

But even without a debounce it should still behave pretty reasonably.
You could possibly get some flipping back and forth when you are close
to the transition, but it should always end up correct. Moving in the
right direction, and getting things right if you move back and forth.
Unless you get some *really* bad readouts...

Johnny

On 5/20/26 18:11, Michael Katzmann wrote:
> Thre reading of the switches is done her.
>  https://github.com/obsolescence/pidp11/
> blob/26d20beda0c6b5a1d3a5cb3d7a4dd494e02bff75/src/11_pidp_server/pidp11/

> gpio.c#L227 <https://github.com/obsolescence/pidp11/
> blob/26d20beda0c6b5a1d3a5cb3d7a4dd494e02bff75/src/11_pidp_server/pidp11/
> gpio.c#L227>

> and I see no debounce.
> After reading the switch row containing the rotary encoders, it calles

> check_rotary_encoders(switchscan) <https://github.com/obsolescence/
> pidp11/blob/26d20beda0c6b5a1d3a5cb3d7a4dd494e02bff75/src/11_pidp_server/
> pidp11/gpio.c#L263> and I can't see any debouncing code here (although

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

> > To view this discussion visit https://groups.google.com/d/msgid/

> pidp-11/ <https://groups.google.com/d/msgid/pidp-11/>
> >
> CAMyt5ORXv400OXAfsvQeYuuRB3uPAL9ihdkZqf1Vw5TK7MpuAA%40mail.gmail.com
> <http://40mail.gmail.com>
> > <https://groups.google.com/d/msgid/pidp-11/ <https://
> groups.google.com/d/msgid/pidp-11/>
> >
> CAMyt5ORXv400OXAfsvQeYuuRB3uPAL9ihdkZqf1Vw5TK7MpuAA%40mail.gmail.com
> <http://40mail.gmail.com>?

> > utm_medium=email&utm_source=footer>.
>
> --
> 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%2Bunsu...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/

> pidp-11/fde91d74-3561-4f26-ad46-2f2e01c3574f%40softjar.se <https://
> groups.google.com/d/msgid/pidp-11/fde91d74-3561-4f26-
> ad46-2f2e01c3574f%40softjar.se>.

[Bert Driehuis]

I've not had many issues with my PiDP-11, but then again I'm not using the rotary encoders that often. But my coffee maker (not a cheap one, it's by Bosch Siemens Haushaltsgeräte) often registers two movements for one "click" of the rotary decoder, and also sometimes registers a back movement for a wavering forward movement. I've not analysed deeply how these things work, but my guess is that tolerances are such that they may give inconsistent results when read in a half-way position (that mental model explains my coffee maker, YMMV). Of course, no one expects a half-way readout to be consistent, but it may well be that debouncing is necessary to reduce if not prevent accidental readouts in a half-way position.

Then again, if BSH can't get it right, it may be a tall order after all.

Cheers,

Bert

To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pidp-11/21326c04-bba5-412c-ba67-262eabd3ebd9%40softjar.se.

[Michael Katzmann]

There is a problem with the existing gpio.c code that decodes the quadrature encoders.

The sequence of bits for each rotary encoder is:
0b11 0b01 0b00 0b10 0b11 in the CW direction or 0b11 0b10 0b00 0b01 0b11 in the CCW direction.

The rotary switches, when partially actuated (but not so far as to move to the next detent) will produce an invalid sequence that was, nevertheless, acted upon by the original code, giving a false count.
e.g. 11 01 01 11 would give a false CCW count even though the switch returned to its original position after a partial turn.

I modified the code to look only for the corresponding start and end sequences so that only valid sequences are accepted.

This, for me, produces a consistent and repeatable action. When I return the switch to its original position, the corresponding indicator shows.

The changed file is here ... 

https://github.com/VK2BEA/pidp11/blob/main/src/11_pidp_server/pidp11/gpio.c

To try it, copy gpio.c to /opt/pidp11/src/11_pidp_server/pidp11/gpio.c, run /opt/pidp11/src/makeserver.sh then restart the server nohup /opt/pidp11/bin/pidp11.sh &

Michael

[Johnny Billquist]

On 2026-05-21 02:11, Michael Katzmann wrote:
> There is a problem with the existing gpio.c code that decodes the
> quadrature encoders.
>
> The sequence of bits for each rotary encoder is:
> |0b11 0b01 0b00 0b10 0b11| in the CW direction or |0b11 0b10 0b00 0b01
> 0b11| in the CCW direction.
>
> The rotary switches, when partially actuated (but not so far as to move
> to the next detent) will produce an invalid sequence that was,
> nevertheless, acted upon by the original code, giving a false count.
> e.g. |11 01 01 11| would give a false CCW count even though the switch
> returned to its original position after a partial turn.

Uh?
The 11 -> 01 transition means a CW movement.
01 -> 01 is no movement at all.
The 01 -> 11 transition means a CCW movement, leading you back to where
you started.

> I modified the code to look only for the corresponding start and end
> sequences so that only valid sequences are accepted.

That sounds broken. Basically, the sequence you gave above would do
exactly what you could/would expect. You ending up back where you started.

> This, for me, produces a consistent and repeatable action. When I return
> the switch to its original position, the corresponding indicator shows.

I should probably look at what you've done, but the whole text in this
mail seems wrong.

Johnny

>
> The changed file is here ...
> https://github.com/VK2BEA/pidp11/blob/main/src/11_pidp_server/pidp11/

> gpio.c <https://github.com/VK2BEA/pidp11/blob/main/src/11_pidp_server/
> pidp11/gpio.c>

> --
> 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 visit https://groups.google.com/d/msgid/pidp-11/

> CAMyt5OTDcmxMqVGLG9_t45FbUTbxiojgQTvXAQfzp2wj8F_NSg%40mail.gmail.com
> <https://groups.google.com/d/msgid/pidp-11/
> CAMyt5OTDcmxMqVGLG9_t45FbUTbxiojgQTvXAQfzp2wj8F_NSg%40mail.gmail.com?
> utm_medium=email&utm_source=footer>.

--
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

[Michael Katzmann]

Yes.. typo.  11 01 00 01 11 is the invalid sequence that is counted.

[Johnny Billquist]

On 2026-05-21 03:22, Michael Katzmann wrote:
> Yes.. typo.  11 01 00 01 11 is the invalid sequence that is counted.

Not invalid either, and also ends up the same...

11 -> 01 CW movement
01 -> 00 CW movement
00 -> 01 CCW movement
01 -> 11 CCW movement

Johnny

>
>
> Uh?
> The 11 -> 01 transition means a CW movement.
> 01 -> 01 is no movement at all.
> The 01 -> 11 transition means a CCW movement, leading you back to where
> you started.
>

[Michael Katzmann]

Look at the original code.. (although it is a little difficult to read)

The point where it's decides to count up or down is when the second 11 is encountered.

https://github.com/obsolescence/pidp11/blob/26d20beda0c6b5a1d3a5cb3d7a4dd494e02bff75/src/11_pidp_server/pidp11/gpio.c#L292

It counts up or down based on the code after the first 11 (ignoring the code before the last 11). This is confusingly called lastCode[i] (which it isn't).

11

01 <= set lastcode to this

00

01

11 <= count up or down based on 'last code' despite the sequence being invalid

Michael

[Johnny Billquist]

Argh. You're right. The code is weird. Ok, I'll check what you've done
tonight. :-)

Johnny

On 2026-05-21 04:06, Michael Katzmann wrote:
> Look at the original code.. (although it is a little difficult to read)
> The point where it's decides to count up or down is when the second 11
> is encountered.
> https://github.com/obsolescence/pidp11/
> blob/26d20beda0c6b5a1d3a5cb3d7a4dd494e02bff75/src/11_pidp_server/pidp11/

> gpio.c#L292 <https://github.com/obsolescence/pidp11/
> blob/26d20beda0c6b5a1d3a5cb3d7a4dd494e02bff75/src/11_pidp_server/pidp11/
> gpio.c#L292>

> It counts up or down based on the code after the first 11 (ignoring the
> code before the last 11). This is confusingly called lastCode[i] (which
> it isn't).
>
> 11
> 01 <= set lastcode to this
> 00
> 01
> 11 <= count up or down based on 'last code' despite the sequence being
> invalid
>
> Michael
>
>
> On Wed, May 20, 2026 at 9:34 PM Johnny Billquist <b...@softjar.se
> <mailto:b...@softjar.se>> wrote:
>
>
> Not invalid either, and also ends up the same...
>
> 11 -> 01 CW movement
> 01 -> 00 CW movement
> 00 -> 01 CCW movement
> 01 -> 11 CCW movement
>
>

[Johnny Billquist]

I sent this to Michael, but I might as well send it here too.
The current knob decoding is pretty ugly, and is really abusing/missing
the point of gray encoding.

I rewrote that whole function (check_rotary_encoders()) to make it
behave much more properly. I haven't had a chance to test this yet, but
maybe someone else can?

The function is now a lot shorter, and easier to understand. In
addition, it's now also easy if you'd want to have some other "speed" on
the rotary knobs. Heck, you could even make that into another
environment variable, if you wanted it to be more flexible.

I haven't touched any other part of that file, so the rest is still in
whatever shape it was before. Even the code I changed isn't fully in a
style I'd really write in, but I tried to stay somewhat in form of the
rest of the code in there.

If someone tests this, let me know.

Johnny

[Michael Katzmann]

I like what you propose as it's a standard gray code decoder.

I presume you did not test the code you posted as it neither compiles nor runs.

After making changes to get it to compile, it continually counts up.

I altered the table (reversing the last 2 entries for each vector) and it partially worked but seemed to create counts that were not right.

Michael

On Thu, May 21, 2026 at 7:03 AM Johnny Billquist <b...@softjar.se> wrote:

I sent this to Michael, but I might as well send it here too.
The current knob decoding is pretty ugly, and is really abusing/missing
the point of gray encoding.

I rewrote that whole function (check_rotary_encoders()) to make it
behave much more properly. I haven't had a chance to test this yet, but
maybe someone else can?

The function is now a lot shorter, and easier to understand. In
addition, it's now also easy if you'd want to have some other "speed" on
the rotary knobs. Heck, you could even make that into another
environment variable, if you wanted it to be more flexible.

I haven't touched any other part of that file, so the rest is still in
whatever shape it was before. Even the code I changed isn't fully in a
style I'd really write in, but I tried to stay somewhat in form of the
rest of the code in there.

If someone tests this, let me know.

   Johnny

On 5/21/26 09:54, Johnny Billquist wrote:
> Argh. You're right. The code is weird. Ok, I'll check what you've done
> tonight. :-)
>
>    Johnny
>

--

[Johnny Billquist]

No. Didn't even try to compile it. I'm sure I missed something stupid,
but in principle, this should work.
First suspect would be the grayShift array, based on what you see. Just
looking at it, I realize that there is something wrong in there.

The diagonal should obviously always be NOP...

Johnny

[Johnny Billquist]

Yeah. The state transition table was stupidly wrong. It should be:

static int grayShift[ N_ROTARY ][ N_ROTARY ] = {{ NOP, CCW, CW, NOP},
{ CW, NOP, NOP, CCW},
{ CCW, NOP, NOP, CW},
{ NOP, CW, CCW, NOP}};

Let me know what else I messed up. :-)

Johnny

On 5/21/26 16:28, Johnny Billquist wrote:
> No. Didn't even try to compile it. I'm sure I missed something stupid,
> but in principle, this should work.
> First suspect would be the grayShift array, based on what you see. Just
> looking at it, I realize that there is something wrong in there.
>
> The diagonal should obviously always be NOP...
>
>   Johnny
>
> On 5/21/26 16:21, Michael Katzmann wrote:
>> I like what you propose as it's a standard gray code decoder.
>> I presume you did not test the code you posted as it neither compiles
>> nor runs.
>> After making changes to get it to compile, it continually counts up.
>> I altered the table (reversing the last 2 entries for each vector) and
>> it partially worked but seemed to create counts that were not right.
>>
>> Michael
>>
>> On Thu, May 21, 2026 at 7:03 AM Johnny Billquist <b...@softjar.se
>> <mailto:b...@softjar.se>> wrote:
>>

>>     I sent this to Michael, but I might as well send ithere too.