python-aaronia 0.7.3__tar.gz → 0.7.5__tar.gz

{python_aaronia-0.7.3 → python_aaronia-0.7.5}/CHANGELOG.md

@@ -4,6 +4,155 @@ All notable changes to this project will be documented in this file.
 
 ## [Unreleased]
 
+## [v0.7.5] - 2026-08-13
+
+### Added
+- **`scale` on the Python config and `aaronia.open()`**, the integer
+  encode multiplier for the `I16` wire format. Rust, the C API and the
+  SoapySDR plugin all had it; Python did not, so a Python program
+  choosing `I16` for bandwidth had no way out of the trap below.
+- **`scripts/validate-iq-live.py`**, an end-to-end check that the
+  samples an application receives are the ones the device sent, rather
+  than that bytes arrived. Every wire format must decode to the same
+  spectrum, the Python and SoapySDR paths must agree, and a known
+  transmitter must land where it should. Run against a live server it
+  places a NOAA weather-radio carrier within 312 Hz of 162.400 MHz and
+  on the correct side of zero — the one check that catches transposed
+  I and Q, which nothing comparing the radio against itself can see.
+
+### Fixed
+- **`format="I16"` silently discards weak signals at the default
+  scale.** The server sends `round(value * scale)`, so the step is
+  `1 / scale`, and the default of 16384 gives 6.1e-5 — coarser than a
+  quiet band's noise floor. Measured against a live server, **68% of
+  int16 samples came back exactly zero** where float32 had none. At
+  `scale=1e6` the zero fraction was 0.0% and the amplitude matched
+  float32. Documented, with the measurements, in the Python README.
+
+### Changed
+- **The Homebrew formula is no longer a release asset.** It is uploaded
+  as the `homebrew-formula` workflow artifact instead. Homebrew 4 and
+  later cannot install from a formula URL, so on the release page it
+  was a file no user could act on, listed among ones they can. Its only
+  reader is whoever updates the tap, and the checksums are still
+  rendered against the published archives so none are computed by hand.
+
+### Documentation
+- **Wire format is a throughput decision, and the default is the
+  expensive one.** At 15.36 MS/s over a LAN, float32 needs 123 MB/s:
+  measured, it delivered 6.5 MS/s with 290 drops, while float16 and
+  int16 both delivered 15.1 MS/s. The Python README now carries the
+  numbers rather than a general warning.
+- **Measured what the 80% usable-bandwidth figure actually is, and
+  explained it in one sentence.** Sample rate and RF bandwidth were
+  described as related by a ratio without saying what the ratio was or
+  where it came from. RTSA declares exactly 0.8 x Fs as the packet's
+  frequency range at every rate — a fixed rule, checked at 61.44,
+  15.36, 7.68 and 3.84 MHz — and every sample still arrives, so an FFT
+  spans the whole rate while only that 80% is flat and calibrated.
+  Sweeping the receiver's own noise floor on a V6 ECO confirms it: the
+  response is flat within 0.5 dB across 0.80 of the rate at 15.36 MHz
+  sampling and 0.89 at 7.68 MHz, and at full span the analog filter is
+  about 1 dB down by the declared edge — which is where Aaronia's
+  44 MHz data-sheet figure comes from, against the 49.152 MHz the
+  device itself declares. The guidance readers need is one line: to see
+  N Hz of spectrum, sample at N / 0.8.
+- **The READMEs stated the V6 ECO's sample-rate ladder as if it were
+  every device's.** "The device runs a fixed ladder of rates: 61.44 MHz
+  halved down to 120 kHz" is measured and true for an ECO, but a full
+  V6 selects its receiver clock and starts higher — by how much is the
+  open question the specs already record, and the user-facing pages did
+  not carry it. The Python, SoapySDR, quickstart and applications docs
+  now say whose ladder it is and point at the note, and
+  `iq_sample_rates` says so in its own documentation.
+- The SoapySDR README gained a Sample rates section: why
+  `listSampleRates` reports the real ladder, that `setSampleRate` snaps
+  and logs, and that `getSampleRate` while streaming is the number to
+  trust on hardware the advertised ladder does not describe.
+- SDKSPEC still gave the eco family's clock as 61.44 MHz in a second
+  place, contradicting the correction made elsewhere in the same
+  document. It is 92.16 MHz; 61.44 MHz is the top IQ rate.
+- The same sweep caught the claim in `unified_source`'s own
+  documentation, in the `/control` span note in HTTPSPEC, and in the
+  0.8 usable-bandwidth ratio, all of which read as universal and are
+  measurements from one device. `seify_impl`'s sample-rate range is
+  capped at 61.44 MHz for the same reason and now says so: seify has no
+  device handle at that point to ask for something better.
+
+## [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

{python_aaronia-0.7.3 → python_aaronia-0.7.5}/Cargo.lock

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

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

{python_aaronia-0.7.3 → python_aaronia-0.7.5}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: python-aaronia
-Version: 0.7.3
+Version: 0.7.5
 Classifier: Programming Language :: Rust
 Classifier: Programming Language :: Python :: Implementation :: CPython
 Classifier: License :: OSI Approved :: GNU General Public License v3 or later (GPLv3+)
@@ -88,17 +88,66 @@ above depends on.
 
 ## Sample rates
 
-The device runs a fixed ladder of rates: 61.44 MHz halved down to
-120 kHz. Ask for anything else and it quietly uses the nearest rung,
-leaving your program computing against a rate that is not in use.
+The device runs a ladder of rates rather than a continuous range: each
+rung is half the one above it. Ask for anything else and it quietly
+uses the nearest rung, leaving your program computing against a rate
+that is not in use.
 
 ```python
 aaronia.sample_rates()                  # every rate, highest first
 aaronia.sample_rate_for_bandwidth(8e6)  # 15.36e6: the lowest rate covering 8 MHz
 ```
 
-A rate carries only 80% of itself as alias-free bandwidth, which is why
-8 MHz of spectrum needs 15.36 MHz of sampling.
+**Sample rate is not RF bandwidth.** You get every sample, so an FFT of
+them spans the full rate — but only the middle 80% is flat and
+calibrated. That is not an approximation: RTSA reports exactly 0.8 x Fs
+as the packet's frequency range at every rate. Outside it, data still
+arrives, attenuated and uncalibrated.
+
+So **to see N Hz of spectrum, sample at N / 0.8**, which is what
+`sample_rate_for_bandwidth()` computes. Aaronia's data sheet quotes a
+more conservative figure still — 44 MHz for the ECO against the
+49.152 MHz it declares at full span — because the analog filter is
+already about 1 dB down at that edge. The
+[quickstart](https://github.com/isaacbentley/sdr-aaronia-rs/blob/main/docs/QUICKSTART.md#4-troubleshooting)
+has the measurements.
+
+`sample_rates()` returns the ladder for a SPECTRAN V6 ECO — 61.44 MHz
+down to 120 kHz — which is measured, rung by rung. A full V6 has a
+selectable receiver clock and can go higher, and exactly how much
+higher is not settled; see
+[the note in HTTPSPEC](https://github.com/isaacbentley/sdr-aaronia-rs/blob/main/docs/HTTPSPEC.md#unresolved-the-full-v6s-top-rate).
+On that hardware, take the rate the device reports over the computed
+ladder: it arrives in the stream metadata, and `diagnose()` prints it.
+
+## Choosing a wire format
+
+`format` decides what crosses the network, and it matters more than it
+looks. Measured against a live server at 15.36 MS/s over a LAN:
+
+| format | bytes/sample | delivered | drops |
+| --- | --- | --- | --- |
+| `F32` (default) | 8 | 6.5 MS/s | 290 |
+| `F16` | 4 | 15.1 MS/s | 9 |
+| `I16` | 4 | 15.1 MS/s | 12 |
+
+`F32` needs 123 MB/s at that rate and the link could not carry it, so
+most of the capture was dropped. Either half-width format fits.
+
+`I16` has one trap: the server sends `round(value * scale)`, so the
+quantisation step is `1 / scale`, and the default of 16384 gives a step
+of 6.1e-5. A quiet band's noise floor is smaller than that — on the
+same server, **68% of `I16` samples came back exactly zero** while
+`F32` had none. Pass `scale=`, or lower `reference_level` for more
+gain:
+
+```python
+aaronia.open(url, freq=2.44e9, rate=15.36e6, format="I16", scale=1e6)
+```
+
+At `scale=1e6` the zero fraction measured 0.0% and the amplitude
+matched `F32`. `F16` needs no such tuning, which makes it the simpler
+choice when the link is the constraint.
 
 ## Configuration (`AaroniaConfig`)
 
@@ -113,6 +162,7 @@ Every field is readable and writable.
 | `sample_rate` | IQ sample rate, Hz (the Aaronia "span") |
 | `reference_level` | Reference level, dBm |
 | `format` | HTTP wire format: `"F32"`, `"F16"` or `"I16"`. `I16` is the low-bandwidth network mode |
+| `scale` | Integer encode multiplier for `I16` (see below). None uses the server default |
 | `receiver_channel` | `"Rx1"` (default), `"Rx2"`, or `"Rx1And2"` (native SDK, full V6) |
 | `read_timeout` | Seconds a blocking read waits before `AaroniaTimeoutError` (default `30.0`) |
 | `auto_reconnect` | Reconnect the HTTP stream after a drop (default `True`) |
@@ -169,8 +219,8 @@ silently defaulting.
 
 | Function | Purpose |
 | --- | --- |
-| `open(url=None, *, freq, rate, bandwidth, ref_level, file, format, read_timeout)` | Configure, connect and start streaming in one call |
-| `sample_rates()` | Every sample rate the hardware can run |
+| `open(url=None, *, freq, rate, bandwidth, ref_level, file, format, scale, read_timeout)` | Configure, connect and start streaming in one call |
+| `sample_rates()` | The V6 ECO's sample rates, highest first (see [Sample rates](#sample-rates)) |
 | `sample_rate_for_bandwidth(hz)` | Lowest rate covering that much spectrum |
 | `diagnose(url)` | `(ok, message, fix)` for each setup check; what `aaronia-doctor` prints |
 

{python_aaronia-0.7.3 → python_aaronia-0.7.5}/docs/APPS.md

@@ -50,9 +50,12 @@ driver=aaronia,url=http://localhost:54664
 ```
 
 Select the sample rate from GQRX's list. The plugin advertises the
-device's real ladder: 61.44 MHz halved down to 120 kHz, which the RTSA
-GUI labels Full through 1/512. The hardware produces no other rate, so a
-request in between snaps to the nearest rung and logs a warning.
+device's real ladder rather than round numbers it cannot produce: on a
+V6 ECO that is 61.44 MHz halved down to 120 kHz, which the RTSA GUI
+labels Full through 1/512. Nothing in between exists, so a request
+between rungs snaps to the nearest and logs a warning. A full V6 has a
+selectable receiver clock and reaches higher; the plugin advertises the
+ECO ladder, so check the rate the device reports if you are on one.
 
 The single gain element is `REF`, the Aaronia reference level in dBm. It
 is not an amplifier gain: raising it reduces sensitivity. Start near
@@ -101,8 +104,13 @@ directly and skip the SoapySDR layer.
 
 ## General notes
 
-- Sample rate is the Aaronia "span", not the usable RF bandwidth. The
-  alias-free span is smaller, roughly 49 MHz within a 61.44 MHz capture.
+- Sample rate is the Aaronia "span", not the usable RF bandwidth. Every
+  sample reaches the application, so the display spans the full rate,
+  but only the middle 80% is flat and calibrated — RTSA reports exactly
+  0.8 x Fs as the packet's frequency range. Set the rate whose 80%
+  covers the span you want to see: 61.44 MHz of sampling gives roughly
+  49 MHz of calibrated spectrum. The edges are real data, just rolled
+  off.
 - `readStream` honours `timeoutUs` and returns partial reads within the
   deadline, per the SoapySDR contract.
 - Retuning mid-stream is safe and requires no Aaronia licence.

{python_aaronia-0.7.3 → python_aaronia-0.7.5}/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
@@ -284,7 +357,17 @@ packet-metadata object, so `payload`, `minPower`, `maxPower`, and
 ```
 
 > **`frequencySpan` is a usable-bandwidth request, not a sample rate.**
-> The device runs at 61.44 MHz divided by a power of two. Given a span
+> The device halves its top rate down a ladder — 61.44 MHz on the V6
+> ECO this was measured against. The usable RF bandwidth it declares in
+> `startFrequency..endFrequency` is exactly 0.8 x Fs at every rate,
+> checked at 61.44, 15.36, 7.68 and 3.84 MHz; every sample still
+> arrives, so an FFT spans the whole rate, but only that 80% is flat
+> and calibrated. Sweeping the receiver's own noise floor puts the real
+> filter at or beyond the declared edge at decimated rates (flat within
+> 0.5 dB across 0.80 x Fs at 15.36 MHz, 0.89 at 7.68 MHz) and just
+> inside it at full span (about 1 dB down at the declared edge, 3 dB at
+> 0.84 x Fs), which is where Aaronia's 44 MHz data-sheet figure for the
+> ECO comes from. Given a span
 > it cannot produce, it selects the rate whose alias-free bandwidth
 > (0.8 x Fs) is nearest the request: 2.5 MHz yields Fs = 3.84 MHz,
 > 1.3 MHz yields 1.92 MHz, and 10 MHz yields 15.36 MHz. A value that is
@@ -320,7 +403,7 @@ packet-metadata object, so `payload`, `minPower`, `maxPower`, and
 }
 ```
 
-#### Save/Reload Mission
+#### Save/Reload/Load Mission
 ```json
 {
   "save": true,
@@ -328,6 +411,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 +535,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 +560,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 +592,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 +722,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 +787,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 +848,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 +879,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 +1024,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