Most of this release is invisible, which is the nicest thing I can say about it.
🎚 The part you could actually have noticed
Ask a HackRF reached through SoapySDR for 100 dB of gain and it stored 100 dB,
drew it on the bar, and reported it as a legal setting. The radio disagreed
quietly, which is the worst way to disagree.
The driver reports 0 to 116 dB for the whole chain, because it counts an
amplifier that has its own key and is not part of the knob. The stage that
number actually goes into stops at 40. sdrtop was clamping against the first
figure and writing into the second.
The two native backends never had this bug. They always answered from their own
stage list, and the front stage says 40, so 40 is what came back. Only the
SoapySDR path clamped a different way, because in 0.5.0 it was a different
way: a variant of its own in a type the other two shared.
I did not go hunting for this. It fell out of making every device answer the
same question through the same code, which is the argument for the rest of this
release in one sentence.
🧱 The wall
0.5.0 taught sdrtop to speak SoapySDR, and it did that by adding a case to the
type the two native radios already used. That works, and it means a fact about
one radio's gain chain lives in the file the other two read. Fix something for
an Airspy, touch the code path a HackRF runs.
So the backends are separated now. native/ holds the two radios sdrtop drives
itself and has tested on real hardware; soapy/ holds everything reached
through libSoapySDR. Exactly one module is allowed to know both exist, because
deciding what to show when two of them find the same radio is a question neither
can answer alone.
The survey that sized the job was the pleasant surprise: the UI layer, over half
the codebase, already contained no reference to any backend at all. The
mixing was about 150 lines in two files. A day's work rather than the fortnight
I had braced for.
Nothing on screen moved. That is checked rather than hoped. The panel tests
render through the real registry and compare the actual buffer, and not one of
them needed its expected text edited.
📻 A note about RTL-SDR
sdrtop's rule for the two native backends is that support lands only after
physical testing. I had a HackRF for this one and no RTL-SDR, so I am saying so
here rather than letting anyone find out.
The exposure is narrower than the diff looks. Not one line of the RTL-SDR
device implementation changed: same tuning, same gain calls, same read thread.
What changed is how it describes its gain chain to the rest of the app, and
which trait call the [A] key picks, both covered by tests. If you have one and
the boost key misbehaves, that is the thing to tell me about.
📋 Upgrading
Nothing to do. No config change, no key change, no new dependency.
cargo install sdrtop --lockedOr the installer, same as before.
As ever: if something looks broken, it is either a bug or an undocumented
feature. Flip a coin, then open an issue. ❤️
Full Changelog: v0.5.0...v0.5.1