v3.10.0

OpenSpectrum v3.10.0 — GHz frequency readout fixed; one fixed render resolution

Two changes: a display-string bug that misread frequencies at and above 1 GHz, and a switch to a single fixed render resolution that removes a pile of window-size-dependent inconsistencies. No change to tuning, capture, or the locked 30 fps at every FFT size. Upgrading is a drop-in replacement for v3.9.1.

WHAT SHIPPED

Frequencies at and above 1 GHz read correctly in the status bar

The status FREQ field built its fractional digits without zero-padding, so 1_090_000_000 Hz printed "1.90 GHz" and 1_009_000_000 Hz printed "1.9 GHz" instead of 1.090 / 1.009 GHz. The tuner was never affected — the frequency axis and the cursor readout, which read the raw Hz, were always right; only the formatted string was wrong. The same latent bug sat in the MHz and kHz branches (100.009 MHz would have printed "100.9 MHz").

That string also stamps .iq capture metadata and the PNG spectrogram JSON "*_formatted" field, so captures taken on GHz tuning before this release carry the wrong label. The numeric center_freq_hz in those files was always correct, so anything that reads the number rather than the label is unaffected.

One fixed 1280x720 render canvas; --width/--height removed

The render canvas was CLI-configurable (default 1050x576), and every buffer — textures, both displays, the waterfall history, the instrument panel — was sized from it. So window size silently drove things it should not have: a taller window bought more waterfall history and a larger marker gutter, and an explicit --width/--height at 1080p or 1440p rendered natively at 2-3x the raster, GPU, and
RAM cost.

The scene now renders at a fixed 1280x720 and the GPU point-samples it up to any window or display — resize and maximize freely, at the same render cost, exactly as the maximize path already did. Waterfall history depth (~12 s at 30 fps), panel layout, and per-frame render cost are now identical on a 1366x768 laptop and a 4K panel; only the final upscale blit grows, which the larger display's GPU
absorbs.

720p over 1080p is deliberate: 1.5x the pixels of the old canvas rather than 3.4x, it upscales cleanly on 1080p/1440p/4K, it only barely downscales on the sub-1080p laptops still in the field, and 1080p would buy horizontal resolution the drawn trace's per-column averaging discards anyway.

-w/--width and -H/--height are gone

Removed, not deprecated. The canvas is fixed and the window is freely resizable, so there was nothing left for them to do. A script passing them will now stop on an unknown-argument error rather than silently changing the render cost.

ALSO IN THIS RELEASE

• README.md — display-size options removed; documents the fixed 1280x720 render and that the GPU scales it to any window.
• TODO.md — "re-render at native resolution on maximize" moved to Declined: fixed-canvas upscale is now the chosen design, for the consistency and the fixed render cost above.
• docs/TECHNICAL.md — the performance numbers are unchanged and still labelled with the 1050x576 canvas they were measured on; cpu there is DSP-side and barely moves with canvas size (raster lives in render_build/present).

Release binary ~363 KB, Linux release build.