Reversed rotary encoder action

[Robert S]

Hope this message goes through - I've posted this same message twice before and it appears as if the message is getting deleted from the "Show us your kits" thread where another user posted about this issue, so trying a new thread.

Anyway, in my case I have one encoder that lights the LEDs in the correct order and the other LED lights the LEDs in reverse.  Based on my read of the other threads discussing this issue, it appears as if the currently known fixes apply to *both* encoders.  Is it even possible to apply such a fix to just one of the encoders?  When assembling my kit I noted that my two rotary encoders were very obviously different parts so I suspect that is the root cause of my "one encoder only is wrong" issue.  Thanks.

Robert

[Nick M]

That message seemed to work :)

I'm new to all this, so this isn't official! (not even sure posting code is allowed here? Apologies if not.) here's a quick and dirty thing I just tried in gpio.c:

        // detect end of rotation
       for (i=0;i<2;i++)
       {
               if ((code[i]==3) && (lastCode[i]==1))
               {
                       lastCode[i]=code[i];
                       switchscan = switchscan + (1<<((i*2)+8));
//                      printf("%d end of UP %d %d\n",i, switchscan, (1<<((i*2)+8)));
//                      knobValue[i]++; //bugfix 20181225
                       if (i==0) knobValue[i]++;else knobValue[i]--; // adjust based on knob #
 
               }
               else if ((code[i]==3) && (lastCode[i]==2))  
               {
                       lastCode[i]=code[i];
                       switchscan = switchscan + (2<<((i*2)+8));  
//                      printf("%d end of DOWN %d %d\n",i,switchscan, (2<<((i*2)+8)));
//                      knobValue[i]--; // bugfix 20181225
                       if (i==0) knobValue[i]--;else knobValue[i]++;
               }    
       }

and it reverses only one of my knobs. Those boldfaced lines are the new ones (as well as commenting out the line above them). Basically, "i" tells you which knob, so you can make the adjustment based on i (and if this reverses both knobs, change swap the two ++ with the two - -).

  -Nick

[Robert S]

Hi Nick - thank you for the quick response to my question!  Having never messed with the sources before, what is the proper sequence of steps once I modify gpio.c per your message?  Assume I just go through the install again and use the "build from source" option?  Or is there a more surgical way to install this change I should be considering?  Thank you.

Robert

[Nick M]

Hi Robert,

For my setup, I just went into /opt/pidp11/src/11_pidp_server/pidp11/ and then said

  make all

Again, I'm still figuring this stuff out, so your mileage may vary. In particular, I'm not worried if my PiDP-11 code base shifts away from the standard setup :)

 Cheers, -Nick

[Robert S]

Thanks again, Nick!

This may be obvious to the more experienced among us but in my case, simply using "make all" produced all sorts of compile errors.  Note that I'm compiling directly on a Pi but I still had to explicitly add the Pi as the build target, which I don't fully understand.  The command that worked for me was: "make all MAKE_TARGET_ARCH=RPI"

Robert

[Nick M]

Ah yes, my bad. At the top of the makefile I added

  MAKE_TARGET_ARCH=RPI

which specifies the target architecture (same as you did on the command line).

> still had to explicitly add the Pi as the build target, which I don't fully understand

The makefile looks to be general-purpose, for the Pi, BeagleBone or X86, so some of the directories etc. vary based on your build target.

And hey, thanks for the STL files for your 2-post rack! I love the design. It's about half printed now - appreciate your posting those files :)

 -Nick

[terri-...@glaver.org]

On Sunday, December 28, 2025 at 6:02:41 PM UTC-5 resi...@sbcglobal.net wrote:

Anyway, in my case I have one encoder that lights the LEDs in the correct order and the other LED lights the LEDs in reverse.  Based on my read of the other threads discussing this issue, it appears as if the currently known fixes apply to *both* encoders.  Is it even possible to apply such a fix to just one of the encoders?  When assembling my kit I noted that my two rotary encoders were very obviously different parts so I suspect that is the root cause of my "one encoder only is wrong" issue.  Thanks.

That was definitely a kitting error by Oscar (earlier kits) or CEDS (later kits) as both

encoders should be the same, just like all LEDs should be the same size, shade of

red, and brightness.

What likely happened is that Oscar / CEDS said "send me 500 more" to the same

supplier they had been using, got a bag with the same part number as before, and

put them in the bin with the few remaining older parts.

If you're comfortable with de-soldering one of the rotary switches, send pictures of

both to CEDS and ask for a replacement that matches one of yours. Then de-solder

the different one and install the replacement.

While there is support for both old-style and new-style encoders in my fork (which

will eventually become the official version), mismatched encoders is not something

that happens often enough (I think yours is the second or third case I've heard of in

6500+ shipped kits) to support. 

[terri-...@glaver.org]

On Sunday, December 28, 2025 at 6:37:25 PM UTC-5 nicholas...@gmail.com wrote:

That message seemed to work :)

I'm new to all this, so this isn't official! (not even sure posting code is allowed here? Apologies if not.) here's a quick and dirty thing I just tried in gpio.c:

 Posting code snippets like this is definitely OK.

  

//                      printf("%d end of UP %d %d\n",i, switchscan, (1<<((i*2)+8)));
//                      knobValue[i]++; //bugfix 20181225
                       if (i==0) knobValue[i]++;else knobValue[i]--; // adjust based on knob #

You need to be careful because there are umpteen versions of the PiDP-11 code

floating around, none of which were under any sort of revision control. That's why

I asked Oscar to move to GitHub.

It is quite easy to make the build go "kaboom" or just not produce working code 

if you are starting with one of the pre-GitHub versions.

For the GitHub ones (either Oscar's or mine), in theory:

cd /opt/pidp11/src

./makeserver.sh

./makeclient.sh 

should work. Sometimes they don't notice that a source file has been changed

and don't do anything.

[Nick M]

cd /opt/pidp11/src

./makeserver.sh

./makeclient.sh 

Wow that's much simpler than what I've been doing! And yeah, I can see how over time things could diverge into many different versions.