Updated PCB design with South Facing SK6812 Mini-E ARGB

[Lefuneste83]

Hi there!

For those interested in building a KLOR keyboard you may check my fork of the design including :

• Full height switch version (fully qualified) anf beta version for low profile Gateron KS33 switches
• Updated and working QMK and ZMK firmware binaries and config files with maximum set of functionalities enabled
• I have included an alternative design for a DIY haptic module based on the Pimoroni design. It has been validated
• Easier to solder and more suited SK6812 Mini-E ARGB LED modules
• South facing LED configuration
• Easier to solder triangular bridge footprints
• Design passes DRC check for JLCPCB with 0 errors and builds without issues
• Almost complete parts rerouting and various small corrections on grounding issues
• Various corrections of SMD footprints for valid stencils fabrication

Make sure you read the disclaimers as there is a slight change in the tenting puck mounting position in case you want to use one.

Please let me know if you wish to have this design improved one way or another. I'll be glad to help!

[psi4j]

These are some awesome updates to the boards. Great work, my friend. Will you be adding the trackpad integration that was done for the KLOR as an alternative? If you made an updated version with the trackpad integration I would switch over to your build real quick. Imagine not struggling with those tiny little LEDs anymore. I have a microscope and I still struggled. Good stuff!

[Lefuneste83]

Thank you for your feedback. I haven't found a proper solution yet for the pointing device. One of the issues I have found after a little bit of research, is that the original design expects an I2C interface which is not, by far, an "industry standard" for pointing devices. I believe the author went with a Pimoroni trackball as the expected pointing device which is one of the few pointing modules using an I2C interface to communicate with the MCU. The best solution for this keyboard would be to use a Thinkpad style trackpoint as they are ubiquitous, very small in size and quite precise. Plus many people including myself really appreciate their ergonomics. The problem is that most of the trackpoint modules found on Aliexpress expect some sort of PS/2 style data interface. Also goes the QMK drivers so it is not only an electrical issue. But I will try to do some research again to find a solution. It may be for instance possible to reroute the tracks going to the trackpad device and define them as PS/2 interface but it would require a few extra pin allocations on the MCU socket as the original design shares I2C pins with the haptic module as it is supposed to be if using I2C data bus. Not sure if there are extra pins available on the MCU socket. I think it would require between 2 and 3 pins for PS/2 dedicated data link excluding VCC and GND. Apart from that any QMK supported I2C pointing device would work on this design as long as there is a driver of course. I2C protocol is excellent overall except that most pointing devices use other interfaces such as SPI. Have a look at QMK documentation for the list of supported pointing devices. You will see that very few devices use I2C communication protocol. Pimoroni trackball and Cirque trackpad are some of them. Also have a look at this github page.

[ux0rial]

Wow! This is an awesome update with a lot of QOL improvements. Thanks a lot, boss.

By the way, is this version compatible with KS-27/33?

[Lefuneste83]

Thank you for your feedback. No as stated in the header comments on my fork this is currently only for normal full height switches but apart from the 3d printed cases it should be pretty straightforward to convert the design to low profile switches as only the switch composite footprint would require an update followed by some fine grain rerouting of the few pins that would get slightly displaced. From what I can experience with my build you may also be able to use the same enclosure with low profiles switches. We would need to give it a try. Also note there already exists a modded version of the 1.3 with low profile switches support although it may restrict you to KS27 and Choc V1. I believe KS27 have the same pinout compared with latest KS33 and in particular will allow the use of Gateron Banana which are excellent tactile switches. Choc V1 are better avoided as they require specific dual tab keycaps that cannot be sourced in any convenient manner and are either very expensive or of very poor quality. The best target for a modded pcb would be to have compatibility to KS33, Choc V2 and Kailh latest offering which are supposed to be excellent. low profile switches.

[ux0rial]

Thanks so much for getting back to me!

For now, I’ll build one using your current version (1.4) since I have no experience with PCB design or modding.

I did see a low-profile fork of the Klor, but as you said, it’s only KS-27 and Choc v1. And as you mentioned, I was actually looking for KS-33 compatibility to try the new Gateron Bananas. I do have a Totem with Choc v1, and those switches are pretty meh. I’m totally up for being a guinea pig if you decide to explore the idea of a KS-33/Kailh v2 version though!

[Lefuneste83]

If you want to spend some time doing a little bit of research around the other low profile modded version, KS27 and KS33 may be pin compatible but make sure the pcb allows for both as it is not only the pin placement but also the cutouts that make the integration possible.

[Lefuneste83]

Thanks so much for getting back to me!

For now, I’ll build one using your current version (1.4) since I have no experience with PCB design or modding.

I did see a low-profile fork of the Klor, but as you said, it’s only KS-27 and Choc v1. And as you mentioned, I was actually looking for KS-33 compatibility to try the new Gateron Bananas. I do have a Totem with Choc v1, and those switches are pretty meh. I’m totally up for being a guinea pig if you decide to explore the idea of a KS-33/Kailh v2 version though!

Hi there. I have made an initial low profile version for Gateron KS33 switches if you want to give it a try. Please read the Changelog for specific informations regarding this version. You can find it here : https://github.com/Lefuneste83/KLOR/tree/main/PCB/klor1_4_LP_KS33

Now I have to do the same for Kailh V2 which cannot fit on the same PCB due to hole cutouts.

[ux0rial]

Awesome! Thanks for taking the time to build this version. I can’t wait to try it out.

By the way, is there any issue using the cases on the KS-27 modded version?

[Lefuneste83]

The KS27 version seems to have some differences in the way it interacts with the enclosure. You should ask its designer. Also I believe that some people would prefer a slimer case for a low profile build so it may be the reason for a different enclosure.

For my version which uses KS33 switches I don't see a reason for incompatibility but I have just designed it in the last few days and I haven't ordered or build it yet. Apart from the traces and footprints of the switches I haven't moved anything so I don't see why it wouldn't fit. Also you should check out my fork for cases as I have included a much nicer case compared with the stock one. Also the step file is included if you wish to modify it.

Lastly in case you haven't noticed I have validated the haptic module I have designed. I will move the functionality to the main PCB in a coming 1.5 version so it will give us more freedom for other device integration. The optional PCB is nice as it is modular but it brings quite a lot of constraints that we can get rid of. Moving the components footprints directly to the main PCB can free up quite a lot of room to add other I2C supported devices.