The encoder has quadrature 2-bit gray code output, and I can see the A and B levels toggle at each detent position according to the truth table.

With polarity set to ACTIVE_HIGH, the program counts positive every four detents when A=1 and B=0 for CW rotation.

With polarity set to ACTIVE_LOW, the program counts negative every four detents when A=0 and B=1 for CW rotation.

I'm thinking about putting some rt-printf statements in Encoder::process(bool a, bool b) to visualize how the different cases of A and B fall through.

    Of course that kinda makes sense if you are only looking for transition edges on input A.

    right, so there may be need to add a new type to the enum and related handling code in process().

    stgislander I'm thinking about putting some rt-printf statements in Encoder::process(bool a, bool b) to visualize how the different cases of A and B fall through.

    Go ahead! You probably need to print only on change (of either b or a) to avoid flooding the console. Needs to temporarily #include <Bela.h> at the top of that file, too.

      Speaking of the console, the window scrolls up as new values come in the bottom. At some point the scrolling stops so I have to pull the side tab down with my mouse so I could see the latest values that came in.

      Are there any settings in the IDE to change that?

        And maybe a new type to the enum is not needed, but looking for the case where a == lastA_ and then dealing with the level transition on b. It's an encoder so there is a transition at every step.

          stgislander Are there any settings in the IDE to change that?

          it may be a browser zoom issue. Try resetting the zoom to 100% and see if that fixes it.

          stgislander And maybe a new type to the enum is not needed, but looking for the case where a == lastA_ and then dealing with the level transition on b. It's an encoder so there is a transition at every step.

          I wrote that class based on some encoders that I had around, for which it worked as expected with one of the enum values. IIRC, the rationale was: wait for a change on a and then look at the level on b to know which way we are turning. The one you have seems to be working differently, do you have a datasheet link?

              Yup, that won't work with current code. Do you need help with fixing it?

              I'm debating if I can get away with (for lack of a better term) double-step operation. My customer wanted to use these for manual setting of operating parameters. The operator will feel every detent click, but only every second click will set anything.

              I've looked at some Arduino code that sets up state machines to count at every step. I'd have to look into seeing if it can be ported over to the Bela/BeagleBone Black.

              What are you thinking the time would be to modify the existing Bela code?

                stgislander What are you thinking the time would be to modify the existing Bela code?

                If one has the encoder at hand, that would be one hour including debugging perhaps. I'd encourage extending the library instead of rolling an entirely different implementation ...

                  Good thing I have four of them handy, huh?

                  So far I've made the following changes to Encoder.h and Encoder.cpp. I'm going on the assumption that I need to perform the same debounce and edge checking operations on input b as I do on input a. I've commented around the code I've added.

                  In Encoder.h I added four new variables to private

                  private:
   bool validEdge(bool a);
   unsigned int debouncing_;
   unsigned int debounce_;
   int position_;
   Polarity polarity_;
   bool a_;
   bool lastA_;
   bool primed_;
   //TIM 3-2-22 New
   unsigned int debouncingB_;
   unsigned int debounceB_;
   bool b_;
   bool lastB_;
   //end NEW

                  In Encoder.cpp I made the following changes

                  void Encoder::setup(unsigned int debounce, Polarity polarity)
{
   debounce_ = debounce;
   reset();
   polarity_ = polarity;
   debouncing_ = 0;
   primed_ = false;
   //TIM 3-2-22 New
   debounceB_ = debounce;
   debouncingB_ = 0;
   //end NEW
}

                  and

                  Encoder::Rotation Encoder::process(bool a, bool b)
{
   Rotation ret = NONE;
   if(!primed_) {
      lastA_ = a_ = a;
      primed_ = true;
   }
    
   if(a != lastA_) {
      if(validEdge(a))
         debouncing_ = debounce_ + 1;
      else
         a_ = a;
   }
    
   //TIM 3-2-22 New
   if(b != lastB_) {
      if(validEdge(b))
         debouncingB_ = debounceB_ + 1;
      else
         b_ = b;
      }
   //end NEW

   // wait for the data to be stable long enough
   // before checking for an updated value
   if(1 == debouncing_ && a_ != a)
   {
      a_ = a;
      if(validEdge(a))
      {
         if(b == a)
            ret = CCW;
         else
            ret = CW;
         if(ACTIVE_LOW == polarity_)
            ret = CCW == ret ? CW : CCW;
         position_ += ret;
      }
   }
   if(debouncing_)
      --debouncing_;
   lastA_ = a;
    
   //TIM 3-2-22 NEW
   if(debouncingB_)
      --debouncingB_;
   lastB_ = b;
   //end NEW
    
   return ret;
}

                  That leaves the checking and counting operation in the if(1 == debouncing_ && a_ != a) conditional statement to handle.

                  Am I on track, and what are your thoughts on performing checking and counting input b?

                  Technically I've made the changes to files on my local PC. I'm guessing the real library files that are used to build programs reside on GitHub?

                  For testing purposes, can I point the IDE to modified library files on my PC?

                    stgislander I'm guessing the real library files that are used to build programs reside on GitHub?

                    no, they are on the board. You can copy your file over with something like

                    rsync -av path/to/Bela/libraries/Encoder/Encoder.* root@bela.local:Bela/libraries/Encoder/

                    or directly edit the files on the board at /root/Bela/libraries/Encoder/

                    When editing a library, you won't automatically trigger a rebuild of the program, so you either need to make a non-meaningful change to the file in your project or add RELINK=1 to the Make parameters box in the project settings in the IDE to automatically rebuild the library (you can remove it later on when you are done with the development).

                      Okay I may have a problem. That looks like Unix (yeah I'm that old) to me, and I live in the Windows world.

                      Can I do any of that through the IDE?

                        stgislander Can I do any of that through the IDE?

                        it's complicated. You could also add all the (modified or not) files from the libraries/Encoder folder to the project folder and turn all instances of

                        #include <libraries/Encoder/Encoder.h

                        to

                        #include "Encoder.h"

                        and

                        #include <libraries/Encoder/BelaEncoder.h

                        to

                        #include "BelaEncoder.h"

                          Thanks. I'll try that.

                          I'm also looking for a Linux desktop/laptop, and/or installing Windows Subsystem for Linux (WSL) on my PC as a fallback.

                          or install github desktop and it comes with "Git Bash" which should have scp and/or rsync

                          So should my modified files still be named Encoder.h and Encoder.cpp, or can I can I rename them to differentiate them from the originals?

                          Also, thanks for pointing out the BelaEncoder.* files. I didn't think to look at those.