Creating a Custom Split Keyboard PCB - Part 3
This is part 3 of 3 of my post on the process of creating my own split keyboard. See part 1 and part 2.
The PCBs arrived today, so that means it’s time to get everything put together. The mousebites worked well. They were easy to break in two, then I took off the remaining tabs with a pair of pliers. The edges are a little rough, but after going over them with an xacto knife for a bit, they’re smooth now, if not pretty. I could go over them with some sandpaper, but it’s really not something I’ll notice day to day.
Soldering & Assembly
The choice of going with the MiniMELF package was well worth it. This diode package is about twice as big, which really does make a huge difference when soldering by hand.
For soldering these, I’ve found the best way is to put some solder on only one of the pads, then slide the diode into place with tweezers while keeping the solder molten. I like to do this part first to all of the diodes, then I’ll go over all of them, realigning if necessary, to make sure they’re all in place and they look nice. After that, I lock them in place by soldering the other side.
My latest order of hot swap sockets were slightly different from my old ones, I was a little worried thinking I might have been bamboozled, but they ended up being a even more secure fit than the old ones. For the soldering process, same thing as the diodes, solder them all in on one side only, heat up the solder while making sure the socket is flush against the board, then go over them all to solder the remaining sides.
I took some time in between posts to remove and resolder the mill-max pins so the MCU will be facing downwards, so all I had to do here was solder in the mill-max sockets. For some reason, the solder here didn’t want to evenly melt. It was kind of chunky, almost. I think it’s because I wasn’t giving it enough heat.
Anyway, all that was left to do was solder in the RJ9s, and plug in the key switches. I’m quite happy with how the hardware turned out. I put some electrical tape over the MCUs, since it wouldn’t make much design sense to keep the PCB clean, but then have the giant Elite-C logo staring me in the face.
QMK Firmware
QMK is my firmware of choice. ZMK is also an option, but QMK has the advantage of being the firmware I used first.
Creating a new keyboard is straightforward. Simply type qmk new-keyboard
, and a wizard will guide you through the process. It also lets you pick a template to start from. I chose split_3x5_3
, unsurprisingly. Then you will pick your MCU. I’m using the Elite C, so I chose that. This gives you a skeleton from which you can build the rest of the keyboard. Full disclosure, I adapted a configuration that I previously created for a hand-wired Dactyl Manuform.
After this, there were a few configuration changes to be made in info.json. Mainly, I needed to set matrix_pins
appropriately. These need to be set to whichever pin on the MCU is connected to each row/column. For some reason, the split_3x5_3
template doesn’t include a setting for the communication pin, which is the data part of the wire connecting each side.
"split": {
"soft_serial_pin": "D2"
},
I ended up setting some of the options that I needed in the rules.mk file, which I believe is deprecated at this point. If I were to convert this to info.json, I think these could be set in the info.json file as follows:
"features": {
"bootmagic": true,
"command": false,
"console": false,
"extrakey": true, // enables media keys, etc
"mousekey": true, // lets you control the mouse with your keyboard
"nkro": true, // n-key rollover
"split-keyboard": true,
"lto": true, // reduces firmware size at the expense of longer compile time.
},
"tapping": {
// used for home row mods. allows a key to do one thing when tapped,
// and another when held. this is how we can get away with 36 total keys.
//
// term_per_key lets you configure different terms per key, which is
// essential for frustration-free homerow mods, imo.
"term_per_key": true,
},
"mouse_key": {
// mouse speed settings. these are all personal preference.
"delay": 10,
"interval": 16,
"time_to_max": 60,
"max_speed": 15,
"wheel_delay": 100,
}
There are some other settings which I couldn’t find appropriate documentation for, so I’ll just leave those in config.h:
#pragma once
// More mouse speed settings
#define MOUSEKEY_WHEEL_DELAY 100
#define MOUSEKEY_WHEEL_INTERVAL 50
#define MOUSEKEY_WHEEL_TIME_TO_MAX 100
// Handedness
//
// EE_HANDS means that in order to determine which side is which, a value
// will be set in the EEPROM denoting which side is left and which is right.
// There are other options for this, like simply using different firmware for
// either side, having a configuration pin, or having a different pin
// configuration. EE_HANDS makes the most sense to me.
#define EE_HANDS
After these are set, it comes time to set the actual keymap. This is a very personal preference thing, so it is up to you to configure how you wish. My configuration is heavily based on the Miryoku layout.
I finished this keyboard a few weeks ago, but I haven’t gotten around to finishing this post until now. I’ve been daily driving it for those few weeks, and after an initial adjustment period, it’s working fantastically. It’s everything I had hoped it would be.
I hope this inspires you to take the plunge and design your own keyboard, or jump into QMK if you’re still using a traditional keyboard. It’s a time sink, but your fingers and wrists will thank you once you get used to it. After all, why reach for different keys, when you can pull them closer to you?
Thanks for reading. I don’t know what my next project will be yet at this point, but I will document it and post it if it is sufficiently nerdy.