ErgoBlue, a Split Wireless ErgoDox Mechanical Keyboard

Posted by Xudong Zheng on June 1, 2019

I have been using the ErgoDox keyboard for the past two years and was recently in search of a wireless edition. Given that one wasn't commercially available, I set out to build my own. This blog post describes the process and how you can do it too.

Table of Contents

• Build Album
• Part List
• Case
• Firmware
• PCB
• Assembly
• Accessories
• Typing Test Video

GitHub Repositories

• Firmware
• Case

About the Keyboard

• The two keyboard halves are both wireless. They both communicate with a central controller, which is a Raspberry Pi Zero W 1.1 in my case.
• The two halves are each powered by a 2000mAh battery. The microprocessor uses an average of 600uA, which puts the battery life somewhere around 4 months per charge¹.
• The Pi Zero is powered by my primary desktop via USB and it emulates a wired keyboard using the same USB cable.
• The controller interprets the messages from the two halves and maintain a consistent state for the keyboard. It generates the appropriate keystrokes for the connected devices.
• The controller supports additional devices via Bluetooth. Multiple devices can be connected at the same time (including one via USB) and the user can switch between them.
• The controller takes a bit over 20 seconds to boot before it can handle keystrokes. Many desktop motherboards power the USB ports before the computer is turned on so in practice it may take less time.
• The firmware for the keyboard halves is written in C/C++ and runs on top of Arduino. The controller software, including the keymap, is implemented in Go.

Frequently Asked Questions

Is it possible to make it wireless without needing a controller?

It is definitely possible. I personally didn't really care to do that since I mostly use the keyboard with my desktop. When on the road, a cheap 2600mAh power bank from Micro Center ($2.99 as of writing) should be enough for almost an entire day. If you turn the controller off when not in use, it will obviously last even longer.

In order for the two halves to maintain a consistent state such as the active layer and the active modifiers, you must have one "parent" half and one "child" half. The parent would need to receive data from the child, which is more energy intensive than more power than sending data to a central controller. This obviously results in a shorter battery life. It is possible to lower the power consumption by increasing the Bluetooth connection interval though that will increase the latency. One can theoretically double the battery life by having the two halves periodically swap roles. That introduces its own set of complexities that may or may not be worthwhile.

Why does this not use QMK?

I wanted several features that would have been difficult to implement on top of the QMK framework. In particular, I wanted it to support multiple devices simultaneously and be able to support slightly key mappings on each. Given my familiarity with Go, it made much more sense to use it and implement the firmware from scratch. On the keyboard halves themselves, matrix scanning and debouncing were also very straightforward to implement from scratch. It therefore made very little sense for me to consider QMK.

Is it possible to make the keyboard solar powered?

Even with solar panels, a battery will always be required since the amount of available light fluctuates and the microprocessor needs a consistent source of current. I experimented with a 30mm by 53mm solar panel from AliExpress that can supply up to 30mA. While the solar panel had no issue supplying 30mA in direct sunlight, it supplied very little current in a more common indoor environment. Though 30mA is more than enough to power the microprocessor, it is not enough to trigger the charging integrated circuit and have it charge the battery.

Footnotes