Sofle Choc variant discussion #29
Replies: 13 comments 33 replies
-
|
100% in agreement on the LED holes, your board was significantly easier for the RGB soldering. I did things "by the book" regarding the tolerance of holes + package for fear of JLCPCBs stated specs, but should have just gone with the flow. I was concerned less with yield and more that the 0.2mm routing tolerance would result in too small of a aperture. For the sockets I didn't feel like I had any major issues, I think the bigger factor than the registration holes was just the solder imbalance from the mismatched pads. I'd agree that tightening them both up will likely be fine. FWIW I've soldered two sets of my prototype boards and your board pair using a mix of the top-notch JBC irons/underheaters/hot air and my own cheap variable Weller 40W Iron. Tried to do my best to run the gamut of gear complexity while acknowledging my soldering experience is greater than typical. That said, any difficulty soldering the sockets shouldn't be inherent to iron power, as none of the pads have significant thermal mass for heat conduction except for copper-defined GND or PWR pins (which my layout addesses by using thermal reliefs). Conductivity for soldering is mostly about properly tinning/wetting your iron tip for conductivity and getting adequate surface contact to both solder surfaces. Larger pad in this case should make things more easily solderable because they will accommodate a larger variation in soldering iron tip sizes. I bought some new tips for my personal station for the first time since college, I had more trouble with fine tips than course on the cheap iron, and that was largely a product of reduced area. HASL helps with this over ENIG, but I'd recommend leaving the large MFG recommended pads intact for the sockets. More thoughts to come, gotta go do dad stuff. |
Beta Was this translation helpful? Give feedback.
-
I'd agree that would be good, the extra distinctions between sides for the halves definitely helped with assembly intuition. Less is more for Silk, particularly regarding text elements I think a high signal-to-noise is very beneficial. Items I'd like to discuss:
I mislabeled Pin28 in patchbay as Pin18
|
Beta Was this translation helpful? Give feedback.
-
|
I think sticking with the bigger components is the best choice for user experience. I've no design objections to using the logo space, since i could swap in the vertical lockup used on the OLED screens. I was also thinking about the logo duplication. I think we should keep the MCU logo on the left-hand switch side, since there is a sofle pico icon on the right hand switch side. This would free up the space below the MCU for more legible/larger attributions. This would also free up the attributions spot by the thumb switch. I think a 27 degree rotation with left alignment would look neat if there's 4 resistors. (For some reason, I thought there was only 2?) sorry for the ms-paint - I just upgraded to KiCad 8, and it's been crashing when i show 3d components If that spots not feasible, my next preference would be closer to the top of the underside of the MCU. I think it's safe to dump the USB + up arrow - but there is always that one user . . .
Thoughts? |
Beta Was this translation helpful? Give feedback.
-
|
You need two pullups for the I2C and two more footprints for handedness pulling an input either up or down. I could get cute with overlapping pads or added testpoints to reduce that a bit, but all at the detriment of clarity for n00bs to the point where I think its counterproductive for our intent. Routing things further north requires weird extensions of the 3V3 and I2C routes and drops all the holes right in the middle of the more critical power routing for VBUS/VSYS, that would definitely be my least preferred path. If not under the MCU the patch bay would certainly be the next-best option. That said, with the larger components even that area gets eaten up really fast. I could split the difference and put one set near MCU, one near patchbay, and retain the logo space (or a slightly downscaled version of it if necessary). ALSO: How the heck do I change parameters like the Revision? I cannot for the life of me find where that's set in KiCAD |
Beta Was this translation helpful? Give feedback.
-
|
Ah - that's right - i forgot about the I2C. I like splitting the difference! If you can swing it, I think vertical orientation under the MCU, and horizontal above the thumb cluster would be ideal, so that it would be easier to distinguish them at-a-glance. (I like the 27degree rotation - but without a set of 4 to solidly establish a pattern, it doesn't feel quite right, hence the horizontal preference). Params are tucked away under page settings: |
Beta Was this translation helpful? Give feedback.
-
|
I'd keep it to 0805 or 0603 resistors. They're easy enough to solder, and not too big. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, I don't think anything 0805 and up is particularly challenging, but conversely I feel like 1/4W resistors are ubiquitous and I don't want to require people to order an odd size. Once that part has established the courtyard its "in for a penny in for a pound" IMO |
Beta Was this translation helpful? Give feedback.
-
|
Another thought - since your Choc variant is clearly superior - it doesn't make sense to refactor the MX version to match, I think waiting until the Choc variant is complete and then swapping in MX switches would be the path of least resistance for syncing the MX/Choc versions. |
Beta Was this translation helpful? Give feedback.
-
|
I pretty much did the reroute for both some degree already as part of my process while tinkering, but its not polished so I'm not sure which path is the least amount of lift without doing a quick self-review. The 3.5.4 layout isn't any worse really, its just different. When I give the files the cleanup pass I'll assess the path of least resistance. The only thing that requires much rerouting is getting 3V3 swapped in on the OLED and Cirque headers. If @uberrice wants to maintain MX I don't want to stomp his work, but I'm also equally willing to do the synch if he's not feeling possessive. |
Beta Was this translation helpful? Give feedback.
-
|
@TheWerle I didn't concern myself much with the hardware since I ordered my own board. Do what you feel like doing! I saw your choc version, and it looks way cleaner than my revision as well. My revision was more of a fix up, yours was a whole new 'redesign'. It you feel up to bring the MX version to the 'choc level', go right ahead, and if you need some help, feel free to ask! |
Beta Was this translation helpful? Give feedback.
-
|
@TheWerle I just uploaded some Pico Choc branding footprints to the main branch. The source files are in the root /design folder, and the footprints are in with the other Sofle Pico footprints for the sake of speed. I kept the line weights consistent between the different icons, but there is some height difference, so it might need some vertical/horizonatl placement tweaks. I kept the origin and scale the same, so you aught to be able to swap em in. (kiCad 8 is way better with creating footprints from vectors)! If I forgot anything, or you want to see some changes, just let me know! (I did agonize over hyphens and bracket variants, but i figured on the board they will be tiny, and I think most people won't really notice . . . )
|
Beta Was this translation helpful? Give feedback.
-
|
OK, I've got the updated Choc PCB and Case files relabeled and organized in a new subdirectory in my fork. @JellyTitan can you pull it down and give it a once-over? Once that's all agreed to be good-to-go i'll do the MX back conversion for the layout and we can start pushing things to the main repo. https://github.com/TheWerle/Sofle-Chico/tree/main/Sofle_Pico_Choc |
Beta Was this translation helpful? Give feedback.
-
|
I requested edit permission on the module sheet. I'll update things based on what I can confidently identify based on photos. If you have any exemplars and a volt-meter I might ask that you verify some results, or we can do more color-coding for confidence.
First pass at clarifying/reformatting the current blurbs. If any note I leave confuses you then its probably needs refinement/justification, you're no naïf so anything that you'd need clarified is probably needed for the general audience. Accessibility is the goal and I want to find the balance between "RTFM" and "here's an essential electrical concept you should learn to improve your designs going forward". I'm happy to clarify or change the language further based on your feedback. Best we can do is provide basic links/terminology in the build guide, lead the horse to water, and hope it drinks. If the end-user doesn't know AC from DC then they'll TLDR it, but at least we'll have done our due diligence. EG: the optional capacitors, which you've mentioned in the past not understanding the function. Short and sweet answer is "adding capacitors to GND at your power pins removes noise and stabilizes power", with smaller caps filtering higher frequencies of noise and larger caps dampening voltage spikes, subsequently preventing damage to parts from over-voltage or instability from under-voltage. https://www.learningaboutelectronics.com/Articles/Decoupling-capacitor.php |
Beta Was this translation helpful? Give feedback.
-
|
I've been poking at that sheet - I'm not sure where that originated - i suspect the owner is the Junco creator? The access requests don't go to me. @daneski13 is that one yours? If so, are you willing to share? If you don't get a response, feel free to spin up a cloned sheet and edit. I can validate the tenstar and some other clones this weekend. I've got a Fluke 117 kicking around somewhere . . . Maybe the official recommendation should be the "official Pico's", with a few tested clones as alternatives, followed by a 'here be dragons'? Your example explanation above is pretty solid - as a layman, that makes sense! |
Beta Was this translation helpful? Give feedback.
-
|
I was not the originator of that modules sheet, I found it linked somewhere on Reddit or Discord. Otherwise, I would be happy to give edit permissions. |
Beta Was this translation helpful? Give feedback.
-
|
@JellyTitan Do you have a Logo w/ text with the same sort of vertical arrangement as the Choc for the OG logo? I'm working on the MX back conversion but the OG logo doesn't fit with the pullups under the MCU
|
Beta Was this translation helpful? Give feedback.
-
|
@TheWerle - Can do! I just created the footprint and pushed to main: |
Beta Was this translation helpful? Give feedback.
-
|
"Alin Marin Elena" have me permission already, so e should be G2G.
I've got ten star blacks, greens, and official picos on hand myself. I'll
let you know if I think I need more info
…On Wed, May 8, 2024, 2:19 PM Dane Skalski ***@***.***> wrote:
I was not the originator of that modules sheet, I found it linked
somewhere on Reddit or Discord. Otherwise, I would be happy to give edit
permissions.
—
Reply to this email directly, view it on GitHub
<#29 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BF7SSQUIBJXYOH2EYCCBDNTZBJUCVAVCNFSM6AAAAABFXUZ3DSVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TGNJYG42TC>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
@JellyTitan I've got the MX back-conversion done, I think both sets of board files should be ready for review and a PR (or manual copy-addition if that's easier) whenever you've got time. I'm unclear on the best approach, my working copy and fork has so many parallel file-sets. https://github.com/TheWerle/Sofle-Chico/tree/Chico_MX_Conv I've kept the latest versions in a branch to make sure I don't somehow stomp on the 3.5.4 layout. |
Beta Was this translation helpful? Give feedback.
-
|
The PR process is should be a good path forward - unless things get real weird. When 3.5.4 was realeased, github 'tagging' was applied so that it's easy to rollback the whole repo and access the v3.5.4 release if need be. (No need to worry about muddying things). I'll start poking through the files today. Thank you for the contrib! |
Beta Was this translation helpful? Give feedback.
-
|
@TheWerle I've started building pico choc - is there an updated bom handy so i can order those new components? I'll ship you a set of the Chocs along in the next few days, as soon as the MX variant comes in too. I gave up on the full color pcb printing and ordered it as is. |
Beta Was this translation helpful? Give feedback.
-
|
Sofle_Pico_V3.5.5.csv |
Beta Was this translation helpful? Give feedback.
-
|
Thanks I just ordered the remaining parts. https://www.digikey.com/en/products/detail/vishay-siliconix/SI2301CDS-T1-GE3/1978728 |
Beta Was this translation helpful? Give feedback.
-
|
@TheWerle Another question - I notice v3.5.5 omits the order number replacement placeholder text: The spot JLC picked for the order number placement is not great: Was the order number placeholder omission intentional? I'm not sure what the etiquette is surrounding that, since it's manufacturer specific? Using the jlcpcb 'specify order number location' option is in the docs, but I can pull it if it's 'gauche'. |
Beta Was this translation helpful? Give feedback.
-
Shoot, no, I forgot to add it back in when reconciling the designs. I'd placed it in the connecting material of the "wing" and milled it off. We could ask around whether there's a "universal" string all vendors will flag, but if not I think we just default to JLC for the newbies ordering our Gerbers and add instructions along the lines of "change this per your preferred vendors recommendation".
I'll try to generate a better formatted BOM over the long weekend with appropriate quantities, but IIRC all the SCH symbols should have the recommended PNs as parameters. With the level shifter and VBUS diodes simplified out I think the "si2301cds" should be the only required part (and even then it can be bypassed). The rest are just "choose equivalent value/package caps/resistors of your choice". |
Beta Was this translation helpful? Give feedback.
-
Thank you. Email me the total and I'll reimburse the cost for shipping and my share of the board fabs. |
Beta Was this translation helpful? Give feedback.
-
This usually doesn't work, as different providers have different string lengths, and the replacement is automatic. The three biggest pcb providers that people probably are going to use are JLCPCB, PCBWay and NextPCB. JLC wants JLCJLCJLCJLC, PCBWay wants WayWayWay, and NextPCB doesn't seem to specify. I'd just output 3 versions once 'the dust is settled': JLC, PCBWay and a 'blank' one. If it's on the rail where it's going to be broken off anyways, you can just put JLCJLCJLCJLC and WayWayWay both on there if you have space (top/bottom?) |
Beta Was this translation helpful? Give feedback.
-
|
Your call, but I'd say a single off-the-shelf Gerber package for JLCPCB is more than reasonable. I wouldn't commit to the configuration management labor of maintaining vendor-specific pre-gen Gerbers over something this trivial. End-users will either have the sophistication to follow instructions and edit it themselves, or if not they're extremely unlikely to care about redundant/oddly placed markings. |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
@TheWerle |
Beta Was this translation helpful? Give feedback.
-
|
No, I've similarly been waiting until I have a build-log with photos to document, and haven't had any spare time lately with work busy again and other projects eating my free time. You going for Thru-hole builds again? If so I can focus on SMT parts/photos and we can do side-by-sides. |
Beta Was this translation helpful? Give feedback.
-
I'll document the through-hole stuff. I've created another branch for working on the documentation, since the When you get a chance to put pen to paper, can you use the doc branch: |
Beta Was this translation helpful? Give feedback.
-
|
@TheWerle If not installing TRRS short protection, bridge the jumpers on both the right and left hands.
|
Beta Was this translation helpful? Give feedback.
-
|
Sorry for delayed response, things have been crazy busy and I had cubital tunnel elbow surgery to hopefully finally let my ulnar nerve issues heal, so I've been uncharacteristically offline. The FET should be installed on whichever hand is the primary connection to the host computer, be that left or right, with the opposite side jumpered. With the hardware resistors for handedness rather than EE Hands I don't think there's anything that requires the master half to be left or right because the boot sequencing will no longer affect how they identify. I've not had the time to build my new boards or test in conjunction with a mouse device, I assume it remain preferable to keep those on the primary half device, but I'm pretty sure it should all just work regardless. I've got a bit of a lull between now and October, I'm hoping to get either another set of top/bottom plates printed up or dismantle my current work unit so I can finally get started on photo-documenting my Choc build up, after which I'll get working on the documentation. |
Beta Was this translation helpful? Give feedback.
-
|
I got a question on Reddit about the protection stuff and I'm realizing I had been misremembering the proper protection setup, in part because I built my prototypes up for right-hand master rather than Left. Looking at my old build photos and revisiting the Issues page, I jumper bypassed the right-hand side, which makes sense. You want the VSYS voltage out the primary half, then the secondary half breaks the link if it detects VBUS. |
Beta Was this translation helpful? Give feedback.
-
|
Glad you're doin alright! Thank you for affirming my understanding of the FET. I installed it that way, but the connection doesn't seem to be working. Now that I know it's supposed to be that way, I'll go back and recheck my connections, and my sloppy FET hand soldering. I updated the QMK PR to default to master left, since the ee_hands was frowned upon and I was concerned the ee_hands would block the commit. On branch docs_v355 I added a writeup for the FET and I2C pullups. I'd appreciate a review to verify my understanding and terminology is correct. I'm not certain what the best way to approach the handedness resistors is - since QMK is defaulting to master, and the FET seals the deal. Maybe leave a note about the unused footprints? (There's a bunch of design choices in the Helix that propagated through subsequent spinoffs - so i expect these will come in handy eventually). |
Beta Was this translation helpful? Give feedback.
-
|
What's not working? It doesn't power at all, or there's some issues with the the handedness properly assigning? If naught else you can always install a header-pin on both halves to selectively bypass the FET while testing handedness options. Since the resistors are there its probably simplest to just go ahead and default to using them. That should make things fully agnostic and reliable. I'll try testing the various options when I get my build done, easy enough to change the config.h and recompile a couple times. |
Beta Was this translation helpful? Give feedback.
-
|
Both halves work fine independently, when connecting the secondary hand doesn't get power. I'll try the FET bypass next. I've got the same issue on the one that you sent me that was built with PCBA. (I'm embarrassed to say i installed the remaining components on the wrong hand - so in that case i probably need to recompile for master RH). The other weird thing that came up, is the Picos from Tenstar don't seem to power the LED's. Not sure exactly what's happening there, but that's a bit of a deeper dive. |
Beta Was this translation helpful? Give feedback.
-
|
OK. Yeah, primary needs the FET, secondary needs bypassed. The Tenstars had the weird pinout that was non-compliant with the official Pico where there is no VRAW pin and the VBUS pin was swapped to a secondary 5V diode input. They're not compatible with the FET circuit. |
Beta Was this translation helpful? Give feedback.
-
|
The workaround is to jumper across D31 with a wire to connect the VOUT pin to the PCB VSYS net. The downside is that without the diode drop voltage difference between the VBUS and VSYS nets the protection FET can't switch on because there's no current flow to active the FET gate. If you're using the Tenstars you just gotta jumper the TRSS power and not cross-power your USBs. |
Beta Was this translation helpful? Give feedback.
-
@TheWerle - i started putting together the excellent variant you built. I did have some UI/UX points I wanted to discuss. (Plus the QMK PR is waiting for re-review!)
I know you mentioned making the LED holes a bit bigger than spec to improve PCBA yield? I'm finding this makes it harder to hand build. (Hand soldering these guys was never easy!)
I'd like to propose using the same hole dimensions as a popular hand built board like the Sofle Choc. Those seem to have a good track record.
Alternately, would it be better to focus on a PCBA specific variant?
The switch socket holes are also big enough to tilt the socket in. I think these could use a reduction as well.
Any socket tilt will be exaggerated when viewing from the keycap grid side.
The socket pad size could be optimized for hand building. I'm thinking many people have entry level soldering irons, and those big pads are harder to get up to temp. Same proposed solution as before - borrow from a tested/popular library. (Foostan is usually my go-to - but his library has big fat pads). I think borrowing from the Sofle-Choc again is worth considering. Brian has tiny pads:
I like the simplification of the LED markings, specifically the removal of the GND pin outline. Leaving the circle indicator is excellent, I'll be incorporating that into the MX version.
I also like the removal of the logo on one side. Not having it on both sides makes it easier to determine RH/LH - I have no idea why I decided to duplicate it on both. I'm thinking I'll replace one side with Open Source Hardware logo, and maybe QMK/VIA - or maybe put the attributions there?
Beta Was this translation helpful? Give feedback.
All reactions