Mechanical keyboard wiring using the Tutte-Coxeter graph

Following my post on Topology meets Keyboard Design, I spent a few days exploring small less symmetric graphs, trying to find something in the region of 30~42 edges, 20~29 vertices, and as good a girth as possible (especially to have better rollover for the modifier & layer keys) for use in an ergonomic keyboard design. Then I realised as a starting point we can just use part of the 30 vertex Tutte-Coxeter graph, and get 6-key rollover automatically.

All 30 vertices in Tutte-Coxeter graph

28 of 30 vertices in Tutte-Coxeter graph

26 of 30 vertices in Tutte-Coxeter graph

Why use graph theory to wire a keyboard? As per the previous blog post it avoids the need for diodes. I am not confident at soldering, so if I were to design my own keyboard at the PCB level, I'd rule out diodes, a separate USB port, BlueTooth (due to the extra complexity and circuitry for batteries), and split designs (due to the wired interconnects). I'm leaning to a small wired mono-block keyboard with a single USB-C socket on the controller daughter board for simplicity. Perhaps physically the same as an existing open choc-spacing design with a nice case design that could be reused.

So, what looks possible with a partial Tutte-Coxeter graph?  As per the set of graphs above, removing one vertex (dropping to 29 GPIOs) loses 3 keys, but after that the next few removals need only drop 2 keys. I suspect slightly more optimal graphs exist, but these are good enough: 

GPIO	Controller(s)	Keys	Suitable keyboard layouts
30	Olimex RP2040-PICO30	45	Keyboardio Arteus (44), Choctopus44
29	Waveshare RP2040-Zero, 0xCB Gemini (both 20 pins + 9 pads)	42	Original Arteus, Zerosprey42, Reviung41
28	RP2040 Pro Micro, YD-RP2040, WeAct RP2040	40	Pica40, Stront (40)
27	?	38	Totem, Stront (38)
26	Raspberry Pi pico series (old USB micro port), CPico RP2040	36	Egret, The Endgame, Gamma Omega
25	elite-pi, 0xCB-Helios	34	Forager, Sweep
24	Elite-C Low Profile (rev4)	32	Onishi's Fish
23	Liatris Microcontroller	30	Hummingbird, Tern

Many of those controllers are based on the RP2040 which has excellent support on the software side, but it is rare to have all 30 GPIOs exposed. Sadly I will avoid the Waveshare RP2040-Zero form factor with 21 GPIOs because 9 of those are awkward solder pads, not pins round the edge. Note often exposed pins like GP25 are tied to an LED, rather than being free for general use. There is also the iMX RT1011 Nano Kit (33 GPIOs) and nRF52840 Connect Kit (32 GPIOs) to consider. The newer RP2350B chip has 48 GPIOs, meaning you could in principle use the simplest circuitry of one GPIO per key for the size of keyboard I have in mind.

The 38 to 42 layouts I am looking at fit within a 3x6+3 pattern per hand (three rows of six columns, plus three thumb keys), or treating the thumbs as columns that's like a total of 14 columns of three (2x7x3 = 14x3 = 42). That makes it easy to layout the scanning matrix column wiring on one side of the PCB. Here my sketches show a Qwerty layout for familiarity, and assume something like the RP2040 Pro Micro form factor with 28 GPIOs, with the scanning and physical columns in red:

There is a lot of flexibility in which pins to use (note the seemingly random white scan row pin labelling), and the column wiring as shown leaves plenty of space to put some of the scanning-row wiring on this side too. However, I could get all of that on the other side of the board, albeit with 9 traces under the controller footprint squeezing between pins - shown here with blue trace wiring to the white row scan pins. These are nothing like the physical rows:

This was laid out to cover either a 40 or 42 key layout, where the top left and top right keys are optional. That would need one more row-scan pin (white node R15), making 29 GPIOs in total. It would hardly change the column wiring, and the extra row traces run along the top.

Dropping down to 36 or 34 keys, the scanning-row wiring is a little easier, but follows the same idea. Between 34 & 36 keys, most people would add/drop thumb keys. Given the scan columns work out as ten sets of three (C1 to C10), and two or three pairs (C11, C12, and optionally C13), I put the two keys "columns" as the thumb keys. This time the 26 GPIO pins are modelled on the Raspberry Pi Pico layout.

Again, the scan-row side is the complicated one, and crossings were avoided by 9 traces under the controller footprint squeezing between pins, and putting all the optional thumb key traces on the row side (scan "column" C13).

That was a nice set of puzzles to play with. I guess I could do a similar sketch solution of the PCB traces for a 32 or 38 key layout, or the 44 or 45 which might be a rat's nest. But perhaps time to move on to trying the open source tools Ergogen and KiCad with a view to getting a PCB made at JLC PCL? And get a case 3D printed there too, or maybe a custom laser cut keyboard case?

The partial Tutte-Coxeter graph ought to work as some silk screen art for the PCB.