python-aaronia 0.7.7__tar.gz → 0.8.0__tar.gz

{python_aaronia-0.7.7 → python_aaronia-0.8.0}/.gitignore

@@ -10,15 +10,13 @@ tests/sdk/
 # Local agent configuration/memory
 .agents/
 
-# CMake build directory for SoapySDR plugin
-soapy-aaronia/build/
-python-aaronia/__pycache__/test_basic.cpython-314-pytest-9.1.1.pyc
-python-aaronia/err.txt
-python-aaronia/check_errors.txt
-branch_diff.txt
+# Local CMake build trees for the SoapySDR plugin. Globbed, not a single
+# `build/`: a second tree under any other name (build-test, build-e2e)
+# was committed once already — 33 files of CMakeCache and compiler probe
+# binaries carrying absolute paths from the machine that made them.
+soapy-aaronia/build*/
 
-# Python bindings dev environment and local plugin builds
+# Python bindings dev environment and build output
 python-aaronia/venv/
 python-aaronia/**/__pycache__/
-soapy-aaronia/build/
 dist/

{python_aaronia-0.7.7 → python_aaronia-0.8.0}/CHANGELOG.md

@@ -2,7 +2,152 @@
 
 All notable changes to this project will be documented in this file.
 
-## [Unreleased]
+## [v0.8.0] - 2026-09-07
+
+**Breaking:** `StreamStats` gained a `device_health` field, so an
+exhaustive struct literal over it no longer compiles. It is
+`#[non_exhaustive]` now, along with the new `DeviceCapabilities` and
+`DeviceHealthSummary`: these are reports a consumer reads rather than
+builds, and the attribute makes every future field addition free. Only
+the `futuresdr` feature exposes `StreamStats`; the default feature set is
+unaffected.
+
+### Added
+- **The SoapySDR probe now reports what the device says about itself.**
+  `SoapySDRUtil --probe` published constants compiled in for one model:
+  `hardware=Spectran V6` whatever was attached, a 10 Hz–6 GHz frequency
+  range, and a −100…+10 dB gain range. A SPECTRAN V6 ECO declares
+  5.5 MHz–8 GHz and −55…+23 dBm — too low at one end for any tune to
+  succeed, two whole GHz short at the other, and a gain slider spanning
+  values the device clamps. The plugin now reads `/remoteconfig` and
+  `/healthstatus` once at construction and publishes the model, serial,
+  firmware version, both ranges with their declared steps, and the
+  sample-rate ladder.
+
+  The ladder is the part that needed care: `status/iqsamples` is the
+  device's native undecimated rate but it is a *measurement*
+  (61 411 246 Hz for a nominal 61 440 000), so it is snapped to the exact
+  `receiver_clock / 1.5` rung it names — new `utils::snap_to_ladder_top`
+  — before being halved once per rung `decimation0` offers. A rate
+  advertised to an application has to be one the device can be set to.
+  `getSampleRateRange` is now taken from the ends of that same ladder, so
+  it can no longer disagree with `listSampleRates`; its old 10 kHz floor
+  sat below the slowest rung the hardware has.
+
+  New API: `http_endpoints::DeviceCapabilities` and `ValueRange`,
+  `HttpEndpointsClient::get_device_capabilities()`,
+  `AaroniaSource::device_capabilities()`, and the C entry points
+  `aaronia_source_get_capabilities` / `aaronia_source_capabilities_free`.
+  Every field is optional and independently so: a device answering about
+  frequency but not gain still gets its frequency range published, and
+  the file and native-SDK backends — which have no equivalent surface to
+  ask — fall back throughout. Nothing here is a guess; a field that
+  cannot be read stays absent.
+- **A stream gap now says whether the device caused it.** `HttpSource`
+  reads `/healthstatus` on each gap report and checks the device block's
+  own loss counters — `status/errors`, `status/usboverflows`,
+  `status/dsboverflows`, all per-second rates, so the reading describes
+  the moment of the gap rather than the run so far. Nonzero and the loss
+  starts at the device, where no amount of network headroom will recover
+  it; zero and the samples went missing downstream, in the server's 8 MB
+  outbound buffer or on the wire. The read is detached rather than
+  awaited: the control-plane timeout is 30 s, and stalling `work()` that
+  long would back the chunk channel up into the very loss being
+  diagnosed. `HttpEndpointsClient::get_device_health()` exposes the same
+  reduction of the health tree, and each reading is published as
+  `StreamStats::device_health`.
+
+  What it cannot settle is whether another client is on the same server
+  block. Nothing in the HTTP surface counts connections, so clearing the
+  device narrows a gap to a set of causes that includes contention
+  without singling it out — which is why the warning names it rather
+  than asserting it.
+
+### Fixed
+- **The SoapySDR plugin reported the clock source as `Internal`, a name
+  the device does not use, on hardware running off an external 10 MHz
+  reference.** `device/sclksource` offers `Consumer`, `Oscillator`,
+  `GPS`, `PPS`, `10MHz` and three `… Provider` variants; the measured V6
+  ECO is on `10MHz`. An operator who wired a house reference up for
+  frequency accuracy was told the device was free-running.
+  `listClockSources` and `getClockSource` now answer from the device.
+  `setClockSource` still only reads: it accepts the current source as
+  the no-op it is, and warns for anything else naming what the device is
+  actually on. `listAntennas` likewise takes its name from
+  `device/devicemode` — `RX1` on this device, and correct rather than
+  coincidental on a V6 running an RX2 mode.
+- **The SoapySDR plugin could link a stale Rust static library.** The
+  CMake rule produced `libsdr_aaronia_rs.a` through an
+  `add_custom_command(OUTPUT …)` with no `DEPENDS`, so CMake treated the
+  archive as up to date the moment it existed and skipped cargo
+  entirely. Editing Rust sources and rebuilding relinked the module
+  against the old archive — silently, producing a module that looked
+  fine and did not contain the change. It is a custom *target* now,
+  whose command runs every build and which cargo no-ops when nothing
+  moved, which is what the comment there always claimed happened.
+- **`SoapySDRUtil --probe` reported `Timestamps: NO` on a device that
+  timestamps every buffer.** `hasHardwareTime("")` answered with the last
+  stream timestamp, so it read as "no capability" until a packet had
+  arrived — and a probe never streams. It is a capability query now:
+  every RTSA packet header carries a start time, `readStream` has always
+  returned `SOAPY_SDR_HAS_TIME` with correct epoch nanoseconds, and an
+  application deciding at setup whether to record timestamps no longer
+  reads the probe as "cannot". `hasHardwareTime("GPS")` is unchanged and
+  still reports a value, since a GPS fix may genuinely not exist.
+- **The SoapySDR plugin advertised a TX channel on every device,
+  including receivers that cannot transmit at all.** `SoapySDRUtil
+  --probe` on a V6 ECO over HTTP reported `1 Tx`, a full TX channel
+  section and `Full-duplex: YES`; an application that believed it failed
+  on the first write. `getNumChannels` did guard on holding a sink, but
+  `aaronia_sink_build` allocates unconditionally — it succeeds on a build
+  carrying no TX code at all, and only `aaronia_sink_initialize` fails —
+  so the guard was never false. A sink is now built only when the new
+  `aaronia_sink_supported()` reports this binary carries the native-SDK
+  TX path *and* the source is that backend, which means a `serial=` open
+  with no `url=`/`file=` overriding it. The probe now reads `0 Tx` and
+  `Full-duplex: NO`.
+
+  Still not a device capability check: a native-SDK build opened by
+  serial against a V6 ECO would advertise TX, since the ECO has no
+  transmitter and nothing here asks the SDK.
+- **Restored a clean CI run.** Three clippy lints had been failing
+  `cargo clippy --workspace --all-features --all-targets` on Linux since
+  v0.7.7 — a collapsible `if let` in `UnifiedSink::initialize`, a needless
+  borrow in `native_sdk`, and a `field_reassign_with_default` in a
+  `sdk_source` unit test. All three sit in code gated to Windows and
+  Linux, so a macOS `cargo clippy` compiles none of it and reports
+  success; only CI's `--all-features` run sees them.
+
+### Documentation
+- **What several clients on one HTTP Server block cost, measured.** The
+  block accepts any number of concurrent `/stream` clients and serves
+  each one a full copy, so *n* clients cost the server *n* times the
+  egress. Two clients at 15.36 MS/s ran contiguous at 61.8 MB/s each;
+  five saturated the 2.5GbE path at 293.9 MB/s — the same ceiling a
+  single fast stream hits — and the loss fell on an arbitrary two of the
+  five, moving to a different pair on a repeat run. Two consequences a
+  client cannot escape: a clean stream is not evidence of being alone,
+  and a gap is not evidence of company. `/info`, `/healthstatus`,
+  `/remoteconfig` and the `/stream` response headers were all checked and
+  none counts connections.
+- **Corrected the free-licence claim in `docs/HTTPSPEC.md`.** It read
+  that running this crate alongside a second client would meet the
+  one-connection limit. Five simultaneous clients were served on a system
+  holding one HTTP Server block licence, with no error and no refusal:
+  the limit is on block instances in the mission graph, not on
+  connections to one block.
+- **The link a device actually needs, measured.** `link_budget`'s module
+  docs gain a 2.5GbE table beside the gigabit one, and the README a
+  requirements section. A 44 MHz real-time-bandwidth device — an ECO 100 —
+  has to run the 61.44 MS/s rung, and that rung costs 245.8 MB/s at 4 bytes
+  a sample, which gigabit cannot carry; 2.5 Gbps Ethernet is the floor for
+  those devices, and the wire format has to stay at 4 bytes a sample
+  because 8 asks 491.5 MB/s and loses 41 % of the stream. Two controls came
+  out of the same measurement: the path saturates at 292 MB/s, 93 % of
+  2.5GbE line rate, so the wire is the limit and not the server; and two
+  configurations asking the same 245.8 MB/s by different routes — 8 bytes a
+  sample at 30.72 MS/s, 4 bytes at 61.44 — deliver the same 244 MB/s,
+  confirming that only the byte rate matters.
 
 ## [v0.7.7] - 2026-09-06
 

{python_aaronia-0.7.7 → python_aaronia-0.8.0}/Cargo.lock

@@ -3027,7 +3027,7 @@ dependencies = [
 
 [[package]]
 name = "python-aaronia"
-version = "0.7.7"
+version = "0.8.0"
 dependencies = [
  "arrow",
  "num-complex",
@@ -3556,7 +3556,7 @@ checksum = "94143f37725109f92c262ed2cf5e59bce7498c01bcc1502d7b9afe439a4e9f49"
 
 [[package]]
 name = "sdr-aaronia-rs"
-version = "0.7.7"
+version = "0.8.0"
 dependencies = [
  "anyhow",
  "bitflags 2.13.1",

{python_aaronia-0.7.7 → python_aaronia-0.8.0}/Cargo.toml

@@ -2,7 +2,7 @@
 name = "sdr-aaronia-rs"
 description = "Unified Rust interface for Aaronia Spectran Spectrum Analyzers / SDRs, featuring Python bindings, a SoapySDR plugin, HTTP streaming, and native SDK support."
 license = "GPL-3.0-or-later"
-version = "0.7.7"
+version = "0.8.0"
 edition = "2024"
 repository = "https://github.com/isaacbentley/sdr-aaronia-rs"
 readme = "README.md"

{python_aaronia-0.7.7 → python_aaronia-0.8.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: python-aaronia
-Version: 0.7.7
+Version: 0.8.0
 Classifier: Programming Language :: Rust
 Classifier: Programming Language :: Python :: Implementation :: CPython
 Classifier: License :: OSI Approved :: GNU General Public License v3 or later (GPLv3+)

{python_aaronia-0.7.7 → python_aaronia-0.8.0}/README.md

@@ -40,6 +40,30 @@ selects a backend and presents the same interface either way.
   wasted: `link_budget` measures the path end to end and names the
   widest span on the device's decimation ladder that fits it.
 
+## Link requirements
+
+The server streams IQ at a fixed number of bytes per sample, so the span
+you ask for sets a byte rate the whole path has to sustain. Miss it and the
+*server* drops what it cannot send — unsignalled gaps that look fine in a
+waterfall and defeat any digital demodulator.
+
+| Real-time bandwidth | Sample rate | Needs (4 B/sample) | Link |
+|---|---|---|---|
+| up to 12.2 MHz | 15.36 MS/s | 61.4 MB/s | gigabit |
+| up to 24.5 MHz | 30.72 MS/s | 122.9 MB/s | gigabit measured 1024 skips; prefer 2.5GbE |
+| up to 49.1 MHz | 61.44 MS/s | 245.8 MB/s | **2.5GbE** |
+
+**A 44 MHz device — an ECO 100 — needs a 2.5 Gbps Ethernet link.** Only the
+top rung covers 44 MHz of real-time bandwidth (30.72 MS/s affords 24.5), and
+that rung costs 245.8 MB/s, which gigabit cannot carry. Measured over
+2.5GbE: 244.3 MB/s delivered against a 245.8 MB/s requirement, on a path
+that saturates at 292 MB/s. Keep to a 4-byte wire format there — `float32`
+doubles the requirement to 491.5 MB/s and loses 41 % of the stream.
+
+`link_budget` measures *your* path end to end and names the widest span that
+fits it, so treat the table as a starting point rather than a substitute for
+measuring.
+
 ## Installation
 
 Add the following to your `Cargo.toml`:

{python_aaronia-0.7.7 → python_aaronia-0.8.0}/docs/APPS.md

@@ -114,7 +114,12 @@ directly and skip the SoapySDR layer.
 - `readStream` honours `timeoutUs` and returns partial reads within the
   deadline, per the SoapySDR contract.
 - Retuning mid-stream is safe and requires no Aaronia licence.
+- The frequency range, gain range and sample-rate list an application
+  shows come from the device itself over the HTTP backend, so they match
+  the model attached rather than a compiled-in default.
 - Gaps detected in the stream are counted by `readSensor("cumulative_drops")`.
   An overrun sets `SOAPY_SDR_END_ABRUPT` on the affected read.
-- TX is hardware-unverified and exists only when the plugin is built
-  against the native SDK on Windows or Linux.
+- TX is hardware-unverified, and a TX channel is reported only when the
+  plugin was built against the native SDK on Windows or Linux *and* the
+  device was opened by `serial=`. Over `url=` or `file=` the probe shows
+  `0 Tx`.

{python_aaronia-0.7.7 → python_aaronia-0.8.0}/docs/HTTPSPEC.md

@@ -189,6 +189,62 @@ the network cannot carry all end here, so reducing the wire format
 (`format=int16`) or the rate (`rate_reduction=n`) is the fix rather
 than a larger client-side buffer.
 
+### Several clients on one server block
+
+The HTTP Server block accepts any number of concurrent `/stream`
+clients, silently, and serves **each one a full copy** of the stream. It
+does not split the data and it does not refuse the second connection, so
+*n* clients cost the server *n* times the egress. Measured against a
+V6 ECO at 15.36 MS/s (`format=int16`, 61.4 MB/s a client), counting
+bytes off the socket over 6 s after a 500 ms settle:
+
+| clients | per client | aggregate  | result                             |
+|---------|------------|------------|------------------------------------|
+| 1       | 61.8 MB/s  | 61.8 MB/s  | contiguous                         |
+| 2       | 61.8 MB/s  | 123.5 MB/s | contiguous, both clients           |
+| 5       | 52–62 MB/s | 293.9 MB/s | saturated; 2 of 5 clients lost data |
+
+The five-client rows are the ones to read. The aggregate pins at
+293.9 MB/s — the same ~292 MB/s ceiling this 2.5GbE path saturates at
+with a single fast stream — so the constraint is the path, not a
+per-client limit. And the loss is **not shared out fairly**: three of the
+five clients ran contiguous at the full 61.7 MB/s while the other two ran
+short with hundreds of timestamp gaps each. Repeating the run moved the
+loss to a different pair.
+
+Two consequences for a client:
+
+- **A clean stream is not evidence of being alone.** You may be one of
+  the connections the server is keeping up with while it starves another.
+- **A gap is not evidence of company either.** A slow link, a slow
+  consumer and a second client all arrive as the same 8 MB outbound
+  buffer overflowing.
+
+#### Nothing reports the number of clients
+
+There is no endpoint, field or header that counts connections. Checked
+against a live RTSA-Suite PRO:
+
+| Surface | What it carries |
+| :--- | :--- |
+| `/info` | `name`, `title`, `uuid`, `port`, `mission`, `features` — no counts |
+| `/healthstatus` | the device block only; the HTTP Server block publishes no health at all |
+| `/remoteconfig` | the device block only, same as above |
+| `/stream` response headers | `Access-Control-Allow-Origin`, `Transfer-Encoding`, `Date`, `DateMS` |
+
+So a client cannot ask. What it can do is rule the *device* out: at the
+moment of a gap, `/healthstatus` reports the device block's own loss
+counters — `status/errors`, `status/usboverflows`, `status/dsboverflows`,
+all per-second rates — and if they are zero the samples went missing
+downstream of the device, in the server's outbound buffer or on the wire.
+That narrows a gap to a set of causes that includes another client
+without singling one out. `HttpEndpointsClient::get_device_health()`
+performs the read; `HttpSource` runs it automatically on each stream-gap
+report and publishes the result on `StreamStats::device_health`.
+
+For a definitive answer, look at the RTSA host itself — the HTTP Server
+block's own panel, or the host's socket table for peers on port 54664.
+
 ### Liveness
 
 There is no status endpoint. Aaronia's own remote control notes probe
@@ -595,7 +651,10 @@ when it is wrong.
 Note: this crate's `get_health_status()` parses the response as a generic
 configuration tree (`HealthStatus` is an alias for `ConfigItem`) rather
 than the typed shape below, which describes the upstream block-health
-fields.
+fields. `get_device_health()` reduces that tree to the per-block loss
+counters — `status/errors`, `status/usboverflows`, `status/dsboverflows`,
+plus `status/devstate` — which is the read that says whether a stream gap
+started at the device; see "Several clients on one server block" above.
 
 **Subgroups** per health-aware block, per Aaronia's specification:
 `info`, `status`, `health`, `settings`, and `components` — the last a
@@ -630,6 +689,32 @@ from packet metadata for that.
 | `title` | User-facing block title |
 | `uuid` | Global unique identifier |
 
+#### What the config tree declares about limits
+
+`/remoteconfig`'s numeric items carry `min`, `max` and `step`, and its
+enums carry their full `values` list, so a client can read a device's
+limits instead of compiling in constants for one model. Measured on a
+SPECTRAN V6 ECO:
+
+| Item | Declares |
+| :--- | :--- |
+| `centerfreq0` | `min` 5 500 000, `max` 8e9, `step` 1000, unit `Frequency` |
+| `reflevel0` | `min` -55, `max` 23, `step` 0.5, unit `dBm` |
+| `decimation0` | `values` `Full,1 / 2,…,1 / 512` — ten rungs |
+
+Two of those are worth stating plainly because published clients have
+had them wrong: the ECO tunes from **5.5 MHz**, not from ~0, and it
+reaches **8 GHz**, not 6. Combined with `/healthstatus`'s
+`status/iqsamples` — the native undecimated rate — the decimation list
+gives the full set of settable sample rates.
+
+`iqsamples` is a running measurement (61 411 246 Hz against a nominal
+61 440 000), so snap it to the exact `receiver_clock / 1.5` rung it
+names before treating it as a ladder top; a rate advertised to an
+application must be one the device can be set to.
+`DeviceCapabilities::from_trees` in this crate does all of the above,
+and `HttpEndpointsClient::get_device_capabilities()` performs the reads.
+
 #### User Information (`/user`)
 **URL**: `/user`  
 **Method**: GET  
@@ -862,10 +947,15 @@ connection is free. Stream Merger and Stream Splitter, the blocks that
 would otherwise let several streams share one connection, are not in
 the free licence either.
 
-This is the licence limit most likely to be met in practice: running
-this crate and a second client — a SoapySDR application, say — against
-one server at the same time is a second connection. It has nothing to
-do with the Remote Config licence discussed below.
+An earlier revision of this document read that limit as covering
+*connections* and warned that running this crate alongside a second
+client — a SoapySDR application, say — would meet it. **That is not what
+a live system does.** On the same RTSA-Suite PRO holding one HTTP Server
+block licence, five simultaneous `/stream` clients were all served, with
+no error, no refusal and no licence complaint. The limit is on block
+instances in the mission graph, not on connections to one block. What
+several clients cost is bandwidth, not licence — see below. It has
+nothing to do with the Remote Config licence discussed further down.
 
 **Remote Configuration** (`/remoteconfig`):
 - Device parameter configuration.
@@ -1029,6 +1119,7 @@ fn parse_iq_int16(data: &[u8], metadata_scale: f32) -> Vec<Complex32> {
 |---------|------|---------|
 | 1.0 | 2025-01-11 | Initial HTTP specification from original documentation |
 | 2.0 | 2025-01-11 | Enhanced with comprehensive streaming protocol specification and implementation guidelines |
+| 2.5 | 2026-09-06 | Measured what several clients on one HTTP Server block actually do: the block serves each connection a full copy and refuses none, so *n* clients cost *n* times the egress — five concurrent clients saturated a 2.5GbE path at 293.9 MB/s and the loss landed on an arbitrary two of them, moving on a repeat run. Corrected the free-licence claim: five clients were served on a one-block licence, so the limit is on block instances, not connections. Confirmed no surface counts connections (`/info`, `/healthstatus`, `/remoteconfig`, `/stream` headers), and documented the device-block loss counters as the cross-check that at least rules the device out |
 | 2.4 | 2026-08-12 | Added Aaronia support's full `/control` settings list (`deviceconnect`, `camera`, per-type fields, `receiverUUID`/`receiverName` scoping), which supersedes the specification's claim that commands cannot be addressed to a block; documented that an unrecognised `format=` silently serves the RTSA file format and that `raw16` aliases `int16`, both verified live |
 | 2.3 | 2026-08-12 | Folded in Aaronia's endpoint specification (rev 11) and the block forum threads: `/control` broadcasts to every block and is PUT-only, the server drops data past an 8 MB outbound buffer, `/healthstatus` subgroups and the fields a V6 ECO reports, and the one-server/one-client free-licence limit. Measured that `status/iqsamples` is the native rate, not the delivered one. Corrected the marker-stream entry: it declares `payload: "spectra"`, so its nested samples are the spectra form and not a counter-example to flat categories |
 | 2.2 | 2026-08-12 | Verified Aaronia's V6 remote control notes (rev 4) against hardware: enum writes by index, multi-group and non-`main` `simpleconfig` PUTs, the silent no-op on an unknown block name, the ignored receiver name in the config-tree form; documented mission loading and the `type` requirement on `/control`, the absence of a status endpoint, and the unresolved conflict over what "Full" means on a full V6; resolved a contradiction over what the Remote Config licence gates |

{python_aaronia-0.7.7 → python_aaronia-0.8.0}/docs/USAGE.md

@@ -176,6 +176,75 @@ naming a narrower span from the device's own ladder that fits. The
 verdict is also published as `StreamStats::link_budget` on the shared
 stats handle, and is re-measured after a configuration restart.
 
+### When a gap happens anyway: was it the device?
+
+A gap that arrives despite a link with headroom has more than one cause,
+and the crate asks the device about the one it can settle. On each
+stream-gap report `HttpSource` reads `/healthstatus` and checks the
+device block's own loss counters — errors, USB overflows and DSP
+overflows, all per-second rates, so the reading describes the moment of
+the gap. If they are nonzero the loss starts at the device and no amount
+of network headroom will recover it. If they are zero the samples went
+missing downstream, in the RTSA HTTP server's outbound buffer (it drops
+past 8 MB) or on the wire. The reading is logged beside the gap warning
+and published as `StreamStats::device_health`; the same read is available
+directly:
+
+```rust,no_run
+# async fn health() -> sdr_aaronia_rs::Result<()> {
+use sdr_aaronia_rs::http_endpoints::{AuthMethod, HttpEndpointsClient};
+
+let client = HttpEndpointsClient::new("http://localhost:54664".into(), AuthMethod::None)?;
+for block in client.get_device_health().await? {
+    // `None` means the block reported none of the counters — the honest
+    // answer is "cannot say", not a device that has been cleared.
+    println!("{} -> losing nothing: {:?}", block.describe(), block.losing_nothing());
+}
+# Ok(())
+# }
+```
+
+### What the device says it can do
+
+The same control-plane surface declares the device's own limits, and
+`get_device_capabilities()` reduces the two trees to them: model, serial
+and firmware version, the bounds on centre frequency and reference
+level, and the decimation ladder's depth.
+
+```rust,no_run
+# async fn caps() -> sdr_aaronia_rs::Result<()> {
+use sdr_aaronia_rs::http_endpoints::{AuthMethod, HttpEndpointsClient};
+
+let client = HttpEndpointsClient::new("http://localhost:54664".into(), AuthMethod::None)?;
+let caps = client.get_device_capabilities().await;
+println!("{:?} serial {:?}", caps.model, caps.serial);
+if let Some(range) = caps.center_frequency {
+    println!("tunes {:.3}-{:.3} MHz", range.min / 1e6, range.max / 1e6);
+}
+// Highest first, and every rung one the device can actually be set to:
+// its reported native rate is a measurement, so it is snapped to an
+// exact ladder top before being halved down.
+println!("sample rates: {:?}", caps.sample_rates());
+# Ok(())
+# }
+```
+
+Every field is optional and independently so, because the answer feeds
+things that must not be guessed. The SoapySDR plugin publishes exactly
+these at probe time — a V6 ECO declares 5.5 MHz–8 GHz and −55…+23 dBm,
+where the plugin previously advertised 10 Hz–6 GHz and −100…+10 dB for
+every model — and falls back per field for a device that cannot answer.
+
+**Clearing the device does not mean you are alone on the server.** One
+of the causes it leaves standing is another client: the HTTP Server block
+serves each connection a full copy of the stream and refuses none, so a
+second client doubles the server's egress. Nothing in the HTTP surface
+counts connections, and the loss under saturation lands on an arbitrary
+subset of the clients — measured, three of five ran contiguous while two
+lost data — so a clean stream is not evidence of being alone either. For
+a definitive count, look at the RTSA host. See `docs/HTTPSPEC.md`,
+"Several clients on one server block".
+
 ## Reusable configuration profiles
 
 Build your own configuration for specific bands:

{python_aaronia-0.7.7 → python_aaronia-0.8.0}/include/aaronia.h

@@ -3,6 +3,7 @@
 
 #include <stdint.h>
 #include <stdbool.h>
+#include <stddef.h>
 
 #ifdef __cplusplus
 extern "C" {
@@ -58,6 +59,43 @@ typedef struct FfiSourceInfo {
     const char* device_serial;
 } FfiSourceInfo;
 
+// --- What the device reports about itself --- //
+//
+// Optionality is explicit: 0.0 is a legitimate reference level and a
+// legitimate step, so no numeric sentinel could distinguish "the device
+// declares 0" from "the device did not say". Strings are NULL when
+// absent, the ranges carry a has_ flag, and sample_rate_count == 0
+// means the ladder could not be derived. Fall back per field, not on
+// the whole struct.
+typedef struct FfiDeviceCapabilities {
+    const char* model;    // e.g. "SPECTRAN V6 ECO"; NULL when unknown
+    const char* serial;   // NULL when unknown
+    const char* version;  // firmware/FPGA revisions; NULL when unknown
+
+    bool   has_center_frequency;
+    double center_frequency_min_hz;
+    double center_frequency_max_hz;
+    double center_frequency_step_hz;  // 0.0 = device declares no step
+
+    bool   has_reference_level;
+    double reference_level_min_dbm;
+    double reference_level_max_dbm;
+    double reference_level_step_db;   // 0.0 = device declares no step
+
+    // Settable IQ sample rates in Hz, highest first. Owned by this
+    // struct; NULL and 0 when the device could not be asked.
+    size_t        sample_rate_count;
+    const double* sample_rates;
+
+    // Stream-clock sources in the device's own vocabulary (a V6 ECO:
+    // Consumer, Oscillator, GPS, PPS, 10MHz, and three "... Provider"
+    // variants). Owned by this struct; NULL and 0 when it did not say.
+    size_t              clock_source_count;
+    const char* const*  clock_sources;
+    const char*         clock_source;   // currently selected; NULL if unknown
+    const char*         rx_antenna;     // e.g. "RX1"; NULL if the mode names none
+} FfiDeviceCapabilities;
+
 // Opaque pointers
 typedef struct AaroniaSourceBuilder AaroniaSourceBuilder;
 typedef struct AaroniaSource AaroniaSource;
@@ -125,6 +163,15 @@ AaroniaFfiError aaronia_source_set_reference_level(AaroniaSource* source, double
 FfiSourceInfo* aaronia_source_get_source_info(AaroniaSource* source);
 void aaronia_source_info_free(FfiSourceInfo* info);
 
+// Read the device's declared capabilities. BLOCKING: two control-plane
+// GETs, so call it once and cache. Returns NULL only for a null source
+// or when called from a current-thread tokio runtime; a device that
+// cannot be asked yields a struct with every field absent. Answers for
+// the HTTP backend — file and native-SDK sources report nothing, having
+// no equivalent surface to ask.
+FfiDeviceCapabilities* aaronia_source_get_capabilities(AaroniaSource* source);
+void aaronia_source_capabilities_free(FfiDeviceCapabilities* caps);
+
 // --- Sink FFI --- //
 //
 // WARNING: the whole TX path is hardware-unverified (driven per the
@@ -148,6 +195,14 @@ typedef struct AaroniaSink AaroniaSink; // Opaque UnifiedSink
 #define AARONIA_TX_SEGMENT_END   ((uint64_t)0x00000008)
 #define AARONIA_TX_PUSH          ((uint64_t)0x00008000)
 
+// True when this build carries the native-SDK transmit path. Ask before
+// advertising a TX capability: aaronia_sink_build succeeds everywhere,
+// so a non-null sink proves nothing. Compile-time only — it cannot say
+// whether the attached device has a transmitter (a V6 ECO does not), and
+// TX also requires the native-SDK source backend, so a device opened
+// over HTTP or from a file has no TX path regardless.
+bool aaronia_sink_supported(void);
+
 AaroniaSinkBuilder* aaronia_sink_builder_new(void);
 void aaronia_sink_builder_free(AaroniaSinkBuilder* builder);
 void aaronia_sink_builder_center_frequency(AaroniaSinkBuilder* builder, double hz);

{python_aaronia-0.7.7 → python_aaronia-0.8.0}/python-aaronia/Cargo.toml

@@ -1,6 +1,6 @@
 [package]
 name = "python-aaronia"
-version = "0.7.7"
+version = "0.8.0"
 edition = "2024"
 description = "Python bindings for sdr-aaronia-rs (Aaronia SPECTRAN V6 SDR source)"
 license = "GPL-3.0-or-later"