r/HandwiredKeyboards

This is actually 3rd design like this of mine. Main body contains slots for wires, diodes, switches, encoder and rp2040-zero. This is first half as im printing second in next days. Keycaps are also 3d printed. Switches are repurpoused switches used in elektron samplers (i have a lot of them with faulty led), they are also used in SteelSeries Apex M800 keyboard. Stay tuned for second half and feel free to ask any questuons.

SPK - Single Print Keyboard

Two sets that were wedding gifts for my friends!

3D printed body contains slots for wires, diodes, switches with hot swap sockets, rp2040-zero.

I dont even remember what switches did I use. Keycaps from aliexpress. As turned out slot for isolated cables were too tight and even with doublesided tape they started to pop out over time.

Guess which one is for whom?

I finally make a minimally acceptable working trackball, thanks to Scatterthought for the semistatic bearing. As it turns out, a single mouse button (hello Magic Mouse) is quite sufficient, given the presence of layers. The ball basically provides pointer and scroll functions.

Firmware and case on github.

So few months ago I made a 60ish% split row staggered keyboard. I wanted to drop the size to actually be the size of an A6 notebook/paper. I finally got back to this keyboard last week after a busy season. Here's the finished keyboard!! I'm really happy with it and it feels so clean. Only thing I'd honestly want to improve would be the wiring and better switches (good low profile switches are quite expensive where I'm from)

Updates:

- swapped from regular RP2040 to RP2040 Zero

- Changed position of the microcontroller to be in the inner part instead of outer portion of the keyboard

... and that's pretty much all I changed. I simply reused the wiring and components from my first version. It's a very simple keyboard but I love it for how compact and clean it is :)

Here's a gdrive link to all the files and a bit of a documentation if anyone wants: gdrive link

(version 1)

I built a handwired trackball to sit next to my keyboards. It comes in two versions.

Wired: RP2040-Zero running QMK with Vial, so the number of buttons, DPI, scroll speed and handedness are set in the Vial app. The case comes with one, two or three buttons.

Wireless: nice!nano clone running ZMK, three buttons, a small battery. Hold the middle button to scroll, middle plus left or right changes the DPI, and the DPI is saved when you switch it off.

An honest note: with this sensor the wireless version drains the battery fast, the cursor is less smooth over Bluetooth, and it is a tight fit inside the case. If you want to build one, build the wired version.

If you'd like to know more about the trackball, the full build log, QMK and ZMK firmware, and case files are on my site. You can also find my other builds there.

About nine months ago, I posted a left-hand controller I was building here.

At the time, that was the project.

I wasn't trying to create a new architecture. I wanted to build a controller.

I was learning as I went—working with microcontrollers, sensors, custom firmware, CAD, PCBs, displays, BLE, and everything else that comes with trying to turn an idea into an actual device.

But as the controller evolved, I kept running into the same problem.

Every time I changed the hardware, experimented with a different sensor, moved something to another pin, added another control, or wanted something to behave differently, I found myself back in the firmware.

Find the right library. Define the pins. Write the input logic. Calibrate it. Test it. Change something. Do some of it again.

Eventually I stopped asking:

"How do I make this controller better?"

And started asking:

"Why am I rebuilding the underlying input system every time I change what I want to build?"

That question took the project somewhere I hadn't expected.

The pictures I'm posting here are from that journey.

Some are from the earlier development bench. Some show where the system is today.

And yes, I'm deliberately leaving all the wires in the pictures.

Different analog sensors. Hall sensors. Joysticks. Encoders. Multi-way controls. Switches. Buttons. Different electrical behaviors. Different connections.

The mess is part of the test.

Because the goal isn't for the creator to build the hardware that my firmware expects.

It's the opposite.

You choose the hardware you want to build with.

Change the sensors. Change the controls. Change where they're connected. Change the physical design because you had a better idea halfway through the project.

The system discovers and electrically qualifies the physical hardware you chose to connect.

Then you tell it what you want that hardware to do.

That's the distinction that eventually became important enough that the controller project grew into something else.

I call the architecture DAHIM, Deterministic Agnostic Human-Intent Machine.

So what does that actually mean if you're just someone who wants to build something?

It means you should be able to spend more of your time designing the thing you wanted to build instead of designing all of the firmware required to make it possible.

Grab the sensors you want.

Choose the controls that make sense for your idea.

Connect them.

Change them if your design changes.

DAHIM's job is to figure out what you've physically built and give you a way to tell it what you want those controls to do.

You shouldn't have to start over because you decided a joystick should use a Hall sensor instead of a potentiometer.

You shouldn't have to keep rewriting input logic because you moved something.

And you shouldn't have to become an embedded firmware developer just because you had an idea for a piece of hardware.

Build the hardware you want. Tell it how you want it to behave. Then get back to designing your product.

That's really what I've been trying to solve.

What you're seeing on the little screen in these pictures isn't a PC interface.

The system is running directly on the hardware.

It can discover physical inputs, electrically qualify them, calibrate them, and allow their behavior to be configured without an IDE or a PC tethered to the development bench.

There's obviously much more happening underneath that, but I'm intentionally not trying to explain the entire architecture in one Reddit post.

There's still a lot being built.

I'm still the same guy who posted that controller here nine months ago, learning, experimenting, breaking things, changing direction and building this around a full-time job.

But I've finally reached the point where I don't have to talk only about what this might be able to do.

I can start showing what it does.

I'm preparing a series of demonstrations showing the development process from physical discovery through calibration, configuration and execution. I'm also putting together a website where I can document the project properly instead of trying to cram nine months of development into individual posts.

Someone actually came back to my original controller post recently and asked me how the project was going.

I guess this is the longer answer.

The controller didn't disappear.

It caused this.

More to come.