Here's what the layout should look like when it's done, and what the schematic for the right half looks like now. I've seen Joe Scotto's tutorial on the subject.
I'm currently making a schematic for this keyboard in KiCad v7.0. The schematic has the power & backspace keys moved down near the thumb keys to use one fewer pin on the controller, hence the slightly messy wiring.
- What controller should i use for a keyboard like this? How many more pins will it need than just the 5 columns and 6 rows on each side?
- What USB connector ports should i use? What are the differences between one USB-C port and another?
- Do i need a controller for each part of the keyboard, or only for the part that plus into the computer?
- Where can i get KiCad files for a trackpoint so i can add that to the schematic and PCB?
- I've only ever owned one mechanical keyboard (Chouchou by dlip) and it doesn't look like it has any diodes. Do i need those or not?
- Can i hide the controller and ports in a case if i'm using low-profile switches and caps?
Thanks in advance.
Actually, I just saw that the image could zoom in if I opened it in a new window.
Regarding your connectors: If you want to have the different parts of the keyboard connect by USB-C, then you would need to add a USB-C hub inside each part that could have downstream devices.
If you are willing to have each part be a different USB device, that would simplify the design a lot. Then, they could all connect to a USB hub.
If you want to minimize cable clutter, you might consider interconnecting the components with something like QWIIC, which is pretty small. It would also require doing custom firmware.
For these split keyboards, the more common thing is to use the functionality built into the custom firmware to have them act as a single USB device. It’s particularly important here as the small number of keys mean there are lots of things going on with layers and macros, so having the two halves talk to each other is quite important.
With the easy availability of wireless-capable controllers, fully wireless splits are becoming more common, but for now the most common way to connect the halves is with a TRRS 1/8” audio cable or a repurposed 4-conductor USB port, as the firmware can send what it needs between the halves with 4 wires.
That’s not to say people (and companies) aren’t doing more involved and creative things with hubs and base stations and the like, just that it’s not necessary to have a split keyboard that operates as a single device with one USB cable to the host and one “USB” cable connecting the halves.
I wanted to use USB-C so everything is hot swappable. From what i've read audio cables aren't great for that.
I do have a USB hub already so i could just make these 3 separate boards instead of a 3 part split. It would mean a few more wires on my desktop but i don't mind that too much. Especially if i make the pad wireless.
The problem you might run into is that if you connect everything "properly" via USB, they are separate, discrete devices. In many ways, that's fine. People have multiple keyboards attached while testing things. Separate numpads and macropads basically are this. The challenge you are going to run into with the two main halves of your keyboard are that if they are discrete USB HID devices, they cannot share any modifiers that are not built into the OS. So like, "Shift" and "Control" will work fine, but "FN1" and "Fn2" and anything you code outside the "normal" HID protocol will be quarantined to that half of the keyboard. You couldn't, for instance, hit a layer-shift key with your left hand and tap F11 with your right.
I agree with the other poster that to make the numpad piece truly modular, integrating a hub of some sort will work. I would just say the two halves of your split keyboard need to work together as a single device, one way or another. ZMK is built for wireless keyboards, so that might be the first place to go looking.
Finally, while I'm personally deeply fond of builds that include numpads, many folks who go ergo do it specifically to keep their hands from flying across multiple devices, so they figure out how to do numerical entry and navigation on the main units of their split device.