Arhan - While implementing the SparkFun Qwiic T...
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
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?
yea it might be easier for me to understand if you have a core repro
Arhan
kk, working on it
Arhan
<@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
<@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
<: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
sure
Seve
that seems fine
Arhan
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
<: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
<: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
<@757706909351411845>
Seve
seems like a checks bug iiuc
Want to add to the conversation?
Reply in Discord so your notes stay connected to the source.
