AI-generated summary of I built a wireless split keyboard, Rico Sta. Cruz. Not written or verified by the author.
Takeaways: I built a wireless split keyboard
2021-11-16, updated Nov 2023 · Source: https://ricostacruz.com/posts/i-built-a-microdox-keyboard · Rico Sta. Cruz
Gist
The author built a Microdox, a 36-key wireless split keyboard kit, as a portable twin of their wired Corne. Each half runs a nice!nano v2 controller on ZMK firmware with a 110mAh battery soldered to the PCB. Layers stand in for missing keys. Most of the post is about living with Bluetooth: pairing, battery life, sleep, and how each OS behaves.
All claims are the author's, from 2021 with Nov 2023 updates. Not checked here, and firmware details may have changed since. The post gives no parts list beyond kit, controller, and battery, and no prices, build time, size, or weight. Photos not read.
Takeaways
Hardware
| Part | Choice | Note |
|---|---|---|
| Kit | Microdox, Boardsource | 36 keys, split |
| Controller | nice!nano v2, one per half (nicekeyboards.com) | Bluetooth, USB charging |
| Battery | 301230, 110mAh per half | Author: smallest that works on nice!nano; others report up to 3,000mAh. Soldered direct, no power switch |
| Firmware | ZMK | Picked because "ZMK supports wireless keyboards, while QMK doesn't." Keymap hand-ported from QMK. Config: rstacruz/my-zmk-config |
| Reset button | Pressable with a pen | One press reboots, two enters the bootloader for flashing |
Layout
- Colemak mod-DH base layer.
- One key is Enter on tap, Ctrl on hold.
Navlayer for numbers and arrows,Symlayer for symbols.- Lock layer: every key
&none, two presses to exit. For a bag, cleaning, pets, fidgeting. Replaces a power switch.
Power
- Left half drains about 8% a day, 1 to 2 weeks per charge. Right half lasts far longer; the ZMK power profiler estimates about 2 months.
- Sleep after 45 min idle (
CONFIG_ZMK_SLEEP, undocumented then). Wake takes about 5 s and only the left half wakes it. Author turned it off: 5 s too slow. - Battery level shows over Bluetooth on Linux, ChromeOS, macOS Monterey. Not on Windows, macOS Big Sur, Android.
- No low-battery warning. The right half once died silently.
- Semi-wireless (75% of use): left half on USB, which also charges it; right half wireless.
Bluetooth
- Stays connected to every paired host at once.
&bt BT_SEL npicks the active one;&out OUT_USB/OUT_BLEsets priority. - Halves bond on first boot and stay bonded through reflashing. Unpairing them takes a special firmware image.
- Bluetooth behaviour varies by OS and device. Mac 5/5 (fails at the FileVault login), Android 4/5, Chromebook 3/5, 2017 Intel PC 1/5. A 2022 Dell later scored 5/5.
- Disconnecting from a phone's Bluetooth menu blocks auto-reconnect. A connected keyboard can hide the phone's on-screen keyboard; Android 14 added a toggle.
- Eager debouncing (press 1 ms, release 5 ms) cuts about 5 ms of latency per press.
Failures
- Both original nice!nanos died: one ran warm (likely a short), one wouldn't hold charge. Nov 2023 update: likely a bad USB cable that killed other devices too.
- Sometimes needs a hardware reset after sitting idle. Author unsure whether firmware or soldering.
Try this
For a handheld AI dictation device. The post covers keys, Bluetooth, and battery. It says nothing on audio capture.
- [ ] Price a nice!nano + ZMK build as the button-and-Bluetooth half: a push-to-talk key sends a hotkey to the host.
- [ ] Decide sleep vs. always-on early. A 5 s wake breaks push-to-talk.
- [ ] Size the battery with the ZMK power profiler before buying.
- [ ] Copy the lock layer for pocket carry.
- [ ] Plan a low-battery signal; ZMK gave the author none.
- [ ] Test each target phone and laptop early. Reconnect and on-screen-keyboard quirks differ by OS.
Patterns
- a software lock state replaces a hardware off switch ← "Replaces a power switch"
- one control does two jobs, split by press duration ← "Enter on tap, Ctrl on hold"
- a saving that adds startup delay gets switched off, losing the saving ← "Author turned it off: 5 s too slow"
- a failure with no warning strands the user mid-use ← "The right half once died silently"
- a shared dependency behaves differently per environment; test each target early ← "Bluetooth behaviour varies by OS and device"
- a hybrid of two modes beats either pure mode in daily use ← "Semi-wireless (75% of use)"
- blame lands on the visible part until a shared upstream cause surfaces ← "likely a bad USB cable"