Teensy with massive rotal encoder and switches array

Support
1

Hi folks,

I am planning to build a massive reto-synth inspired midi controller with a whopping 176 rotary encoders (not potiometers) and 32 toggle switches, plus a few other bits and bobs.

I have been researching options for this for a while and come up with two general architectures:

Option 1
Distributed processing with Teensy Master and 3 ESP32s with multiplexer arrays to handle encoder inputs. Basically, each ESP would process 64 encoders and switches, and pass the information to the teensy over UART packages.

Option 2
A teensy with chains (three sets of 22 deep!) of step registers 74HC165 (DIP-16) to gather the digital inputs from the econders and switches and process in one heap.

The first option may provide a little more flexibility in pre-processing, and I think the ESP32s should handle 64 encoders and the switches sufficiently quickly, even though they are processed sequentially.

The second option seems to be more efficient, as all encoders and switches read at every cycle.

The design will benefit from the fact that it is only humanly possible to move two encoders or switches as a time, so we are not talking fast changing data here.

Does anyone have experience in creating massive pools of digital input devices? If so, what are your thoughts and tips of both or either of these two approaches?

1 Like
2

Option 1 depends on the type of encoder. An encoder that depends on the MCU counting pulses as it is moved will not work in a multiplexed system, as it relies on interrupts. If the encoder canā€™t inform the MCU that it needs attention, and has to wait for the MCU to swing by, then interrupts wonā€™t work.

If itā€™s the type of encoder that calculates it position and reports that position when requested, then that would be OK because the multiplexing will likely be able to keep up with whatever the user can do (although you can be pretty sure the user will find a way to move more than two encoders at a time).

For option 2 I canā€™t see what the arrangement would be. You seem to be implying that the registers provide a means for the teensy to access 8 digital inputs of three bits each through each MCU port. But 3 bits is not enough for an encoder to report its setting.

1 Like
3

Man talk about targeted clickbait.
I absolutely need to see photos of this when itā€™s done ya know?

Yeah actually. I just finished a project where I needed 20 servo motors all controlled via open sound control. To distribute the logic I used the I2C protocol.

image
image1140Ɨ614 11.8 KB

i2c was great for me because it meant each individual device was responsible for fewer things, making it more responsive. Additionally, when it came time to debug, my master device had lotā€™s of logging and it was really easy to find where the problem was.

This modular approach is most similar to your option 1 using UART.
I must say the multi-device style infrastructure had a pleasant, take it one step at a time, build process.

With that being saidā€¦
Aesthetically Iā€™m in love with your option 2.
I would consider trying to build some kind of bus to try and compartmentalize it.
Then I would use these 74HC125 tri state buffers to manage who own the bus at each point.

my two cents.

1 Like
4

Thank you for the diagram. It is very similar to my option 1. The teensy is going to be the master, since it has USB midi. I have what I need to prototype that up to 64 encoders (will start with a far smaller number)

Comments on option 2 are appeciated. I plan to prototype that an, it the clock speed it up to the task. Will definately keep it modular as you suggest.

As for the click baitā€¦ this is my ā€˜bucket list projectā€™. Every five years or so I take on a new area to learn. Over covid, it was modular synths (virtual, with VCV and Cherry Audio Voltage.) That took me into the virtual retro synth worldā€¦ but.. I really wanted my knobs to twist! I purchase the wonderful German Faderfox PC12, but it lacks the ability to quickly switch between synths and have all knobs remapped and on-target. So I looked at rotatary encoder devices and got the ElectraOne, which is excellent bit of kit, but still did not give me the olā€™ school FEEL I wanted. I began design my ideal midi surface: one that can handle the naunces of the dual CS-80 (Cherry Audio CX-80 is a beautiful thing!), Elka or the Glorious Korg 3300. Hense the need for lots of encoders and switches. I intend to go ā€œ80ā€™s Dr Who Tardisā€ with the look of the controller. So I guess I also need to learn carpentry.

My plan it to take this project slowly. Starting with 8, then 20 encoders, then moving to 64, etc. Early iterations will be a cardboard frame. I have no idea what Iā€™m doing, but Iā€™m spending effort researching options, reaching out to others whoā€™ve done synth or controller projects, etc.

So, yeah. Trying to keep this bedraggled brain busy and distracted.

1 Like
5

Nice one man.

Feels good.
Just letting you know that I believe UART is a device to device protocol.
Both Option 1 and Option 2 may both need a bus of some sort: something for multiple devices and or components to share and talk to the teensy. Iā€™m not saying you canā€™t do that with UART, but some of the strengths of i2c and spi is that theyā€™re protocols that assume a bus.

You could make a UART bus if you were inclined.
I donā€™t think you can put pull-ups on the UART lines though so you might have to connect and disconnect between each transmission??? ā€¦ uhhh not sure about that more research might be required before you commit.

Also seconding what @Jeff105671 said about multiplexers. I wouldnā€™t fancy having to micro manage the clock of my multiplexor whilst handling all of that traffic.

1 Like
6

I second the I2C suggestion! Fewer wires and the ability to have many encoders wired through the same input sounds like a helpful thing, considering the number of encoders you are planning on using.

SPI would also work and is usually faster in most cases, but in my experience, it can be a little more complicated than I2C to implement.

2 Likes
7

Thank to everyone who has been providing input to this.

After some messing about, I now planning to use ESP32 S2 minis (or similar) as the slaves as they are dirt cheap in bulk. I am going to keep the I2C lines on these free to drive an OLED screen for each ā€˜moduleā€™ of the controller.

I will use UART for the coms between the slave modules and the master, which is likely to be a Teensy, though an ESP32 S3 38pin looks to be a viavble option, since so much of the workload is being handled by the swam of ESP32 minis.

In addition, I have been working with 74HC165 PISO (Parallel in, Serial Out) chips to read the rotary encoders and buttons. I can chain these chips so that I can retreive a large number of rotary encoders signalsā€¦ though I am not yet sure what ā€˜largeā€™ cuts out at. Inital research suggest it could be as high as 64 input lines (32 encoders!). Plus I could run another chain to do the buttons.

THE TEST AND A REQUEST FOR WISDOM

To test the above concept, I started with a simple single 74HC165N chip, connected to four rotary encoders (each encoder needing 2 lines on the chip). The rotary encoders are KY-40s, and have 10K Ohm pullup resistors. The voltage used is 3.3, but also tested at 5v.

The breadboard test worked pretty wellā€¦ the encovers were returning data when twistedā€¦ butā€¦

The encoder readings get duplicated, or under reported.

In short, I am finding it difficult to debounce them.

Iā€™ve looked through the forum here (and others) and see a few entries about debouncing and stablizing rotary encoders, but nothing that deals with the situaiton of using a PISO chip with the encoders.

Has anyone else done this, or something similar? If so, any tips on stablizing the encoders reads would be very helpful.

Iā€™d like to get the encoder reading stable prior to chaining more PISO chips and more encodersā€¦ letā€™s see how many encoders and buttons I can chain reliably!

1 Like
8

8-12mm momentary buttons with RGB LEDs?

On a related topic, I am looking for a soft rubber momentary button that also features an RGB LED light inside to indicate status. Iā€™ve not found any buttons that fit the bill. Any suggestions are very much appreciated.

Attached is a photo of the wonderful Midicake Arp. These are my ideal buttons!

20250605_162753
20250605_1627531920Ɨ2560 353 KB

Best regards,
Joe

1 Like
9

Do what I do and steal someone elseā€™s idea from a datasheet.
Never fails :slight_smile:
I mean it absolutely does fail all the time but itā€™s always entirely my fault.

This encoder for example seems to me to be just a breakout. On itā€™s datasheet it has a diagram recommending some external components.

image
image265Ɨ171 9.32 KB

There are RC filters on the outputs of the encoders, and thatā€™s what theyā€™re suggesting for debouncing. This is how Iā€™ve always debounced my rotary encoders and itā€™s been reliable for me. (I just made up random values and pray :man_shrugging:).
This hardware approach should be compatible with your PISO chip and similar 74HC devices.

I think I would start by just building the circuit as depicted with 5v, make sure itā€™s working. Then bring it down to 3.3v and experiment with the resistor values if required. (I typically use 5k for pullups on 3.3v circuits but I donā€™t think there is a hard and fast rule).

Do you think RC filters like this work for you?

10

Hi Joseph

If this is the Core device it has an on board de-bounce filter which works pretty well up to a point. As with any passive circuit it has limitations and can be beaten if you try hard enough.

If you go to the Core product page there is a lot of discussion and oscilloscope pics from myself and others which covers just about everything. Have a read of this topic and should answer most of your questions. The whole topic is under ā€œCommentsā€ tag.

I guess that the bottom line if you want zero or near zero bounce you donā€™t use mechanical switches. Optical or magnetic are the go, preferably with a built in Schmidt Trigger which should remove any little aberrations on the output pulse.

The cost of such devices could be a game changer but I am not sure how much more expensive they actually are.
Cheers Bob
Core SKU: CE09436

11

I donā€™t see how this can work. How are you synchronizing the readout of the 74HC165N with the rotation of the encoders? Unless you are sure that the encoder is not changing as the data is read, then you will sometimes get a data stream that includes a portion of the motion - the A click without the B click or vice versa. And even if you get both clicks you canā€™t tell which occurred first. Or, are you hoping that you always read out the data between clicks of a movement, so that you can see that one click happened before the other? In that case how do you know that the subsequent data readout waited long enough to get the second click, and didnā€™t wait too long to miss it and interpreted it as a different movement? These rotary encoders depend entirely on interpreting the timing and sequencing of the clicks, and it seems to me thatā€™s not possible if you are feeding them through a PISO and serial data stream. I think your problem is not debouncing, but the errors that are inherent in that setup.

12

Hi Joseph
Take a look at this web site which may interest you

They have some interesting switch/encoder interfaces. I personally have the BU-0836X which seamlessly added 10 encoders and 2 potentiometers to my flight simulator. Just make the USB connection. Button and axis configuration done within the flight simulator so donā€™t know exactly what the USB signal looks like.

In your case the interesting one might be the BBI-64. 64 button / 32 encoder interface. All debouncing etc seems to be within the interface. The encoders I am using behave without any sign of instability.
Cheers Bob