Behind the Scenes of Issue 109

Dead week, giveaway feedback, vendor database updates, etc.

Hey y'all,

Welcome back for another edition of Keyboard Builders' Digest (this time Issue #109), a weekly roundup of this DIY keyboard focused newsletter and blog from Tamas Dovenyi – that's me. If you are new to this, you can read how this started out and what this is all about nowadays. If you like what you see, you can subscribe to the newsletter (free) and donate some bucks to keep this otherwise free and ad-free project alive.

---

Happy new year everyone! While it's already 2023, the posts and projects featured in Issue #109 were published last week so I consider this issue the last one of 2022.

I'm just back from my holiday so another quick editorial today.

Dead week

The few days between (and also before/after) Christmas and New Year's Eve, Dead Week as Helena Fitzgerald calls it, are probably the strangest part of the year. They have so much potential but are doomed to failure from the very beginning. Should you relax and be with your family? Or should you go on with your long-time project and post keyboards? :D Either way, this no-man's-land in the calendar seems like a wasted opportunity. At least for me. I hope you spent it well.

As usual, I spent the last days of the year in the mountains with family and friends, and while hiking, visiting ruins in the wilderness and playing board games, I tried to keep track of interesting keyboard projects.

Giveaway feedback

More feedback from giveaway winners:

Vendor database

Some more additions to the database of keyboard shops as a fallout of the recent r/mk week of giveaways:

• XVX Keyboard added.
• Locus (US) added (deskmats).
• From Scratch (US) added (cables).
• Clackeys (US) added.

Donors

• A generous extra year-end donation from top recurring donor Chad. Thanks!
• And a donation from Adam Batkin. Thank you!

And many thanks to all the donors who supported this project in 2022.

As I write it in my year-end summary, maintaining kbd.news takes a lot of energy and time. (According to the Reddit Recap stats that's 100 hours per month on Reddit only.) If you'd like and can afford to help, here is the donation form.

Small developments

• Tiny tweaks in the dark mode css – still some to go.

---

That's all for today. Thanks for reading.

Feel free to comment in this issue's r/mk thread, and as always: keep learning and building.

Cheers, Tamás

Why on earth should a keyboard do that?

Nick Brassel (@tzarc), one of QMK’s Directors, wasn’t satisfied with keyboards only having switches and an indicator LED or three.

Intro

In 2019, Nick Brassel (@tzarc) started a keyboard design in an attempt to convert something “simple” – in-game key repeat while held – from an AutoHotkey script into keyboard code. He found QMK, but for some silly reason decided to pick a fight with QMK-incompatible hardware… clearly the right choice.

QMK

If you've been living under a rock for some time, you may not know of an open-source project called QMK Firmware. Its aim is to allow people to write code for their keyboard – perhaps even one of their own design – allowing firmware-based features to be embedded into the keyboard itself.

There are also other satellite projects under the QMK umbrella, such as QMK Configurator, which allows end-users to configure their keyboard layout without needing a local development environment.

As it's an open-source project, QMK firmware inevitably stands on the shoulders of giants – the QMK community. It wouldn't be anywhere near where it is now without the tireless contribution of community members – the Discord server is where the bulk of the work gets done. I'd like to explicitly call out and thank the QMK collaborators team – the vast majority of the day-to-day grind is (usually) thanklessly handled by the donation of their time, so let's make it a little less thankless. :)

And a final shameless plug – QMK has an open collective for donations. Keeps the lights on!

Anyway, on to my personal journey of keyboard design…

Designing the Cyclone – a bit of history

As is the case with a lot of open-source projects, someone will usually get an itch and then decide, "hey, I can do something about that!"

In my case I had wrist pain – something a lot of us suffer from nowadays – so I'd originally wrote an AutoHotkey script that allowed me to hold down a key and get it to repeat. Normally this would be handled by the operating system, but for games… they usually only handle keydown and keyup. And I was playing a lot of games.

For most people, they'd write the script and they'd be done. For me… it wasn't enough.

The Cyclone was where my rabbit-hole started – I discovered custom keyboard design. Some people start out with handwiring, but I chose violence to design a keyboard PCB from scratch with an integrated USB hub. I was new to the scene and chose hardware first – something we need to do nowadays due to the component shortages – but at the time, it was a pretty stupid move.

Initial design complete, sent off to manufacturing… now, firmware.

Sigh… QMK does not support the microcontroller.

For ARM devices, QMK depends on a third-party library called ChibiOS to handle a lot of the low-level hardware. At the time, I was using a relatively new microcontroller – STM32L082KZ – which the older version of ChibiOS used by QMK did not support.

Hey, I can do something about that!

At the time, the ChibiOS upgrade had been attempted previously and failed. I eventually created a PR for ChibiOS 17->19 in December 2019, and it was merged in February 2020. Done, right?

Well no, we're never done, are we?

Using an Iris – a revelation

You'd note that the Cyclone was the left half of a "normal" layout keyboard. One of the other advent calendar writers, @bakingpy, produces a split keyboard called the Iris – and on a whim (well, after a suggestion from one of the QMK collaborators), I bought one.

Argh, how did I not know about split keyboards until now?

This was a revelation – I'd finally found something that helped with my wrist pain in general! After using it for a while, I realised I wanted certain keys to be physically present, and I missed some sort of visual feedback on the board itself – the display that the Cyclone had.

Hey, I can do something about that!

Argh, here we go again.

Designing the Djinn – fit for (my) use today?

Another itch – the Cyclone's OLED wasn't big enough. The microcontroller wasn't fast enough. I wanted safety mechanisms like current limiters. I wanted support for USBPD. I wanted encoders. I wanted audio. I wanted per-key RGB.

So I started a new design – the Djinn. You'd think I'd have learned from last time, but no – I'd chosen yet another microcontroller for which neither QMK nor ChibiOS had support. I'd chosen a display technology which QMK didn't support. Heck, at the time neither ARM split nor split RGB LEDs were supported by QMK.

Make no mistake, these choices were intentional. QMK needed to be closer to bleeding-edge, and this thing was going to be another vehicle to get there:

• A breadboard ratsnest evolved.
• ChibiOS gets upgraded again, this time from 19->20. Faster microcontroller supported, check.
• At the time, integrate in-flight PRs @zvecr created for ARM split. Working… check. Merged to QMK.
• At the time, integrate in-flight PRs @XScorpion2 created for split RGB. Uhoh, issues. Fixups sent, stability achieved. RGB all good… check. Merged to QMK.
• Now for the display… and the graphics library already present in QMK doesn't work with the hardware.

Hey, I can do something about that!

A new graphics subsystem is born within QMK – Quantum Painter – a set of generic drawing APIs which ended up taking 2 years to create and rewrite several times. The timespan was annoying but necessary when you've only got a limited time budget to spend.

The resulting code produced support for 7 different display panels, with more still inbound. It supports graphics primitives like lines, boxes, circles. It supports custom fonts, even unicode. It supports animations, and the QMK CLI can even convert animated gifs for playback.

So, two years after starting – June 2022 – I finally get the rest of the dependencies into QMK so that the Djinn can actually be PR'ed into QMK firmware. Done, right?

Well no, we're never done, are we?

Designing the Ghoul – a universal testbed?

As you can probably tell, there's a bit of a running theme going on – what new hardware capabilities would be cool for QMK firmware to pick up?

Rewinding back to October 2021, QMK firmware is starting to look like it'll finally get support for the Raspberry Pi Foundation's RP2040. @KarlK90 raises the PR and starts iterating. As a QMK collaborator, we try to have evaluation boards on-hand in order to verify functionality wherever possible – and I have a handful of Pi Pico's available for testing. Did I think that was that enough? Not even close.

SparkFun has the MicroMod ecosystem with a set of processor modules available. QMK already supported the STM32F405, and was soon to pick up support for the RP2040.

They also produce processor boards for Teensy 4, Nordic nRF52, and Atmel/Microchip SAMD51. Perfect – get things working with STM32F4, then do feature parity testing for RP2040. When we pick up support for the other microcontrollers, I'll have a testbed ready to go.

What else should I put on the Ghoul?

The number of available GPIOs on the MicroMod is actually quite low, if you look at the available GPIOs across the MicroMod processor boards. I guess I'll design a new low-pincount shift register based matrix.

We have basic ADC support within QMK firmware, what can I measure on the board to ensure ADCs work for each of the new microcontroller types? I guess I'll add USB voltage and current measurement.

EEPROM isn't really big enough for some of the future QMK firmware initiatives. I guess I'll add support for SPI NOR Flash.

Actually… I guess I'll add an SDcard socket too.

Separate bootloader reset switches are a pain in the backside to use, sometimes requiring opening up cases and the like. I guess I'll add the ability to reset the board using a 5-key hardware-based keyswitch combination.

Oh cool, a shiny new RGB OLED is available! Well, I guess I'll add support for that, too.

Turned out a treat, don't you think?

Future possibilities

Right now I'm sure you're thinking – @tzarc, what do you plan to do with all the currently-unsupported hardware on the Ghoul?

Well, QMK is headed to a much more dynamic future with QMK XAP in the pipeline – a new host<=>keyboard protocol which will allow for much greater customisability without recompiling and reflashing.

I've already gotten Lua running within QMK as a proof of concept, so ideas such as onboard scripting and display themes, uploaded through XAP and backed by Flash or SDcard isn't outside the realm of possiblity. Given a DAC, perhaps XAP audio uploads are feasible, too? Only needs someone in the community with an itch and the desire to scratch it!

Signing off

Obviously this has so far been purely through the lens of my own designs… but there are far more contributions to QMK by the community, both hardware- and firmware-wise.

As of the 23rd of December, QMK has support for 2,804 keyboards (!!!), up from 2,077 at the start of the year – an increase of 727 new keyboards, +35% in this year alone.

Also throughout this year, QMK has picked up firmware features such as:

• Autocorrection
• RP2040 support
• Caps word
• Encoder mapping
• Split pointing devices
• Board converters (from ProMicro into STM32 and RP2040 pin-compatible boards)

…to name a few, along with tons of cleanup and payback of technical debt.

Pure stats-wise, in 2022 QMK firmware has gone from 15,516 valuable commits up to 18,230 – an average of 7.6 PRs merged per day. A phenomenal effort from everyone involved.

Now, the more astute readers will have noticed that I'd never mentioned the key repeat code through my keyboard building journey. Did I ever actually rewrite it?

Well, yes… though it took me 18 months to stop messing with QMK internals for a while and do what I originally intended to do with my first custom keyboard.

But hey… going down the rabbit hole is the fun of it, right? It's what we do!

	Nick Brassel (38) tzarc
Location	Sydney, Australia
Description	QMK Director
Occupation	Professional draftsman of interconnected lines, boxes, and clouds
Niche	Coaxing unwilling hardware to work with QMK
Fav. switch	Box Navies, or 98g spring-swapped versions everything he gets his hands on
Fav. keycap profile	DSA, MT3
Other hobbies	You think there’s time for others?!?!
Links	https://github.com/tzarc, https://qmk.fm

Pangaea released

More than a year after the announcement, Pangaea 1.2 with its notoriously flexible layout has been released.

The Pangaea, a long-time project of @k2, @otahinosame and @e3w2q, is now released (version 1.2).

I'm pretty sure many of you will remember it from last December (KDB#55), but here is a short reminder:

Pangaea is a column staggered keyboard that allows you to adjust the layout for the pinky and thumb areas relatively freely.

Isolating the layout into several “islands”, it allows the user to move around each part: the main body, the thumb cluster, and the pinky section.

Development started in June 2021, and after a long testing phase, things are getting a bit eventful these days: version 1.2 files have been published, just like a whitepaper on the concept, along with an introductory article in the Japanese MK advent calendar. In addition, the detailed build guide has been updated as well, which is a valuable resource on its own.

Resources

• Github repo
• build guide
• whitepaper
• e3w2q's advent calendar write-up

Christmas ornament keypad

Hide-key's new design is a Christmas ornament shaped macropad with X switches.

Hide-key's (Hideki Nakamura) name may sound familiar from some cool but closed source low profile ortho projects with X switches,

This time he published a macropad in the shape of a Christmas ornament.

A keypad that imitates Christmas ornaments. But, in terms of keymap, it's not a keyboard anymore💦 However, since it supports Remap, the keymap can be changed freely. Switches and keycaps use X Switch, and MCU uses XIAO RP2040. MERRY CHRISTMAS🎄✨ – hide-key.

Resources

• Gerbers and build guide

Sunflower macropad

Hide-key's another macropad design: Sunflower #001.

Looking for the files of Hide-key's Christmas ornament macropad, I saw two other projects in his Github repo: one of them being the Sunflower macropad published last month.

It's a seven key macropad inspired by the Banana (normal & split) and Corn keyboards, featuring a XIAO RP2040 controller. This time the switches are vanilla Kailh Chocs. The middle part conceals a low-profile EC12E2440301 rotary encoder.

Resources

• Build guide and Gerbers

Fusion with supercap

Fusion by steven4012 updated with a supercap and solar charging.

Crides aka steven4012 published an update to his folding travel keyboard: the fusion.

Basically did a bit of bodging to replace the original battery and charging circuit with a Li-ion supercap and solar charging – Steven.

Some comments question the safety of this approach. Be careful when working with a supercap.

The Fusion was featured in Issue#72 of kbd.news. It's a compact, steno-capable board for on the go. Magnets keep it closed, and Hall effect sensors take care of shutting off the power when closed. Read the original post here.

Resources

• https://github.com/crides/fusion

Boston case

Technofrikus shared a case design for Pylon's Boston, a compact 120%.

Fellow redditor Technofrikus aka Georg designed a 3D printable case for Pylon's Boston, based on the original metal case. (You'll need a printer that can print a 405 mm object.)

I made a printable version of the Metal Case of the Boston. Thanks a lot Pylon for opensourcing everything! – Technofrikus.

The Boston is an open-source "compact 120%" keyboard designed by Pylon. There was a GB of a case specifically designed for 3D printing, but '''Technofrikus didn't like the compromise of a split case. So he took the metal version and optimized it for printing:

• Removed a lot of material on the inside to save on print time and cost.
• Added a map of Boston to the underside (optional).
• Removed the 3 LEDs for a cleaner look (optional).
• Removed the big light guide next to the encoder and replaced it with a 1 mm hole for plastic light fiber.
• Added a version with 4 degree typing angle instead of the 6.5 of the original.

Since Georg shared his files with the specs/features of the original version as well, that's eight case variations if I'm right: 4 or 6.5 degree bottom, map or no map, and top with or without LEDs.

Resources

• Details and files available here: https://github.com/Technofrikus/Boston-Case
• Pylon's Boston repo

0xCB Helios

The 0xCB Helios is an Elite-C compatible development board sporting an RP2040 chip.

After the 0xCB Pluto sporting an Atmega32u4, Jakob and Conor announced the 0xCB Helios with an RP2040 chip. Pro Micro/Elite-C compatible, open source, and available at keeb.supply as well.

The Pluto is based on the AtMega, Helios is based on RP2040. With this new IC the controller gets cheaper, but is way more powerful feature and space wise. You can do a lot more stuff with displays for example – 0xCB-dev.

Specs

• Pro Micro/Elite-C compatible footprint
• 26 GPIO pins
• 16MB (128Mbit) of flash
• Dual ARM Cortex-M0 @133MHz
• 264kB SRAM
• default off red power LED
• blue user LED
• a level-shifter to drive 5V components
• onboard ESD protection chip
• VBUS detection support for split keyboards
• D+ and D- pads
• "unbrickable" bootloader: its located in ROM on the rp2040 itself
• single button reset circuit (reset the board with a short press and enter the bootloader with a long (>500ms) hold).
• price: €17 (with headers for all three sides)

The one button reset circuit is based on the one used on the Sea-picro by Josh Johnson.

No silk art this time, the 0xCB team opted for a stealth design to go as sleek as possible so that the controller blends in with most keyboards.

Resources

• 0xCB Helios product page
• Github repo

Keyboard as Python code

A keyboard designed entirely in Python – by hsgwchan.

There are a lot of DIY keyboards running Python code (CircuitPython, KMK), but this one by Takuya Urakawa aka hsgwchan is different: the whole design process was done in Python.

I designed the entire keyboard, including the PCB, case, and firmware, using only Python. No need to use Kicad and Fusion360 – hsgw.

Featured in the Japanese MK Calendar, the author used various Python libraries during the project to replace steps of the usual workflow: skidl was used to describe the relation of electronic components, pcbflow to design the PCB, and CadQuery to build the parametric 3D model of the case.

And of course CircuitPython/KMK was used as firmware.

Resources

• hackaday project: https://hackaday.io/project/188907-keyboard-as-a-python-code
• githu repo: https://github.com/hsgw/keyboard-made-by-python
• article

Berthold Diatronic

This cool Berthold fototype diatronic typesetting machine was spotted by OnlineLion.

This 200 kg piece of vintage hardware with the intriguing keycap profile was spotted by OnlineLion in a museum. As cerement points out, it's a Berthold Fototype Diatronic phototypesetting machine.

We hadn't had that much time left until the museum had to close. But it was in an area that was about printing – OnlineLion.

Here is the Berthold Fototype brochure (in German) on Archive.

And on page 3 the Diatronic in all its splendor:

The "Fotosatz" part seen in many photos is misleading: it isn't a nameplate but an 8-character display showing the last characters you typed.

This is explained in the brochure, and Marcin Wichary has a tweet about it in his awesome thread on tiny (and expensive) screens from the 70s/80s as well:

A Berthold typesetting machine came with a beautiful and unique keyboard – and in the periphery, a “screen” that felt more like a calculator display, with room for only eight last characters you typed. pic.twitter.com/hLy1ZSCxOz

— Marcin Wichary (@mwichary) September 17, 2019

Rotary keyboard

Squidgeefish hacked a rotary dial into a mechanical keyboard, replacing the numpad.

Chad pointed me to this project committed by Squidgeefish earlier this year – a project which was meant to be an April Fool's prank: a mechanical keyboard with a rotary dial instead of a numpad.

I have a coworker who is fond of reminiscing about the good ol’ days, when his grandparents had a rotary dial phone on the wall that they were renting from the phone company. Combine this with his devotion to the tenkey pad on a full-size keyboard and the fact that I happened to have an old rotary dial in my bin of spare parts, and the path forward for this year’s April Fool’s prank was self-evident – Squidgeefish.

The keyboard features a custom 10u keycap spanning across the whole number row and made via the OpenSCAD parametric keycap generator by rsheldiii. Hiding/eliminating all the number keys, its legend states:

the rotary dial is mightier than the number keys

In fact, pressing the 10u key types out exactly this phrase instead of numbers, leaving you with the rotary dial to enter numeric values.

Read the full build log here.

OGRE cyberdeck

OGRE is a doomsday or simply field cyberdeck, a knock-off of Jay Doscher's Recover Kit. Shared by rmw156.

The OGRE (Off-Grid Research Engine) by rmw156 is a knockoff of Jay Doschers Recover Kit.

Published in 2019, the original Recovery Kit is a sturdy cyberdeck with lots of features and the ability to run various useful tasks without Internet connectivity.

This was my first go at a cyber deck. I knew nothing about Linux, wiring switches, calculating amps or what a zim file was. But I got a 3D printer and I get seasonal depression so I wanted a challenge – rmw156.

Keyboard wise it features a 12x4 Plaid ortho, but what's more interesting: It has GPS maps loaded for off grid use (foxtrotgps), kiwix with multiple wikis, and all of the Survivor Library’s PDFs.

This would be a benefit to any doomsday prepper if kept in a Faraday cage (EMP protection from a solar flare or high altitude nuclear attack) but in a normal world it would still be useful for camping. You can use it to identify plants, berries, birds and other animals. It allows you to map waypoints on a map via GPS if you have no cell signal. Teaches you what knots you could use for different applications and a plethora of other helpful tools.

The Ethernet ports, more for the doomsday scenario, would allow people to treat OGRE as a server and connect to its network via networking switch. They could access files and useful PDFs that could be share to separate devices.

There are many charging options. 5v barrel jack, USB in so it can be powered by an external battery bank or wall wart, and it also has an internal battery bank.

The switches are a power saving mechanism. The far left is an On-Off-On switch so in the up position it pulls power from the internal battery but in the down position it pulls from the external power sources. The individual switches are just On-Off switches for the Raspberry Pi, Touch screen and Network switch. So lets say I want to power on the raspberry pi and SSH into it but I don't want to use power on the display or the switch, I could just keep those off, or maybe I want to turn on the pi and the network switch but I don't need the screen on. These physical switches give me power saving options while on battery – rmw156.

Resources

• Full part list in Jay's blog post.
• 3D files on Thingiverse.
• More photos in rmw156's reddit post.