i2c encoders in matrix with I/O #ubitx

John (vk2eta)

Hello Tom,

Further read of the manual reveals that as you said the 256 registers are at one I2C address, and are divided between control registers and EEPROM addresses (two banks of 128 bytes).

The current implementation has the current modes for the encoder:

A. Relative, where the counter keeps the number of steps since last read. Reading it resets the counter to zero. Useful for frequency tuning in our case.

B. Absolute
     B1. Without limits.
     B2. With user defined limits
            B2.1. No wrap around, like a potentiometer, hard stops at the limits.
             B2.2 With wrap around, goes back to low limit if high limit is exceeded and vice-versa.

The encoder push button events are:
- button down
- button up
- double-press with user selectable double-press interval.

Current consumption is listed at less than 2mA plus LED current if used.

The board mounted PIC controller's program is open source so it can be customized as well.

Very neat IMO.

73, John

Tom, wb6b

On Wed, Aug 28, 2019 at 01:49 AM, John (vk2eta) wrote:
From a quick read of the Arduino library (
Thanks for the URL to the library. Now I can look to see what they did to handle the registers. It sounds like the registers are pseudo registers, not using up I2C addresses.

Tom, wb6b

Tom, wb6b

On Wed, Aug 28, 2019 at 07:28 AM, Don, ND6T wrote:
it would need to be polled constantly to avoid missing a movement
It looked like they keep a counter in the PIC chip that is on each board, so each time you check the status of an encoder board it will tell you how many encoder pulses took place since the last time you polled the data. This should greatly relax any timing issues.

Tom, wb6b

Don, ND6T

Please let us know how this board works out. My biggest concern would be that it probably would need to be constantly queried. For example; If you wanted to put the tuning knob on it, then it would need to be polled constantly to avoid missing a movement. As it is, just a millisecond of delay can mean a missing action and is intolerable. That's why non-interrupt encoder schemes are often flaky.
The I2C bus is incredible. I feed two displays and the synthesizer with just a minimum of wiring and it frees a slew of pins. Love it! Great for temperature sensing and time, too. Fingers crossed for a good result, Don

Gary Anderson

On the hardware side, the interrupt pin INT, is an open drain asserted low signal (maybe better described as INT_B).  This node can be wired OR'd. ( 'daisy-chained' as John described)
The software will need to scan/poll each device to determine which module(s) asserted an interrupt, and service it  or them appropriately.


John (vk2eta)

Interesting devices. The boards also have 2 or 3 general I/O pins (depending on the usage of the LED), and 128 (256?) Bytes of EEPROM.

From a quick read of the Arduino library ( they have mapped registers at the selected I2C bus address (one for each encoder module). The registers perform configuration and access to encoder, push-button and GPIO pins and EEPROM data.

The library supports interrupts and callbacks which is handy but requires one interrupt enabled digital input pin (but I am not sure if it's one per module or if the modules can be daisy-chained to the one input).

73, John (VK2ETA)

Tom, wb6b

It looked like they mapped 256 I2C address to the various internal registers and the EEPROM. Then had an additional 7 bits of high order I2C addresses. There is an expanded I2C addressing scheme, greater than 7 bits, but I do not know how many libraries support it.

If what they actually did is create a bunch of pseudo registers, then you will need to deal with creating a protocol on top of the I2C protocol. Hope they provide drivers to layer on the pseudo register addressing and handshake, over the I2C protocol, if that is the case.

Tom, wb6b

John Scherer

From what I can tell, each board is an i2c slave and utilizes a single i2c address. However, each board is configurable to use one of 127 possible i2c addresses.  I would assume each board would need a separate i2c address, and with 127 available, I don't think this would be a problem.  Or am I missing something?
John - N0CTL - Fulltime RV in a 40' motorhome

Tom, wb6b

On Tue, Aug 27, 2019 at 01:59 PM, John Scherer wrote:
I came across an interesting, i2c addressable rotary encoder board
Very clever deign. Also did not know encoders with an RGB LED that could send light down a clear shaft to the knob were available. 

These boards seem to use a lot of I2C addresses, but they claim they are compatible with most or all development boards.

Tom, wb6b

John Scherer

I came across an interesting, i2c addressable rotary encoder board that allows you to connect encoders in just about any configuration.  The board has pins for digital or adc I/O, has 256 bytes of eeprom, pads for setting each encoders i2c address, and works from 3.3-5v  I just ordered several boards to play so I'll see how well the work.  For something like the uBitx this could be a easy way to add additional physical I/O (i.e. knobs) for those of us that like knobs ;-)

There is also a video that gives a pretty good overview of how they work.

I did a quick search to see of anyone else posted this but if by chance I miss it, and someone already has this working, let me know.