Mechanical Keyboard: derb-planck

derb-planck is a custom mechanical keyboard based on a planck keyboard whit an USB multiplexer. It can connect up to three host devices. In this post I will go over the idea and motivation, design/build phase and all the mistakes I did.

Idea

The work of an software developer can be differentiated in organisational work and development work. Since I’m an 100% Linux developer and never got accustomed to using virtual machines, I use two laptops: One with the default corporate software stack (MS Office, …) and one for software development. Carrying around two laptops for work has some issues. One of them is, what I call “keyboard confusion”: If one of the laptops is connected to an external display, than I often try to use the internal keyboard of the other laptop to type on the display.

This sparked the Question: Why is there no keyboard, witch can be connected to more than one device? I think, the reason is, that one still has to keep track, which keyboard port is active. Even worse, after getting a new cup of coffee you have to remember, which port was active when you left. In fact, I think such keyboard would introduce a higher potential for “keyboard confusion”. Nevertheless, the idea stuck in my head and I decided to build such a keyboard. This also gave me the chance to indulge another passion: Learning how to solder SMD parts.

The Keyboard

I try to avoid the usage of a pointing device as much as possible, but I find it almost impossible to navigate the web without using one. Therefore, it would also be nice to integrate some kind of pointing device. Unfortunately, while building the keyboard, I gave up on the this requirement. I will come back to it later.

This keyboard is based on the planck keyboard. It is a 40% keyboard (48 keys) and all keys are arranged as a matrix (orthographic), which is easier to design than other keyboard. To keep the hight low, Cherry MX LowProfile keys are used.

To switch between several host devices, it has a FSUSB36 IC on the USB connections between the MCU (ATmega32u4) and the host. Shortcuts are used to switch between the hosts (see video).

Another important requirement is, that the keyboard has to be light and small. Carrying around two laptops is already a drudgery and every additional weight is a burden. It weights about 210g and has a size of 229mm x 75mm x 18mm (WxHxD)

The PCB is designed with KiCad and the FreeCAD was used for the Case.

QMK is used as firmware.

Mistakes and Learnings

There are two mistakes in the schematic. I was expecting, that a USB-DFU-Bootloader is pre-installed on the ATmega32u4. Some of the variants have such bootloader pre-installed, but not those in the QFN packages. Therefore, the schematic doesn’t have a dedicated connector for the serial programming interface. I did similar mistakes in the past, which is annoying: RTFM! I ended up soldering cables to seemingly random pads to upload an DFU-Bootloader. Note: The DFU-Bootloader works only on the default USB port on the top of the keyboard, since this is the preselected port of the USB multiplexer.

In the past, I worked with ARM microcontroller. For each I/O pin, they can configure either a pull-up or a pull-down resistor. I assumed, that the ATmega32u4 is also able to do this, but it can only configure pull-up resistors. Therefore, the signal lines for detecting connected USB cables do not have a pull-down resistor which makes them unusable. That means, the keyboard cannot automatically activate the USB port which is used, if only one USB cable is connected. It is still possible to manually switch between the USB ports, but its inconvenient.

The most surprising learning I had, is how easy SMD soldering becomes with the right tool: a hot plate. Together with the tip from this YouTube video on how to remove excessive solder paste from below of an QFN packages, the soldering process becomes a pleasure. At least compared to the usage of a soldering iron for a TQFP package. I tried a reflow oven, but this was not satisfying. After soldering the MCU (ATmega32u4), it could be flashed and used immediately. Later, I had to resolder it once, since some of the pins were not connected. But it was possible with a hot plate! I never got a TQFP re-soldered with an soldering iron without destroying the MCU. Soldering the FSUSB63, a 1.8x1.8mm IC with 12 pins, was as success on the first try.

While soldering I discovered, that I bought diodes in the SOD-323 packages instead of the SOD-523 package, which I used for the PCB. I had to wait one more week before finishing the keyboard. This was really annoying and demotivating.

The keyboard has support for connecting a PS/2 mouse. This was intended for adding a track point. While trying this out, I mixed the GND with VCC and thereby I burned some diodes on the keyboard. Luckily, this did not destroy the MCU, but still I had to desolder the LEDs on the front of the PCB and rework the diodes on the backside. After going through this and already knowing, that I will create a second version of the keyboard, I decided to drop this feature for now.

The keycaps and the enclosure are also custom designs. The keycaps have a flat top with sharp edges. This is a bad design since it makes it easy to accidentally hit neighboring keys (see figure on the left). One can reduce the probability by chamfering the key top (see figure on the right). Alternatively, one can increase the distance between the keys by reducing the size of the keys. This has a similar effect and is used a lot on laptop keyboards.

Another issue with the keycaps is, that they are opaque. I used the key backlight of some keys to indicate, which USB port is currently in use. One can not see it at all, if not viewed from the side.

Furthermore, I only gave 0.2mm tolerance for the enclosure. Therefore, I had to squeeze the PCB into the enclosure and the whole keyboard is bend a little. But printing the enclosure took 4 hours and 45 minutes. I wasn’t that patient anymore. I wanted to type on the keyboard.

The same impatience almost destroyed my 3D printer. For the first time, I changed the filament type from PLA to PTEG. I also had to change from a plain sheet to a textured sheet and I forgot to recalibrate the first layer before starting the print. This would be OK, if I had monitored the printer while the first layer was in process, but no, I left the room. You can see the result in the image.

Leaning to type on the planck is arduous. At least for the first few days. After that, it becomes a lot better. There are some issues, which I wasn’t aware of before building the keyboard. While typing, I use right shift and left shift, but by default, the planck has only left shift. This is a fundamental issue. Luckily, Matt Gemmell had a good idea: By holding the Enter key, it becomes a right shift. This is incredible useful. I still struggle to remember positions of all the special characters which are important for programming.

I is another issue with the planck: Writing German text. German has some special character (äöüß) on the German keyboard layout. I don’t know how to access ‘ü’ or ‘ß’.

Summary

For a first hardware iteration, I’m satisfied with the result. I will design and build a second version keyboard to fix some issues: The keyboard is still missing a pointing devices and the keycaps need a redesign.

Another idea was to integrate an USB hub, so that a mouse could be attache to the keyboard, which than can be forwarded to the current activer USB port. Since I seperated the USB ports with diodes and therefore the board does not have 5V current, I dropped this idea. Using an zero voltage diode (ideal diode, perfect diode) it would be possible to add mouse port. With the LM66100 the added circuit complexity becomes reasonable.

After building the keyboard, I discovered deskhop. Integrating such a nice desktop change into the keyboard would also be a nice improvement.