r/olkb

*Chosfox sent this to me for free to check out and give feedback on*

The Geonix Rev 2.5 is heeeeerrrreeee!!

When I say I've been excited about this board since Evan told me he was working on it, "excited" is an understatement. I already loved the Rev 2 and use it quite often, but the 2.5 vaults it to a whole other level. As an ortholinear user, I'm all for anything to constantly make them more accessible and palatable for anyone.

Just to hit some highlights and not go into too much depth, they added a 2u stabilizer for the spacebar, the keycaps are more stable while typing on top of my favorite Kailh low profile switches as the previous revision had some stability issues. The case design has improved and the weight actually went up around 40 grams (rev 2 is 340 grams, rev 2.5 is 388 grams), but still lightweight enough for a backpack or bag to carry with you. PLUS IT'S WIRELESS.

They kept that awesome as heck RGB too and made it pop even more with the PC sides.

Well done, ChosFox, I'm super happy with the improvements.

*Just a reminder, Chosfox sent this to me for free, my opinions are my own and I don't receive any compensation for this.*

Howdy! First Totem build here, and I've hit a wall with the right-half RP2040 that I can't troubleshoot my way out of. Hoping someone's seen this.

Setup

• Totem split, XIAO RP2040 on each half, wired (TRS between halves)
• Firmware: Pre-Compiled VIAL
• XIAO mounted pad-to-pad, castellated vias filled
• Left/master half works perfectly. Issue is isolated to the right half

The problem The right XIAO won't enter bootloader anymore. Holding B + tapping R, shorting RST, nothing gets RPI-RP2 to mount, and the computer doesn't recognize the board at all. I flashed this exact chip fine before soldering it on, so something broke or shorted during/after mounting.

It briefly connected once out of nowhere on a reset, but now it won't, and it doesn't register keys over the TRS cable so the firmware may also be in a bad state (or it never got a clean flash in the first place).

What I've checked (multimeter + testing)

1. No pads shorted to each other. RST not shorted to GND and it reads ~3.3V while powered, so it's not being held in reset.
2. Flux cleaned with IPA (twice).
3. All joints look well soldered. no visible cold joints or bridges.
4. Not battery powered. No heat, no buzzing, no sign of a short.
5. Cable is good as the same cable enumerates the working left half fine.
6. Red power LED stays solid, so power is reaching the board. It's the data/connection side that's failing.
7. Wiggling the USB-C cable may be changing the behavior as certain angles seem briefly connect or hold longer which makes me suspect the connector but there is no angle that "solves" it.

LED behavior (video attached)

• Originally: USER LED flashed white to green sporadically, seemed to track USB-C wiggle.
• After a second IPA + toothbrush clean: now it's a sporadic white to off flash (video). Current state.

My guesses (newbie, grain of salt)

1. The USB-C data pins are cracked/damaged. not sure how to verify this directly.
2. The USB-C anchor tabs may be cracked, letting the connector wobble. no visible proof.
3. RST is shorted in some way I can't catch with the meter, causing constant resets.
4. The chip is just broken from some unforeseen issue.

Constraints / what I'm hoping for

• No hot air station, so I can't easily reflow/replace the connector or remove the chip.
• This is the right/slave half, so it only needs USB for flashing. it should run off the TRS cable in normal use. So if I can land even one successful flash, it should work.
• I looked at SWD, but the debug pads are on the underside facing the PCB (how it's mounted), so they're buried/inaccessible without desoldering.
• Worst case I cut it off with flush cutters, wick the pads, and start over but that's a 2-3 week wait for a new chip, which I'd love to avoid if this is fixable.

Any way to verify the data pins, or revive the connection without hot air? Thanks!

i have no problem spending an entire night chasing one stupid rattle in the spacebar.

but cleaning the board? suddenly i’m unavailable.

it’s not even gross-gross. just desk dust, a cat hair here and there, random tiny fibers, whatever crumbs appeared from food i swear i did not eat near the keyboard. enough to notice under a desk lamp, not enough to make me want to pull every keycap again.

i’ve been keeping a vacuum on the desk for quick lazy passes. mostly dust and cat hair, nothing serious. it buys me time before the inevitable full teardown, but obviously it doesn’t replace actually pulling caps and cleaning the board properly.

curious what people here actually do between deep cleans. little brush? air duster? desk vac? or do you all just pretend not to see it until the board looks cursed?

Spec details etc here: https://chosfox.com/pages/rev2-5

Looks like extra discounts on the pre-order. Not sure about the pricing details though.

I’m using the XYZ Workboard r2 as my daily driver these days, and have been experimenting with 5-sided dyesub keycap manufacturers.

Magikarp is my favourite Pokemon, so naturally I said fk it and got it made into a keyset as a process test, but it actually turned out way better than I was expecting.

This is isn’t an official collab with Pokemon, and the keyset is not for sale, but maybe one day we’ll get a collab with them!

Which Pokemon would you have done?

It seems the previous post violated the rules of r/ErgoMechKeyboards, so I am republishing the article here.

Outsider is an ortholinear keyboard developed with the Planck as its core. My initial purpose was to "research ZMK". Although it was developed based on wireless keyboard standards, it does not mean it cannot support QMK.

Current status of the Outsider PCB:

• Soldering only.
• ProMicro footprint MCU driven.
• Multi-layout, break-off sections supported.
• QMK (Wired version):
  • Supports EC-11, TPS43, TM040040 (choose one of three).
  • Supports VIAL.
• ZMK (Wireless version):
  • Only supports EC-11.
  • Supports GitHub Actions.
  • Supports ZMK Studio.

Project Link:https://github.com/DreaM117er/Vanguard-Keyboard-Outsider

Regarding the GitHub Actions and ZMK Studio parts, I developed them along the way while researching ZMK. I have also written this process into a tutorial article under the project for everyone's reference. There are both English and Chinese versions:

https://github.com/DreaM117er/Vanguard-Keyboard-Outsider/blob/main/about-zmk-eng.md

If you are interested, feel free to dive in for some self-learning.

Thanks.

Hi everyone, DreaM117er here again.

This time I'm releasing a keyboard I built specifically for ZMK. It's called the Outsider, a modular ortholinear keyboard continuing the Explorer Keyboard Blank module architecture.

I really love ortholinear keyboards like the Planck. Aside from being an absolute favorite for OCD, it has a lot of extensible design points, especially for split keyboards. But I'm not discussing splits here—what can it support?

• QMK, VIAL
  • Supports TPS43, TM040040 trackpads.
  • Supports EC-11, EC-12 encoders.
• ZMK
  • Only supports EC-11, EC-12 encoders.
• Multi-layout, break-off sections, flippable soldering, multi-switch support.
  • Soldering only.

After final testing, I found it was an MCU core design issue that prevented ZMK from supporting the trackpad, which is a deep regret. But that's not the main point. As mentioned, I developed this board for ZMK, so I wrote an about-zmk-XXX tutorial under the project. All texts have both English and Chinese versions for everyone to read. The outline is below:

1. Differences between QMK and ZMK
2. ZMK Cloud and Local Architecture
   • zmk-main
   • zmk-config
3. Building the ZMK Local Compilation Environment
   • Installing dependencies & error handling
   • west.yml setup
   • .gitignore
   • Zephyr engine
   • How to compile firmware locally
4. zmk-config Directory Architecture
   • Adding a new keyboard
   • Operating core & function setup
   • PCB schematics & actual matrix diagrams
   • Adding an encoder
5. Introduction to Pointing Devices
   • How to read the specification sheet?
   • Mounting third-party databases
6. How to setup GitHub Actions
7. Physical Debugging Rules
8. Pointing Devices (Under construction)
9. Starting ZMK Studio (Beta)
   • Prerequisites
   • Coordinate system principles
   • How to write the coordinate system

If you are interested in this part, I have open-sourced everything. I'll find some time later to put the firmware in the Release section, or you can directly check the source code in my Repo/vial and Repo/DreaM117er-zmk-config.

Project Link: https://github.com/DreaM117er/Vanguard-Keyboard-Outsider
About-ZMK-ENG: https://github.com/DreaM117er/Vanguard-Keyboard-Outsider/blob/main/about-zmk-eng.md

Thanks everyone.

Ortho 40% spotted in OGDB E05: Beware of Robot. Bulma is definitely vibing but I think Krillin is a normie.

So far there was no structured overview of keyboard input mechanisms. In my opinion understanding some basic concepts and outlining them in an overview can be highly valuable for anyone trying to find or create his personal "best" keyboard solution:

https://rpnfan.github.io/keyboard-heaven/deep-dive/keyboard-input-methods/

The core idea is a distinction between three categories of input mechanism that I think is often overlooked, or at least rarely made explicit:

• Free-timed — the timing window is controlled by your own physical action; output is always predictable
• Threshold-timed — the firmware or OS has a fixed invisible deadline; misfires are possible; you need to match your typing speed to the time-window or vice versa
• Context-aware / adaptive — the system watches your typing and modifies behavior automatically

Knowing which category a mechanism falls into immediately tells you what its tradeoffs are: reliability, latency, cognitive load, and learnability all follow directly from the category.

More explanatory text is coming, but the tables are already useful if you are trying to decide which approach fits your setup. They cover QMK, ZMK, Kanata, Karabiner-Elements, and all three major operating systems natively.

Feedback and corrections very welcome.

Hey guys! I'm really proud to share the first version of my keyboard. The point of the keyboard is to break out the IO of the ATmega32u4 so that it can be used when developing other projects, while also having it be a keyboard! It is split of course with an MCP23017 on the right side. No problems so far and I'm very happy with it. The next version will definitely look a bit different. Need to get new parts since those USB connectors ruined my life fr.

The inspiration for it (other than the fact that I wanted a cheap split keyboard with QWERTY), was that during project development you may need a GPIO to go high or low to test another IC or a dev board. Well with this keyboard you can do that. The software for it needs some tweaks still but it's at a very good stage currently.

I hope you also like the DIY aesthetic on the keycaps. That is also intentional since I don't want to have to buy expensive keycap sets for it. The plan is to just write over them like that which I really like.

Any feedback or questions are very welcome!