Robots y modelos

Notas sobre pruebas, modelado y aventuras en Java y Android

Building a custom GH60 keyboard

leave a comment »

diy-keyboard

I have always been a big fan of mechanical keyboards: the feel is completely different and much more satisfying than what you get from typical membrane keyboards. Since 2011, I’ve had at home a Filco Majestouch 2 that I bought at the Keyboard Company. Particularly, a tenkeyless (no numpad) tactile version with Cherry MX Brown switches. Still as good as new after all these years!

So far, I only had one for home, and at work I was using the (admittedly quite good) keyboard of my Thinkpad X1 laptop. While it’s decent, it wasn’t quite as nice as a mech keyboard. I could have bought a pre-made one, but that would have been no fun :-). Instead, I teamed up with Peter Lewis (a fellow Lecturer at Aston) to build our own.

Layouts and PCBs

Building your own keyboard is obviously more expensive than buying a pre-made one, and you do need to solder the switches yourself. For that reason, DIY keyboards tend to use smaller layouts to reduce the number of parts. The most popular layout is the 60% one, where you have the core QWERTY island and nothing else: no arrow keys, no Home island, no keypad and no Fn keys. To cover for the reduced set of keys, 60% keyboards operate in “layers”: a specific keystroke can make all other keys take a different role. For instance, one of my keys changes the right block of Control/Shift/Win/Menu keys into the arrow keys. There are other slightly different layouts, such as 65% (which keeps the arrow keys) and MINILA (which has a similar size but keeps the arrow keys by reducing the size of the right Shift) – it’s just harder to find parts for these.

For our build, Peter chose this PCB, which was sold as a KC60 SE but to the effects of firmware works like a bog standard GH60:

20171005_194652.jpg

It is actually a pretty nice PCB, with good quality pads and plating on the pins. It is rather flexible as well: you can choose whether to split your backspace, left shift, or right shift areas, and you could also have keys of various widths in the bottom row (you could go for a wider spacebar with narrower right alt, or different widths for the Control/Win/Alt keys as well.

Switches, so many switches

Having chosen the PCB, the next decision is what sort of switch we would solder on it. Choosing your switch is very complicated: there are entire wikis dedicated to the differences between various types of switches. However, for the most part the most common type of switch nowadays are the “Cherry MX compatible” ones. They are easy to deal with, reasonably inexpensive (unlike those expensive capacitive Topre switches), and most commercially available keycap sets are made for them.

Largely, there are three types of Cherry MX switches: the “clicky” ones (Blue, Green) make a distinct noise along with a slight tactile bump when they activate, the “tactile” ones (Brown) only have the bump and not the noise, and the “linear” ones do not have either (Red, Black). Typically, clicky ones are recommended for typing, linear ones are for gaming, and tactile ones are a hybrid that can cover both. My Filco had Brown switches, and while they were comfortable and silent (to me), the lack of a “click” meant that I tended to “bottom out” quite a bit (bash the key down all the way to the plate, making much more noise than needed). Peter’s Filco had Cherry MX Blues, and I liked the click quite a bit, so I decided to go for a “clicky” board this time.

There are choices to make even within Cherry MX-compatible clicky switches, however. In addition to the genuine Cherry MX switches, you can find compatible switches from other manufacturers such as Zealio or Gateron. Sometimes they are cheaper, sometimes they feel different. In addition, within the clicky family, you can find multiple versions with different activation heights, stiffness and springiness. For that reason, Peter ordered a nifty switch tester kit from Massdrop which included both Gateron and Cherry switches. We tried them a bit, and we found that the Gateron ones were slightly easier to activate while also springier than the Cherry ones. We decided to go with the Gateron clicky ones, with Gateron Blues for most keys, and Gateron Green (a slightly stiffer version) for the spacebar, as we would be pressing that one with our thumbs.

Keycaps – materials, profiles, printing styles/methods

Right, so we have the PCB and we have decided on the switches – now we need to choose the keycaps. Once more, these come in a huge variety, depending on the material (ABS plastic, PBT plastic, wooden/metal/ceramic/resin artisan ones), the profile (cyllindrical, spherical and variants thereof), the style of printing (top/front/blank), and the method used for the printing (dye sublimation, laser engraving, stamping, doubleshot).

Generally, artisan keycaps made in “exotic” (not plastic) materials are far too expensive to populate an entire keyboard with, so that was out of the picture. In general, I knew that ABS was stronger, while PBT tends to be cheaper as it is easier to work with. For the profile, my Filco had Cherry-style cyllindrical and contoured keycaps (keys are slightly different depending on the row) – I wanted to try a more retro style with spherical keycaps this time and see how they compared against my Cherry-profiled keys.. There’s an entire thread dedicated to discussing spherical keycap profiles here.

As for the style of printing, I always loved how the Filco “Ninja” sets looked. However, it can be quite hard to find keys in that style unless you have them custom made by sellers such as MAX. My original keycap set for my brown Filco was blank: while this makes you look like a Jedi with your crazy touch typing skills, it was a pain for entering some of my passwords with random symbols :-). I didn’t mind going for a regular top print this time, but after checking some of the (crazy expensive) Massdrop keycap sets, I decided I’d like to have letters printed on the center of the keys rather than on the top left as it seems to be the norm these days.

For the printing method, stamping is generally for very cheap keyboards only. Laser engraving is quite resilient while also being reasonably cheap, but not as flexible as dye sublimation (which I’ll be getting two spacebars on soon) or doubleshot (which looks really crisp, as it’s literally a second layer of differently colored plastic). I didn’t mind the exact printing method too much as long as it wasn’t stamping.

Peter and I checked quite a few different sets on Massdrop – my favourite so far was the GMK Laser, a cyberpunk-inspired one with doubleshot ABS keycaps. Another very nice looking keycap set was the Oblivion one. The main problem with obtaining keycap sets over Massdrop is that you have a very small window to do so, and the GMK Lasers weren’t even out yet. We had to buy an alternative keycap set to pass the time while our ideal set came up. We also had to keep an eye out for whether we wanted to have an ISO layout (with an L-shaped enter and one more key), an ANSI one (with a straight enter, and easier to find keycap sets for), or some sort of hybrid. Furthermore, very old (pre-ANSI/ISO standards) keyboards had an odd “bigass enter” key that combined both ANSI and ISO Enters – we might want to try that as well.

Peter wanted to go for a “navy” aesthetic, with a wooden case and yellow-on-blue colors, while I wanted to try something more “neon”-styled with white-on-blue. We finally settled on these DSA-profiled PBT laser engraved sets from KBDFans, which had enough keycaps to allow us to experiment with ISO, ANSI and hybrid layouts.

Stabilisers and case

We have the PCBs, we have the switches, and we have the keycaps. Almost there! But wait, we still have more choices.

First of all, we need to decide whether the switches are going straight to the PCB, or on top of a plate (here’s another thread on that). In short – using a plate gives you a sturdier keyboard but makes replacing switches harder (or impossible, depending on the plate). In my case, I was used to the sturdiness of my Filco and I wanted to keep it that way.

By the way, your switches will also slightly vary depending on whether you want a plate or not. PCB-mounted switches are “5 pin” (3 plastic pegs and 2 metal pins), while plate-mounted switches are “3 pin” (1 plastic peg and 2 metal pins). You can simply snip off the extra plastic pegs in a 5 pin to make it a 3 pin, if necessary.

Additionally, if you do go for a plate, you have to be careful to pick one that will allow for your desired layout. Thankfully, quite a few plates are “universal” and are flexible enough to accommodate both ISO and ANSI layouts. Peter and I went for this one from KBDFans. During our experimentation with various layouts, it looked like this:

plate

One negative thing about this plate is that it wouldn’t really allow us to use the LED pins in the GH60 board, but we weren’t big on LEDs anyway :-).

The next bit of shopping was the stabilisers. These are needed for the largest horizontal keys (the Enter, Shift and Space ones) and are a consistent source of headaches if you pick the wrong ones. As usual, there are many types. Apparently, people aren’t quite fond of Cherry-style stabilisers (which are reported to be “mushy”), but those were the type of stabilisers we needed for our keycaps. We didn’t see the point in paying the premium for the “genuine” Cherry ones, so we chose the generic Cherry-style ones instead. These are PCB mounted ones, so you must install them on the keyboard before you fit the plate with the switches.

I feel I was luckier with the stabilisers than Peter was: for some reason, his felt much mushier than mine. I hope he has fixed these issues by now: it might be that he didn’t insert the keycaps fully into the stems, and that a small air cushion might be left which makes them so mushy.

I only had to pick the case, and then I could go soldering this. For my neon aesthetic, I decided on an electric blue anodised aluminum case (again from KBDFans) with an additional weight. It was rather expensive, but it has a really nice heft to it (over 600g with the weight included) and the finish is excellent.

Assembly

This was largely as you’d expect, with some caveats:

  1.  We test fitted the switches and keycaps on the plate, trying various layouts. We found that the PCB would not be able to accommodate the bigass enter key, so we had to discard that option.

    I went for an HHKB-like layout, with Control in the place of the Caps Lock key and two keys where the backspace would typically be. However, I decided to split the left shift as well to gain an extra key (I’d decide what to do with it later).

    I was thinking of swapping the Tab and Backspace keys: as Tab moves the caret to the right, logically you’d think that it’d make sense for it to be on the right side of the keyboard. Some fumbling with muscle memory later, I decided not to do it.

    Likewise, I was tempted to put 0 to the left of the 1 in the top row, as it is done for some Hungarian layouts and as another “makes sense” idea. After some experimentation and reading this thread on Stack Overflow, I scrapped the idea as well. Interestingly, you want the 0 to be away from 1 so you may quickly type 10 and other similar numbers, by using your left hand for the first number and your right hand for the 0. If the 1 and the 0 were next to each other, you wouldn’t be able to type that so quickly.

  2. Once we were happy with the layout, we removed the keycaps, installed the stabilisers on the PCBs and put the plate with all the switches on top of it.The stabilisers required a bit of fumbling, but in general you are simply supposed to insert the side with the wire through the larger holes first, then snap the side with the smaller holes until it sits flush on the PCB. You do have to be careful that the wire snaps into the retention tabs on both sides, or you will have a very shaky key.
  3. Next, it was time for the soldering. We used my Aoyue 968A+ soldering station, keeping the tip at 350C and using the built-in fume extractor. As recommended by Dave in the EEVBlog, we used thin leaded solder (0.5mm diameter, I believe) for good control of the amount of solder, plus a chiselled tip for better heat transfer. Not much to say here: place the tip on both the pad and the pin, add solder so the pin will melt, and make sure you get a nice fillet on the joint!
  4. We did have to desolder and move around a few switches after we were done, as they had moved around a bit with all the fitting and trying out things. Luckily, we did have a solder pump and some solder wick around, and the plate didn’t give us any trouble in replacing those switches.

At this point, you’d think that we would simply screw the soldered board on the case and call it a day, but no: it turns out that our version of the GH60 has two rather silly DIP switches (probably to control the split backspace and something else) where you’d expect to have a reset button. The only way for us to reset the board to install our custom firmware with our desired layouts was to bridge two pads on the back of the keyboard!

Time to fix this, then.

Firmware: TMK or QMK? Which device?

Right, so we did have a working keyboard – we just had to tweak it so it’d fit our desired usage scenarios. One of the main advantages of these DIY keyboards is that they use a full-fledged microcontoller inside, so you can install your custom firmware to make the keyboard work exactly as you like.

GH60-based boards use Atmel microcontrollers, so at the very least you’ll need to have the TKG toolkit installed in your system. It will allow you to flash those .hex firmware files to your keyboard.

Your next step is to either use a web-based .hex generator, or compile it on your own. Some of the most popular websites are the TMK Keymap Generator, the TMK Firmware Builder, or the QMK Firmware Builder. I am not a big fan of using third-party generators: I’d rather compile the firmware on my own from properly version-controlled sources.

To do that, you’ll need to set up a GCC cross-compiler for Atmel chips and its C standard library. It sounds scary, but in Linux it’s just a matter of installing a few packages (gcc-avr and avr-libc). Then, you’ll clone the sources of the TMK or QMK firmwares. In general, TMK supports the most keyboards, while QMK has some nice extra features and better design for the keyboards it does support. Crucially, QMK allows you to reset the keyboard to its bootloader from a key combination, so unless I wanted to unscrew and screw again the PCB for every little change, I needed this one.

Before we could go into that, first we had to figure out exactly what was the right firmware for our PCB. The seller said it was a GH60 KC60 SE board – no idea if it’d work with GH60 firmware, KC60 firmware, or if it was entirely custom. We flashed quite a few different versions – using the TMK KC60 firmware would make one of the columns in the keyboard stop responding. The firmware for the Satan edition of the GH60 board would result in a completely unresponsive keyboard. Other firmware would not allow us to use the split backspace or split left shift.

After quite a bit of experimentation, we found that the QMK GH60 firmware was the way to go. Time to customize this – we only need to figure out exactly how to…

Tweaking the QMK GH60 keymap

I created my own fork of the QMK firmware, and set out to work on my keymap file.

The QMK firmware is structured quite well: if you simply want to create a keymap, you need to go into “keyboards/your_board/keymaps” and create your own directory in there with your “keymap.c” file inside. Normally it’s a good idea to start from an existing keymap, and I based mine on the default keymap. Once I am done with my next version, I can issue “make gh60-bluezio” and then flash the resulting “gh60-bluezio.hex” file into my keyboard with the TKG “reflash-dfu.sh” tool. Rinse and repeat until I get exactly the behaviour I want.

In the TMK/QMK firmwares, key presses are processed by a stack of “layers”. A key press is processed from the topmost layer: you look up its code into a table and do what it says, which may be a standard keycode (e.g. “A”), or an action (e.g. “reset to bootloader”, “invoke custom C function” or “activate layer X”). There are special keycodes for “do nothing” (key is disabled) or “transparent” (continue looking from the next layer in the stack). Generally you have a default layer that stays at the bottom of the stack, and then you add layers for navigational keys or alternative layouts (e.g. Dvorak or Colemak).

This is how it looks for mine at the moment:

const uint16_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = {
    /* 0: qwerty */
    KEYMAP(
        KC_ESC,KC_1,KC_2,KC_3,KC_4,KC_5,KC_6,KC_7,KC_8,KC_9,KC_0,KC_MINS,KC_EQL,KC_BSLS,\
        KC_TAB,KC_Q,KC_W,KC_E,KC_R,KC_T,KC_Y,KC_U,KC_I,KC_O,KC_P,KC_LBRC,KC_RBRC,KC_BSPC,\
        OSM(MOD_LCTL),KC_A,KC_S,KC_D,KC_F,KC_G,KC_H,KC_J,KC_K,KC_L,KC_SCLN,KC_QUOT,KC_NO,KC_ENT, \
        OSM(MOD_LSFT),F(1),KC_Z,KC_X,KC_C,KC_V,KC_B,KC_N,KC_M,KC_COMM,KC_DOT,KC_SLSH,KC_NO,OSM(MOD_RSFT), \
        F(0),KC_LGUI,KC_LALT,       KC_SPC,             KC_GRV,KC_RALT,KC_RGUI,KC_APP,OSM(MOD_RCTL)),
    /* 1: fn */
    KEYMAP(
        KC_ESC,KC_F1,KC_F2,KC_F3,KC_F4,KC_F5,KC_F6,KC_F7,KC_F8,KC_F9,KC_F10,KC_F11,KC_F12,KC_TRNS,\
        KC_TRNS,KC_TRNS,KC_UP,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,RESET,\
        KC_TRNS,KC_LEFT,KC_DOWN,KC_RGHT,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,\
        KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,\
        KC_TRNS,KC_TRNS,KC_TRNS,       KC_TRNS,            KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS),
    /* 2: arrows */
    KEYMAP(
        KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,\
        KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,\
        KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,\
        KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,KC_TRNS,KC_UP,\
        KC_TRNS,KC_TRNS,KC_TRNS,       KC_TRNS,            KC_TRNS,KC_TRNS,KC_LEFT,KC_DOWN,KC_RGHT),
};

As you can see, the first layer (which is the default one) defines most of the keys. It uses the KEYMAP C macro (defined in “gh60.h” a few directories above) which allows you to map all the possible keys in the keyboard. More importantly, it can handle both split left shift and backspace – the other KEYMAP_ISO, KEYMAP_ANSI and KEYMAP_HHKB macros are too limited in that regard. The only non-obvious detail is that the right part of the split backspace is defined not where you’d expect it to be, but instead next to the KC_SPC keycode in the bottom row.

In this layer, I have split the left shift so the right half will invoke “function 1” by using “F(1)”. We’ll see what that means later on. The key that used to be LCtrl is now “function 0” as well. As for the Shift and Control keys, you may notice the odd “OSM(MOD_LCTL)” style: these use a QMK feature called “One-Shot Modifiers“. Instead of having to hold Shift to enter a capital letter, I can just press it once and it will “stick” until the next key is pressed. Seems quite handy for my Emacs editing.

These “F(x)” keys work from a so-called function table. Here it is:

const uint16_t PROGMEM fn_actions[] = {
    [0] = ACTION_LAYER_MOMENTARY(1),  // to Fn overlay
    [1] = ACTION_LAYER_TOGGLE(2),     // toggle arrow overlay
};

It’s quite simple: function 0 will enable layer 1 while the key is pressed, while function 1 will toggle layer 2 every time it is pressed. That means I can enter F1 by holding my “Fn” function and pressing 1, and that I can toggle the right block of mod keys between regular Ctrl/AltGr/Win/Menu and arrow keys. More importantly, I can reset the keyboard into its bootloader by using Fn+Backspace.

Conclusions

Several months since we started, Peter and I finally have some really nice keyboards that are exactly to our liking :-). It hasn’t been cheap (I’d say this summed up to £150 in total for me) or easy, but it was indeed very fun!

At this moment I’m still 50% with my layout: I still need to decide if this is the best arrangement. I’m finding I still would like to have a Delete key and the Home/End/PgUp/PgDown keys, and I’m not sure if I might like the SpaceFn layout a bit better. Thankfully, this is all software now, which is a lot easier to change!

I hope this may be helpful to someone: I’d have appreciated something like this when I started. There is a lot of knowledge out there, but it tends to be rather fragmented.

Happy hacking, folks!

Anuncios

Written by bluezio

8 de octubre de 2017 a 14:24

Publicado en Uncategorized

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: