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.

[joeblackwaslike]

@Lefuneste83 I would like to express my sincere appreciation for the improvements you made on the Klor 1.3 PCB. After several unsuccessful attempts at building it myself, your modifications have me eager to give it another go, this time with the confidence that your changes have resoilved the issues previously encountered.

I recently attempted to order the new Klor 1.4 PCB (full height) using the zip file in your forked repository. However, I encountered an issue with JLCPCB, where they warned me about a minimum hole size of 0.2 mm, with a diameter of 0.4 mm in the file. They recommended a 4-Wire Kelvin Test to ensure the quality of my order, which would incur an additional cost of ~$60. Alternatively, they suggested modifying the hole size/diameter to 0.2/0.45mm, which would eliminate the need for the test.

Given that my expertise does not lie in PCB design, I am unsure of the implications of this warning. I would be incredibly grateful if you could provide some guidance on this matter. Is this something I should be concerned about? If so, could you possibly assist me in making the necessary modifications?

Thank you once again for your invaluable contribution to improving the Klor PCB. Your expertise and dedication are truly admirable.

[Lefuneste83]

This is weird, I've never had this issue when ordering on JLCPCB as I use their design rules to validate the design. I'll have a look and let you know.

[Lefuneste83]

@Lefuneste83 I would like to express my sincere appreciation for the improvements you made on the Klor 1.3 PCB. After several unsuccessful attempts at building it myself, your modifications have me eager to give it another go, this time with the confidence that your changes have resoilved the issues previously encountered.

I recently attempted to order the new Klor 1.4 PCB (full height) using the zip file in your forked repository. However, I encountered an issue with JLCPCB, where they warned me about a minimum hole size of 0.2 mm, with a diameter of 0.4 mm in the file. They recommended a 4-Wire Kelvin Test to ensure the quality of my order, which would incur an additional cost of ~$60. Alternatively, they suggested modifying the hole size/diameter to 0.2/0.45mm, which would eliminate the need for the test.

Given that my expertise does not lie in PCB design, I am unsure of the implications of this warning. I would be incredibly grateful if you could provide some guidance on this matter. Is this something I should be concerned about? If so, could you possibly assist me in making the necessary modifications?

Thank you once again for your invaluable contribution to improving the Klor PCB. Your expertise and dedication are truly admirable.

Note sure what zip file you tried.

Firstly please submit this kind of issue on my fork directly here, as it concerns a design hosted there and this can be confusing for some.

I have just tried ordering a batch of PCB with my latest 1.4 version zip file from my forked repo and I don't get any warning. Let me know at what stage of the ordering process you get this kind of warning.

When ordering you just need to upload the zip file and choose the number and color of the PCB. Nothing else. By default JLCPCB has removed the board markings so there is nothing else that should be modified in the PCB specifications except if you want to improve it for instance having ENIG finish but this will cost you more. Be aware that if you modify other parameters, sometimes the calculated total will not revert back to the previous default price if you revert your specification. There seem to be some bugs in the JLCPCB web page for this.

[joeblackwaslike]

@Lefuneste83 I did everything exactly as you described, I checked out and paid, later that day I got the following email from jlcpcb.

I have since cancelled that order, and placed a new one which uses the exact zip file you linked to above, and ensuring I followed all your instructions exactly, will update this thread on what happens and open an issue in your repo.

[Lefuneste83]

Maybe they changed something in their requirements. Let me know and I'll do the modifications if required.

[joeblackwaslike]

@Lefuneste83 the second try worked with no issues, for what it's worth.

I noticed the improvements being made in 1.5 and may wait on that to be verified since it seems to address many pain points I experienced with the original 1.3.