A low profile ortholinear split keyboard with per-key RGB.

This is a project that began as my first adventure into PCB and keyboard design.

This table is for one PCB. You need double of this for both hands.

Fabrication gerber files are in ./PCB/gerber directory.

103.188 mm H x 168.275 mm W
2 layers
Unleaded HASL or ENIG
1.6mm thick
white on black

The images below are PCBs for v3.

The board is designed to be reversible. You can flip the PCB to the other side to serve as the other half.

The parts that are mountable on both sides of the PCB are the type C port, the TRRS jack, the reset button and the key matrix (switch, LED, diode).

The side for mounting type C port and TRRS jack is up to your will. The reset button should always face up for ease of access. The LEDs for keyboard are reverse mounted. Key diodes should be on the underside.

As one side would have its electrionic components mostly facing down, you should lift the split halves up to avoid shorting. If you have leftover boards from ordering in batch amounts, it is possible to use them as bottom plates using M2 screws and standoffs.

For information, the shortest M2 standoffs I can find are 3mm in length, the type C port is 3.2mm high, and the TRRS jack is 5mm high (the outer plastic ring might be 5.6mm high). If you decide to put the type C port and TRRS jack on the top side, you can have the standoff as short as just higher than the electronic components on the board.

By default the keyboard is set to use EEPROM handedness check, this means that for the first time for both halves the following commands need to be used:

make 5x07:default:dfu-split-left
make 5x07:default:dfu-split-right

afterwards the end part can be dropped when flashing again.

For v3 and below there is no VBUS detection, so USB activity detection must be used for split master detection if you do not want to hardcode the master half.
V3.1 onwards has VBUS detection and you can use it normally.

I couldn't for the life of me figure out how to stably enable the per key RGB, so use at your own risk.

Some problems that I encountered were:

• RHS board (using EEPROM flags) could have RGB lights on in QMK, but then it disconnects if the mode switches from the static gradient to static solid color.
• RHS board can change modes between different static gradients if its hue/saturation/value are turned down first.
• LHS board disconnects from computer immediately after connection when RGB is enabled. If the USB is connected to RHS board and LHS is connected to RHS via i2c, it would drag both halves down with the disconnection. After disconnection, the RGB lights start to flicker.
• RHS board would also display random disconnection behavior if the hsv are changed too fast.