The live panel showed ~80 Hz on a 100 Hz collection. Its clock started when
the receiver had applied and forwarded the START message, so the START ->
first image gap counted as collection time; the images were stamped when a
forward thread dequeued them, and the last image only after END and the
thread joins; and N images were divided by a span holding N-1 intervals.
- ImagePullerOutput carries `received`, a steady_clock time set by the TCP
and ZeroMQ pullers as the message comes off the socket, before it is
queued or deserialised (TestImagePuller stamps it on Put when unset).
- RugnuxLiveStatus takes those times: START's for its origin, each image's
for the first and last image (min/max, as forward threads report out of
order). last_image_s is the last data image's puller time.
- Zero of every reported time (elapsed_s, steps' started_s, probe_s,
last_image_s, cut_s) is now the FIRST IMAGE, as the frontend already
said; before the first image arrives "now" is 0 and earlier steps are
negative. The START -> first image time is recorded on its own as
start_to_first_image_s (snapshot, OpenAPI rugnux_live_status, regenerated
C++ model and frontend client, OpenAPIConvert).
- The frontend rate is (images_received - 1) / (last - first image); the
panel headers show "START -> first image X.X s".
- The broker logs "rugnux live: START -> first image ..., N images in T s
from the first to the last (R Hz)"; "done X s after the last image" and
last_image_to_written_s run from the puller time of the last image.
The deadline timer is unchanged (it still starts once the forward threads
have joined). No analysis result changes.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PXc1zD1yxHqaR1DGdCTHL4
leonarski_fandClaude Opus 5.5
7349832309