What Cascade does · Scripts & trust

Running it, and trusting the numbers

Running it unattended

Bench time is the scarce resource, so Cascade can run procedures by itself. A script is a short .cscript text file dropped into a folder. The app validates the whole script first, locks the controls, shows an ABORT button and a banner while it runs, and writes the results to a "done" folder. A script reads like this:

view fft; set channels AB; set size 8192; set amplitude -20; set frequency 1000; capture; screenshot site_fft

The safety limits are built in. Scripts use only operations the app already has, so nothing new goes out on the wire. Generator level is capped at +6 dBV. Every script ends with the generator off and the instrument disconnected, and each script states its expected cabling at the top. Chris authorised Claude to run these on the loopback rig unattended ("No overcooking the voltages"). New protocol experiments still go through Chris. Scripts 00 to 10 have run unattended. The FFT and multitone screenshots in this section came from two of them (scripts 09 and 06); the others are Chris's own bench screenshots.

Every run can also be saved with EXPORT CSV, and is auto-exported to a session folder. The CSV header records the instrument state that applied (input, level, ranges, Ch B results), so a file found weeks later still says how it was measured.


How we know the numbers are right

The project's working rule is to suspect the measurement first. When a number disagrees with expectation, check the measuring path before inventing an explanation in the device. That rule exists because it was broken once: a DUT reading 7.4 dB low was explained as cable loss, twice, until Chris objected ("i am pretty suspicious of this cabling taking 7.4dB out of the signal. that doesn't sound right to me."). It was a decode bug, and it cost three sessions.

Checks against something independent of Cascade:

The software also has offline unit tests (123 as of 10-04) that run in about 30 ms. Many are invariant tests: rather than pinning a number, they check a property that must hold. For example, "SINAD must not change when the whole spectrum moves 40 dB." That one would have caught a bug where THD was computed from absolute dBV instead of relative to the fundamental. It hid for months because the test tone sat near 0 dBV, where the error vanishes.

Where it is still unverified or uncertain:

The roadmap lists every feature with its verification status and the evidence behind it.


Where it's going

From the roadmap: