Post #1862799

2026-04-26 10:07 UTC

So fun story, I’ve been running those as a daily driver for a couple of weeks, and they’re pretty sweet. The problem is that the trackball is on the peripheral side and it beams x/y diffs to the left (central) side via BLE. And because the central part also does HID events to the host over BLE it would oversaturate the RF and I’d get randomly sluggish cursor behaviour. Cont... #keyboard #diy #electronics

Replies (2)

@kaievans@mastodon.social 2026-04-26 10:11

So I struggled with that for a few weeks. In my previous iteration I ended up putting the central side on the right but that’s not great for battery usage. I was about to give up and do the same here, but then I had an ingenious idea. I packed the two 16bit x/y diffs into a 32bit value with a bit shift and then reported as a single custom off the HID range event. Then on the left side I picked that up, split it back in two with an input processor and then reported as normal HIDs to the host

Open ##2193259
@kaievans@mastodon.social 2026-04-26 10:14

As the result it halved the horizontal BLE traffic between the halves and it actually worked surprisingly well. Feels like a normal BLE trackball even with the dual hop I’m still not sure though whether it’s actually a BLE issue or ZMK internal processing that was chocking. But either way it worked. Yay!

Open ##2193260