python-aaronia 0.7.2__tar.gz → 0.7.4__tar.gz

{python_aaronia-0.7.2 → python_aaronia-0.7.4}/CHANGELOG.md

@@ -4,6 +4,90 @@ All notable changes to this project will be documented in this file.
 
 ## [Unreleased]
 
+## [v0.7.4] - 2026-08-12
+
+### Fixed
+- **The SoapySDR plugin ignored an unrecognised `format=` silently.**
+  A device string carrying `format=int16` — the wire name rather than
+  the plugin's `I16` — streamed the default format while claiming
+  otherwise. It now warns and continues. The server behaves the same
+  way and worse: an unrecognised `format=` on `/stream` serves the
+  RTSA file format with HTTP 200 rather than an error, so a typo
+  changes the wire format entirely. `raw16`, which Aaronia's own Qt
+  reference client sends, is a working alias for `int16`.
+
+### Documentation
+- Checked Aaronia's V6 remote control notes (rev 4, May 2026) against
+  the hardware. `/remoteconfig` enum fields take an index as well as a
+  label; one `simpleconfig` PUT can carry several groups, and groups
+  other than `main` work; and a PUT naming a block that is not in the
+  mission returns 200 and changes nothing, which
+  `simple_remote_config` now warns about since it reports `Ok(())` for
+  a write that did not happen. In the config-tree form the receiver
+  name is ignored altogether — the write is routed by `config.name`.
+- Documented loading a mission over `/control`, and that every
+  `/control` payload needs its `type` or the server answers `400`.
+  Loading a mission is deliberately not exposed by the crate: swapping
+  the mission under a running capture should be a caller's decision,
+  not a side effect.
+- Noted that RTSA-Suite has no status endpoint. Aaronia's own liveness
+  check reads the `404` from `/api/status` as proof the server is up.
+- **What "Full" means on a full V6 is unresolved.** A V6 ECO follows the
+  SDK's `spanfreq <= receiverclock / 1.5`, measured. Aaronia's Remote
+  Config screenshots show a full V6 at a 92 MHz clock delivering
+  92.16 MHz of IQ samples per second at span "Full" — the clock itself.
+  `iq_sample_rates_for_clock` may therefore understate the top of the
+  ladder by 1.5x for a full V6 at a non-default clock; it says so now.
+  Settling it needs a full V6.
+- HTTPSPEC contradicted itself on the Remote Config licence, asserting
+  in one section that writes need it and in another that a live
+  unlicensed system accepts them. The second is what the hardware does,
+  re-confirmed for centre frequency, decimation, reference level and
+  the preamplifier.
+- SDKSPEC still gave the V6 ECO's receiver clock as 61.44 MHz, which
+  0.6.2 corrected in code to 92.16 MHz. 61.44 MHz is the ECO's top IQ
+  rate, that clock over 1.5; the document had the two confused.
+- **A marker stream is not a categories packet**, which the previous
+  draft of this entry got wrong. Aaronia's example declares
+  `payload: "spectra"`, and spectra samples are a 2D array, so its
+  nesting is correct for what it says it is. Its three frequency fields
+  are all zero, so the category names and ranges are the only
+  description of what the numbers mean.
+- Aaronia's endpoint specification (rev 11) settles several things this
+  document had only inferred, and their support answers go further.
+  `/control` takes PUT only, and a command reaches every block that
+  understands it unless `receiverUUID` or `receiverName` scopes it —
+  the specification says such commands cannot be addressed to a block,
+  which their support corrected in 2024. The per-type settings are now
+  listed in full, including `deviceconnect` and `camera`, which this
+  crate does not model. Zones cannot be configured remotely at all.
+  The server starts dropping data once its outbound TCP buffer passes
+  8 MB, which is the mechanism behind most unexplained gaps.
+  `/healthstatus` is organised as `info`, `status`, `health`,
+  `settings` and `components`, the last being how satellites attached
+  over HTTP appear in a local tree.
+- **`status/iqsamples` is the native rate, not the delivered one.** It
+  held at 61.44 MHz while the same device delivered 15.36, then 7.68,
+  then 61.44 MS/s. It looks like a sample rate and is not the one your
+  stream is running at; read `sampleFrequency` from packet metadata.
+  Documented the other fields a V6 ECO reports alongside it.
+- **One HTTP Server and one HTTP Client connection are free**;
+  additional instances and connections are licensed separately, as are
+  Stream Merger and Stream Splitter. Running this crate and a second
+  client against one server at the same time is a second connection —
+  the licence limit most likely to be met in practice, and unrelated to
+  Remote Config.
+
+## [v0.7.3] - 2026-08-12
+
+### Fixed
+- The Windows leg of the new module load check could not run: vcpkg's
+  SoapySDR port ships no `SoapySDRUtil`, so the check failed rather
+  than verifying anything, and 0.7.2 published no release archives.
+  Where the tool is absent the packaged DLL is now loaded directly,
+  which still catches a module whose dependencies do not resolve away
+  from the build machine.
+
 ## [v0.7.2] - 2026-08-12
 
 ### Fixed
@@ -31,10 +115,11 @@ All notable changes to this project will be documented in this file.
 
 ## [v0.7.1] - 2026-08-12
 
-An incomplete fix for the macOS module, superseded by 0.7.2. It reached
-crates.io and PyPI but published no GitHub release: the new load check
-refused to ship a macOS module that would not open. The Rust crate and
-the Python wheels are sound and identical in content to 0.7.2.
+An incomplete fix for the macOS module, superseded by 0.7.2. Like
+0.7.2, it reached crates.io and PyPI but published no release archives,
+because the new load check refused to ship a macOS module that would
+not open. Its crate and wheels are sound and identical in content to
+0.7.3.
 
 ## [v0.7.0] - 2026-08-12
 

{python_aaronia-0.7.2 → python_aaronia-0.7.4}/Cargo.lock

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

{python_aaronia-0.7.2 → python_aaronia-0.7.4}/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.2"
+version = "0.7.4"
 edition = "2024"
 repository = "https://github.com/isaacbentley/sdr-aaronia-rs"
 readme = "README.md"

{python_aaronia-0.7.2 → python_aaronia-0.7.4}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: python-aaronia
-Version: 0.7.2
+Version: 0.7.4
 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.2 → python_aaronia-0.7.4}/docs/HTTPSPEC.md

@@ -161,6 +161,43 @@ http://localhost:54664/stream?format=int16&scale=1000000
 http://localhost:54664/stream?rate_reduction=10
 ```
 
+### An unknown `format` is not an error
+
+`format=` accepts `json`, `int16`, `float16` and `float32`. `raw16` is
+an accepted alias for `int16` — Aaronia's own Qt reference client
+defaults to it — and produces byte-identical framing.
+
+Anything the server does not recognise serves **the RTSA file format**
+instead: a `DSFH` header followed by `STRM`/`ANTA` chunks, with HTTP
+200 and no warning. A typo in `format=` therefore yields a completely
+different wire format rather than an error, and a parser expecting
+JSON-plus-binary will fail somewhere well past the point that would
+have identified the cause. Verified against a live server: `format=`
+with a nonsense value returned `DSFH`.
+
+This crate builds the string from an enum, so it cannot typo, and the
+SoapySDR plugin now warns on an unrecognised `format=` device argument
+rather than silently falling back to the default.
+
+### When the server drops data
+
+The HTTP server block starts dropping data once its outbound TCP
+buffer passes **8 MB**. Nothing announces it; the loss shows up as a
+gap between the timestamps of two adjacent packets, which is what
+`DropDetector` watches for. A slow consumer, a slow link, or a rate
+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.
+
+### Liveness
+
+There is no status endpoint. Aaronia's own remote control notes probe
+with `curl -v http://127.0.0.1:54664/api/status` and treat the `404 Not
+Found` as the answer: a reply of any kind proves the port is open, the
+mission is loaded and the HTTP Server block is running. A connection
+refused or a timeout means it is not. `/info` serves the same purpose
+and returns something useful, which is what this crate uses.
+
 ### Application Process Control
 **URL**: `/app/process`  
 **Method**: PUT  
@@ -250,6 +287,42 @@ packet-metadata object, so `payload`, `minPower`, `maxPower`, and
 `stepFrequency` (the sample rate) is optional; `push: true` marks the packet for immediate transmission.
 
 ### Control Endpoint
+
+`/control` accepts **PUT only**. A GET — which is what a browser does
+with the URL — is not supported.
+
+**A command reaches every block that understands it, unless you scope
+it.** Aaronia's 2022 specification says control commands "are not
+addressed to a specific RTSA block and will be processed from all RTSA
+blocks in the block graph", which is true as a default. Their support
+staff refined it in 2024: `receiverUUID` and `receiverName` "can be
+used to limit the requested setting to individual blocks", and "in some
+cases it may be necessary to specify them". Read the names or UUIDs
+from `/remoteconfig` first if you need to target one block.
+
+These are one-off requests. Aaronia's own words: if they cannot be
+executed, or conflict with the local configuration, the behaviour is
+undefined — nothing reports the conflict.
+
+**The settings each `type` accepts**, per Aaronia support (January
+2024), which goes well beyond the published specification:
+
+| `type` | Settings |
+| :--- | :--- |
+| `capture` | `receiverUUID`, `receiverName`, `frequencyCenter`, `frequencyStart`, `frequencyBins`, `referenceLevel`, `start` — plus `frequencySpan` and `frequencyEnd`, which the specification documents and this crate uses |
+| `deviceconnect` | `receiverUUID`, `receiverName`, `start` — connect or disconnect a device |
+| `streaming` | `receiverUUID`, `receiverName`, `filename`, `start` |
+| `recording` | `receiverUUID`, `receiverName`, `filename`, `start` |
+| `mission` | `save`, `reload`, `load` (with the path in `file`) |
+| `antenna` | `receiverUUID`, `receiverName`, `latitude`+`longitude` (both or neither), `azimuth`+`declination`, `rotate` |
+| `camera` | `receiverUUID`, `receiverName`, `latitude`+`longitude`, `azimuth`+`declination`, `aperture`, `channel`, `altitude`, `start` |
+
+`start`, `rotate`, `save`, `load` and `reload` are booleans. A
+`filename` must be an absolute path **on the machine running
+RTSA-Suite**, with forward slashes.
+
+Zones cannot be configured this way; Aaronia state that remote
+configuration of zones is not supported.
 **URL**: `/control`  
 **Method**: PUT  
 **Description**: Send commands to the RTSA suite
@@ -320,7 +393,7 @@ packet-metadata object, so `payload`, `minPower`, `maxPower`, and
 }
 ```
 
-#### Save/Reload Mission
+#### Save/Reload/Load Mission
 ```json
 {
   "save": true,
@@ -328,6 +401,28 @@ packet-metadata object, so `payload`, `minPower`, `maxPower`, and
 }
 ```
 
+A mission can also be swapped outright, which is how a headless station
+changes what it is running. `load` takes an absolute path to an `.rmix`
+on the machine running RTSA-Suite, not on the client:
+```json
+{
+  "type": "mission",
+  "load": true,
+  "file": "C:/Aaronia/Recordings/HTTP streaming/http_test.rmix"
+}
+```
+A mission carrying an HTTP Server block must already be running, or
+there is nothing listening to accept the request. Aaronia's remote
+control notes (rev 4, May 2026) give this as a `curl` invocation from
+an elevated prompt. This crate does not expose it: swapping the mission
+out from under a running capture is the caller's decision to make
+deliberately, not a side effect of a library call.
+
+**Every `/control` payload needs its `type`.** A body without one is
+rejected with `400` and the text `Type argument missing`, so a
+hand-built payload that omits it fails loudly rather than silently —
+unlike a partial capture request, which is accepted and ignored.
+
 ### Configuration Endpoints
 
 #### Server Info (`/info`)
@@ -430,8 +525,18 @@ Notes verified against a live V6 ECO:
   and `frequencySpan` are both present.
 - **The `receiverName` key is case-tolerant.** `receivername` was accepted
   identically.
-- Enum-valued settings are written as their label string, for example
-  `decimation` as `"1 / 128"`, not as an index.
+- **Enum-valued settings take either the label string or the index.**
+  Aaronia's example writes `decimation` as `"1 / 128"`; writing
+  `decimation0` as the integer `3` was accepted and applied identically
+  (verified against `/sample`: index 3 gave 7.68 MHz, index 2 gave
+  15.36 MHz). Indices are positions in the `values` list that
+  `GET /remoteconfig` reports for that item.
+- **Groups other than `main` work**, and several can go in one PUT:
+  `{"main": {...}, "calibration": {"preamp": 1}}` applied both.
+- **An unknown block name is a silent no-op.** A `simpleconfig` PUT
+  naming a block that is not in the mission returns HTTP 200 and changes
+  nothing. There is no error to catch, so read the value back if it
+  matters.
 - Other keys the example writes: `run` (bool), `preamp` (`"Auto"`),
   `reflevel` (float), and `filerecord` (bool) plus a filename template on
   a FileWriter block, which is how it starts and stops recording.
@@ -445,7 +550,15 @@ Notes verified against a live V6 ECO:
   }
 }
 ```
-`receiverName` must match a block in the running mission; `HttpEndpointsClient::find_iq_demodulator_block_name` auto-discovers it.
+`receiverName` must match a block in the running mission;
+`HttpEndpointsClient::find_iq_demodulator_block_name` auto-discovers it.
+A name that matches nothing still returns 200 (see above).
+
+In the full `{request, config}` form the receiver name is ignored
+altogether: the write is routed by `config.name`. Sending
+`receivername`, `receiverName` or no name at all applied the same
+change. Nothing depends on getting that key right, and nothing warns
+when it is wrong.
 
 **Configuration Item Fields**:
 | Field | Description |
@@ -469,6 +582,28 @@ configuration tree (`HealthStatus` is an alias for `ConfigItem`) rather
 than the typed shape below, which describes the upstream block-health
 fields.
 
+**Subgroups** per health-aware block, per Aaronia's specification:
+`info`, `status`, `health`, `settings`, and `components` — the last a
+recursive list of sub-blocks when satellites are attached over HTTP,
+which is how a remote station's devices show up in a local tree.
+
+**What a V6 ECO actually reports** under `status` and `health`,
+alongside the `info` fields below:
+
+| Item | Example | Meaning |
+| :--- | :--- | :--- |
+| `status/iqsamples` | 61439323 | **Native** IQ rate in Hz, not the delivered one. Measured constant at 61.44 MHz while the same device delivered 15.36, then 7.68, then 61.44 MS/s — it does not follow the decimation setting |
+| `status/usbbuffer` | 0.0625 | USB buffer fill, fraction |
+| `status/adcrange` | 17.16 | ADC headroom in dB |
+| `status/strmtimedist` | 5.96e-06 | Stream time distance in seconds |
+| `health/fronttemp` | 64.7 | Frontend temperature, °C |
+| `health/fpgatemp` | 52.5 | FPGA temperature, °C |
+| `health/boardpower` | 8.975 | Board power draw, W |
+
+`iqsamples` is the one to be careful with: it looks like a sample rate
+and is not the one your stream is running at. Read `sampleFrequency`
+from packet metadata for that.
+
 **Health Status Fields**:
 | Field | Description |
 | :--- | :--- |
@@ -577,7 +712,35 @@ The samples in a category ordered packet have one measurement per category.
 }
 ```
 
-As with histograms, category samples are a flat number array (one value per category).
+As with histograms, category samples are a flat number array (one value
+per category) — that is what a live server produced.
+
+**A marker stream is not a categories packet.** Aaronia's remote
+control notes show the Spectrum block's `Marker` output wired to an
+HTTP Server, and the result looks like this:
+
+```json
+{
+  "payload": "spectra",
+  "startFrequency": 0, "endFrequency": 0, "sampleFrequency": 0,
+  "sampleSize": 4, "sampleDepth": 1,
+  "categories": [
+    { "name": "Slow Sine(R)", "startFrequency": 2403000000, "endFrequency": 2405000000 },
+    { "name": "Marker",       "startFrequency": 2412852325.3, "endFrequency": 2412852335.3 }
+  ],
+  "samples": [[-78.6, -57.26, -47.28, -114.25]]
+}
+```
+
+It carries a `categories` array but declares `payload: "spectra"`, and
+spectra samples are a 2D array — one row per frame — so the nesting is
+correct for what it says it is, not a contradiction of the flat
+categories form above. `sampleSize` is the number of values in a row,
+here one per category.
+
+What is worth knowing before parsing one: all three frequency fields
+are `0`, so nothing can be derived from them, and the category names
+and ranges are the only description of what the numbers mean.
 
 ### Antenna Data
 Data captured using antennas with location or directional information.
@@ -614,7 +777,44 @@ and `Location and Time`; `sclksource` offers `Consumer`, `Oscillator`,
 
 `decimation0` takes the same labels as the SDK's `main/decimation`,
 `"Full"` through `"1 / 512"`, verified by writing one over HTTP. Both
-transports drive the same divider.
+transports drive the same divider. Over HTTP the index works as well as
+the label: writing `3` and reading `/sample` back gave 7.68 MHz, and `2`
+gave 15.36 MHz, which is 61.44 MHz halved that many times on a V6 ECO.
+
+#### Unresolved: the full V6's top rate
+
+The SDK constrains `spanfreq * 1.5 <= receiverclock`, and a V6 ECO
+follows it: its top IQ rate measures 61.44 MHz against the 92.16 MHz
+clock the crate assumes for it. `iq_sample_rates_for_clock` takes that
+ratio as the rule, so it puts a full V6 on the `245MHz` clock at
+163.84 MHz.
+
+Aaronia's own figures do not agree. Their endpoint specification closes
+with a note about achieving "the full 250M samples of IQ data", their
+block documentation advertises "a real-time bandwidth of up to 245MHz
+each" for the V6's two inputs, and both round to the 245.76 MHz that
+the `245MHz` clock label denotes — the clock itself, not two thirds of
+it.
+
+There is a reading that reconciles them. The clock list runs past
+`245MHz` to `492MHz` (491.52 MHz), and 245.76 MHz of span satisfies the
+1.5 rule against that clock with room to spare. On that reading 245 MHz
+of real-time bandwidth is real but needs the fastest clock, and the
+`245MHz` label tops out at 163.84 MHz exactly as the crate computes.
+
+What does not fit either reading is the Remote Config panel Aaronia
+published in 2021 and again in 2022: a full V6 with the clock set to
+`92MHz` reporting roughly 92.16 MHz of IQ samples per second. That
+counter is not the delivered rate — measured on an ECO, `iqsamples`
+held at 61.44 MHz while the device was actually delivering 15.36 and
+then 7.68 MHz, so it reports the native undecimated rate. Taken at face
+value it says a full V6 at a 92 MHz clock has a native rate of
+92.16 MHz, which the 1.5 rule forbids.
+
+No full V6 has been available to measure, so this stays open. The
+practical guidance is unchanged: the ECO path is verified rung by rung,
+and for anything else read the rate the device reports in its stream
+metadata rather than trusting a computed ladder.
 
 ### Two things that do not carry over
 
@@ -638,6 +838,20 @@ transports drive the same divider.
 - `/info` - Device information
 - `/healthstatus` - Device health monitoring
 
+**HTTP Server and Client blocks are themselves licensed, and the free
+tier is one of each.** Aaronia's staff put it plainly in the HTTP
+Server thread: only one HTTP Server instance is included in the free
+RTSA-Suite PRO licence and additional instances must be licensed
+separately, the same going for the HTTP Client, where only one
+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.
+
 **Remote Configuration** (`/remoteconfig`):
 - Device parameter configuration.
 - Aaronia sells a "Remote Config" license, and this document previously
@@ -655,10 +869,17 @@ transports drive the same divider.
   and may be what actually matters.
 - This crate does not depend on the answer: it tunes through `/control`,
   which needs no license.
+- Re-confirmed 2026-08-12 against RTSA-Suite PRO and a V6 ECO on the
+  same unlicensed system, in both payload forms, for `centerfreq0`,
+  `decimation0`, `reflevel0` and `calibration/preamp`.
 
 **License Detection Methods**:
 
-**Important**: Read access to `/remoteconfig` is available WITHOUT license, but write operations require the license. Because reads are license-free, a read-only check cannot distinguish "licensed" from "unlicensed" — only a write test can.
+**Important**: reads of `/remoteconfig` are license-free, so a read-only
+check cannot prove write capability either way — only a write test can.
+It cannot prove the *license* either: writes succeeded on an unlicensed
+system (see above), so a successful probe means "this server accepts
+writes", not "this server is licensed".
 
 The client therefore exposes two methods:
 
@@ -793,8 +1014,10 @@ 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.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 |
 | 2.1 | 2026-08-06 | Live-hardware corrections folded in (two-byte separator, spectra frame counting, `scale` inversion); documented `/samples`, the `/sample` TX push, and the `simpleconfig` PUT form; corrected `limit` semantics, field types, and flat histogram/categories sample arrays; removed decorative icons |
-
 ---
 
 ## Sources and Attribution

{python_aaronia-0.7.2 → python_aaronia-0.7.4}/docs/SDKSPEC.md

@@ -52,9 +52,9 @@ The Aaronia RTSA Vendor SDK provides low-level, high-performance access to Aaron
     *   **SpectranV6 ECO**: `spectranv6eco/raw`, `spectranv6eco/iqreceiver`, `spectranv6eco/iqtransceiver`, `spectranv6eco/iqtransmitter`, `spectranv6eco/sweepsa`
 *   **Configuration Tree**: Hierarchical configuration system with verified parameters:
     *   **Clock Rates** (V6): 46MHz (46.08), 61MHz (61.44), 76MHz (76.80), 92MHz (92.16), 122MHz (122.88), 184MHz (184.32), 245MHz (245.76), 492MHz (491.52) — see the full label table under [Rust Binding Notes](#rust-binding-notes)
-    *   **Clock Rates** (V6 ECO): Fixed at 61.44 MHz
+    *   **Clock Rates** (V6 ECO): fixed at 92.16 MHz. Its top IQ rate is 61.44 MHz, which is that clock over 1.5 — the two are easy to confuse and this document once recorded the rate as the clock
     *   **Decimation**: Full, 1/2, 1/4, 1/8, 1/16, 1/32, 1/64, 1/128, 1/256, 1/512
-    *   **IQ Mode Sample Rate**: equal to `spanfreq` (constraint: `spanfreq ≤ receiverclock / 1.5`)
+    *   **IQ Mode Sample Rate**: equal to `spanfreq` (constraint: `spanfreq ≤ receiverclock / 1.5`). Measured on a V6 ECO, untested on a full V6, and not obviously consistent with Aaronia's own 245 MHz / 250 Msample figures for the V6 — see [HTTPSPEC](HTTPSPEC.md#unresolved-the-full-v6s-top-rate)
 *   **Health Monitoring**: Real-time device status including temperatures, sample rates, power levels, USB statistics, GPS data
 
 The SDK is designed for building custom spectrum analysis applications, SDR integration, and specialized RF measurement tools.
@@ -256,8 +256,8 @@ source.open_device("spectranv6/raw", &serial_wide)?;
 `NativeSdkSource::configure_iq_receiver` calls
 `utils::validate_iq_mode(span, clock)` after applying the config,
 where `clock` is read live from `device/receiverclock` via
-`AARTSAAPI_ConfigGetString` (or 61.44 MHz on eco devices, which expose no
-such key and run at a fixed clock). The check enforces
+`AARTSAAPI_ConfigGetString` (or `DEFAULT_RECEIVER_CLOCK_HZ`, 92.16 MHz,
+on eco devices, which expose no such key and run at a fixed clock). The check enforces
 `span * 1.5 <= clock` and returns a typed error before the device starts.
 
 The ConfigItem labels the SDK exposes are *rounded* — `"92MHz"` is
@@ -911,8 +911,12 @@ reads a single stream and deinterleaves it, so it writes `Rx12`.
 | Raw-mode open string | `spectranv6/raw` | `spectranv6eco/rtsa` |
 
 The clock matters beyond configuration: with `span * 1.5 <=
-receiverclock`, a V6 on the fast clock reaches roughly 163 MHz of span
-where the ECO's fixed clock allows 61.44 MHz.
+receiverclock`, a V6 on the `245MHz` clock reaches roughly 163 MHz of
+span where the ECO's fixed clock allows 61.44 MHz. Aaronia advertise
+245 MHz of real-time bandwidth per input, which under this rule would
+need the `492MHz` clock; see
+[HTTPSPEC](HTTPSPEC.md#unresolved-the-full-v6s-top-rate) for why that
+is not settled.
 
 ### Sample rates
 

{python_aaronia-0.7.2 → python_aaronia-0.7.4}/packaging/homebrew/soapy-aaronia.rb

@@ -12,7 +12,7 @@
 class SoapyAaronia < Formula
   desc "SoapySDR plugin for Aaronia SPECTRAN V6 spectrum analyzers"
   homepage "https://github.com/isaacbentley/sdr-aaronia-rs"
-  version "0.7.2"
+  version "0.7.4"
   license "GPL-3.0-or-later"
 
   # Prebuilt modules: the plugin statically links its Rust core, so there

{python_aaronia-0.7.2 → python_aaronia-0.7.4}/python-aaronia/Cargo.toml

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

{python_aaronia-0.7.2 → python_aaronia-0.7.4}/soapy-aaronia/Registration.cpp

@@ -111,8 +111,22 @@ static SoapySDR::Device *makeAaronia(const SoapySDR::Kwargs &args) {
     }
     // format=I16 enables the genuine low-bandwidth HTTP wire mode
     // (int16 from the server), optionally with scale=N.
+    //
+    // Checked here rather than left to the C API, which ignores a value
+    // it does not recognise and returns nothing to say so. A typo would
+    // otherwise stream the default format while the device string
+    // claims something else — and the server is no help either: it
+    // answers an unknown `format=` with the RTSA file format rather
+    // than an error.
     if (args.count("format") != 0) {
-        aaronia_source_builder_stream_format(builder, args.at("format").c_str());
+        const std::string &fmt = args.at("format");
+        if (fmt != "F32" && fmt != "F16" && fmt != "I16") {
+            SoapySDR::logf(SOAPY_SDR_WARNING,
+                           "aaronia: ignoring format=%s; expected F32, F16 or I16",
+                           fmt.c_str());
+        } else {
+            aaronia_source_builder_stream_format(builder, fmt.c_str());
+        }
     }
     if (args.count("scale") != 0) {
         aaronia_source_builder_stream_scale(builder, parseArgDouble(args, "scale"));

{python_aaronia-0.7.2 → python_aaronia-0.7.4}/src/http_endpoints.rs

@@ -838,7 +838,21 @@ impl HttpEndpointsClient {
     /// `main` is the typical group, but any subset of the block's
     /// configuration tree may be passed via `config_groups`. Keys are
     /// group names ("main", "device", "calibration"); values are field
-    /// → `serde_json::Value` maps.
+    /// → `serde_json::Value` maps. Several groups in one call are
+    /// applied together.
+    ///
+    /// Enum fields take either the label the device reports or its
+    /// index in that item's `values` list.
+    ///
+    /// **A wrong `receiver_name` is silently accepted.** Naming a block
+    /// that is not in the running mission returns HTTP 200 and changes
+    /// nothing, so this returns `Ok(())` for a write that did not
+    /// happen. The server offers nothing to check against, so resolve
+    /// the name once from [`Self::get_config`] (or
+    /// [`Self::find_iq_demodulator_block_name`]) when the session
+    /// starts, rather than hard-coding a block name and trusting the
+    /// status code. Read the value back afterwards when a write has to
+    /// be certain.
     pub async fn simple_remote_config(
         &self,
         receiver_name: &str,

{python_aaronia-0.7.2 → python_aaronia-0.7.4}/src/utils.rs

@@ -333,8 +333,18 @@ pub fn iq_sample_rates() -> [f64; 10] {
 /// [`DEFAULT_RECEIVER_CLOCK_HZ`], verified rung by rung. A full V6 can
 /// select other clocks — Aaronia's own samples use `"92MHz"` and
 /// `"245MHz"` — and the rates there follow the same constraint but have
-/// not been confirmed against hardware. Read `device/receiverclock`
-/// from the device and pass it here rather than assuming.
+/// not been confirmed against hardware.
+///
+/// **The 1.5 may be wrong for a full V6.** Aaronia advertise 245 MHz of
+/// real-time bandwidth per input and "the full 250M samples of IQ
+/// data", which is the `245MHz` clock label itself rather than the
+/// 163.84 MHz this returns for it. That may simply mean the fastest
+/// rate needs the `492MHz` clock, where 245.76 MHz of span does
+/// satisfy the 1.5 rule; a published Remote Config panel showing a
+/// full V6 at a `92MHz` clock with a 92.16 MHz native rate fits
+/// neither reading. Until one can be measured, treat this as the ECO's
+/// ladder and prefer the rate a device reports in its stream metadata
+/// over the one computed here.
 pub fn iq_sample_rates_for_clock(receiver_clock_hz: f64) -> [f64; 10] {
     let top = receiver_clock_hz / 1.5;
     let mut rates = [0.0; 10];