[Umang018]

This is really impressive, especially considering the complexity of designing a wireless split keyboard from scratch! Having built my own mechanical keyboard before (though not wireless), I know how much goes into PCB design, key switch selection, and firmware development.

One challenge I’ve seen with wireless keyboards (especially splits) is managing synchronization lag between halves. Some DIY split builds struggle with Bluetooth interference, while others use NRF-based communication. What approach did you take to keep latency low and ensure reliable keypress synchronization? Also, how does the power efficiency compare to something like a ZMK-powered split?

[varispeed]

Maybe stupid question, but can split keyboard work as two separate keyboards connecting independently to the operating system? That way you don't have to synchronise anything.

[zxter]

There’s no issue with a computer recognizing two keyboards, but smaller keyboards often lack all the keys found on a standard one. So, you’ll need to use modifiers to create the keystroke and then send it to the computer. If you press a modifier on one half, the other half needs to be aware of it to send the final keystroke. Creating a layout with these modifier-based key combinations is just a small part of the many tricks you can pull off with custom firmware. While the computer thinks it’s connected to a standard keyboard, you can do some really deep customization on the keyboard side.

[varispeed]

Wouldn't operating system take care of that?

[zxter]

When you have two halves of a keyboard recognized as separate keyboards by the computer, then just like you said. For example, if you press shift on the left half and u on the right, the computer first sees the shift and then the u. It then types a capital U.

But in my case, let's say I don't have any numbers on the keyboard. Instead, I use modifier keys to create a layer for numeric values. So, when I press a modifier on the left, the computer won't notice. Then, pressing what would normally be the U key on the right sends a 7 instead. The computer just sees a 7 being pressed.

[varispeed]

What I am trying to say is that operating system should collate events from all keyboards, so that wouldn't matter which one had modifier pressed on.

[zxter]

First, for an operating system to process input, it must continuously scan the keyboard matrix to detect keypresses. This adds extra load to both the OS and the CPU. Additionally, every OS must implement the same logic with the same parameters. Since there are many types of keyboards, each OS would need to know every keyboard's matrix layout.

However, before addressing that, like keyboards other HID peripherals are not directly part of the hardware. They connect to computers via USB or Bluetooth, and to do so, keyboards must have an internal chip, "a brain" even just for communication, let alone scanning keyboard matrix. This is similar to how a mouse processes sensor data internally rather than relying on the computer to interpret it. As a result, they can be used on almost any smart device with USB or Bluetooth.

Since we already have this extra chip, "brain", we can add personalized custom logic to simplify our lives and give our hands and wrists a break. This is similar to how gaming mice reduce DPI when the aim button is pressed or how old joysticks had an auto-fire button.

Shh! The computer doesn’t need to know ;)