The docs should say what a channel's RTP timestamp is seeded from, and that it is meaningful only within one channel incarnation. The mechanism is only in the source: ka9q-radio/src/linear.c:88-91 seeds a new channel's counter from radiod uptime — "Tie the RTP timestamps to radiod uptime … reference RTP timestamp 0 to the first radiod block", chan->output.rtp.timestamp = (int32_t)(first_block * (chan->output.samprate / block_rate)) with first_block the master FFT job counter (src/filter.c:397). Nothing in ka9q-radio/docs/ or ka9q-python/docs/RTP_TIMING_SUPPORT.md says so; the latter discusses only the 32-bit wrap and radiod restarts, so a reader can reasonably conclude the counter is a station-wide clock reading. Two consequences a consumer needs: (a) re-creating a channel — which every recorder restart does — starts a new counter space, so two captures hours apart can carry overlapping RTP timestamps labelling completely different UTC; (b) the (int32_t) cast is of a double, so once uptime × sample_rate exceeds INT32_MAX (~49.7 h of radiod uptime at 12 kHz) the conversion pins at 0x80000000 and every new channel starts at exactly 2³¹ — measured on DASI002 2026-08-23 across three ephemeral channels (anchors 2147495888, 2147495888, 2147496128; first packets 2³¹+7.26 s and 2³¹+12.90 s against heartbeats at 7.3 s and 13.0 s; radiod up since 2026-08-15). Documenting the seed, and the pin as a defect, would let a consumer reason about the counter instead of measuring it. Re-homed here because HamSCI/ka9q-radio has issues disabled; the C-side fix is upstream in ka9q-radio, and the doc fix belongs in ka9q-python/docs/RTP_TIMING_SUPPORT.md, which the ledger names as co-owner.
Docs page(s) blocked/affected: sigmond/docs/scientist/data-and-timing.md §Pitfalls
Provenance: docs-gap ledger row 51, HamSCI/sigmond docs/contributor/docs-gap-ledger.md (2026-08 documentation program, Phase 2).
The docs should say what a channel's RTP timestamp is seeded from, and that it is meaningful only within one channel incarnation. The mechanism is only in the source:
ka9q-radio/src/linear.c:88-91seeds a new channel's counter from radiod uptime — "Tie the RTP timestamps to radiod uptime … reference RTP timestamp 0 to the first radiod block",chan->output.rtp.timestamp = (int32_t)(first_block * (chan->output.samprate / block_rate))withfirst_blockthe master FFT job counter (src/filter.c:397). Nothing inka9q-radio/docs/orka9q-python/docs/RTP_TIMING_SUPPORT.mdsays so; the latter discusses only the 32-bit wrap and radiod restarts, so a reader can reasonably conclude the counter is a station-wide clock reading. Two consequences a consumer needs: (a) re-creating a channel — which every recorder restart does — starts a new counter space, so two captures hours apart can carry overlapping RTP timestamps labelling completely different UTC; (b) the(int32_t)cast is of adouble, so onceuptime × sample_rateexceedsINT32_MAX(~49.7 h of radiod uptime at 12 kHz) the conversion pins at0x80000000and every new channel starts at exactly 2³¹ — measured on DASI002 2026-08-23 across three ephemeral channels (anchors 2147495888, 2147495888, 2147496128; first packets 2³¹+7.26 s and 2³¹+12.90 s against heartbeats at 7.3 s and 13.0 s; radiod up since 2026-08-15). Documenting the seed, and the pin as a defect, would let a consumer reason about the counter instead of measuring it. Re-homed here becauseHamSCI/ka9q-radiohas issues disabled; the C-side fix is upstream in ka9q-radio, and the doc fix belongs inka9q-python/docs/RTP_TIMING_SUPPORT.md, which the ledger names as co-owner.Docs page(s) blocked/affected: sigmond/docs/scientist/data-and-timing.md §Pitfalls
Provenance: docs-gap ledger row 51, HamSCI/sigmond
docs/contributor/docs-gap-ledger.md(2026-08 documentation program, Phase 2).