“Eating one’s own dogfood” is a well-known concept in computing projects, and a frequent stomping grounds for the lab (consider please, Tapestry). For a computer enthusiast who is also into working with electronics, designing and producing your own keyboard is definitely high up on the list of such projects. Nothing else you could reasonably expect to design yourself would see as much use in a computer room, after all.
All keyed positions are supported by Cherry MX Blue keyswitches for that “just exactly what I personally like” crisp click feeling. The keyboard itself is nearly a full “standard” keyboard layout, offering full compliment of function keys and numberpad for maximum utility in spite of its peculiarities.
The exterior-facing materials and overall design of the keyboard compliment its intended use as a potential keyboard for a cyberdeck built around other existing components in the lab, without sacrificing utility as a daily-use keyboard. The narrower-than-average design also allows for greater utility of the surrounding desk space when used with a desktop computer, and after less than a day the alternative key bindings mean no functionality is meaningfully lost.
Three rotary encoders on the right-hand side of the keyboard and a pair of additional keys offer the full functionality of a standard mouse, in terms of providing an alternative way to direct a screen pointer under a GUI regime - a highly desireable quality given its intended use as a cyberdeck device. With a bit of extra work on the firmware, these encoders could be toggleable into another set of purposes, such as adjusting between virtual desktops or changing the system master volume level.
Top-on photograph of the model 2.
Detail view of the numberpad area, showing the position for the missing rotary encoders. These would be mapped to mouse axes to allow the user to control the pointer without an additional device.
Detail image of the signal lines attached to the Teensy controller that operates the keyboard, showing why this approach is leading to so many problems with the wiring harness; they are constantly under strain from the weight of the keyboard itself, and no back panel can be installed, because the design failed to take these leads into account.
“Eating one’s own dogfood” is a well-known concept in computing projects, and a frequent stomping grounds for the lab (consider please, Tapestry). For a computer enthusiast who is also into working with electronics, designing and producing your own keyboard is definitely high up on the list of such projects. Nothing else you could reasonably expect to design yourself would see as much use in a computer room, after all.
The Arcana Labs Model 2 was my attempt at such a project, though I must admit that at the time of writing it was something of an incomplete success (there are, after all, no failures). It just needs some love to get it up to full scratch, but the idea was pretty simple: create a keyboard with full-size, full stroke keys, that would fit physically inside the container I intend to use for a future cyberdeck project, while also including some method of manipulating a pointer. I’m absolutely thrilled with the design I came up with, and while it had some growing pains in implementation, I’m hopeful that by 2024 I can bring it back into regular usage. For now, it has a comfortable and sheltered home in my lab waiting for me to finish figuring out all the corrective work needed to make it truly reliable.
This project and its output are provided free of upfront charge as part of the philosophy of FOSS and OSHW development practices. If you like this project and want to support its ongoing development, please check our support page.
Having finally decided to get off my backside over the last few weeks and make the templating changes that would let me make a proper project page for the Model II, I have decided that this is as good a time as any to go ahead and do a follow up blog post to the series from last summer on the Model II. It’s been over a year since I put that keyboard into use and I used it for most of that year, so let’s talk about what worked, didn’t, and what comes next for that project if I want to really get my money’s worth out of it.
The first two articles in this series talked about designing and building a mechanical keyboard - the Arcana Labs Model 2. This is a speciality keyboard that I custom designed to fit a very specific set of space and functionality constraints, and while a fair amount of work went into meeting those constraints broadly, there was a lot that did go wrong from a design perspective before laser ever met stock and solder ever met iron.
Earlier on, I discussed the process I went through trying to design the Arcana Labs Model 2, a specialty mechanical keyboard that had to fit a space constraint while also including some kind of pointing device. That post dealt largely with the process of design at a high level; how I came up with the necessary constraints, and what tools I used to facilitate things. This post is going to deal with assembly, as well as the process of getting the firmware working.
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.
