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.
Electrical engineer here. I can only answer a few of the questions:
This will be a “USB Device” (as opposed to USB Host or USB OTG) so the correct USB connector to use is B receptacle, mini-B receptacle (obsolete), micro-B receptacle (obsolete), or C receptacle. You can pick any one of those. The obsolete ones still work fine, it’s just hard to find cables for them. Mini-B is actually very durable. Alternately, you could have a captive cable with a USB A male plug on the end.
KiCad has pretty good facilities for making your own component layouts. Many components you simply can’t find existing files for. Unfortunately, this is part of the life of circuit design. It should only take an hour or so per component.
Adding diodes can enable N-key rollover. If you don’t need that feature, you could skip it. If you’re going to the trouble of making your own keyboard, diodes are a comparatively small cost, so you should do it. The Chouchou keyboard uses a separate pin for every single key, so it doesn’t need diodes.
Yes, you can hide the parts in a case. But you could also just make the back of the circuit board really long, and there should be enough space for it. Picking out connectors and cables and stuff is always a pain, so try to avoid having multiple boxes if you can. The electronics should be pretty small anyway.
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.
A great place to learn is QMK docs. I built custom keyboard twice (but both handwired) and got all answers from https://docs.qmk.fm/hand_wire.
But after some years of using qmk I migrated to zmk.
I believe this two docs have all answers you need.
Feel free to crosspost to [email protected]
- I haven’t done a proper split, but for my builds I like RP2040 boards. They come in lots of form factors and have more memory than Pro Micros.
- For a keyboard, you don’t need the full power or speed of USB-C. If it looks physically robust and supports data, even at USB2 speeds, it should be fine.
- I would strongly recommend two controllers. If you use one, you need to figure out how to string a wire for every single pin that the other side has to use. For you, that’s going to mean a very thick cable between halves. QMK and ZMK are well set up to support dual controllers, and MCUs are cheap.
- You can search GitHub for libraries of footprints, or craft your own with the right spacing. This all might be a bit tough though.
- Use diodes. It’s possible to craft a layout that is usable without diodes, but it can’t be optimal, it’s hard to do, it requires intentionality, and it makes the wiring more complex than just using diodes.
- Sure. Some people don’t like exposed electronics. Take the height of your switches and mounted keycaps as a guide and make something to go over the MCUs and ports. I’ve seen other fully wrapped around cases or simple panels on standoffs. Search online for something like
Corne keyboard concealed controllersWow sweet project! Best of luck to you!
I don’t have much advice to give, maybe you can look into the seeed new line of tiny USB-C MCUs, they look neat and easy to work with!
I was wondering about that 6-keys thumb cluster though. It looks unwieldy on such a tiny board. Got any prior experience with that ?
My current layout for an ANSI board moves the home row up and i type the bottom two rows (space & QWERTY ZXCV…) with my thumbs, so i don’t think it’ll be too bad. If i’m wrong i can move all those characters to other keys on the hyper layer.
I designed one a while back and used esp32 with custom firmware I wrote. Completely wireless and worked fine. A few years later I made a new board and used zmk with a couple of nrf52480 which works great! The esp32s were a bit heavy in the current draw and I wanted to try out low profile switches. All boards I made were fully split and had hot swap.
