Session story · 2026-10-17

The first non-sine signal Cascade ever made

Session: 2026-10-18 02:37 → 09:10 UTC (2026-10-17 19:37 → 2026-10-18 02:10 PDT; one conversation, the 2522 on the bench throughout, and for the first time a second Claude, on the PC) · a night of testing a week of changes, fixing what the tests found, and then the measurement this project had failed at six times.

Where we started

The previous session ended with a pile of interface changes nobody had run on the instrument, and with a discovery that undid a headline: the "native IMD" decoded from T90 was probably a D/A sine. Chris opened with: "if my memory serves, there have been a number of changes that now need testing so that we can be sure the app is operating correctly. Am i right ? if not, what are the next steps we defined?" The plan on file: test the changes, merge the retired-probe deletion, then run two new APWIN captures, T91 and T92, on the PC.

The question

Is the app actually right after a week of changes, and can it do real IMD?

What happened

The script passed, and still found a bug. The standing regression (script 29) ran unattended and came back RESULT: OK, the FFTs at −20.12 and −20.10 dBV, the multitone 21 of 21 tones. But one capture, an FFT taken after a visit to Multitone, showed the multitone instead of a 1 kHz sine: 21 tones at −40.9 dBV. Logs from 10-10 and 10-11 showed the same thing, so it was old, not new, and had been sitting in a passing script for a week.

Before the fix: an FFT capture taken after visiting Multitone, still playing the multitone. The MORE summary reads "Multitone 21" in orange and INPUT reads "XLR (fixed in arb)"
Before the fix: an FFT capture taken after visiting Multitone, still playing the multitone. The MORE summary reads "Multitone 21" in orange and INPUT reads "XLR (fixed in arb)"
  1. 1 MORE still names the multitone
  2. 2 INPUT locked to the arb's XLR path
  3. 3 21 tones at about −41 dBV, where a −20 dBV sine was asked for

A test that could not fail. The checklist's safety step said: set STOP AT THD to 0.1 % and the sweep must stop. On a clean loopback THD+N is about 0.003 %, so 0.1 % can never trip. Claude caught it before the run and split the step in two: one run that must not trip, one at 0.001 % that must. Chris noticed the numbering before the logic: "why is it called step 5 if it's step 1", and asked for the file to change "since that's the source of truth". Then step 1 ran and Chris still could not judge it: "for test 1, i can't say if it worked. the y axis is in dB, and the fitst measurements are around -77dB." The limit was in % and the graph in dB, with nothing on screen to connect them.

Chris's results column. Chris ran the hand steps and recorded pass/fail in a new column of the checklist. Of four fails, one was the old FFT bug, one was SET REF behaving as built but not as wanted, one was Multitone stuck on the FFT's Log axis with no control to change it. The fourth was a question, and Chris pointed Claude at the evidence: "i think you can find that in the log can't you?" The log answered it: in DUT mode the meter read +1.24 dB high at every level, while GenMon was within 0.03 dB. The raw registers were identical in both modes; a correction constant from August, 1.27 dB, had been made wrong by a September decoding fix. Chris added the caution that keeps the fix honest: "be aware also that in the DUT test setting, there are cables invovled that might have loss. we tested that before i think. genmon is direct, internal wiring nad relay". After removal both modes read 0.0997 Vrms, and THD vs Level's commanded-vs-measured delta went from +1.23 to −0.03 dB.

Fake data on a real instrument. Reading the screenshots, Claude found that every view drew a placeholder curve, and the HISTORY strip showed five runs that had never happened: nothing in the code had ever added a real run to it. The placeholders went; then Chris: "yes implement the history strip". After two recall checks: "both of those pass. that is a great feature".

What SET REF is for. The Frequency Response reference subtracted a whole stored curve, so a flat loopback became a flat zero. Chris said what it should be: "the point of Set Ref to me, is so that we can easily see deviation from a reference point. that is most useful in something like an FFT test, so that one can easily see "this many dB below the fundamental" as a relative instead of an absolute value, when desired. in APWIN it's if you are showing the graph in dBr (reference) and you set the fundamental at 0". Claude built dBr, then got the scale wrong twice; Chris settled it: "the test sets the auto-scale. the result of "set ref" needs to match it."

Harmonics that were noise, and one counted twice. The FFT tiles labelled a noise bin at 1.888 kHz as the second harmonic of a 998 Hz tone. A note from September had recorded the same weakness and refused to fix it without real data, so Claude ran the narrower rule over the September Heathkit captures first: THD moved from 0.01287 to 0.01283 % against APWIN's 0.0127 %, and the old rule turned out to count the 9th and 10th harmonics as the same bin.

Two failures after 75 passes. Late in the evening the multitone failed twice in a row, once silent and once as a single tone near 6 kHz. Every capture since 10-10 had passed, and the code had just changed, so the code was the suspect.

The second failure: the Multitone capture measured one tone near 6 kHz at about −20 dBV, and still reported "21 found" with flatness 64.46 dB
The second failure: the Multitone capture measured one tone near 6 kHz at about −20 dBV, and still reported "21 found" with flatness 64.46 dB
  1. 1 one tone near 6 kHz, not 21
  2. 2 "flatness" 64.46 dB, reported as a result

A power cycle of the 2522, on the same code, brought the multitone straight back: 21 of 21. The cause was earlier: a THD vs Level run in Generator Mon had hung, polling 20,000 times without an answer, and left the instrument in a state that survived reconnecting. That mode was disabled with a stated reason, and THD start-up now stops and says so instead of polling on. Chris drew the line for the rest of the night: "once item 7 is fixed then hopefully we can have a stable and verified build and then can move on to t91 t92".

A retry that did not exist. Claude listed one more loose end, a "multitone retry" that re-enabled a sine. Reading the code showed there was no retry: a stopped capture had turned the generator off, and the next capture reused a waveform the generator was no longer playing. Chris: "do it now. i want this solid before moving on". The fix reloads the waveform after the generator has been off, and the analysis now refuses a capture that is not the multitone instead of reporting "21 found". Checked against every saved multitone capture first: 59 accepted, 5 rejected, all 5 genuinely bad.

After the fix: the same FFT-after-Multitone capture plays a 1 kHz sine again; MORE reads "Sine · BH · Linear"
After the fix: the same FFT-after-Multitone capture plays a 1 kHz sine again; MORE reads "Sine · BH · Linear"
  1. 1 back to Sine
  2. 2 the 1 kHz sine at −20 dBV

The bench moves to the PC. Chris had a new channel: "we now have the Obsidian sync that syncs on PC and on Mac, and we have Claude Code on the PC as well as the Mac." Claude wrote a handoff folder; Chris corrected where the procedures go: "it should copy them to the folder i have been using for these tests and procedures. not to APWIN's folder. APWIN's file and folder structure should remain teh same." and, when asked for that folder: "you should tell claude code on the PC to find that." The PC Claude found it, checked the logs, and wrote a report Claude on the Mac could read; Chris carried the captures across.

T92: real IMD. The capture settled the doubt in one line of APWIN's log: error 11013 only for Wfm 1,3, the D/A sine T90 had used. Real IMD is the analog generator, set by four plain register writes, and the analyzer reads it through the same two registers as THD. T91 answered its own questions: every grounding, impedance and coupling setting reached the hardware, byte-identical on every repeat. Chris: "yes" to a probe. It replayed APWIN's 57,053 commands and read the meter: reference level 17,521 against APWIN's 17,520, raw residual 2.815e-3 % against 2.77e-3 %. After six silent attempts at non-sine modes, the first one worked.

The turns

  1. The script passing was not the app being right: a week-old bug sat inside a green run.
  2. "Same setup, sudden failure" was the instrument, not the code; a power cycle on the same build said so.
  3. T90's IMD was a sine; T92's is real, and Cascade can make it.

Beliefs that changed

BeforeAfterWhat changed it
Script 29 passing means the views are rightIt ran a capture that measured the wrong signal for a weekReading r06, not the verdict
DUT levels need +1.27 dBThat correction became a +1.24 dB error after September's decode fixIdentical raw registers in both modes
The HISTORY strip showed past runsIt only ever showed five invented onesReading MockData.demoHistory
New code broke the multitoneA hung THD run had left the 2522 in a bad stateA power cycle on the same build
A "retry" re-enabled the sineThere was no retry; a reused waveform wasReading the capture path
T90 captured IMDT90 was a D/A sine; real IMD works from CascadeT92's error log and the probe

What we learned about the instrument

What we learned about working together

Evidence

Where we ended

A stable build, verified by script 29 on the 2522, with every fix of the night checked on the instrument. Real analog IMD works from Cascade through a 57,053-command replay. Next: the other IMD types, a scale factor calibrated against a device with real distortion, and a smaller replay, before an IMD view. Chris: "time for a break. i will disconnect from the 2522. please commit and push any code. and record lessons from today".