Future Choc Rev - Quick and Dirty double-sided footprint

[TheWerle]

Out of curiosity / desire to learn KiCAD I went ahead and hacked together a reversible Choc socket footprint, borrowing from your current "DS" (double-sided presumably) MX library and other Keyboard plugin libs. I didn't do any switch column / row spacing changes, just kept it MX gapped, but the component placement rework for a future fork seems like it should be fairly trivial.

When you're ready to consider future builds I'd be happy to contribute.

[JellyTitan]

Looks great!
In rev 3.5.4 I refactored the footprints to make them easy to swap out. (Previous versions were based on the combo/nested footprints found in Brian Lowes sofle choc.)

I'm a big fan of the foostan footprint library - thats usually my go-to for first drafts of pcbs with footprints i haven't used before. I mention that because it looks like the center hole there is oversized for choc V2, but there's no extra hole for the Choc V2 vestigial pin.
Without looking at the footprint library - i think this one has that extra hole:
https://github.com/foostan/kbd/blob/main/kicad-footprints/kbd.pretty/ChocV1_V2_Hotswap.kicad_mod
The MX spacing would make sense with the Choc V2, and there's not many choc boards out there that support both the v1 & the v2. (Which is one of the reasons why i designed the Cantor MX variant).

After all the prototyping I did for the Sofle Choc - I'm sick to death of these little guys. Are you interested in refining this design and taking it to the point of building a prototype of this?

[JellyTitan]

Also - keeping the layout/spacing/outline the same makes it easier with cases. I'd like to keep any subsequent Sofle Pico variants the same in terms of those specs, to help with adoption and keep things simple.

[TheWerle]

Definitely interested in advancing it. I'm confident in my ability to refactor boards, but QMK and 3d printing are newer territory, so piggybacking off your start and providing an inevitable request seems like a win/win to gain skills and dig in. If I can figure out the best KiCad panelization solution to solve the PnP Assembly with reversible layout quandary that seems like a real potential benefit as well.

Physical switch differences are something I'm still familiarizing myself with, I just own choc v1 numpad for tinkering ATM and a cheap mech "clicky" keyboard. I like the choc low profile and think the short movement may help my RSI, but packing the rows any tighter just seems like they would feel cramped. People can presumably fine tune the gaps with caps.

I'd definitely support "minimize changes between variants", I dig this "poka-yoke" design ethos. Might build an interim MX model so can try both once you've blessed the last bits. I've got an Adafruit order on the way to get my basic toolkit going.

[TheWerle]

I grabbed starting pads/artwork from Keyswitch Kicad Library, its a native import to KiCAD now.
https://github.com/kiswitch/kiswitch?tab=readme-ov-file

... it looks like the center hole there is oversized for choc V2, but there's no extra hole for the Choc V2 vestigial pin. Without looking at the footprint library - i think this one has that extra hole: https://github.com/foostan/kbd/blob/main/kicad-footprints/kbd.pretty/ChocV1_V2_Hotswap.kicad_mod The MX spacing would make sense with the Choc V2, and there's not many choc boards out there that support both the v1 & the v2. (Which is one of the reasons why i designed the Cantor MX variant).

Figured out why I omitted it the "vestigial" hole, a combo of defaulting to V1 STEP and the "spare" pin dropping right in the middle of the per-key LED vias. Dual V1/V2 Solution would either involve a larger SK6803 footprint or just omitting it and directing users to trim the leg. I'm inclined towards the LED fix for assembly simplicity or parts reuse.

http://www.normandled.com/upload/202107/SK6803MINI-E%20LED%20Datasheet.pdf

Can you tell me why the symbol for the LEDs is swapping the pin-order? The recessed mount stuff makes it weird, but standard practice would still be adhering to the datasheet for numbering and fixing the orientation in the footprint.

[JellyTitan]

the best KiCad panelization solution to solve the PnP Assembly with reversible layout quandary that seems like a real potential benefit as well.

I don't understand that statement. Can you explain it like I'm 5?

the choc low profile and think the short movement may help my RSI
Oddly enough the chocs travel length is close to MX. Chocs travel is about 3mm, with an actuation point of 1.5, compared to MX switches which are usually about 4mm travel with a 2mm actuation distance. I've been trying to emulate the light touch and short travel of the MBP for years without success. The closest I've got is Kailh speed Bronze with the short actuation distance of 1.1mm, and I put O-rings on DSX keycaps to bring the travel down to about 1.8mm.

omitting it and directing users to trim the leg
On the Choc v2 - I tried trimming it before - it doesn't work very good. I tried to put together a "Master key" footprint at some point with support for 7 different switches. I found that keys mostly need to have at least 2 good points of contact to keep from getting wobbly.

The Choc V1's have extra plastic pins to the right and left of the center post., whcich give it enough stabbility despite the oversized center hole for the V2. The V2 chocs don't have those extra plastic pins, so it needs that third pin to keep it oriented properly in the hole!

I see what you mean about that pin dropping into the LED VIAs:

Those LED footprints were mostly a creative choice. (Plus @uberrice taught me some stuff about manufacturability which led to the via size increase and relocation to improve yield).

KiCad 7 made it really easy to edit footprints, so i got real weird with it. I think the best solution would be to use a different LED footprint, or heavily modify the current one to avoid those Choc V2 pins.

The Choc V2 profile never really caught on in the custom keyboard community, so there aren't many switch variants. (Not sure if it's a 'chicken or the egg' type situation)? I'd be surprised to see a .step of those included in most repos.

As far as swapping the pins go - i suspect it's from the SK6812 Mini-E. That was used by the Sofle Choc, so I probably got it from there when I used Brian Low's design as a starter.

[TheWerle]

I don't understand that statement. Can you explain it like I'm 5?

https://jlcpcb.com/help/article/96-pcb-panelization
On the main Sofle discussion page either you or @uberrice (probably him I guess) were asking about how to optimize the design for JLCPCB automated SMT soldering of the diodes/level-shifter/etc. You'd want them to populate surface mount parts on a single board side, extra sides = extra paste/placement/reflow-oven operations and thus cost. An optimized-for-cost set of gerbers would have both Left & Right hand mirrored copies on one side of the panel so they can install the components in a single pass.

JLCPCB has some panelization rules so people don't game the system too hard, folks probably won't save money on bare boards due to size and complexity of the board outline, but the ability to spend $10-15 for automated assembly on the small stuff folks struggle with would be nice.

On the Choc v2 - I tried trimming it before - it doesn't work very good. I tried to put together a "Master key" footprint at some point with support for 7 different switches. I found that keys mostly need to have at least 2 good points of contact to keep from getting wobbly.
The Choc V1's have extra plastic pins to the right and left of the center post., which give it enough stability despite the oversized center hole for the V2. The V2 chocs don't have those extra plastic pins, so it needs that third pin to keep it oriented properly in the hole!
The Choc V2 profile never really caught on in the custom keyboard community, so there aren't many switch variants. (Not sure if it's a 'chicken or the egg' type situation)? I'd be surprised to see a .step of those included in most repos.

Yeah, V1 seems like a superior design mechanically. Without a soldered connection I don't know how much resilience the extra V2 pin would even offer. I presumed that most of the registration reinforcement would come from a keyplate, but i guess there's enough body-size difference that it wouldn't be one-size fits all, but by the same token the PCB can be universal easily enough.

As far as swapping the pins go - i suspect it's from the SK6812 Mini-E. That was used by the Sofle Choc, so I probably got it from there when I used Brian Low's design as a starter.

Ah. Its a weird choice by the vendor, the package has visible pin1 marks with the chamfered pin and body and is presumably pick-and-place capable from the bottom-side. At least they are drop-in equivalent, but i hate breaking from convention or contradicting datasheets if avoidable.

[TheWerle]

Power and Diodes:
I'm reading your build log to understand design choices and I think you're operating under some misconceptions for the power diode and voltages (or at least have some confusing notes). The power diode like a one-way valve, its there to provide protection from reversed voltages or backpower into your PC at the cost of dropping the voltage. The diode forward voltage (Vf) is essentially a constant for your purposes, rated 1A Vf for1N4148 = 1V and 1N5817 = 0.45V, so the reason the 1N4148 gets so hot is because its dumping >2x the power as wasted heat. That in turn increases the LED current due to lowered supply voltage, the LEDs draw more current to get equivalent power w/ a reduced voltage, and all together its more heat/power.

Your 1N5817 Schottky should not be reducing VSYS to ~3.3V, the diode forward voltage drop should be ~0.1-0.4V and subsequently VSYS should be ~4.6-5.0V. If the voltage were dropping to ~3.3 your RGB LEDs wouldn't work, their minimum VDD input voltage is 3.7V. Do you own a voltmeter to double-check that your diode is operating nominally?

****EDIT: Updated with LTSpice simulations, rereading build log to confirm D31 is back **
The Pico D1 protection diode you show from section 4.5 is similar in function is redundant to D31, but it would be worthwhile to add a second protection element. That diode protects the PC-USB from backpower, but it doesn't protect the RP2040 from backpower risks from powering both boards across the split, a second diode or PFET is still needed for that scenario. For optimized protection you'd want that protection at the TRRS jack, where if USB voltage is applied the TRRS power-path shuts off. The DMG2305UX P-FET solution shown on RPI Pico datasheet section 4.5 (pg22) could be implemented in this manner by connecting J4.2 to the "external supply" portion of that image. (I don't know why this hasn't been done commonly in Split-Kb community if its in the RPI datasheet, makes me think I'm overlooking something still)

This is a "close enough" simulation (couldn't import exact DMG2305UX P-FET model but got close-enough). "Right Hand" is primary half to PC, "Left Hand" is secondary that should operate from power across the TRRS cable. Top "I(Trrs)" waveform is current across the TRRS cable, middle waveform is the USB voltage into either Pico, bottom is each split's VSYS. When the left-hand USB power asserts the TRSS cable current drops out as expected, preventing current backpowering from the secondary-side to the primary.

TLDR:
The RPI datasheet's usage of VBUS and VSYS infer voltage expectations. VBUS can be presumed to be 5V +/-0.2V. VSYS infers that the voltage at that point is variable, either from diode-drops or stuff like inconsistent voltage levels from battery power. Either VBUS or VSYS should still be available at near 5V w/ wired USB as intended power path. (You mention a solenoid, this is some planned inductive battery charging for eventual FMK/BLE wireless split? That would complicate things, but it all could be done).

Adding a DMG2305UX PFET to the left-hand side by the TRRS jack seems like a low-cost / low effort option for folks who want added backpower protection. Its a bog-standard SOT23 package, pretty easy for anyone comfortable with surface mount soldering, and the bypass option is just another simple solder-bridge.

1N5817 is solid for add-in USB-backpower protection diode purposes, but could be swapped /optioned with a lower forward voltage alternative if a SOD123 surface mount pad option was added. The surface mount package reduces power consumption/heat from a reduced forward voltage current response. The MBR120VLSF diode already used for D1 on the Pico is pretty ideal and in the same SOD123 package as the 1n4148, so anyone who's open to surface mount shouldn't be intimidated, so making it the option for D31 would be nice.

[JellyTitan]

Sorry - i missed these comments!

I won't pretend to understand half of what you said there.
Adding protection against TRRS jack shorts would be really helpful.
The split keyboard community tends to iterate on designs, so getting something like that into the Sofle Pico before downstream variants start popping up would be really helpful. I don't have the skill or the bandwidth to do that right now - but I'll turn this comment into an open issue, hoping somebody with the time and skill can implement it.