# How we measured, 2026-10-16 Three results, all measured with `rate_kit.py` on our bench on 2026-10-16, each counted on AUX OUT by a second scope (`--method aux-external`). Every window's raw readings are in `data/2026-10-16/windows.csv`; each run's full report, with every SCPI line and its time, is in `data/2026-10-16//rate-kit.json`. Times are UTC. ## The units and the wiring | role | model | `*IDN?` firmware field | wiring | |---|---|---|---| | unit under test ("stock unit") | MHO934 | Rigol stock, 00.01.00 | G2 into CH1; AUX OUT into the counting scope's CH3 | | counting scope ("Kiszka's mod v0.1.5 unit") | MHO934 | Kiszka's mod v0.1.5 (`NK TECHNOLOGIES,MHO934,...,00.01.03`) | CH3 from the stock unit's AUX OUT | Short BNC cables; inputs at 1 MOhm, DC, probe x1, no bandwidth limit. Only the counting scope's counter is used, in totalize, on its CH3 (shown, set up while shown, trigger level 1.5 V, sweep AUTO). ## The scene and the count On the stock unit, right after `*RST` (MHO900 Programming Guide, 3.12.2: "Restores the instrument to its factory default settings"), the kit's `--scene minimal`: G2 a 10 MHz square from 0 to 3 V, CH1 at 1 V/div and -1.5 V offset, 20 ns/div, edge trigger on CH1, rising, 1.5 V, NORMal sweep. Depths 1k, 10k and AUTO (AUTO read back 800 points with CH1 alone, 400 with a second input digitised). Each window: `:COUNter:TOTalize:CLEar` on the counting scope, 3 s, `:COUNter:CURRent?` (count0, t0 = when the answer arrived), ten times 1 s then `:TRIGger:STATus?` to the stock unit, `:COUNter:CURRent?` again (count1, t1). rate = (count1 - count0) / (t1 - t0) For the first window of run J-A: (324,000 - 63,000) / 10.3722 s = 25,163 wfm/s. ## 1. The clean stock unit, CH1 alone: about 25,000 wfm/s Three runs, each after its own `*RST`. `:ACQuire:SRATe?` read 4 GSa/s in every window. | run (time) | depth | wfm/s, each 10 s window | |---|---|---| | G (20:19:45-20:22:15) | as the reset left it (10k) | 25,754 / 24,393 | | | 1k | 24,370 / 25,537 | | | 10k | 24,942 / 25,885 | | | AUTO | 25,725 / 24,998 | | H (20:39:00-20:41:28) | as the reset left it (10k) | 24,678 / 25,118 | | | 1k | 26,057 / 24,873 | | | 10k | 25,667 / 24,895 | | | AUTO | 24,881 / 26,069 | | J-A (21:18:17-21:20:45) | 1k | 25,163 / 24,013 / 26,077 | | | 10k | 25,411 / 25,262 / 27,265 | | | AUTO | 24,838 / 25,897 / 24,323 | All 25 windows: mean 25,284, from 24,013 to 27,265 wfm/s. The depth made no difference we can tell apart from the window-to-window spread (about 10 %). ## 2. Counting on the unit's own input: -48 % hidden, -64 % shown Run J, the same scene, each part after its own `*RST`. In J-B and J-C the stock unit's own counter also ran, in totalize, on its empty CH4 (`--load-counter-input 4`), set up while shown, then hidden (J-B) or left shown (J-C). It was not read; the count is still the counting scope's. | depth | J-A: CH1 alone (21:18:17-21:20:45) | J-B: own counter on CH4, hidden (21:21:35-21:23:44) | J-C: own counter on CH4, shown (21:24:33-21:26:42) | |---|---|---|---| | `:ACQuire:SRATe?` | 4 GSa/s | 2 GSa/s | 2 GSa/s | | 1k | 25,163 / 24,013 / 26,077 | 12,875 / 13,207 / 13,026 | 8,918 / 9,542 / 8,939 | | 10k | 25,411 / 25,262 / 27,265 | 13,298 / 12,969 / 13,264 | 9,131 / 8,737 / 9,412 | | AUTO | 24,838 / 25,897 / 24,323 | 13,804 / 13,248 / 12,816 | 9,042 / 9,166 / 8,651 | | mean of the 9 windows | **25,361** | **13,167** (-48 %) | **9,060** (-64 %) | This is what `--method aux-self` measures against: a counter on the unit's own input makes it digitise that input too, so it reports a lower bound, not the one-channel rate. ## 3. One measurement item on the screen: -21 % Run G, after the same `*RST`, at 1k. The second part differs only in one `:MEASure:ITEM? VPP,CHANnel1` sent before counting (it answered 3.1039E+00, i.e. 3.10 V), which leaves a VPP measurement running on the screen. | 1k, run G | wfm/s, each 10 s window | mean | |---|---|---| | no measurement item (20:20:27-20:20:51) | 24,370 / 25,537 | 24,954 | | one VPP item on the screen (20:23:06-20:23:30) | 19,490 / 19,875 | **19,683** (-21 %) | ## What is wrong or uncertain - **The count moves in steps.** 75 of the 90 counter readings are multiples of 500. A step of 500 at each end of a window of about 260,000 counts is up to about 0.4 %. - **The window is timed by the PC.** t0 and t1 are when the answers reached the PC, 22-33 ms after each query was sent (median 24 ms over the 90 reads); any difference in that delay between the two reads goes into the 10.37 s window. - **Two or three windows per setting.** The windows of one setting differ by up to about 10 %; we have not found why. - **A second count ran in some windows.** In runs G (first part), H and J-A, a second, independent count was read on the stock unit itself during the same windows. It is not part of this kit and its readings are not published here. If it cost the unit anything, those figures are low, and the costs in sections 2 and 3 are, if anything, understated. Run G's VPP part, J-B and J-C ran without it. - **The counting scope ran Kiszka's mod.** Its counter counted the stock unit's AUX OUT on a shown, set-up input; we have not compared it with a stock-firmware counter on the same pulses. - **The stock app aborted once** at 21:26:47 (the unit's clock), during the kit's restore after run J-C, as its counter went back to FREQ with a shown, unconnected channel as its source. It started again by itself at 21:27:15. The measurement had finished. The kit now switches the counter off before changing its mode or source. ## Files `data/2026-10-16/` holds, per run, the SCPI part of the kit's report (`rate-kit.json`), and where there is one the `preset` report (`preset.json`), the snapshot taken before anything changed (`snapshot.json`) and the settings read before the reset, after it and after the restore. Values are as recorded. Serial numbers and addresses were replaced by the kit at the time; we also removed the second count named above and the local output paths. `windows.csv` lists every window: run, scene, sample rate, depth read back, t0, count0, t1, count1, seconds, rate.