This is a little nine-encoder project that you may have seen floating around, with a build album link included. This one is hand-wired to a ProMicro as a test piece running off QMK, and is using a printed case and knobs. My main goal right now is seeing if people are interested in a small, budget-oriented, encoder-only project board as just something nifty to have. I’d also like to hear suggestions to what you personally might want out of a little board like this
Right now each of them is set up with left/right/press/hold functions of volume down/up/mute/setvalue for different app groups on my pc. First one is systemwide, second one is active window, then Spotify, Discord, and Firefox, with the last four I’m working on setting up the usage for them.
As nine in one place could be too many for some people, an idea I’m tossing around is a snappable PCB that would allow you to do anywhere from 2x2 to 2x3, 3x2, or 3x3 setups all off the same base configuration.
That’s pretty cool. I just recently discovered the Windows+G function on windows 10 that allows you to quickly access all audio sources for volume. It’s a really fast and efficient way to set things up. But this looks even better.
I’m just using AHK and NirCmd with a relatively simple script that’s just running a nircmd function when it receives a keypress.
The "changeapp(or sys)volume commands are changing volume in 2.5% increments, muteapp(sys)volume is toggling mute on/off, and setapp(sys)volume sets volume to 50% for when I want to re-reference them. All the stated keypresses are “wrapped” inside a F24 keypress so that AHK can suppress the presses from being picked up by other running apps. This functionality is borrowed and adapted from Taran of LTT and his scripts here.
Eventually I’ll be moving to using AHK’s “hotstring” functionality and sending probably 20 character strings that will include info on what board, switch position, and layer the press was sent from in that identifying string. It’s gonna be super overkill, but I’m trying to setup my personal use case to be able to handle expansion in the future to utilizing stuff like a ScrabblePad as a function board while not worrying about running out of easily accessible addressing for my function usage.
I know lots of people won’t want to or can’t work with AHK and another app, so that’s the benefit of QMK giving as many options for assigning commands as you can work with.
Been getting a little more work done up on this project lately, just needing the motivation to poke at it after hitting a bit of a wall on it. Hoping to get some proto PCBs soon that’ll allow me testing with a few diode configs to see if that helps the intermittent crosstalk I was getting in previous tests.
Proto PCBs received, gonna get to do some testing for a couple different things I’m looking into on these before my next revisions happen. A few of these are extra since the minimum I could order is 5, so if you’re looking to snag one hit me up and I’ll get back to you once I make sure they’re completely functional.
Good news, the boards work! I managed to get silkscreen backwards for one of the diodes, but no biggie there. Gonna order another pack of encoders so I can fill out the board and do some testing with debounce circuits in case that helps with some of the other downsides to the matrix layout. I’m playing with case design stuff including SLA considerations, and planning to look more at Bourns encoders for my future needs, including this eventual GB, as I can find the models I like much easier than Alps.
Far as I can tell my PCB behaves as I expected it to, but nothing more. This is good in that my transcription from handwire didn’t introduce any weirdness. This means I can focus on features now over any troubleshooting.
What’s next:
Case design: The original case won’t fit the PCB or discrete controller setup, so obvs I’ll be needing to work on that I’d also like an improved bottom retention piece since my previous one was functional but lackluster. I’m also exploring options for doing the cases via SLA to look extra cool, like so:
Small version: One of my original ideas was having “breakaway” portions of the board so people who didn’t need 9 encoders could go down to a configuration of 6 or 4 with a smaller footprint, but keep the same board design for that volume efficiency. I’m still onboard(hah) to try this, but also trying to make it so the PCB edges after doing so aren’t scuffed af with potential clear cases.
Bourns encoders: Alps may be what everyone’s more familiar with, but they’re also a pain and slightly pricey to source. Meanwhile I was introduced to the fact that Bourns’ datasheet actually makes it super easy to nail down the exact model of encoder you want and then you can actually find them available for a decent price. When this hit’s GB these will be what I’m offering alongside the other components.
Other fancy bits: Obvious the design of encoders having a large bit of casing under the plate surface leaves a lot of room inside of the case, so I’m always looking at bits to fill that if. If anyone has any suggestions for stuff to put in here like OLEDs or such, hit me up.
Thoughts on putting all the encoders closer together? I love the concept but the board seems to have too much negative space to it, even if you got decent sized knobs there would still be pretty big gaps, and far be it from me to turn down a big knob, I’d love a more minimal footprint.
The big reason for the spacing is getting your fingers inbetween them.
As it is, if my thumb is out a little bit I’ll still hit neighbors sometimes. Right now this spacing allows more decorative knobs to be used while keeping neighbor impacts low, and it’s an even increment of normal keyswitch spacing. A single row/column of encoders wouldn’t need this spacing, but since you have them on both an X and Y axis arrangement that adds the spacing need.
Ah that makes a lot of sense, you seem to have thought this through very thoroughly. It would be cool to see a pair oleds running verticaly down the device in between the rows. what process/material do you intend to use to fabricate the final case?
Right now the plan is most of the cases be FDM PLA in a slew of colors, but I would like to make SLS resin clear cases an option as well should the interest be there and if reliably producing them is viable.
Nicely aged PanaVise Products, Inc. using a version of my printed parts tray for it at Panavise Tray Base Plus by donutcat - Thingiverse and some leftover pieces of a Harbor Freight helping hands for the spare clamps. I actually had plans at one point to try modeling up a mimic of the design for printing but that got sidelined for other work.
is it possible you could share the wiring diagram for the rotary encoder matrix? I’d love to learn how it works and implement it in a keyboard I’m designing.
I’ve actually been meaning to post an update as I’ve been slowly getting back to working on this. I managed to just hit a slew of roadblocks all at once back when I stopped; Breakaway tab system was causing a lot of issues for the doubled up amount of routing, the positioning on the Pro-Micro footprint didn’t properly take into account the excess length at the front of the controller and it stuck way out into the case, pin assignments needed to be drastically changed to free up pins for other components, and I was still facing the issue of the interactions of encoders in a matrix.
I had actually begun getting back to work on ScrabblePad2/BitBang, but as it turns out the chip shortage has stepped on my ARM learning experience there. With this I can work on it without being as impacted by the shortage. I’ll also be looking into seeing how this works out with KMK as I’ve just learned about that existing and I’ve been looking at a good reason to dive into CircuitPython for some time now.
So, it’s update time again and it’s a pretty good one.
This is one of the proto PCBs I previously had produced, though you’ll notice I’ve a fair deal of jank wiring hanging out on top of it now.
Through the assistance of the awesome @xyz over on the QMK wiki and their marvelous help with QMK encoder code, essentially every problem that previously existed with the encoder wiring is gone. No more ghosting when using multiple at once, and no more having an entire row/column locked because one is stuck between detents. And I was fortunate enough to be able to test for myself one a current PCB instead of needing to run a batch.
So what now?
Step 1: Redo my schematic to account for the new wiring layout needed for the updated encoder handling functionality.
This I’ve already got down and done.
Step 2: Embrace Kicad 5.99 and sick themes
Obviously having a stylish theme is crucial to the process. Also new features are so worth it. Also I’ve just noticed my PCB isn’t centered in my sheet, I will need to fix that immediately.
Step 3: Finish PCB design for next proto orders.
I’m hoping to have this done soon as I’d like to have protos on hand to gather feedback at an upcoming (vaccinated)meetup or two. Right now the main thing that I’ll need to test for with the proto PCBs will be new case fitment and getting the breakaway portions to, well, breakaway in a nice manner. Also some nifty silkscreen to take up some of that empty space is probably on the todo.
Step 4: Feature finalization then setup component sources
Yeah that’s it, we’re that close. Just to recap on features as they sit right now:
ProMicro or ProMicro-Compatible controller.
If you have a particular ProMicro replacement you like to use, it’ll work for this so long as it’s pin-compatible/drop-in replacement.
Controller choice affects firmware compatibility. Some available ProMicro replacements don’t run QMK because of the chips used.
3D printed case and knobs/wheels.
Right now the plan is still FDM PLA for both of these as that’s what I have access to.
Case design will be similar to the proto in my earlier pics and the renders I’ve posted, wheel/knob design will have a few custom options including what you see in my earlier pics.
SLA isn’t completely out of the question, but as I don’t have access to a machine currently it’d take a lot of interest and effort to make it available.
Up to 9x EC11 rotary encoders.
The plan is to use Bourns PEC11R series encoders in the kit, exact variant to be determined
Default layout is a 3x3 matrix, but the PCB will be snappable in two steps to move to either a 3x2 or 2x2 config.
Case variants will be available for “snapdown” configurations.
Breakout headers for SPI, I2C, and digital RGB connections.
Feeling adventurous and can’t leave well enough alone? I made it easy to throw even more features on here if you so choose.
Part of the RGB connection is a solder jumper for power selection. This allows using the RAW pin for 5v access if you’re using a 3.3Vout controller. I’ll probably also add one each for SPI/I2C.
QMK firmware compatible
Yes this is basically the free space on the keeb featureset bingo card, but still worth saying. You use a QMK compatible controller and it’ll run QMK, funny how that works.
The encoder matrix code is still experimental and not part of main, but the plan right now is I want to make it compile the modded code at the board/keymap level in case it doesn’t get pulled to main before the board is available.
Right now I still have a smidge more feedback I’d like to get:
Board color prefs: Green PCBs are plain, what does popular opinion say the best color is?
SLA case option: How many would actually be interested in this over FDM? Note that the super clear rendition above is likely super unrealistic without a super fancy process to go with it.
ProMicro option for the kit: If there’s enough interest I could see about hitting up a vendor that regularly has them about some bulk pricing for the GB, but tbh I expect that a lot of people would already have some on hand or be using a replacement.
Case/knob/wheel ideas: Thanks to the procedural nature of printing, there’s a lot of room for customization and fancification in designs. Have any ideas you’d like to see integrated in the parts for this board?
Bit of a side note, I’m also doing some experimenting concerning socketing options for dev boards, and whatever tidbits I pull away from that is likely to be at least partially applied to this board. If you’ve got any feelings/info on that topic, just throw it my way.
As usual, always happy to get feedback and info from anyone willing to share.
I’m a little behind on this week’s work from dealing with my second dose, but so far I’ve been able to test the snap-off part of the PCB and it worked as nice as I was hoping it would. I’ll get to throw one together for full testing in the next few days, but until then take a peek at the pics and see if you can notice some other nifty tidbits I’ve included.
