# Arhan - While implementing the SparkFun Qwiic T...

Channel: #contributor
Source: https://discord.com/channels/1233487248129921135/1532123285998010478
Started: 2026-07-29T20:30:57.531000+00:00
Last activity: 2026-07-30T21:54:58.788000+00:00

## Arhan — 2026-07-29T20:30:56.856000+00:00

While implementing the SparkFun Qwiic ToF Imager VL53L5CX (SEN-18642), I isolated what appears to be a `SolderJumper` issue into a minimal reproduction.

The attached screenshot is from that repro. The DRC reports three `pcb_trace_error` entries for disconnected bridge trace endpoints, even though the generated bridge traces appear to terminate on the SMT pads.

After tracing through the implementation, my current understanding is:

- The bridge traces intentionally terminate exactly on the pad boundary.
- `isPointInPad()` performs strict `<=` boundary comparisons for rectangular/pill pads.
- Other geometry checks already use tolerances (`POINT_ON_SEGMENT_TOLERANCE_MM` / `EPSILON`), but these boundary checks do not.
- I think this results in a floating-point boundary case where the endpoint is mathematically on the pad edge but is reported as disconnected.

Please correct me if I'm misunderstanding the intended behavior or if I've missed something in my investigation.

If my understanding is correct, would you prefer that I open a repro PR?
Attachment: Screenshot_2026-07-30_at_1.59.30_AM.png — https://community.tscircuit.com/media/1532123285700219051

## Seve — 2026-07-29T21:29:47.522000+00:00

yea it might be easier for me to understand if you have a core repro

## Arhan — 2026-07-29T21:52:46.368000+00:00

kk, working on it

## Arhan — 2026-07-29T22:23:19.339000+00:00

<@757706909351411845> I realized the previous repro was in the wrong repo. Sorry about the confusion. I've recreated it in @tscircuit/core: https://github.com/tscircuit/core/pull/2923  Could you take a look when you have a chance?

## Arhan — 2026-07-29T22:37:54.933000+00:00

<@757706909351411845> I traced the metadata-only approach. It enters the intended port-aware DRC path, but the geometry validation still runs and fails because one endpoint evaluates 5.55e-17 mm outside the pad boundary.

That's why I introduced the coordinate adjustment. If the preferred architectural fix is instead to make `isPointInPad` tolerant to floating-point boundary cases, I'm happy to move the fix there instead.

## Sapphire — 2026-07-29T22:37:56.414000+00:00

<:warning:892823499205406760> Please avoid using excessive mentions, as it creates unnecessary notifications and disrupts others — use mentions only when truly needed to keep the discussion focused and respectful; repeated misuse may lead to moderation action.

## Seve — 2026-07-29T22:38:21.815000+00:00

sure

## Seve — 2026-07-29T22:38:35.905000+00:00

that seems fine

## Arhan — 2026-07-29T22:41:03.895000+00:00

Just to confirm before I update the PR: would you prefer I keep the current @tscircuit/core fix, or would you rather I move the fix into @tscircuit/checks?

## Sapphire — 2026-07-29T22:44:55.727000+00:00

<:warning:892823499205406760> Please avoid using excessive mentions, as it creates unnecessary notifications and disrupts others — use mentions only when truly needed to keep the discussion focused and respectful; repeated misuse may lead to moderation action.

## Sapphire — 2026-07-30T16:57:36.279000+00:00

<:warning:892823499205406760> Please avoid using excessive mentions, as it creates unnecessary notifications and disrupts others — use mentions only when truly needed to keep the discussion focused and respectful; repeated misuse may lead to moderation action.

## Arhan — 2026-07-30T21:53:02.449000+00:00

<@757706909351411845>

## Seve — 2026-07-30T21:54:58.788000+00:00

seems like a checks bug iiuc