I really liked the sculpted DCS family from Signature Plastics but couldn’t find too many resources on what you need to build a DCS keycap set for the Ergodox. Overall, spherical seems to be the preferred (and cheaper) choice for this. The biggest issue you will face is that there are no vertical 1.5 keys in the DCS family, and you need to reuse the 1.5 horizontal keys for your vertical ones. This is broadly what you need :
1.5xR1 x2
1.5xR2 x4
1.5xR3 x4
1.5xR4 x2
1xR1 x16
1xR2 x14
1xR3 x8
1xR3 x2 (homing bar)
1xR4 x20
1xR2 x4 (vertical)
My actual configuration is slightly different because I used keys from multiple rows to give a better feel on Row 1, you can see the full config with colours and applicable rows here. I used 2x R2 x1.5 and 2 x R3 x 1.5 for the 1.5 verticals, with coloured accents for the corner keys, all in PBT. The stock on the vertical keys varies, so you might have to make some substitutions.
This post covers compiling ergodox firmware from scratch, and loading it via teensy loader cli
Massdrop has a nice ErgoDox layout configurator you can use to make your own layout. However, their code base is outdated and is closed source, so there is no easy way to fix this.
You can directly use Benblazak’s github repo to compile your own ergodox firmware, but manually editing the layout directly in code is a bit cumbersome. There is an easy way however to use the layout generated by the configurator and compile it into Benblazaks’ repo.
First, clone the github repo
The default layout used is called qwerty-kinesis-mod, and can be found under ergodox-firmware/src/keyboard/ergodox/layout. Create a layout you like at the configurator and download the source instead of the compiled firmware by ticking the “Source Code” checkbox next to the Download link. Here’s mine for example. Extract the resultant zip file into a predetermined location, say massdrop_layout. Copy the required files as follows:
# ls
ergodox_firmware/ massdrop_layout/
# cd massdrop_layout/keyboard/ergodox/layout/# cp default--layout* ../../../../ergodox-firmware/src/keyboard/ergodox/layout/.
Next, install the make dependencies for the ergodox firmware. On ArchLinux, you need avr-binutils, avr-gcc & avr-libc. They might be named slightly differently depending on your distro.
Now we actually compile the firmware by overriding the default target of qwerty-kinesis-mod with our custom layout as follow:
# cd ergodox-firmware/src# make LAYOUT=default--layout# ls firmware*
firmware.eep firmware.elf* firmware.hex firmware.map
Next, we compile and fire up the cli teensy loader to actually load the firmware. You can use the GUI version as well, but it turned out to be a little flaky for me
And your Teensy should be up and running at the end of this.<p>
The -w parameter indicates that the loader should wait for the device to appear, -v indicates verbose output. The -mmcu parameter depends on the version of the Teensy you have. atmega32u4 indicates a Teensy 2.0 (The one included in the Massdrop kits), full list available here. Note: the teensy loader does not flash until you press the reset button on the Teensy (or press the reset key on the ergodox, if you have that as part of an already flashed layout)
This post builds on the ErgoDox Assembly Instructions provided by Massdrop. As such it references components that are part of the Massdrop kit. All images are copyright Massdrop
While Massdrop’s instruction page is pretty solid, there a couple of places where it’s lacking or confusing and makes it easy to slip up. I’ve listed them in the order that you would face them during construction. Before proceeding, I’d like to include some links that might be helpful in the construction process.
EEV blog has a great tutorial on soldering if you’re new or just rusty. Part 1 is an introduction to soldering equipment, Part 2 covers soldering and Part 3 covers surface mount soldering (required for the diodes, which is the first thing you solder).
There is a complete Ergodox assembly video by user WhiteFireDragon available here, however there are no instructions included and it is not real time.
The Teensy controller currently provided in the Massdrop kit is the Teensy 2.0 (atmega32u4), not the Teensy++ 2.0
Now for the actual keypoints :
You want to use a thinner solder for the surface mount diodes and the USB mini plug than you would for the other components. .032” is a good thin solder.
The diodes are directional, you want the cathode (marked with a line) facing the side with the square pad (the through-hole with the square frame), as show in the image here. The diodes are also the only components that go on the underside of the PCB.
The resistors are also directional, align them as shown in the image below using the coloured lines as reference.
Welp, resistors are not directional, but picking an alignment will make it easier for you to read the color codes.
The MCP23018 I/O expander (which is also directional) has three unused pins on the lower side. These are obvious as the holes on the PCB have no copper casing on them, don’t try and solder these as there is no base to heat up.
If you solder the capacitor on to clean the signal, make sure you short the pins next to it as show in the image below, the capacitor does not work without this. Note the bit of solder shorting the pins to the right of the capacitor.
You can use the extra bit of wire that you trim from the resistors and the capacitor to short the connections with the white outline which is required by the TRRS connectors.
Do not remove the black plastic spacer below the Teensy controller, it is required to provide clearance between the Teensy and the PCB. Note the black plastic spacer seen right below the Teensy in the image below.
After you connect the USB mini connector, make sure you solder it on both sides where applicable for stability.
You need to put Layer #3 onto the PCB before you start soldering the switches. The switches hold the plate in place and need to be put above the plate.
The LEDs are also directional. The long end is aligned to the square pads, same as the diodes.
Cherry MX switches can be separated into two pieces, however you will not be able to do this for the 3 switches that have LEDs on them unless you modify the switch tops, as detailed here
You need to trim the legs of the Teensy, the resistors, the capacitor and anything else that is sticking out before you can put on the bottom of the case (Layer #1).
Layer #5 (as provided by massdrop) actually has a hole you can use to access the teensy reset button, so you don’t need to take it off to reset the teensy.
If you use the Kernel coding style, one of the more taxing issues is staying within the 80 char limit. Instead of using something like checkpatch.pl to identify code failing this requirement after creating patches, you can use vim’s inbuilt long line highlight options to identify offending lines in code. The following snippet will highlight all any text that crosses virtual column 80
:match ErrorMsg '\%>80v.\+'
If you prefer something less in your face, the following snippet will only highlight characters at column 81
:2mat ErrorMsg '\%81v.'
You can also directly add these to your .vimrc file, removing the colon the at the start. More details can be found at the vim help page
If you get the following error while compiling a kernel (I seem to only hit it when compiling RHEL kernels)
crypto/signature/ksign-publickey.c:2:17: error: key.h: No such file or directory
crypto/signature/ksign-publickey.c: In function ‘ksign_init’:
crypto/signature/ksign-publickey.c:10: error: ‘ksign_def_public_key’ undeclared (first use in this function)
crypto/signature/ksign-publickey.c:10: error: (Each undeclared identifier is reported only once
crypto/signature/ksign-publickey.c:10: error: for each function it appears in.)
crypto/signature/ksign-publickey.c:11: error: ‘ksign_def_public_key_size’ undeclared (first use in this function)
make[2]: ***[crypto/signature/ksign-publickey.o] Error 1
make[1]: ***[crypto/signature] Error 2
make: ***[crypto] Error 2
You need to disable signature checking for modules on module load to get around this compilation problem. Just disable these two options in your kernel config
[*] Enable loadable module support --->
[] Module signature verification
-*- Cryptographic API --->
[] In-kernel signature checker
I really liked the sculpted DCS family from Signature Plastics but couldn’t find too many resources on what you need to build a DCS keycap set for the Ergodox. Overall, spherical seems to be the preferred (and cheaper) choice for this. The biggest issue you will face is that there are no vertical 1.5 keys in the DCS family, and you need to reuse the 1.5 horizontal keys for your vertical ones. This is broadly what you need :
