atreus revisted: engineering compromises
2020/04/21
I've enjoyed using my Atreus keyboard, but have never been happy with the approach I took for bluetooth integration. The battery life was mediocre, the firmware had no awareness of the connection or power usage, and the hand-wired rats' nest was an atrocity. I wanted to come up with a better solution; specifically, USB C, Qi wireless charging, bluetooth low energy (BTLE), better battery life, and an actual PCB. Also, there are some higher level goals I consider for all my projects, like ease of assembly and part sourcing, using only open source software, and documentation.
As an aside, I also came up with a nice approach for painting engraved areas of lasercut material (perfect for the back plate of an Atreus).
compromises
For optimal power usage, I wanted a single chip doing everything. The best option for bluetooth and USB right now seems to be the Nordic nrf52840. Unfortunately, there are no nice off the shelf through-hole modules that would be suited for this project, and the available modules all have a number of pads underneath, rather than only using castellation. Another issue is Nordic's firmware licensing. Radio functionality depends on a blob, and the headers/libraries have a non-free license. I would be willing to accept writing my own firmware with a BSD license, but I strongly prefer running the de facto standard QMK firmware, which is GPL only.
The other option is the Adafruit Feather 32u4 Bluefruit LE; this module has both an Atmega32U4 (the most popular platform for QMK) and a BTLE module. It has standard through-hole headers, battery management circuitry, and a USB port, which saves a lot of work on parts, assembly, and PCB design.
I want to go on a short digression here: as an engineer, I think we should have some clarity of purpose in how we spend our (always finite) time. Is my goal to develop a complete PCB 'from scratch' without any modules, picking my own battery charging IC, specing out crystals, choosing connectors, routing everything nicely without RF issues, and then put a completely original firmware on top of that? Is my goal to as simply as possible get the keyboard working so I can use it? Is my goal to develop a project that other people can make their own copies of easily? Do I want to have to maintain the firmware? What do I want to learn from this?
I think if one wants to make open software or hardware, it must be as simple as possible for others to replicate. For software, dependencies should be as few as possible, and easy to install, and a build should be trivial to run. For hardware, parts must be easy to source or fabricate (ideally mechanized via 3D printing, laser cutting, etc.), and must be reasonable for a hobbyist to assemble (e.g. avoiding difficult BGA packages). My conclusion in this context was that I should minimize physical part count and choose the platform that will support QMK (i.e. the Feather mentioned above). Replicating existing functionality in a new firmware doesn't seem useful to anyone.
Ideally, QMK should work with only minimal configuration, and the power issue can be ameliorated by massively oversizing the battery.
reality
I threw together a pretty standard PCB, based on the normal Atreus. Unfortunately, despite using the same board outline as the standard Atreus, it didn't fit in the laser-cut case I used previously, so I had to grind it down a bit on the inside.
Qi charging was implemented with a $1 module meant for retrofitting into a phone, which simply outputs 5V and could be connected directly to VUSB on the Feather. After assembly, I found that I also needed a zener diode.
Due to the wide, flat shape of the Atreus, I could fit in a thin 2000mAh battery with no trouble. Even under peak power usage (approx. 10mA), I expected (and got) about a week between charges. I had the "clever" idea of directly connecting the battery and not using a power switch, instead running in low power modes as often as possible. Unfortunately, this messes up a number of assumptions, including, I think, various registers that are usually reset more often. I couldn't get QMK to work with a few days of work. I think there are some problems with its USB detection, and automatic switching between bluetooth and USB is unlikely to work on my setup. Also, I've found that QMK has no real conception of power management. Furthermore, QMK support for the Feather may have been broken for the past 6 months or so.
I needed to implement a firmware with basic matrix scanning, USB, and bluetooth to test my hardware, which was, ironically, the exact thing I decided to avoid doing.
more compromises
It's a frustrating situation. Spending time debugging the internals of QMK would be the pro-social move, but still won't provide the power functionality I'm looking for. Developing my own power-efficient firmware will give the performance I want, but also require reimplementing many features from QMK, while also being a maintenance burden I'm not looking for.
I understand that the two solutions to a late project are reducing scope or extending deadlines. Unfortunately, I can't afford to dedicate more time to this project right now. I don't want to do another iteration of the PCB in the immediate future, and on its current trajectory, this project is not going to be clean enough to release as an open hardware project. I plan to finish a basic firmware implementation and move on.