# Seve - @Abse RE: pico in common RE: pico in common `` ## Abse — 2026-07-18T17:03:32.513000+00:00 <@757706909351411845> https://github.com/tscircuit/footprinter/pull/709 https://github.com/tscircuit/circuit-json-to-footprinter/pull/10 ## Abse — 2026-07-19T14:10:08.985000+00:00 <@757706909351411845> no sure about the variables names for the usbc footprint haha let me know if you got something better https://github.com/tscircuit/footprinter/pull/712 ## Seve — 2026-07-19T14:10:41.780000+00:00 Specific variants, also dont use any speculative params ## Seve — 2026-07-19T14:11:03.525000+00:00 Every param needs a test footprintjbb. ## Seve — 2026-07-19T14:11:25.323000+00:00 Ie, a real footprint it was creted to match ## Seve — 2026-07-19T14:11:36.907000+00:00 Speculative params are extremely dangerouus ## Abse — 2026-07-19T14:12:22.709000+00:00 [attachment] Attachment: image.png — https://community.tscircuit.com/media/1528404137014722750 ## Seve — 2026-07-19T14:12:23.377000+00:00 usbcmidmount or whatever is alredy the correct fn for your proposed footprint ## Seve — 2026-07-19T14:12:41.855000+00:00 I merged it if im not mistaken ## Seve — 2026-07-19T14:13:35.587000+00:00 Wasnt merged https://github.com/tscircuit/footprinter/pull/708 ## Seve — 2026-07-19T14:15:11.636000+00:00 Idk if that pr is good, but midmount is a good term to indicate it has pill holes ## Seve — 2026-07-19T14:15:27.712000+00:00 We want to have major variations with expicit fn names ## Seve — 2026-07-19T14:15:42.495000+00:00 Idk if those examples are real so idk if that pr is mergqble or not ## Abse — 2026-07-19T14:25:11.877000+00:00 Ok I will take the PR and work over it ## Seve — 2026-07-19T14:25:22.186000+00:00 Yea its good stuff ## Seve — 2026-07-19T14:26:32.427000+00:00 I think the configurable/custom pads were the worse thing but lots of good stuff- we just shouldnt have that much customization because it means we were not able to do proper data modelimg ## Seve — 2026-07-19T14:26:47.410000+00:00 We dont want footprinter to look like a footprint as a string ## Abse — 2026-07-19T14:36:28.560000+00:00 so if we wanted to support 6 pin we make a 6 pin variant and not pad count ? ## Seve — 2026-07-19T14:38:40.457000+00:00 possibly! Depends if it has a name that is nice and domain specific ## Seve — 2026-07-19T14:39:26.212000+00:00 Do you have an example of that? Maybe we can pull all the jlc usbc footprints into footprinter somehow??? Then try to match them and think the best names? ## Seve — 2026-07-19T14:39:59.104000+00:00 midmount is nice because it implies its mounted, in the middle, most likely with pill plated holes ## Seve — 2026-07-19T14:40:07.057000+00:00 smdusbc is similarly nice ## Seve — 2026-07-19T14:40:20.412000+00:00 I dont know anything about 6pins atm ## Abse — 2026-07-19T14:40:35.926000+00:00 [attachment] Attachment: image.png — https://community.tscircuit.com/media/1528411238944608287 ## Seve — 2026-07-19T14:40:39.769000+00:00 There are ones that stick “straight out of a board”- they would have a custom variant i think ## Abse — 2026-07-19T14:40:44.289000+00:00 old code , but this is one ## Seve — 2026-07-19T14:40:49.355000+00:00 Good ## Abse — 2026-07-19T14:41:05.059000+00:00 this will also be midmount ## Abse — 2026-07-19T14:41:09.373000+00:00 6pin ? ## Seve — 2026-07-19T14:41:16.272000+00:00 Yea ## Seve — 2026-07-19T14:41:22.187000+00:00 Is it midmount tho? ## Seve — 2026-07-19T14:41:32.320000+00:00 What does the part look like? ## Seve — 2026-07-19T14:41:45.551000+00:00 Could be 90 degrees ## Abse — 2026-07-19T14:42:02.134000+00:00 [attachment] Attachment: image.png — https://community.tscircuit.com/media/1528411600527298700 ## Seve — 2026-07-19T14:42:17.184000+00:00 Yep midmount ## Seve — 2026-07-19T14:42:21.701000+00:00 Yep ## Abse — 2026-07-19T14:43:11.735000+00:00 just to make sure I understand we will use the same midmount you had in your pr and add _6pin flag ? ## Seve — 2026-07-19T14:43:24.357000+00:00 usbcmidmount6 seems ok ## Seve — 2026-07-19T14:43:27.129000+00:00 I think ## Seve — 2026-07-19T14:43:54.248000+00:00 I dont know if my pr is that great- your original seems very broad but most of the params are ok ## Seve — 2026-07-19T14:44:00.463000+00:00 Wish i could do a proper review ## Abse — 2026-07-19T14:44:29.747000+00:00 can you review this , this is after taking inspiration from your pr https://github.com/tscircuit/footprinter/pull/712 ## Abse — 2026-07-19T14:45:02.911000+00:00 we can also wait until you finish the opensauce dont want to make it on a rush ## Seve — 2026-07-19T14:45:15.825000+00:00 no that seems pretty good imo ## Abse — 2026-07-20T11:19:15.735000+00:00 <@757706909351411845> I think I finally found the subcircuit bug ``` The child subcircuit routing itself was correct. The bug happened when Core prepared the parent-board SRJ. Expected flow: Route the Pico subcircuit. Preserve its copper as static traces. Mark which exact PCB ports each preserved trace physically connects. Route only the remaining board connections. Actual flow: Core preserved the child copper geometry, so the autorouter saw it as static obstacles. But Core dropped the autorouter’s connectsTo: [portA, portB] property. It replaced it with broad connectedTo electrical-net metadata, which the autorouter does not use for physical route state. Therefore, the board router saw the child copper but did not know that its endpoints were already connected. It generated the Pico’s internal MST connections again, tried routing over the static Pico traces, and eventually ran out of iterations. The fix: Core now preserves the native connectsTo property with only the exact endpoints connected by each physical trace. It no longer expands a child trace into every identifier on the electrical net. This uses explicit properties—not trace-name or exposed_net.* string matching. In the autorouter, overlapping physical pairs are now merged transitively. For example, [A,B] and [B,C] correctly mean that A, B, and C are already one connected component. Verification: Generated board SRJ: 51 remaining connections and 136 child traces. All 136 child traces had physical connectsTo pairs. The full SRJ routed successfully in the autorouter in about 84 seconds. A clean rerun passed and matched the generated full-board SVG snapshot. Core also completed the Gameboy routing using autorouter 0.0.696 with zero autorouting errors. So this was a routing-state contract bug between Core and the autorouter—not a need for more iterations or a Gameboy-layout workaround. ``` ## Abse — 2026-07-20T11:45:41.295000+00:00 most of the snapshots changes is in the svg metadata for the core version when you use `export BUN_UPDATE_SNAPSHOTS=1` ## Abse — 2026-07-20T11:46:47.811000+00:00 https://github.com/tscircuit/core/pull/2732 ## Abse — 2026-07-20T20:03:40.462000+00:00 <@757706909351411845> https://github.com/tscircuit/circuit-json-to-footprinter/pull/13 ## Abse — 2026-07-20T23:57:31.301000+00:00 <@757706909351411845> https://github.com/tscircuit/tscircuit-autorouter/pull/1708 ## Seve — 2026-07-21T15:11:41.544000+00:00 ooh