Session story · 2026-10-03 → 10-04 · pilot

The generator was never silent

A belief about a missing write turned out to be a busy DSP. Then arb played our own multitone, Chris handed the bench over to scripts, and running it unattended found three regressions in one evening.

one conversation, 3 sittings findings 25–34 11 bench scripts

Where we started

The night before had ended on a high and a correction. Native IMD worked. Arb had played once, at 1368 Hz, but on a stack of state: T89's session, one reload of apib_fft_full, and four replays of the arb window. It hadn't played on the clean state that was claimed. With the reload suppressed, the generator went silent. The working belief was that apib_fft_full did something the generator needed.

what is the next step? we have had a lot of progress and a lot of problems too

What happened

A diff instead of another hypothesis

The two blobs were compared packet by packet. They had the same DSP program, the same final value in every register, and the same last shift-chain load. No write was missing. What differed was where each one stopped. apib_fft_full ends at a clean idle point. T89's blob runs on into an FFT acquisition, replayed open-loop, and leaves the DSP busy. The reload wasn't giving the generator anything; it was resetting a busy DSP.

The procedure, not the goal

The first bench steps described goals. Chris pushed back:

those instructions are nonspecific. please write the steps that are needed

That meant building the probe first, then writing click-level steps against its real button names. The A/B came back 2/2 each way: on apib_fft_full's state arb played 1368 Hz at −20.01 dBV; on T89's state the DSP was busy and the capture timed out.

Our own samples, and a wrong instruction

both of the ARB ON FFT STATE ones errored saying it was neither 1kHz nor 1.368kHz. However, the scope verified 1.368kHz in both cases.

The scope was right. The steps said “Generator Mon, no cable needed”, but the replayed blob routes the analyzer to the physical XLR input, and the loopback was off. A five-signal picker on the next run settled it: our 2 kHz tone played at 2000 Hz, −20.01 dBV.

Multitone, and “that seems low”

The first multitone try failed on a write I had removed. The view switch turns the generator off, and I had dropped the line that turned it back on. With that restored: 21/21 tones, then 38/38, flat to 0.01 dB, with the scope's own FFT showing the comb.

also i see that the tones amplitudes look to be about -50dbV. that seems low. is that matching APWIN?

It wasn't. Our waveform was scaled for the worst case and peaked at −9.6 dBFS, where AP's files peak near −1. Rescaling gained 8.6 dB. A LEVEL control rewrites the values of APWIN's own amplitude writes; at −20 it sends APWIN's exact bytes, and a test checks that.

−40.91 dBV

per tone at LEVEL −20

−30.92 dBV

per tone at LEVEL −10

−20.91 dBV

per tone at LEVEL 0

0.005 dB

Ch B vs Ch A

“Is this what APWIN does?”

A fix forced both channels onto the less sensitive range.

is this what APWIN does or is it something you decided?

It was a decision. APWIN's capture showed it sets each channel's range separately, so the design became per-channel ranges, with a test that puts Ch B one range less sensitive to prove which register belongs to which channel.

Handing over the bench

is this something you are able to script? Even script the interface so that you do get the real behavior of it? you could also screen shot just the cascade app for verification. then that makes this almost unattended

yes, OK to 1. you know the safety protocols and have been staying within them. No overcooking the voltages. this is a good additional step, because it gives us something like the APBASIC procedures.

A script runner was built. It checks every line before anything is sent, caps levels at +6 dBV, always ends with the generator off, and saves logs, CSVs and screenshots for review.

What running it unattended found, in one evening

The range read-back lags a write. One capture read 12.04 dB low, flat and believable. Decoding now uses the written code.
A click on HISTORY cut a capture short, and the runner called it done. Now the controls lock and a capture must prove it completed.
The unit-test host, a second copy of the app, picked up a running script. Now the runner refuses to start inside a test host.
The guard against AP content in the bundle had been failing for days. Nobody had run it.
An intermittent broken capture, 1 in 8, traced to an open-loop poll inside apib_fft_full. Still open.

What scripts could not see

along the way we may have introduced a problem. i just hooked an external oscillator to channel a input and ran an fft. it came back "0 stimulus".

Every scripted run had used a loopback.

i have a bit of time - do you have an organized way of troubleshooting this ?

Step 1 reproduced the failure with a control. Step 2 varied one thing at a time. Eight interleaved captures named the cause: the per-channel change had stopped freezing a third range register, and with an external signal that hangs the FFT. Fixed, verified 3/3. The same captures showed that Generator Mon in the FFT view had never switched the input, probably since August. Fixed and verified too.

Beliefs that changed

Believed	Then	What overturned it
`apib_fft_full` gives the generator something	T89's tail left the DSP busy	packet diff, then A/B 2/2
GenMon needs no cable here	the blob routes the analyzer to XLR	scope read 1368 Hz, analyzer read 0
our tone silences the generator	intermittent, cause not proven	same samples played 4/4 next run
the range read-back is the range	it lags a write	Ch B forced +1 read exactly −6.022 dB
per-channel ranges are a pure win	reg 02 must still be frozen on DUT	external oscillator, interleaved arms
the FFT's GenMon setting routes	it never did after a reload	GenMon captures tracked the oscillator's drift
“there is no story document”	there was, and it was stale	Chris linked it

What we learned

About the instrument

Arb plays on any clean, idle state. Replaying an acquisition open-loop is what broke it.
The generator plays whatever samples it is given, at 65,536 Hz, at the level they imply.
A third range register matters for external signals.

About working together

A guard that nobody runs is not a guard.
Instructions must come from what the blob does, not what the UI shows.
Scripts multiply runs on one rig. A different rig catches what they miss.
Quote only numbers that were measured.

Where it ended

Arb multitone works with a LEVEL control, Ch B matches Ch A, the bundle carries no AP content, and the bench runs from scripts. External and GenMon FFTs are fixed.

Open threads: the intermittent broken capture (proposed: closed-loop replay), a 0.15–0.2 dB GenMon level offset, FFT readouts that use Ch A only, and the crosshair no longer snapping to harmonics.