Skip to content

fix: make the sot343 footprint symmetric#668

Open
technologyet31-create wants to merge 1 commit into
tscircuit:mainfrom
technologyet31-create:fix/sot343-symmetric-pads
Open

fix: make the sot343 footprint symmetric#668
technologyet31-create wants to merge 1 commit into
tscircuit:mainfrom
technologyet31-create:fix/sot343-symmetric-pads

Conversation

@technologyet31-create

Copy link
Copy Markdown
Contributor

sot343 was the only SOT footprint with lopsided pads. Pins 1 and 2 are placed at x = -p * 1.92, but pins 3 and 4 were placed at just x = p, so the right column sat much closer to the center than the left:

before:  pads x = [-1.056, -1.056, 0.55, 0.55]    (center -0.253, columns ~1.6mm apart)
after:   pads x = [-1.056, -1.056, 1.056, 1.056]  (centered, columns ~2.1mm apart)

So the part was off-center and the spacing didn't match a real SC-70-4. I gave the right column the same * 1.92 spacing as the left so the four pads mirror each other.

One catch: the courtyard outline was hardcoded to the old off-center pads (it ran from -1.703 to +1.197), so once the right pad moved outward it would have stuck outside the courtyard. I mirrored the right side of the outline too, so it stays symmetric and still wraps the pads. The silkscreen already centers itself off the pad bounds, so that fixed itself.

Regenerated the two sot343 snapshots.

Closes #667

@technologyet31-create

Copy link
Copy Markdown
Contributor Author

Heads-up on the red test check — it isn't from this PR. All the parity/* tests fail the same way (sot89, bga165, soic24 … none of which are touched here), because the cached KiCad reference now stores each courtyard as a set of 2-point line segments, while the parity fixture only builds a polygon from an outline with 3+ points. So kicadPolygon ends up empty and it throws "Could not convert courtyard geometry into polygons". main was green a few days ago, before the cache changed format.

The sot343 tests themselves pass. Once the parity comparison can read the reference again I'll regenerate the two kicad-parity sot343 snapshots — the fix should line up with the KiCad SOT-343 reference more closely (its courtyard is symmetric at ±1.45, which is exactly what this change is about).

@technologyet31-create technologyet31-create force-pushed the fix/sot343-symmetric-pads branch from cbefafd to f490bd4 Compare June 29, 2026 22:55
@technologyet31-create

Copy link
Copy Markdown
Contributor Author

Reworked this against the now-restored parity test. The original version made the pads symmetric but at the wrong position (p*1.92 = ±1.056). The KiCad SC-70-4 reference actually has its pads at ±0.825 (p*1.5) and a ±1.45 courtyard, so I matched those — the parity courtyard diff is now 0%. Rebased onto current main (which has the courtyard-segment stitcher) and regenerated the sot343 snapshots, including the kicad-parity ones.

sot343 placed pins 1/2 at -p*1.92 and pins 3/4 at just p, so the pads
were lopsided. Beyond the asymmetry, p*1.92 (= +-1.056) didn't match a
real SOT-343 either: the KiCad SC-70-4 reference has its pads at +-0.825
(= p*1.5) and a +-1.45 courtyard. Use p*1.5 for all four pads and match
the courtyard to KiCad -- the parity courtyard diff is now 0%.
Regenerated the sot343 snapshots (including kicad-parity).

Co-authored-by: abdalrouf-AAA <236259618+technologyet31-create@users.noreply.github.com>
@technologyet31-create technologyet31-create force-pushed the fix/sot343-symmetric-pads branch from f490bd4 to 4c01c88 Compare July 4, 2026 11:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

sot343 footprint is lopsided — the right pads sit too close to the center

1 participant