Follow-up to #37. That issue's fix (Option A, landed) makes the Remote API's sweep command reject start_hz == stop_hz outright, since passing a zero-span sweep through to the device is known to hang at least one real device (RigExpert Match). That closes the safety gap, but leaves a real capability gap: there is currently no way to get a single-frequency reading over the Remote API at all -- the GUI has one (Single Fq mode), the API doesn't.
The plan (Option B from #37's discussion, not started)
Add a real single-frequency path to the Remote API, mirroring what the GUI's on_singleStart_clicked() already does for the equivalent input (routes to on_startOneFq() instead of a zero-span range sweep).
Not a simple reuse of on_startOneFq()/the measureOneFq signal, though -- traced the call chain: MainWindow::measureOneFq is connected to two slots -- AnalyzerPro::on_measureOneFq (the real device request, fine) and Measurements::on_newMeasurementOneFq, which unconditionally calls showOneFqWidget(parent, dots) -- i.e. pops up a floating on-screen readout widget. Fine as a side effect of the GUI's own button; not fine as a surprise side effect of a remote client's API call (especially under -headless).
Proposed shape:
- A new method on
MainWindow (e.g. startRemoteSweepOneFq(), alongside the existing startRemoteSweep()) that calls into AnalyzerPro::on_measureOneFq directly -- bypassing the measureOneFq signal (and therefore Measurements::on_newMeasurementOneFq's widget-showing side effect) by construction, rather than threading a "was this remote?" flag into GUI-facing code.
RemoteApiConnection::cmdSweep() (or a new dedicated command) calls this when start_hz == stop_hz, instead of erroring.- Needs confirming during implementation (not yet verified) that OneFq mode's per-point/completion events still flow through the same
newMeasurement/newData/measurementComplete signals RemoteApiConnection already listens to -- on_startOneFq()'s own comment suggests it reuses the normal per-point pipeline just looped one-point-at-a-time, which would mean this works for free, but that needs confirming, not assuming.
Open question: new dedicated command (e.g. {"cmd":"read","freq_hz":...}) vs. keep it inside sweep (allow start_hz==stop_hz again, but route it differently under the hood)? Leaning toward a separate command for clarity -- sweep returning a single point via the same multi-point point/sweep_done event pair feels like it'd surprise clients expecting a real sweep -- but not decided.
Effort: moderate. Real risk: getting the widget-bypass wrong and having a stray on-screen artifact show up anyway despite the request coming from a remote client.
Follow-up to #37. That issue's fix (Option A, landed) makes the Remote API's
sweepcommand rejectstart_hz == stop_hzoutright, since passing a zero-span sweep through to the device is known to hang at least one real device (RigExpert Match). That closes the safety gap, but leaves a real capability gap: there is currently no way to get a single-frequency reading over the Remote API at all -- the GUI has one (Single Fq mode), the API doesn't.The plan (Option B from #37's discussion, not started)
Add a real single-frequency path to the Remote API, mirroring what the GUI's
on_singleStart_clicked()already does for the equivalent input (routes toon_startOneFq()instead of a zero-span range sweep).Not a simple reuse of
on_startOneFq()/themeasureOneFqsignal, though -- traced the call chain:MainWindow::measureOneFqis connected to two slots --AnalyzerPro::on_measureOneFq(the real device request, fine) andMeasurements::on_newMeasurementOneFq, which unconditionally callsshowOneFqWidget(parent, dots)-- i.e. pops up a floating on-screen readout widget. Fine as a side effect of the GUI's own button; not fine as a surprise side effect of a remote client's API call (especially under-headless).Proposed shape:
MainWindow(e.g.startRemoteSweepOneFq(), alongside the existingstartRemoteSweep()) that calls intoAnalyzerPro::on_measureOneFqdirectly -- bypassing themeasureOneFqsignal (and thereforeMeasurements::on_newMeasurementOneFq's widget-showing side effect) by construction, rather than threading a "was this remote?" flag into GUI-facing code.RemoteApiConnection::cmdSweep()(or a new dedicated command) calls this whenstart_hz == stop_hz, instead of erroring.newMeasurement/newData/measurementCompletesignalsRemoteApiConnectionalready listens to --on_startOneFq()'s own comment suggests it reuses the normal per-point pipeline just looped one-point-at-a-time, which would mean this works for free, but that needs confirming, not assuming.Open question: new dedicated command (e.g.
{"cmd":"read","freq_hz":...}) vs. keep it insidesweep(allowstart_hz==stop_hzagain, but route it differently under the hood)? Leaning toward a separate command for clarity --sweepreturning a single point via the same multi-pointpoint/sweep_doneevent pair feels like it'd surprise clients expecting a real sweep -- but not decided.Effort: moderate. Real risk: getting the widget-bypass wrong and having a stray on-screen artifact show up anyway despite the request coming from a remote client.