The board, the capture and the verdict in one window
Left: every net in the board graph, coloured by what YProbe knows about it. Centre: the capture. Right: each parameter judged against the expected signal, a signal-health score, and the ranked fault hypotheses. The strip under the toolbar is the assistant's next move — “Probe c:EN/sync_5V4 next (4 still open).”
The dialog is YProbe arguing with the expectation rather than the board: 2 MHz was asked of a node whose RC corner sits near 25 kHz (≈ 102 kΩ source, ~62 pF of probe and load). A clean square is not physically realizable there, so a low-amplitude capture is physics — not a defect — and you get told before it becomes a false FAIL.
And that warning is completely deterministic. Nothing was asked of a model: the source impedance comes out of the resistor network in your netlist, the capacitance is the probe and load, and the corner is arithmetic. Same board, same expectation, same answer, every single time.
- Nets colour-coded by state — the tree footer reads 2254 nets · 1 bad · 3 suspicious
- Every parameter judged on its own: DC voltage, Vmax, Vmin — expected against measured
- Hypotheses re-ranked after each measurement — top one here at 44 %
- Scope, channel, V/div, time-base and trigger driven from the same toolbar
That check is one of a family. Before any capture is judged, YProbe runs every physical-feasibility objection it can derive from your netlist's own topology — resistor networks, filters, dividers, pull-ups, reset and crystal networks, op-amp stages, series rectifiers, AC coupling. Each is computed, not inferred:
The same holds for most of what this page shows: the PASS/FAIL comparison, the probe-contact classifier, the protocol decode, the startup rise/overshoot/settle limits, the monitor's threshold crossings, the aliasing cross-check against the scope's own frequency reading — all of it is arithmetic over samples, topology and instrument readings. The AI proposes and ranks explanations; it never gets to decide what the board did.