METROLOGY.md §4.3's justification for treating (GPS_TIME, RTP_TIMESNAP) as a sample-precise pair should match ka9q-radio's source. It does not. §4.3 says the two "are both derived from input_sample_index / decimation — they are in the same counter space. No pipeline offset correction is needed." In encode_radio_status() the two are written from different clocks at different instants: GPS_TIME is gps_time_ns() evaluated as the status packet is built (ka9q-radio/src/radio_status.c:718-719), and gps_time_ns() is clock_gettime(CLOCK_TAI) offset to the GPS epoch — the host system clock (ka9q-radio/src/misc.c:546-563) — while RTP_TIMESNAP is chan->output.rtp.timestamp (radio_status.c:859), "the next RTP timestamp to be sent" (src/monitor-display.c:886), advanced by the frame count each time a block is emitted (src/audio.c:49-51, l.177-179) and therefore quantised to the 20 ms block grid plus that emission's lateness. §4.3's own "Prerequisites for authoritative" paragraph already hedges on A-level and RTP_TIMESNAP freshness, so the fix is the counter-space sentence, not the conclusion. A scientist reading §4.3 will attribute a sub-block offset to physics. Includes merged ledger row 46: src/hf_timestd/core/buffer_timing.py's module docstring repeats the same claim verbatim ("Both are in the same counter space (input_sample_index / decimation)", alongside "GPS_TIME is the GPSDO-disciplined ground truth") and must be fixed in the same pass, since hf-timestd's own TIMING-PIPELINE-WIRING.md §2 agrees radiod_clock "= system_time" — fixing METROLOGY.md alone would leave the wrong statement in the module every downstream sidecar reader imports.
Docs page(s) blocked/affected: sigmond/docs/hardware/character.md §Timing-chain caveats, sigmond/docs/scientist/data-and-timing.md
Provenance: docs-gap ledger row 35 (includes merged row 46), HamSCI/sigmond docs/contributor/docs-gap-ledger.md (2026-08 documentation program, Phase 2).
METROLOGY.md§4.3's justification for treating(GPS_TIME, RTP_TIMESNAP)as a sample-precise pair should match ka9q-radio's source. It does not. §4.3 says the two "are both derived frominput_sample_index / decimation— they are in the same counter space. No pipeline offset correction is needed." Inencode_radio_status()the two are written from different clocks at different instants:GPS_TIMEisgps_time_ns()evaluated as the status packet is built (ka9q-radio/src/radio_status.c:718-719), andgps_time_ns()isclock_gettime(CLOCK_TAI)offset to the GPS epoch — the host system clock (ka9q-radio/src/misc.c:546-563) — whileRTP_TIMESNAPischan->output.rtp.timestamp(radio_status.c:859), "the next RTP timestamp to be sent" (src/monitor-display.c:886), advanced by the frame count each time a block is emitted (src/audio.c:49-51, l.177-179) and therefore quantised to the 20 ms block grid plus that emission's lateness. §4.3's own "Prerequisites for authoritative" paragraph already hedges on A-level and RTP_TIMESNAP freshness, so the fix is the counter-space sentence, not the conclusion. A scientist reading §4.3 will attribute a sub-block offset to physics. Includes merged ledger row 46:src/hf_timestd/core/buffer_timing.py's module docstring repeats the same claim verbatim ("Both are in the same counter space (input_sample_index / decimation)", alongside "GPS_TIME is the GPSDO-disciplined ground truth") and must be fixed in the same pass, since hf-timestd's ownTIMING-PIPELINE-WIRING.md§2 agreesradiod_clock"=system_time" — fixing METROLOGY.md alone would leave the wrong statement in the module every downstream sidecar reader imports.Docs page(s) blocked/affected: sigmond/docs/hardware/character.md §Timing-chain caveats, sigmond/docs/scientist/data-and-timing.md
Provenance: docs-gap ledger row 35 (includes merged row 46), HamSCI/sigmond
docs/contributor/docs-gap-ledger.md(2026-08 documentation program, Phase 2).