Model 2, Part 1 - Designing a Specialty Keyboard

Last Updated: 2022-07-11 01:30:00 -0500

If you’re a member of the #secret_projects_chan on the Arcana Labs Discord or have been following me on twitter for any real length of time, you probably know that I have been designing and building a mechanical keyboard; a project I’ve been working on for the better part of half a year. As is tradition for secret projects, now that it’s more or less complete, I’m documenting it retroactively in a small series of posts on the site. This post is about the process I went through in order to design the keyboard, both conceptually and in real, preparing-for-manufacture terms.

I want to be clear too - this project did not “go well”. It had a happy ending; this article is written on the Model 2 (admittedly in a state of partial completion), but it was also, for me, a deeply frustrating experience that is only just starting to taste sweet through its bitterness as I clobber out the final bugs.

Why make a keyboard?

Keyboards are effectively a commodity product. If you walk into your local electronics vendor you’re going to find as many as a half dozen, all more or less competing on brand and brand alone. Even if you’re a burgeoning keyboard snob like me, you’re going to be able to find high-quality switches in stock, easily available parts. This begs a really important question - why would you invest half a year and *mumble* dollars into building one entirely custom?

The answer comes to you in two parts, and both answers are going to have an impact on the final design:

Are you building this for vanity reasons? In my case, yes. This isn’t just a flex. I’m building up a brand/aesthetic around myself and I wanted to make something that was kind of fun to look at, as much as it would be to use.
Do you need a keyboard that can do something a commodity keyboard can’t? This proves to be a startlingly common and broad question. Most custom mechanicals I’ve seen incorporate at least one small feature that I haven’t seen in commodity - or even small-batch production - keyboards. Whether it’s a peculiar ergonomic split, an accessibility feature, or something simple like incorporating a few unusual inputs that would be extremely useful for that operator’s usual computer usage. I needed to touch on this as well in my design.

In short, the real answer for the question “why make a custom keyboard” is usually a variant of “Because I can, and in doing so I can make something more useful to me personally than the big box stores can sell me.”

Determining the Overall Design Constraints

Of course, if we approach any kind of creation task without some clear constraints, scope creep, featureitus, and Ooh Shiny are going to ensure that we either never finish or we wind up making something horribly ineffective. In my case, I had a pretty clear list of constraints, which can be generalized:

How much cash can we afford to throw into this new and exciting cash sinkhole? The answer to this, in the arclabs case, is always “as little as humanly possible”. I approached this project on the understanding I should expect to spend roughly $300-$400 CAD on the components and outsourced manufacturing. If you throw overboard overquantity ordering and missed components, I’m actually somewhat under that budget. If you include everything I’ve spent on it, though, your mileage will certainly vary.
Physical envelope constraints sound silly to consider for something as standard-sized as a keyboard, but they provide a sane upper bound for extra bells and whistles you want to include, stopping you from turning your custom keyboard project into a full size concert audio mixer that just happens to include a keyboard in it. In my case this was extremely relevant for other future projects down the road.
Desired Aesthetics will impact the materials you are able to use, including but not limited to the materials you’ll construct the case and other parts out of, or which keyswitches are available to use.
Minimum desired functionality, since the same rules govern the creation of a 10-key macro panel for extra livestreaming or editing controls as does a full-size keyboard. You need to go into this with a clear understanding of what you need to be able to get out of the keyboard, because that is how you know you’re “done” when it comes to building out the specification.

In my case, the physical envelope was actually both the driving consideration for the design as well as the main reason I was approaching my “personal” keyboard project as a design-from-scratch project rather than ordering parts or a kit and simply assembling a keyboard.

A Note On Kits

If you’re looking at the above listing of constraints and realizing you’d be perfectly happy with a more or less block standard keyboard (full size, 60%, or whatever), you can probably save yourself a lot of heartache by investigating keyboard kits. There are small-batch producers out there who have things made like PCBs for 60% keyboards, 3D printed case designs for the same size, and so on. If you’re able to start with something like that your design phase becomes simply chosing and assembling parts instead of a lot of the hearache we’re about to cover below.

Selecting Active Components

Even before I had really set out to make a fully custom keyboard, I had the intention to build my own mechanical keyboard. I’ve wanted a mechanical keyboard for years; and now that COVID-19 has made it more or less the industry norm for us tech weirdos to work from home, I had no real incentive not to build exactly the right kind for me.

A year or two ago I bought, through Amazon, a keyswitch sampler. Mine had 9 different kinds of Cherry MX keys, though personally unless you already have experience using different kinds of mechanical keyboards, if you can afford it, I would strongly recommend you get a sample set that had more vendors and varieties on it than just the nine. They come as acrylic panels with the switches laid out in an ortholinear grid and simple keycaps on them; the prospective user then plays with this like a goofy sort of fidget toy until they’ve got a clear favourite, or at least a clear tier list.

The other major choice I was able to make before I got started was the selection of QMK as a firmware base. QMK is an actively-maintained, GNU Licensed keyboard firmware that was designed to faciliate a high degree of customizability, and while I had a fair amount of work in getting it working - in part due to my own hubris - it made making a keyboard miles easier as I didn’t really have to write my own firmware.

Opportunity For Learning: I’ll go in more detail about this later, but if you decide to use a specific firmware for your project, you should first double check that the controller board you intent to use is available and supported. I ended up selecting the Teensy 4.0 which was in the realm of technically compatible. If someone didn’t have an unofficial fork of QMK where they were working on Teensy 4.1 support for their keyboard, I never would have figured out how to get it working on my 4.0.

Designing a Layout

Because I had a layout in mind, a set of physical constraints, and wasn’t doing anything especially odd with the layout, I had fantastic options available to me in terms of tooling. The community, in general, has created Keyboard Layout Editor which does exactly what it says on the tin.

It was pretty easy to use this to enforce both the physical envelope constraints and lay out all my keys, including the weirder keys like LMB and RMB. Where it actually got really handy, though, was on two important features:

The Raw Data tab, which lets you download and upload the keyboard in JSON format, which will come in handy later when we talk about programming, and;
The Summary tab, which among other functions spits out a full list of keys and key sizes used. This helps you in forming a Bill of Materials for the project and making sure you order enough keys and keycaps (as well as the right kinds of keycaps).

This seems like a pointless step to a degree because it doesn’t result in a programmed firmware, right? Wrong! Enter the Plate and Case Builder. Take the Raw Data from KLE, bring it to P&CB, enter some specifics, and you’ll spit out the needed images for manufacture.

Considerations for Case Manufacture

We learned a few lessons the hard way when it came to case manufacture.

A “Sandwich” Case design is trivially assemblable, but you have to understand how to build it, which comes in two major flavours of problem: thickness and material properties.

The P&CB tool does not give you material thicknesses, and in fact makes no considerations for the material properties at all. This is especially a problem when dealing with the Switch Layer. When I sent my switch layer off for manufacture, I had it made from 4.5 mm acrylic. This was entirely too thick for what I was doing in terms of switches, and as a result I have two real problems. My keyswitches are now loose in their places (meaning that, for good alignment, I will ultimately have to glue them down, which is a really bad idea), and my Cherry MX-style stabilizers do not fit in place on the plate and had to be heavily, heavily modified in order to support their keys and fit in the plate. I recommend instead making a metal copy of the switch layer and having that be quite thin, or perhaps using costar stabilizers.

The other major problems I ran into with the case itself, and we’ll talk about more during assembly, were not setting the “padding” values thick enough, not including a kerf adjustment, and not using enough mount holes. I’d recommend enough mount holes that you have one in each corner and one in the middle of each long edge.

If you’re going to follow me in making the machine out of acrylic, no dimension should be smaller than 4 mm in thickness. Anything else has just too damn much flex in it. On the other hand though, that could lead to a very thick keyboard. You’re going to want to spend some time thinking about your material choices and thicknesses accordingly.

Finally: laser cutting from reputable vendors is expensive, and that expense scales with the part area. Do not do what I did, and try to save money with the open and closed layers. In an effort to save on cost of manufacture, I edited those layers so that they had keyed corners and would have to be assembled. This did save a marginal amount of money, but more pressingly, it also ensured that no amount of fussing and fidgeting was ever going to get those corners square.

If you have access to a local makerspace with laser cutting proficiency or have been blessed with a cutter yourself, you can manufacture these SVGs much cheaper than having them made by a third-party vendor, and I wish I’d had that option available. Additionally, you can make these parts yourself entirely by hand, if you’re patient, though I wouldn’t really recommend doing that for the switch layer.

The next article in this series, which should come soon, will cover the process I followed for having parts manufactured, and assembling the keyboard. Some time after that, we’ll do agressively summarizzed lessons-learned as well as my thoughts on what I would change about the design if there was ever a reworking of it.

You can find my original design files, as well as my specific keyboard files for QMK, at this repo.

PETI is a major project intended to design and construct a virtual pet from Open Source Hardware and Software, and to encourage others to modify and tinker with similar projects. If you would like to support the development of this, or any of the other projects I’m working on for Arcana Labs, and you wanted to show your support financially, your best avenue is via my Github Sponsors account or by making a one-time donation to Arcana Labs via Ko-Fi.com or through other avenues detailed here. Github Sponsors also get access to a special patrons-only section of the Arcana Labs Discord Server, where we talk about the ongoing super-secret project.