docs/RTP_TIMING_SUPPORT.md should not promise more precision than the (GPS_TIME, RTP_TIMESNAP) pair can carry (the client-side mirror of the hf-timestd METROLOGY §4.3 issue). It says the two fields "let you convert any RTP timestamp in a packet header into a sample-accurate Unix wallclock time" (l.5) and defines RTP_TIMESNAP as "the RTP timestamp value at that exact GPS time" (l.24). In ka9q-radio they are not co-sampled: GPS_TIME is gps_time_ns() (the host CLOCK_TAI) read as the status packet is built (src/radio_status.c:718-719, src/misc.c:546-563), while RTP_TIMESNAP is the channel's next-to-send RTP timestamp (src/radio_status.c:859, src/monitor-display.c:886), advanced per emitted block (src/audio.c:49-51) — so the pair is block-grid plus emission lateness. The library's own 3.19.0 release notes measure the consequence and say so: the pair "jitters ~0.45 s and occasionally tears between ~450 ms snapshots" (CHANGELOG.md l.238-239), which is why per-update step detection was removed. The doc also still names the deprecated rtp_to_wallclock() rather than rtp_to_utc() (ka9q/rtp_recorder.py:128).
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 37, HamSCI/sigmond docs/contributor/docs-gap-ledger.md (2026-08 documentation program, Phase 2).
Related: #4
docs/RTP_TIMING_SUPPORT.mdshould not promise more precision than the (GPS_TIME, RTP_TIMESNAP) pair can carry (the client-side mirror of the hf-timestd METROLOGY §4.3 issue). It says the two fields "let you convert any RTP timestamp in a packet header into a sample-accurate Unix wallclock time" (l.5) and definesRTP_TIMESNAPas "the RTP timestamp value at that exact GPS time" (l.24). In ka9q-radio they are not co-sampled:GPS_TIMEisgps_time_ns()(the hostCLOCK_TAI) read as the status packet is built (src/radio_status.c:718-719,src/misc.c:546-563), whileRTP_TIMESNAPis the channel's next-to-send RTP timestamp (src/radio_status.c:859,src/monitor-display.c:886), advanced per emitted block (src/audio.c:49-51) — so the pair is block-grid plus emission lateness. The library's own 3.19.0 release notes measure the consequence and say so: the pair "jitters ~0.45 s and occasionally tears between ~450 ms snapshots" (CHANGELOG.mdl.238-239), which is why per-update step detection was removed. The doc also still names the deprecatedrtp_to_wallclock()rather thanrtp_to_utc()(ka9q/rtp_recorder.py:128).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 37, HamSCI/sigmond
docs/contributor/docs-gap-ledger.md(2026-08 documentation program, Phase 2).Related: #4