Spectrum dominates the server↔client connection, and all three things that
govern its cost were working against a poor link.
**It was polled, one round trip per frame.** The client asked for a frame every
50 ms on a dedicated connection and waited for the reply, so the frame rate was
capped at 1/RTT — on a 200 ms link, five frames a second no matter what was
configured. Add SubscribeSpectrum alongside the existing SubscribeMeter: the
server pushes frames from a per-rig broadcast that rig_task fills only while
somebody is subscribed. A server too old to know the command answers with an
error and leaves the connection usable, so the client falls back to polling on
the same connection without reconnecting.
**Bins were JSON floats.** 1024 bins spelled out as decimal text is around
10 KB a frame, ~200 KB/s at full rate — while the very next hop, client to
browser, already sends the same information as base64 i8 in about 1.4 KB. Bins
now travel base64-encoded whole dBFS, the resolution the display draws at
anyway. Decoding still accepts the old array form.
**Nothing was tunable.** [sdr].spectrum_fft_size and [sdr].spectrum_interval_ms
replace the compile-time FFT size and cadence; [[remotes]].spectrum_interval_ms
lets the client ask for less. 512 bins at 5 frames/s is roughly 3.5 KB/s
against roughly 200 KB/s before.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SyX26FCpMQxiBoC7r5K1A7
Signed-off-by: Stan Grams <sjg@haxx.space>
A receiver spreads by being linked to, and there was nothing to link to:
the routes carried the tab and nothing else, so "listen to this" could
only ever mean a screenshot and a frequency typed out in a message.
The query string now carries the dial -- rig, frequency, mode and
bandwidth -- in both directions. Opening a link selects the rig, sets
the mode, tunes, then applies the bandwidth: a mode change brings its
own default bandwidth with it, so an explicit bw has to land after it.
Frequencies are read the way someone writes them by hand (7074k,
14.074M) and written back as whole Hz, so what comes out of the address
bar is the same link in canonical form.
After that the address bar keeps up with the dial, which is what makes
it copyable at any moment rather than only at load. It is rewritten
with replaceState -- tuning is not navigation, and a swept dial would
otherwise bury the back button. A link button in the top bar copies
the current link; it folds into the overflow menu when the bar is tight.
Applying a link changes the radio, so an rx session says so instead of
failing control calls one at a time. A tab listening to a virtual
channel leaves the address alone rather than publishing a frequency the
rig is not on, and bw is skipped in both directions on rigs without
filter control, which would only refuse it.
The fixture pinned every state frame to 100 MHz plus jitter to keep
frames distinct, so no test could observe tuning at all. The jitter
moves to the S-meter and the fixture echoes set_freq/set_mode/
set_bandwidth, as it already did for squelch.
Signed-off-by: Stan Grams <sjg@haxx.space>
sjgandClaude Opus 5