6 Commits

Include renames

Author	SHA1	Message	Date
sjgandClaude Opus 5	e41c13917d	[fix](trx-frontend-http): put HF APRS on the map, under its own source ... The HF APRS list never plotted anything. Its plugin ships in the map plugin group and its packets carry positions, but nothing ever handed one to the map, so a station heard on 30 m appeared in the panel and nowhere else — and unlike the replay gaps around it, no reload brought it back. Plot it, and not as more VHF APRS. HF is a different band and a different path, and lumping the two together would leave no way to tell them apart or to look at one without the other, so it goes on as a source of its own: its own colour, its own chip in the map's Show filter, its own entry in the source legend, and its own clear. Station entries are keyed by source and callsign rather than callsign alone, so a station worked on both bands keeps a marker for each while the popups, the search text and the tracks still show the callsign as heard. decode-flow feeds an HF beacon alongside the VHF one and checks all of it: both reach the map under their own sources, the Show row offers HF APRS next to APRS, and turning that chip off takes the HF station off the map while the VHF one stays. 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>	2026-08-07 09:05:26 +02:00
sjgandClaude Opus 5	bf3bcc8a84	[fix](trx-frontend-http): show one rig at a time on the digital modes page ... A client connected to several rigs decodes all of them at once, and the decode stream carries every rig's traffic to every browser. The decoder panels listed all of it: a station a background rig copied on another band appeared in the APRS list next to the selected rig's, the vessel counts and the "latest seen" lines counted both, the status lines said "Receiving" because some other rig was, and the CW pane interleaved two rigs into one stream of text that read as neither. The page is about the rig the operator selected — the one whose spectrum is on screen and whose audio is playing — so each panel now shows what that rig heard: rows, counts, latest-seen, status, the live picture a WEFAX or SSTV frame is painting, and the CW pane. Nothing is dropped on the way in. The map is the whole station's view, has its own rig filter, and would empty out if the plugins stopped feeding it, so the histories still hold every rig and the map still plots them. That also means a switch loses nothing: the runtime gained a rerender hook, which the rig switch calls, and switching back brings the other rig's traffic up again. The CW pane is the exception — a running stream of text cannot be unpicked after the fact — so it starts empty on the rig switched to. 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>	2026-08-07 08:11:13 +02:00
sjgandClaude Opus 5	b78c4a4dd4	[feat](trx-rs): make spectrum affordable over a slow link ... 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>	2026-08-07 00:15:50 +02:00
sjgandClaude Opus 5	cfaeb6ee15	[docs](trx-rs): generate the example config and correct the manual ... trx-rs.toml.example was maintained by hand and had fallen well behind: no [[rigs]], no [[remotes]], no [timeouts], no bandplan or decode-history settings, and a [frontends.http].default_rig_id that had been renamed. Generate it from the config structs instead, so a new field shows up the moment it exists, and add a test that fails when the checked-in copy drifts: cargo run -p trx-config --example generate_example Section comments come from a small table; a section without an entry is still emitted, so forgetting a comment can never drop a setting from the example. The manual was wrong about the basics. It listed five config search paths, none of which the loader has ever looked at (the real order is ./trx-rs.toml → XDG → /etc), called --print-config output "fully commented" when it carries no comments at all, and documented a TRX_PLUGIN_DIRS variable no code reads. It also still described [frontends.rigctl].port as the bind port years after rig_ports replaced it. Fixed, and the new configuration features are written up alongside. 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>	2026-08-06 21:32:46 +02:00
sjg	a2c630a92b	[feat](trx-frontend-http): put the tuned frequency in the address bar ... 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>	2026-08-05 22:31:12 +02:00
sjg	ba48de2d30	Initial commit ... Signed-off-by: Stan Grams <sjg@haxx.space>	2026-05-17 23:25:14 +02:00