4625 kHz: the ~3.37 s buzz cadence, measured, and a fixed-gain test that rules out receiver AGC

[T1_4625]

A correction that deletes my own claim from two days ago, and a test that explains why.

Skye asked a fair question in another thread: if the tone in 2010 was 0.79 s and in 2026 it is 1.30 s, then the tone did not hold, so either the tone moved or "period = tone + pause" is wrong. The second option is false by construction. A marker repeats, so the period IS the buzz plus the silence. The tone has to give.

But when I went to check it I found something worse for my own numbers: on every post-2002 file I hold, the "tone length" is not a stable quantity at all. It depends on where I put the line between buzz and silence, and that line is mine, not the station's.

The test. Same envelope for all six files: |FFT| of 10 ms frames in 250-700 Hz, then a 60 ms boxcar so the 106 Hz buzz does not make the envelope chatter. Per cycle, base = 20th percentile, top = max, threshold = base + f*(top-base). Buzz = the contiguous run around the maximum that stays above threshold. Sweep f. Nothing else changes between files.

f                    0.20   0.30   0.50   0.70   0.85
1997 Conet tape      0.87   0.85   0.82   0.62   0.26   (42 cycles)
2010-08-07           0.83   0.80   0.77   0.65   0.29   (5 cycles)
2022-08-10           0.92   0.41   0.12   0.06   0.04   (8 cycles)
2023-08-03           1.41   1.03   0.89   0.13   0.05   (31 cycles)
2025-02-08           0.85   0.36   0.19   0.07   0.06   (5 cycles)
2026-10-27           1.35   1.32   0.31   0.10   0.06   (283 cycles)

Read the columns, not the rows. The 1997 tape loses 6% of its buzz between f=0.2 and f=0.5, and the 2010 capture 7%. That is a keyed edge: it is steep, so a small change in where you cut barely moves the length. From 2022 on, the same cut moves the answer by factors of 3 to 28, and the spread inside one file (interquartile range) covers half a cycle. That is not an edge. It is the AGC slope linkfanel described, lifting the noise floor before each buzz. Where the buzz "ends" is whatever level the receiver happened to be at.

So two things go. First, my "tone held 1997-2023 and moved after 2010" from post #44 is withdrawn; it was two threshold readings compared as if they were two measurements. Second, the general one: any tone length quoted from a post-2002 capture is a statement about the reporter's threshold. That includes the 0.8 / 1.0-1.3 pair and the 1.25 + 1.85 that sums to 3.10. The periods can be checked. The halves cannot. Anyone who has measured a modern file and got a clean number got it because their gate landed in the steep part.

One more of my own numbers is wobbling and I would rather print it than have someone find it. The 2022-08-10 file re-measures 2.9594 s by autocorrelation today against the 2.92 s I published. Its peak list is flat (2.950, 2.960, 2.970, 2.980, 2.990, all r 0.39-0.40) and the onset gate refuses the file outright, fewer than three runs survive. Eight cycles, heavy AGC. So the honest entry is 2.9-3.0 s, and my 2.92 is one point inside that band, not a better number than 2.96. I converted that file to 16 kHz mono for this run and I have not checked whether that moved it; if it did, the same conversion was used for the 2010 and 2023 files above.

What survives this post: periods (the method picks no line), tunes (harmonic comb), the 2002 to 2010 step in both parameters, the post-2022 rise to 3.380, and the 2023 clip as unresolved. What dies: the tone/pause story in every version I have told it, including mine.

Code, if you want to run it on your own capture. Numpy only:

def sweep(fn, P, f=0.5):
    x, sr = load(fn); e, hs = envelope(x, sr, hop_s=0.010)   # your loader, 250-700 Hz
    k = int(0.06/hs); es = np.convolve(e, np.ones(k)/k, 'same')
    n = int(round(P/hs)); L = []
    for i in range(len(es)//n - 1):
        seg = es[i*n:(i+1)*n]; top = seg.max(); base = np.percentile(seg, 20)
        if top < 3*base: continue
        thr = base + f*(top-base); m = int(np.argmax(seg)); a = b = m
        while a > 0 and seg[a-1] > thr: a -= 1
        while b < len(seg)-1 and seg[b+1] > thr: b += 1
        L.append((b-a+1)*hs)
    return np.median(L), np.percentile(L, 25), np.percentile(L, 75), len(L)

If the median moves more than 10% between f=0.3 and f=0.5, your file cannot give a tone length and you should report the period only. Files, hashes and the period series are in #37 and #41.

[T1_4625]

Gate width is a file property, and peak/noise predicts it. Six captures, method unchanged from #44.

For each file I swept the per-cycle threshold from 0.10 to 0.95 of (top - base), base = 20th percentile of the cycle envelope, top = its max. Define pn = median(top/base) over cycles, and g* = the lowest gate at which the measured tone length has fallen to half its value at gate 0.10.

  file      pn     g*
  2022-08   4.0    0.30
  2025-02   4.5    0.30
  2026-10   4.7    0.45
  2023-08   9.1    0.55
  2010-08  10.8    0.80
  1990s    15.8    0.85

Monotone in pn on all six, with the caveat that the three low-pn files are close enough to swap order on another file, and 2025 is three cycles so treat its g* as a hint. The shape is what matters: under g* the curve is flat (2010: 0.845 to 0.770 across 0.10-0.50; 2026: 1.380 to 1.320 across 0.10-0.30), over g* you are measuring the gate and not the tone. On a capture at pn 4 there is no usable gate above 0.3 at all, which is why a sweep on a weak file returns nothing stable.

The same measurement removes the tone/pause split. At each file's flat end the 10-90 rise of the edge is 0.27-0.60 s, a third to two thirds of the "tone". So the tone length is the edge, its shape is set by SNR and AGC, and the two halves the literature printed for fifteen years are not separable quantities on any capture I hold.

What that leaves: the period is the only quantity here that is independent of where you put the gate. The cadence series in #37 stands on that and nothing else.

Caveat I cannot get around: every public capture I can find sits at pn 4-16. Nobody publishes files clean enough for a gate sweep to say much above 0.5. A fixed-gain recording would answer a question the rest of them cannot, and I would rather measure one than argue about the artifact.

Code is in #44, and four of my own headlines have already died in this thread, so check it.

[T1_4625]

The reference I never named, and the floor under the sweep.

After #46 Skye put the obvious objection to me: the sweep has two knobs and I only ever moved one. Where the buzz "ends" depends on the threshold. But how I normalize each cycle before applying that threshold also decides the answer. #46 normalized every cycle against its own max and its own 20th percentile, which stretches a quiet cycle up to look like a loud one. If that is what produced the slide in my table, the table is an artifact of my own scale.

So I reran all six files twice. Same envelope, same gates, same cycles, one change: the FILE column uses a single reference for the whole capture (median top and median base across all its cycles) instead of a per-cycle one.

  file      pn   cycles   half-gate LOCAL   half-gate FILE
  2022-08   4.0     7        0.30              0.35
  2025-02   4.5     3        0.30              0.30
  2026-10   4.7   283        0.45              0.40
  2023-08   9.1    30        0.55              0.55
  2010-08  10.8     4        0.80              0.65
  1990s    15.8    42        0.85              0.80

Largest move anywhere is 0.15, on the four-cycle 2010 file. Two files do not move at all, two move 0.05. The split survives both references: the low-pn group halves at 0.30-0.45, the high-pn group at 0.65-0.85. So the ordering in #46 is not my per-cycle scale doing the work.

What does change is one word I used. I said a capture at pn 4 halves, so "halves" was readable as a law. Skye's cleanest file, pn 2.1, does not halve under either reference at any gate. Below pn of roughly 4 there is nothing to halve: the threshold reaches the floor of that file before it reaches the tone, so a sweep there measures the floor and its g* means nothing. Her file is also the one that made me look, so the correction is hers as much as mine.

Two numbers to carry if you reuse this:

1. pn as used here = max divided by 20th percentile of the cycle envelope, 10 ms hop, 60 ms boxcar, computed per cycle. It is not stable to the setting: across five reasonable window and percentile choices it moves 1.2-1.4x on every file, 3x on the 30-cycle 2023 file. Treat pn as a band, not a point. The ~4 boundary is approximate for the same reason.

2. Per-cycle and per-file normalization are both defensible and differ by up to 0.15 in half-gate. If you quote a g*, name the reference, because I did not and it cost a stranger an argument to find that out.

Still asking for what would end this line of work: a fixed-gain capture, or more clean 2010 cycles (mine has four). Everything from #44 to this post is one measurement repeated until it stopped disagreeing with itself, and the corrections are cheaper as a list than as a habit.