python-aaronia 0.8.2__tar.gz → 0.9.0__tar.gz

{python_aaronia-0.8.2 → python_aaronia-0.9.0}/CHANGELOG.md

@@ -4,80 +4,59 @@ All notable changes to this project will be documented in this file.
 
 ## [Unreleased]
 
-### Performance
-- **The int16 and float16 IQ decoders are ~23% faster end to end.** Both
-  built their output with `Vec::with_capacity` then `push` per sample,
-  which carries a capacity check the compiler cannot elide and which was
-  blocking vectorisation. Collecting from the slice iterator instead —
-  `TrustedLen`, so the vector is sized once — measured 495 to 2433 MS/s
-  on the decode loop alone, and 123.5 to 152 MS/s over the whole HTTP
-  path including framing and transport. float32 was already a single
-  `copy_nonoverlapping` and is unchanged.
-
-  Worth stating what this does not buy: at 605 MB/s the crate is about
-  2.5x the fastest a V6 can produce and 6x a WiFi 6E link, so it was not
-  the bottleneck before and is not now. What it buys is CPU left over
-  for whatever consumes the samples.
-
 ### Added
-- **`scripts/fake-rtsa-server.py`** serves `/stream` in the real wire
-  format at loopback speed, so a decode path can be measured without a
-  device or a network. It is how the figures above were taken: over any
-  real link the transport dominates and a CPU change is invisible. Its
-  docstring carries the caveat that goes with it — over loopback hyper's
-  adaptive read buffer never leaves its 8 KiB floor, so kernel time there
-  is a property of the harness, not of the crate.
+- **SoapySDR: device sensors.** The plugin exposed one sensor
+  (`cumulative_drops`); it now surfaces the device's live telemetry from
+  `/healthstatus` — FPGA and frontend temperature, ADC headroom (dB below
+  full scale, so a client can raise the reference level before it clips),
+  USB and DSP buffer fill, error and overflow rates, GPS satellites and
+  position. `listSensors` / `readSensor` / `getSensorInfo`, read through a
+  dedicated connection and briefly cached, so polling them during a
+  capture neither stalls the sample stream nor costs a fetch per key.
+  HTTP backend only: the native SDK's own `AARTSAAPI_ConfigHealth` tree
+  reads all zeros in raw-SDK mode — the live telemetry is computed and
+  populated by RTSA-Suite, the managing application, not by the raw SDK,
+  confirmed by dumping the tree live from a V6 ECO — so over `sdk=true`
+  the plugin reports only `cumulative_drops`, which is real and
+  client-side. Verified live over HTTP on a V6 ECO.
+- **SoapySDR: bandwidth API.** `setBandwidth` / `getBandwidth` /
+  `listBandwidths` / `getBandwidthRange`. The device's alias-free
+  bandwidth is 0.8x its sample rate; these expose that as SoapySDR's
+  separate knob, mapping a requested bandwidth to a sample rate and
+  driving the already-verified `setSampleRate` — no new device-write path.
+  Verified on a V6 ECO: 15.36 MS/s reports 12.288 MHz, `setBandwidth`
+  snaps to a rung.
+- **SoapySDR: the native SDK is discoverable.** `find` advertises a
+  second `sdk=true` device beside the HTTP one whenever the SDK is
+  installed, and `sdk=true` / `serial=` force the native backend instead
+  of silently falling back to localhost HTTP. Verified streaming 15.357
+  MS/s over the SDK through the plugin from Python.
+- **C ABI.** `aaronia_source_read_sensors` (fills a value struct, `NaN`
+  for absent — no ownership, nothing to free);
+  `aaronia_source_builder_force_source_type` and `aaronia_sdk_installed`,
+  the C equivalent of `force_native_sdk`, which C had no way to request;
+  and the stateless bandwidth helpers `aaronia_usable_bandwidth_hz` /
+  `aaronia_iq_sample_rate_for_bandwidth`. `DeviceSensors` is the Rust type
+  behind the first.
 
-### Documentation
-- **`rate_reduction` is time compression, not a sample-rate divider.**
-  Five places described it as reducing the rate or optimising bandwidth.
-  It thins frames over time — the operation the `waterfall` payload is
-  described by — so a continuous IQ stream, having no frames, is
-  unaffected: measured at factors of 2, 10 and 64, `sampleFrequency`
-  holds at 15,359,988 Hz and the byte rate does not move. That is the
-  parameter behaving as specified on a payload it was not meant for.
-  `live_stream_rate_reduction_and_scale` had asserted only that packets
-  arrived, which is true either way, so nothing caught the wrong
-  description; it now pins the IQ behaviour.
-- **The stream can be compressed, up to 6.55x, via `format=rtsa`.**
-  Captured from RTSA-Suite's own HTTP Client block:
-  `GET /stream?format=rtsa&rate_reduction=8&input=main&compression=5&rate_adaption=0`.
-  `format=rtsa` streams the file container and is the only format that
-  accepts `compression=N`, which applies the file format's own lossy
-  codec. The container carries `float32` (`mSampleType` 11, `DSST_F32N`),
-  so level 0 is plain float32 with under 1% of chunk overhead — 123.0
-  MB/s against 122.9 theoretical at 15.36 MS/s. Against that baseline the
-  codec buys 2.74x at level 1, 4.43x at level 5 and 13.10x at level 9;
-  even level 1 undercuts plain `int16` while carrying float precision.
-  Ratios hold at 3.84 MS/s too.
-
-  HTTPSPEC had documented `format=rtsa` only as the thing a typo falls
-  back to — "a completely different wire format rather than an error" —
-  and this release had gone on to claim compression was neither offered
-  nor useful. Both are corrected. Generic HTTP compression is still not
-  available on `/stream` and still would not help (zlib manages 1.07x on
-  `float32`); Aaronia's codec wins by being lossy and signal-aware.
-
-  This crate cannot use it for IQ, tested rather than assumed: a real
-  compressed payload handed to `Decompressor::decompress` comes back
-  rejected as proprietary `DSPT_IQ`, the same wall that stops compressed
-  IQ *files*. `format=rtsa` also defaults to `mCompression=1`, so only
-  `compression=0` is decodable and that is 20% larger than plain `int16`.
-  Spectra should decode, `DSPT_SPECTRA` being documented, but this
-  mission has no spectra input to try.
-
-### Performance
-- **The control plane is now requested compressed.** `reqwest` gains the
-  `deflate` and `gzip` features, so the client sends
-  `Accept-Encoding: gzip,deflate` where it previously sent none. Measured
-  against the device: `/remoteconfig` 17,432 bytes to 3,299 deflated,
-  `/healthstatus` 6,100 to 1,436. Both are read at every device open, and
-  `/healthstatus` again on each stream-gap report. No effect on `/stream`,
-  which the server does not compress at any level.
-- The reader channel's size comment claimed ~157 KiB chunks and ~10 MB of
-  queue. Measured against a live server it is 64 KiB for 71% of chunks,
-  so the queue is ~4 MB, about 45 ms at the 88 MB/s a WiFi 6E path
-  delivers.
+### Fixed
+- **File playback reported the decompression time as the capture time.**
+  A DSPT_IQ-compressed `.rtsa` is decompressed through RTSAFileTool, which
+  writes a fresh header stamped with the moment of conversion, so the
+  re-opened file reported *now* — a 2020 capture read as 2026. The
+  original header's `creation_time`, parsed before compression was
+  detected, is now carried across the decompression, and the derived
+  start/end fall-backs follow it. Surfaced the first time the fixture test
+  ran on a machine with RTSA-Suite installed.
+- **The SoapySDR plugin could not load the SDK inside a host that carries
+  its own Qt6.** The loader was given `LOAD_LIBRARY_SEARCH_DEFAULT_DIRS`,
+  which searches the host application's directory first; a GNU Radio
+  (radioconda) install holds a different Qt6 build there under the same
+  names, and the load failed. It now searches only the DLL's own
+  directory, the SDK install root, and System32.
+- **The Seify native-SDK test panicked on teardown.** `AaroniaSeifyDevice`
+  owns a tokio runtime, and dropping one inside an async context is a
+  tokio panic; the test is synchronous now.
 
 ## [v0.8.2] - 2026-09-08
 
@@ -169,6 +148,84 @@ MSVC against radioconda's SoapySDR, streams 15.357 MS/s over the SDK
 into Python; see [docs/VERIFICATION.md](docs/VERIFICATION.md) for the
 two limits found on the way.
 
+
+_Also in 0.8.2 (recorded here on the 0.9.0 pass; these landed across the 0.8.x docs/perf commits and were never restamped):_
+
+### Performance
+- **The int16 and float16 IQ decoders are ~23% faster end to end.** Both
+  built their output with `Vec::with_capacity` then `push` per sample,
+  which carries a capacity check the compiler cannot elide and which was
+  blocking vectorisation. Collecting from the slice iterator instead —
+  `TrustedLen`, so the vector is sized once — measured 495 to 2433 MS/s
+  on the decode loop alone, and 123.5 to 152 MS/s over the whole HTTP
+  path including framing and transport. float32 was already a single
+  `copy_nonoverlapping` and is unchanged.
+
+  Worth stating what this does not buy: at 605 MB/s the crate is about
+  2.5x the fastest a V6 can produce and 6x a WiFi 6E link, so it was not
+  the bottleneck before and is not now. What it buys is CPU left over
+  for whatever consumes the samples.
+
+### Added
+- **`scripts/fake-rtsa-server.py`** serves `/stream` in the real wire
+  format at loopback speed, so a decode path can be measured without a
+  device or a network. It is how the figures above were taken: over any
+  real link the transport dominates and a CPU change is invisible. Its
+  docstring carries the caveat that goes with it — over loopback hyper's
+  adaptive read buffer never leaves its 8 KiB floor, so kernel time there
+  is a property of the harness, not of the crate.
+
+### Documentation
+- **`rate_reduction` is time compression, not a sample-rate divider.**
+  Five places described it as reducing the rate or optimising bandwidth.
+  It thins frames over time — the operation the `waterfall` payload is
+  described by — so a continuous IQ stream, having no frames, is
+  unaffected: measured at factors of 2, 10 and 64, `sampleFrequency`
+  holds at 15,359,988 Hz and the byte rate does not move. That is the
+  parameter behaving as specified on a payload it was not meant for.
+  `live_stream_rate_reduction_and_scale` had asserted only that packets
+  arrived, which is true either way, so nothing caught the wrong
+  description; it now pins the IQ behaviour.
+- **The stream can be compressed, up to 6.55x, via `format=rtsa`.**
+  Captured from RTSA-Suite's own HTTP Client block:
+  `GET /stream?format=rtsa&rate_reduction=8&input=main&compression=5&rate_adaption=0`.
+  `format=rtsa` streams the file container and is the only format that
+  accepts `compression=N`, which applies the file format's own lossy
+  codec. The container carries `float32` (`mSampleType` 11, `DSST_F32N`),
+  so level 0 is plain float32 with under 1% of chunk overhead — 123.0
+  MB/s against 122.9 theoretical at 15.36 MS/s. Against that baseline the
+  codec buys 2.74x at level 1, 4.43x at level 5 and 13.10x at level 9;
+  even level 1 undercuts plain `int16` while carrying float precision.
+  Ratios hold at 3.84 MS/s too.
+
+  HTTPSPEC had documented `format=rtsa` only as the thing a typo falls
+  back to — "a completely different wire format rather than an error" —
+  and this release had gone on to claim compression was neither offered
+  nor useful. Both are corrected. Generic HTTP compression is still not
+  available on `/stream` and still would not help (zlib manages 1.07x on
+  `float32`); Aaronia's codec wins by being lossy and signal-aware.
+
+  This crate cannot use it for IQ, tested rather than assumed: a real
+  compressed payload handed to `Decompressor::decompress` comes back
+  rejected as proprietary `DSPT_IQ`, the same wall that stops compressed
+  IQ *files*. `format=rtsa` also defaults to `mCompression=1`, so only
+  `compression=0` is decodable and that is 20% larger than plain `int16`.
+  Spectra should decode, `DSPT_SPECTRA` being documented, but this
+  mission has no spectra input to try.
+
+### Performance
+- **The control plane is now requested compressed.** `reqwest` gains the
+  `deflate` and `gzip` features, so the client sends
+  `Accept-Encoding: gzip,deflate` where it previously sent none. Measured
+  against the device: `/remoteconfig` 17,432 bytes to 3,299 deflated,
+  `/healthstatus` 6,100 to 1,436. Both are read at every device open, and
+  `/healthstatus` again on each stream-gap report. No effect on `/stream`,
+  which the server does not compress at any level.
+- The reader channel's size comment claimed ~157 KiB chunks and ~10 MB of
+  queue. Measured against a live server it is 64 KiB for 71% of chunks,
+  so the queue is ~4 MB, about 45 ms at the 88 MB/s a WiFi 6E path
+  delivers.
+
 ## [v0.8.1] - 2026-09-07
 
 ### Fixed

{python_aaronia-0.8.2 → python_aaronia-0.9.0}/Cargo.lock

@@ -3092,7 +3092,7 @@ dependencies = [
 
 [[package]]
 name = "python-aaronia"
-version = "0.8.2"
+version = "0.9.0"
 dependencies = [
  "arrow",
  "num-complex",
@@ -3621,7 +3621,7 @@ checksum = "94143f37725109f92c262ed2cf5e59bce7498c01bcc1502d7b9afe439a4e9f49"
 
 [[package]]
 name = "sdr-aaronia-rs"
-version = "0.8.2"
+version = "0.9.0"
 dependencies = [
  "anyhow",
  "bitflags 2.13.1",

{python_aaronia-0.8.2 → python_aaronia-0.9.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.8.2"
+version = "0.9.0"
 edition = "2024"
 repository = "https://github.com/isaacbentley/sdr-aaronia-rs"
 readme = "README.md"

{python_aaronia-0.8.2 → python_aaronia-0.9.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: python-aaronia
-Version: 0.8.2
+Version: 0.9.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.8.2 → python_aaronia-0.9.0}/PLUGINS.md

@@ -23,6 +23,11 @@ crate built with both features — `features = ["seify", "native-sdk"]` —
 on Windows or Linux with RTSA-Suite PRO installed. Without the feature
 the request is a clean error, never a fallback to HTTP.
 
+`AaroniaSeifyDevice` owns a tokio runtime. Drop it from synchronous
+code: dropping it inside an `async` context (a `#[tokio::test]`, a task)
+is a tokio panic, "Cannot drop a runtime in a context where blocking is
+not allowed".
+
 ```rust
 use sdr_aaronia_rs::seify_impl::AaroniaSeifyDevice;
 use seify::{Args, RxDevice, RxStreamer, DeviceInfo};
@@ -95,13 +100,29 @@ SoapySDRUtil --info
 
 ### Usage
 
-The driver expects the `url` argument to connect to the Spectran V6 RTSA HTTP server.
+`url=` connects to an RTSA-Suite HTTP server block, `file=` plays back a
+recording, and `sdk=true` (or `serial=<device serial>`) opens the device
+through the Aaronia native SDK — a build with `-DAARONIA_NATIVE_SDK=ON`
+on a machine with RTSA-Suite PRO installed. A bare `driver=aaronia` keeps
+its old meaning, the HTTP server on localhost; when the SDK is installed,
+`SoapySDRUtil --find` lists a second, `sdk=true` entry beside it.
 
 ```bash
 # Example testing with SoapySDRUtil
 SoapySDRUtil --probe="driver=aaronia,url=http://localhost:54664"
+SoapySDRUtil --probe="driver=aaronia,sdk=true"
 ```
 
+Two things learned running the plugin on Windows inside a GNU Radio
+(radioconda) install: that build's Python binding rejects the `dict`
+form for every driver — `SoapySDR.Device("driver=aaronia,sdk=true")`
+works where `SoapySDR.Device(dict(driver="aaronia", sdk="true"))` raises
+"no match" — and a host process that has already loaded its own Qt6
+(GNU Radio Companion itself) cannot also load the Aaronia SDK, which
+brings a different Qt6; use `url=` from inside GRC. Loading the SDK from
+a host whose *directory* merely contains Qt6 copies, such as
+`SoapySDRUtil` in radioconda's `Library\bin`, works since 0.8.3.
+
 In Python (using `SoapySDR` python bindings):
 ```python
 import SoapySDR
@@ -161,3 +182,48 @@ In SoapySDR, you can access these metrics via the `readSensor()` API:
 drops = sdr.readSensor("cumulative_drops")
 print(f"Gaps seen: {drops}")
 ```
+
+### Sensors
+
+Over the **HTTP backend** the plugin also surfaces the device's live
+telemetry from `/healthstatus` as SoapySDR sensors. `listSensors()`
+returns only those the device is currently reporting:
+
+```python
+for name in sdr.listSensors():
+    info = sdr.getSensorInfo(name)
+    print(f"{name} = {sdr.readSensor(name)} {info.units}")
+# fpga_temp = 54.3 C
+# frontend_temp = 65.1 C
+# adc_range = 29.4 dB        # headroom below full scale; near 0 is close to clipping
+# usb_buffer = 0.0625        # transfer-buffer fill, fraction 0-1
+# dsp_buffer = 0
+# gps_satellites = 0
+# ...plus cumulative_drops
+```
+
+`adc_range` is the one to watch when setting the reference level, and a
+climbing `usb_buffer` is the first sign the host is not draining the
+stream fast enough. The reads are briefly cached, so a probe's burst of
+`readSensor` calls costs one HTTP fetch, and they go through a separate
+connection from the sample stream — polling sensors during a capture does
+not stall sample delivery. Over the **native SDK** backend only
+`cumulative_drops` is reported: the raw SDK's own `AARTSAAPI_ConfigHealth`
+tree reads all zeros (the live telemetry is populated by RTSA-Suite, the
+managing application, not by the raw SDK), so exposing it there would
+report a device permanently at 0 °C.
+
+### Bandwidth
+
+SoapySDR keeps sample rate and analog/usable bandwidth as separate knobs.
+The RTSA's alias-free bandwidth is ~0.8x its sample rate, exposed here:
+
+```python
+sdr.setBandwidth(SoapySDR.SOAPY_SDR_RX, 0, 10e6)   # asks for ~10 MHz usable
+print(sdr.getBandwidth(SoapySDR.SOAPY_SDR_RX, 0))  # the bandwidth actually delivered
+print(sdr.listBandwidths(SoapySDR.SOAPY_SDR_RX, 0))
+```
+
+`setBandwidth` maps the request to the nearest sample-rate rung and
+drives `setSampleRate`; the two stay consistent, so setting either
+updates the other.

{python_aaronia-0.8.2 → python_aaronia-0.9.0}/docs/VERIFICATION.md

@@ -38,7 +38,9 @@ full V6 are marked unverified.
 | Native SDK from Python (`aaronia.open(sdk=True)`) | Native SDK | **Verified manually** on the same machine against radioconda's Python 3.12: 15.363 MS/s of a 15.36 MS/s request into NumPy, retune, timestamps and drop counters populated |
 | Native SDK from the C ABI | Native SDK | **Live-verified**: a builder with neither URL nor file auto-detects the SDK; there is still no explicit selector over C |
 | Native SDK from Seify (`sdk=true`) | Native SDK | Compiled with `--features seify,native-sdk`; the live test exists but was not run on this pass |
-| SoapySDR plugin over the native SDK | Native SDK | **Verified manually** on Windows 11: built with MSVC (VS 2022 Build Tools) against radioconda's SoapySDR 0.8.1, loads into it, and streams 15.357 MS/s of a 15.36 MS/s request into Python via `driver=aaronia,serial=…` (`SoapySDR.Device("driver=aaronia,serial=…")` — that build's binding rejects the `dict` form for every driver). The plugin reaches the SDK only through `serial=`; a bare `driver=aaronia` still pins to localhost HTTP. In the C++ host `SoapySDRUtil`, which sits beside radioconda's own Qt6 copies, the SDK library failed to load: the loader searched the host's directory ahead of the SDK's, fixed after 0.8.2 |
+| SoapySDR plugin over the native SDK | Native SDK | **Verified manually** on Windows 11: built with MSVC (VS 2022 Build Tools) against radioconda's SoapySDR 0.8.1, loads into it, and streams 15.357 MS/s of a 15.36 MS/s request into Python. `find` advertises a `sdk=true` device when the SDK is installed, and `sdk=true`/`serial=` open it; `SoapySDR.Device("driver=aaronia,sdk=true")` works (that build's binding rejects the `dict` form for every driver). The C++-host DLL-load failure — the loader reaching radioconda's own Qt6 first — is fixed in 0.9.0 (search restricted to the DLL dir, SDK root, System32) |
+| SoapySDR bandwidth API (`setBandwidth`, `getBandwidth`, `listBandwidths`, `getBandwidthRange`) | Both | **Verified manually** on a V6 ECO over the native SDK: `getBandwidth` at 15.36 MS/s reports 12.288 MHz (0.8x), the ladder lists one usable bandwidth per rung, and `setBandwidth` snaps to a rung through the live-verified `setSampleRate`. Pure reparametrization, so the HTTP path follows |
+| SoapySDR sensors (temperatures, ADC range, buffer fill, GPS) | HTTP | **Live-verified** on a V6 ECO: the crate's `live_device_sensors` reads real values over HTTP (FPGA temp, ADC range), and the plugin's `readSensor`/`listSensors` return the full set through `SoapySDRUtil` / Python. Parser also unit-tested against a `/healthstatus`-shaped tree. Over the native SDK the plugin reports only `cumulative_drops`: the raw SDK's `AARTSAAPI_ConfigHealth` tree reads all zeros (dumped live), the live telemetry being RTSA-Suite's, not the raw SDK's — so rich sensors are HTTP-only by design |
 | HTTP TX push (`/sample`) | HTTP | Endpoint exercised live; RF output not measured |
 
 "Live-verified" means an `#[ignore]`d test in

{python_aaronia-0.8.2 → python_aaronia-0.9.0}/include/aaronia.h

@@ -96,6 +96,24 @@ typedef struct FfiDeviceCapabilities {
     const char*         rx_antenna;     // e.g. "RX1"; NULL if the mode names none
 } FfiDeviceCapabilities;
 
+/* Live sensor readings. A plain value struct the caller allocates; every
+ * field is a reading or NaN for "not reported". No ownership, nothing to
+ * free. Fill it with aaronia_source_read_sensors. */
+typedef struct FfiDeviceSensors {
+    double fpga_temp_c;
+    double frontend_temp_c;
+    double board_power_w;
+    double adc_range_db;              // ADC headroom below full scale, dB
+    double usb_buffer_fill;          // fraction 0.0-1.0
+    double dsp_buffer_fill;          // fraction 0.0-1.0
+    double errors_per_second;
+    double usb_overflows_per_second;
+    double dsp_overflows_per_second;
+    double gps_satellites;
+    double gps_latitude;             // degrees; 0 with no fix
+    double gps_longitude;            // degrees; 0 with no fix
+} FfiDeviceSensors;
+
 // Opaque pointers
 typedef struct AaroniaSourceBuilder AaroniaSourceBuilder;
 typedef struct AaroniaSource AaroniaSource;
@@ -116,6 +134,24 @@ void aaronia_source_builder_reference_level(AaroniaSourceBuilder* builder, doubl
 void aaronia_source_builder_http_source(AaroniaSourceBuilder* builder, const char* base_url);
 void aaronia_source_builder_file_source(AaroniaSourceBuilder* builder, const char* file_path);
 void aaronia_source_builder_device_serial(AaroniaSourceBuilder* builder, const char* serial);
+
+/* Pin the source to one backend instead of auto-detecting. Forcing
+ * NativeSdk makes a missing SDK a build error rather than a silent
+ * fallback to localhost HTTP. */
+void aaronia_source_builder_force_source_type(AaroniaSourceBuilder *builder,
+                                              CAaroniaSourceType source_type);
+
+/* Whether the native SDK library is present, by the search the builder
+ * uses; does not load it. */
+bool aaronia_sdk_installed(void);
+
+/* Alias-free bandwidth (Hz) delivered at an IQ sample rate; smaller than
+ * the rate. Stateless. */
+double aaronia_usable_bandwidth_hz(double sample_rate_hz);
+
+/* The IQ sample rate (Hz) whose alias-free bandwidth covers bandwidth_hz;
+ * the inverse of aaronia_usable_bandwidth_hz. Stateless. */
+double aaronia_iq_sample_rate_for_bandwidth(double bandwidth_hz);
 // RX channel selection (native-SDK backend): 0 = Rx1 (default),
 // 1 = Rx2, 2 = Rx1+Rx2 dual capture (read with
 // aaronia_source_read_samples_dual). Other values ignored.
@@ -172,6 +208,12 @@ void aaronia_source_info_free(FfiSourceInfo* info);
 FfiDeviceCapabilities* aaronia_source_get_capabilities(AaroniaSource* source);
 void aaronia_source_capabilities_free(FfiDeviceCapabilities* caps);
 
+/* Fill *out with the device's live sensors. Returns true when the read
+ * completed (fields may be NaN where unreported; file/native-SDK backends
+ * complete all-NaN), false (out untouched) for a null pointer or a
+ * current-thread runtime. Blocking: one /healthstatus GET on HTTP. */
+bool aaronia_source_read_sensors(AaroniaSource* source, FfiDeviceSensors* out);
+
 // --- Sink FFI --- //
 //
 // WARNING: the whole TX path is hardware-unverified (driven per the
@@ -233,6 +275,11 @@ AaroniaFfiError aaronia_sink_write_samples(
 HttpEndpointsClient* aaronia_endpoints_client_new(const char* base_url);
 void aaronia_endpoints_client_free(HttpEndpointsClient* client);
 FfiServerInfo* aaronia_endpoints_client_get_info(HttpEndpointsClient* client);
+
+/* Fill *out with the device's live sensors through a standalone client,
+ * off the streaming source's read lock. Same reading and return contract
+ * as aaronia_source_read_sensors. */
+bool aaronia_endpoints_client_read_sensors(HttpEndpointsClient* client, FfiDeviceSensors* out);
 void aaronia_server_info_free(FfiServerInfo* info);
 AaroniaFfiError aaronia_endpoints_client_control_streaming(HttpEndpointsClient* client, bool start);
 AaroniaFfiError aaronia_endpoints_client_control_recording(HttpEndpointsClient* client, bool start, const char* name);

{python_aaronia-0.8.2 → python_aaronia-0.9.0}/python-aaronia/Cargo.toml

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