This is KIL0 => This is my project

[KIL0]

Hey there fellow keeb makers,

long time lurker and maker finally putting hands on my diy keyboard project.
My name is Daniel, I’m an electronics development engineer and long time maker from germany (3D-printing, custom electronics, tinkering with some arduinos, …).
I started looking into building a custom keyboard actually for my wife about two years ago because nothing in the market would fit her requirements. I bought two sets of brown Gateron G Pro Switches and ordered five sets of Adafruits neoKey 5x6 ortho snap-apart with two KB2040 to test out different layouts. But like with many projects while these parts were shipped to germany, other projects became bigger priority, but I regularly went back to do some research on all diy keyboards.

So when my second (!) G910 I’m currently using started to experience the same double stroke issues like the first one I had, I picked this project back up, now whit a relatively clear view about the most design choices of the keyboard.

The requirements:

• 100% design with ISO layout
• wired
• snap keyboard
• highly modular (hot swap)
• KB2040 as MCU

I am kind a nerdo when it comes to making a pcb for my own projects. I usually want to have as many possibilities to use it in different ways as I possibly can cram into it. This is partly due to my professional background as a developer and partly because I’m usually working on projects in segmented time slots and keep forgetting stuff (I am totally lazy in documenting ).

The plan:

• Main Keyboard 60% layout with function keys in split configuration
• Arrow pad and num pad as snap on modules with own MCUs (I will get into this later)
• Macro pad and 6 axis space mouse as snap on modules with own MCUs
• All units usable as stand alone via USB and QMK firmware

The technical aspects:

• Every piece of the keyboard gets it’s own KB2040
• The left and right main parts are connected with spiral USB-C cable (like UHK 60 v2)
• The snap on modules can be connected with magnetic pogo connectors to the left and right of the main modules (protocol is discussed later)

I highly like the design of the UHK 60 v2 but it does not fit all the requrements like having function keys ect. What I like are the thumb modules that can be screwed on, to me it looks like they connect via I²C to the main board but due to them being screwed in place I think they can not be hot swopped.

The current idea for the connection between the units via the pogo pins is to use the USB connection. Therefore the USB connection from the MCU can be switched between the USB-C connector on the edge of the board to the pogo pin connector via TS3USB30, activated by Vbus of the USB-C connector (priority, level corrected to the IC).

To handle all the USB communication I plan to implement a CH334 USB hub in the left and right main modules. With this setup I could use USB for the connection of the left and right main keyboard parts as well, handling them as individual USB keyboards all along.

The problem with this is, that I want to syncronize (momentary) layer switching between the two main modules. This is typically done with I²C (if my research is correct) but due to the mapping happening in the keyboard and not in an application on the receiving device (what I highly like) I did not get any results when searching for a solution to this via USB. The alternative to this would be to drop the USB connection between the modules and implement it via I²C. But due to there not beeing a hot swap functionality this means that I need to reset the keyboard every time that I connect a module.

An alternative thought was to use the super speed contact pairs on the cable between the two main modules to indicate the press of a super key for syncronisation.

I would highly appreciate your feedback on my project. I have some more stuff up my sleve when getting into the details but that’s the great picture ,)

Regards

Daniel

[schizobovine]

Wow, that sounds like a neat project, especially the modularity!

Synchronizing layers via USB is going to be tricky, as the HID protocol is mostly one-way from the device to the host. This is why Via and other dynamic remapping systems use a generic USB ACM interface to control that. Which you could use, but you’d need some software on the host side of the connection to handle synchronization.

I2C isn’t normally hot plug, but I think there might be chips that can do that? But would probably require some bus resetting every hot plug. Is UART or 1-wire an option, maybe?

If you’re using USB-C 3.0+ cables, I want to say there’s some alternate wires for signalling besides the usual 2.0 and 3.0 bus wires, for just this sort of thing (a bit like HDMI has CEC for remote control). That way you can use standard cables and don’t have to worry about it confusing the hell out of an actual USB 3.0 host.

[KIL0]

From the engineering side of view there is no restriction for I²C to be hot pluggable, the question would just be how often the I²C master “scanns” the bus for participants. Usually there is nothing on the protocoll level implemented for a client to register itself at the master. And the scanning usually just sends a request and checks if there is a response before a timeout. So this is a litte lime consuming.

I think I will go down the path with the communication over USB and use some of the additional wires of the USB C cables to create something like an interface for the super keys to the other module. Your comment on this sounds like you have a suggestion on which pins to use for this?

I am currently planning to put all the USB and pogo connectors on the main pcb of the keyboard but connect them only to some tht pads. With this configuration the USB connection can be wired with actual wires for each situation.

[KIL0]

I had some time to set up the first schematic for the left main unit.

Main page contains the key matrix, the SOMs (KB2040 as MCU, CH334 USB hub) and all the connectors:

• P1 and P2 are USB C ports at the back of the housing
  • P1 is planned for the main connection to my computer => Sink config
  • P2 is held for as input for the right main unit => Source config
• P10 is planned as USB C port for USB C spiral cable to the right main unit
  • I want the straight piece to disappear inside the housing so I need the connector to be in the middle of the pcb. Therefore I need to lift it up from the main pcb (because otherwise the connector would just not fit)
  • Breakout board will contain the polyfuse, the ESD protection and the source configuration resistors
• P3 is an old school USB A connector as a spare
• P4 is dual USB and I²C pogo connector to connect extension modules
• P5 is I²C pogo connctor for thumb pads
• P6 and P7 are I²C connectors for displays and other stuff inside the keyboard module

I modified the super key (S62) to have a mosfet driving the MCU pin. The gate pin of the n-fet will be linked thru to the right main module with the same schematic. With this configuration both super keys can be read by both MCUs without rising damaging the MCU.

Picture in the next post

I planned the key lighting and implemented a logic level shifter. For the underglow I designed a footprint for the SK6812SIDE leds. Currently I have “just” 16 pcs for this side, if this number will change depends on the layout and your feedback ,)

Picture in the next post

My plan is to have absolutely no parts on the top of the pcb to be able to clean it very easy (just remove all the connectors and have a clean sweep).

Current thoughts:
As I’m writing this I think I will implement some ESD protecion to the I²C pogo pins as well.

I will try to get to the layout soon. I am intrigued what changes I will/want to do while doing the layout.

[KIL0]

Key leds

[KIL0]

Underglow leds

[KIL0]

I started working on the layout and after placing all the switches and key leds I took some time thinking about the placement of the additional USB connectors and the USB hub.

I revised the plan to put everything onto one pcb and will now be going to make a pcb stack like the nullbits keyboards with the USB connectivity and the underglow leds on the bottom board. It should be possible to design the pcbs in a way that the upper pcb could be used stand alone as a simple keyboard.

About the underglow:

I would be happy about everyone sharing some experiences about the underglow regarding placement, spacing and maybe even the impact of the color of the pcbs (if it has some).