Session story · 2026-09-12-b
Session: 2026-09-12, 16:58 → 20:59 UTC (transcript 330e8a64, bench then offline) · Procedures: T82–T84, T87 written · Shipped: FFT averaging, Phase 0 blob split
The 2522 had cleared. The night before had ended with the unit wedged, T82 written but unrun, and Claude's verdict that the Fast vs High Accuracy theory was dead because no mode write appeared in the self-check capture.
The working belief was: the frequency error is in our measurement path, not a generator mode.
Chris opened with: "can you give a summary of last night's work, and a list of next steps based on it?"
What bytes set Fast/High Accuracy, the analyzer lowpass and InputFormat? And, as the session went on, can Cascade stop depending on AP's code?
T82, and a retraction. The first run hit "Method or property not found" on AP.Anlr.FreqA. Claude audited every AP.* reference, found its own audit had matched FreqA as a substring of FreqATrig, and re-ran it with word boundaries. With the right property, the log settled the frequency question outright: Fast read 998.5256 Hz (−1474 ppm), High Accuracy read 999.8376 Hz (−162 ppm). Claude retracted the previous night's verdict. The reference had already said the mode change takes effect at the next frequency command, so the absence of a write proved nothing. The analyzer lowpass decoded cleanly to one register, module 0x01 register 0x04. InputFormat was located across several DSP writes but not safe to implement yet.
AP's test library. Chris copied APWIN's pre-made tests into docs/apwin-tests. A-A Multitone.apb was plain text and showed one Sweep.Start and four Sweep.Reprocess calls. A test file named its waveform, 65kMulTon33+6.ags. Claude tried diffing two .at2c binaries to extract InputFormat for free; 1283 bytes differed across 342 clusters, and it reported that as a dead end.
T83 and T84. Chris copied the waveform library and the whole S2Cascade test folder, and ran both captures. T83's 2-D grid separated the sub-registers: 0x34 tracks transform length only, 0x3A, 0x3D and 0x3B track InputFormat only. Claude's marker formula collided above 32,400 Hz, so three cells shared a marker; the order was recoverable. The .ags multitone decoded on the third try to 39 tones on exact 4 Hz bins, 33 common to both channels and 6 private to each. In the next sitting T84's ten downloads were byte-identical to the file's two channels, and they showed Claude's channel offset had been wrong by three bytes. A spectrum is not sensitive to a one-sample shift, so the tone analysis had not validated the offset; only the wire bytes did.
The Dunn suite. "go through the Dunn suite next, because maybe more research will lead to new ideas for the implementations" Every noise procedure power-averaged four FFTs. Cascade averaged none, and AppState.fftAverages had been declared since August and used nowhere. Chris: "yes go ahead with that. and write up a way to test and verify that it (1) was a good idea. we may need to roll back if it didn't work well". Claude implemented averaging in the power domain, extended sizes to 16384 and 32768, and wrote the verification before any run. Its key criterion: spread must fall and the mean must not move.
The bench queue. Chris queued "what is the procedure called? is it T88 or something?" Claude proposed V-numbers for Mac-side checks, and Chris asked for a document: "there should be a document that outlines the series of things to do when we are back at the unit." That became docs/BENCH_QUEUE.md. Reading the abort-limit code, Claude found it retreated to levels.first and changed it to levels.min(). Its note said the limit had never fired on a real load. "i did test it on a small RIAA inverse filter, and it cut when it found the stated limit. Best to test it on something else though." The record was corrected.
Tables, library, FASTTEST. All 47 .ads sweep tables decoded once a header-dependent offset was found from the one outlier. The library survey turned up a level ladder (Sine400-*dB) and showed the 48k distortion files were the Hd1k files under another name. It also exposed a slice edit that had broken read_agm. FASTTEST's reprocess modes turned out to be different reads of one acquisition at bin address Hz × 128, the same encoding Cascade already used. Multitone.swift followed, and its crosstalk test failed first: measuring at the -Xtlk.ads midpoint reported 0.0 dB of crosstalk on a perfect stimulus. Claude then wrote T87 to capture the one missing register, arb mode.
AP's code in the bundle. "the blobs are potentially Audio Precision IP, so they could not be distributed with it. Can you think about this, and write a plan for making it so that the software is not dependent on those blobs?" Claude found 40 opcode-0x03 packets of 3098 bytes inside the FFT blob, 151 KB at 7.15 bits/byte: a DSP program image. Chris pasted a Claude project's view that the existing backlog item already fixed it, and added "I don't know that this takes care of all the blobs and AP IP. Combine this with what you just wrote and let me k now what you think". Claude checked §1 and found the earlier breakdown summed to 97.9%. The bulk transfers were 60 packets, 0.049% of the count, and 151,384 bytes, 19.7% of the size. Counting packets had hidden them. A program image cannot be expressed as explicit setup, only re-sent.
Phase 0. Claude split the blobs into .regs.bin files and one shared image, proving byte-exact round-trips before writing anything. It concluded 7 of 14 blobs were unreferenced and moved them out of the bundle. Its new guard, check_no_ap_code.py, first fired on zero-runs. Under those false positives was a real leak: 0x83 continuation packets carrying 12,516 bytes the splitter had missed. Bytes in the app target went from 3,722,074 to 2,144,103, with one copy of AP's image.
Stop changing things. "better to take care of the queue of tests now rather than make any more changes i think." Claude agreed there was more unverified than was comfortable, 41 commits that day, and added V0, "does the app still connect", as the gate for everything.
| Believed | Then | What overturned it |
|---|---|---|
| Fast vs High Acc is dead | Fast −1474 ppm, High Acc −162 ppm | T82 log |
the .ags channel starts at 256 | it starts at 253 | T84 wire bytes |
| Cascade's FFT averaging is a setting | fftAverages was never used | grep, after reading Dunn |
| the abort limit never fired on a load | Chris ran it on the RIAA filter | Chris |
crosstalk is measured at the -Xtlk midpoint | no tone exists there | oracle test reading 0.0 dB |
| replacing the replay removes AP's code | the image is 19.7% of bytes | counting bytes, not packets |
| the splitter caught all the image | 0x83 continuations carried 12,516 bytes | the new guard, after its false positives |
| 7 of 14 blobs are unreferenced | (overturned next sitting: 11 referenced) | V6 bench run |
8A 01 04, 03/01/00 = 22 kHz / 80 kHz / >500 kHz.docs/T82_RegisterUnknowns_v2.apb, T83, T84_multitone.pcapng, docs/T87_GenArbMode_v1.apbdocs/apwin-tests/, docs/Waveform/, docs/S2Cascade/docs/dunn_suite_findings.md, docs/V1_verify_fft_averaging.md, V1_verify_fft_averaging.py, docs/BENCH_QUEUE.md, docs/plan_blob_independence.mdsplit_blobs.py, check_no_ap_code.py, reference/apib_blobs_original/, Multitone.swiftThe register unknowns are mostly decoded, AP's file formats read, multitone analysis built, and AP's image confined to one file. Nothing new had touched hardware. Open: the whole bench queue, gated by V0, with T87 (arb mode) and V6 (does the DSP image need loading?) as the high-value items.