Two things arrived in this release, and they could hardly be more different. One is a whole new section of the app that listens to the 2.4 GHz band. The other is a small handheld spectrum analyser that a contributor taught sdrtop to speak to, properly, in calibrated dBm.
NET: the 2.4 GHz band, as a bench measurement
The obvious joke writes itself: a terminal app that lists the Bluetooth devices in the room. There are phone apps for that, and they are prettier.
That is not what this is. NET is the Lab benches pointed at other people's transmitters. It decodes BLE advertising and finds classic Bluetooth piconets, and then it measures them, the way an RF test set would, except that it never transmits and nobody had to put the device into a test mode first:
- every device's modulation index, deviation and frequency drift against the specification's limits, read from its own ordinary packets;
- its crystal error in ppm, with an uncertainty, relative to our own oscillator until you give it a reference, and then corrected (and the panels say which of those two it is, every time);
- its advertising interval, the random delay on top, and whether it sits on the 0.625 ms grid the specification asks for;
- the frame error rate against SNR of the whole room, or of one device;
- for classic Bluetooth: the piconet's UAP, which it never sends, worked out from its headers; the BR modulation index; and its slot timing jitter against its own fitted 625 µs grid and the 1 µs limit.
Every figure carries its uncertainty or a dash. Limits read from the Bluetooth Core Specification say which section, and the BLE ones that are still recalled rather than read are documented as exactly that. A panel with nothing to say tells you which of three kinds of silence it is (refused, nothing heard, not listening), and a measurement that could be chance is refused as one. Five CSV exports take it all away, each opening with where, when and against what it was measured.
It is a toy in the same sense that a spectrum analyser is a toy: you can play with it, but it was built to be believed.
What is honest to say about it: BLE decoding, the census and the classic access-code search have run in a real room on a HackRF. The classic header decode, BR modulation and slot jitter pass every synthetic test and have not yet met a piconet whose UAP resolved, so they are marked "unchecked on air" where they appear. And decoding two protocols at once is real work: on the deliberately old i3 this is developed on, 4 Msps of BLE plus classic runs at about one and a half times real time, and the panels say [FEED LOSS] when blocks are dropped rather than pretending the room was quieter.
tinySA
@AlCalzone added the tinySA and tinySA Ultra family as a backend: calibrated power traces on the spectrum and waterfall, native band sweeps, and the device-options framework that gives the menu's Options pane something to hold, typed numbers included. Verified on a tinySA Ultra ZS405. It arrived as a sequence of small, reviewable pull requests, which is rarer and nicer than it should be.
The same contributor made libhackrf and librtlsdr runtime loads instead of link-time dependencies: the release tarball links no SDR library at all, a missing library disables only its own backend, and install.sh --hackrf / --rtlsdr / --soapy installs just what your radio needs.
Also
- The menu grew up: a colour per section, one selection mark shared with every list in the app, a live line under each NET view that is only as live as its receiver, and a Keys pane that opens with the focus keys of the section you came from, read from the panels themselves.
- The config file gains
[net]and[tinysa]blocks. Old files still load; the minor bump is for the new shape, as the changelog promises.
The full list is in CHANGELOG.md, the story in user_docs/whats-new.md, and the NET section has its own page, user_docs/net.md.