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

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

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

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

@@ -2,7 +2,462 @@
 
 All notable changes to this project will be documented in this file.
 
-## [Unreleased]
+## [v0.8.0] - 2026-09-07
+
+**Breaking:** `StreamStats` gained a `device_health` field, so an
+exhaustive struct literal over it no longer compiles. It is
+`#[non_exhaustive]` now, along with the new `DeviceCapabilities` and
+`DeviceHealthSummary`: these are reports a consumer reads rather than
+builds, and the attribute makes every future field addition free. Only
+the `futuresdr` feature exposes `StreamStats`; the default feature set is
+unaffected.
+
+### Added
+- **The SoapySDR probe now reports what the device says about itself.**
+  `SoapySDRUtil --probe` published constants compiled in for one model:
+  `hardware=Spectran V6` whatever was attached, a 10 Hz–6 GHz frequency
+  range, and a −100…+10 dB gain range. A SPECTRAN V6 ECO declares
+  5.5 MHz–8 GHz and −55…+23 dBm — too low at one end for any tune to
+  succeed, two whole GHz short at the other, and a gain slider spanning
+  values the device clamps. The plugin now reads `/remoteconfig` and
+  `/healthstatus` once at construction and publishes the model, serial,
+  firmware version, both ranges with their declared steps, and the
+  sample-rate ladder.
+
+  The ladder is the part that needed care: `status/iqsamples` is the
+  device's native undecimated rate but it is a *measurement*
+  (61 411 246 Hz for a nominal 61 440 000), so it is snapped to the exact
+  `receiver_clock / 1.5` rung it names — new `utils::snap_to_ladder_top`
+  — before being halved once per rung `decimation0` offers. A rate
+  advertised to an application has to be one the device can be set to.
+  `getSampleRateRange` is now taken from the ends of that same ladder, so
+  it can no longer disagree with `listSampleRates`; its old 10 kHz floor
+  sat below the slowest rung the hardware has.
+
+  New API: `http_endpoints::DeviceCapabilities` and `ValueRange`,
+  `HttpEndpointsClient::get_device_capabilities()`,
+  `AaroniaSource::device_capabilities()`, and the C entry points
+  `aaronia_source_get_capabilities` / `aaronia_source_capabilities_free`.
+  Every field is optional and independently so: a device answering about
+  frequency but not gain still gets its frequency range published, and
+  the file and native-SDK backends — which have no equivalent surface to
+  ask — fall back throughout. Nothing here is a guess; a field that
+  cannot be read stays absent.
+- **A stream gap now says whether the device caused it.** `HttpSource`
+  reads `/healthstatus` on each gap report and checks the device block's
+  own loss counters — `status/errors`, `status/usboverflows`,
+  `status/dsboverflows`, all per-second rates, so the reading describes
+  the moment of the gap rather than the run so far. Nonzero and the loss
+  starts at the device, where no amount of network headroom will recover
+  it; zero and the samples went missing downstream, in the server's 8 MB
+  outbound buffer or on the wire. The read is detached rather than
+  awaited: the control-plane timeout is 30 s, and stalling `work()` that
+  long would back the chunk channel up into the very loss being
+  diagnosed. `HttpEndpointsClient::get_device_health()` exposes the same
+  reduction of the health tree, and each reading is published as
+  `StreamStats::device_health`.
+
+  What it cannot settle is whether another client is on the same server
+  block. Nothing in the HTTP surface counts connections, so clearing the
+  device narrows a gap to a set of causes that includes contention
+  without singling it out — which is why the warning names it rather
+  than asserting it.
+
+### Fixed
+- **The SoapySDR plugin reported the clock source as `Internal`, a name
+  the device does not use, on hardware running off an external 10 MHz
+  reference.** `device/sclksource` offers `Consumer`, `Oscillator`,
+  `GPS`, `PPS`, `10MHz` and three `… Provider` variants; the measured V6
+  ECO is on `10MHz`. An operator who wired a house reference up for
+  frequency accuracy was told the device was free-running.
+  `listClockSources` and `getClockSource` now answer from the device.
+  `setClockSource` still only reads: it accepts the current source as
+  the no-op it is, and warns for anything else naming what the device is
+  actually on. `listAntennas` likewise takes its name from
+  `device/devicemode` — `RX1` on this device, and correct rather than
+  coincidental on a V6 running an RX2 mode.
+- **The SoapySDR plugin could link a stale Rust static library.** The
+  CMake rule produced `libsdr_aaronia_rs.a` through an
+  `add_custom_command(OUTPUT …)` with no `DEPENDS`, so CMake treated the
+  archive as up to date the moment it existed and skipped cargo
+  entirely. Editing Rust sources and rebuilding relinked the module
+  against the old archive — silently, producing a module that looked
+  fine and did not contain the change. It is a custom *target* now,
+  whose command runs every build and which cargo no-ops when nothing
+  moved, which is what the comment there always claimed happened.
+- **`SoapySDRUtil --probe` reported `Timestamps: NO` on a device that
+  timestamps every buffer.** `hasHardwareTime("")` answered with the last
+  stream timestamp, so it read as "no capability" until a packet had
+  arrived — and a probe never streams. It is a capability query now:
+  every RTSA packet header carries a start time, `readStream` has always
+  returned `SOAPY_SDR_HAS_TIME` with correct epoch nanoseconds, and an
+  application deciding at setup whether to record timestamps no longer
+  reads the probe as "cannot". `hasHardwareTime("GPS")` is unchanged and
+  still reports a value, since a GPS fix may genuinely not exist.
+- **The SoapySDR plugin advertised a TX channel on every device,
+  including receivers that cannot transmit at all.** `SoapySDRUtil
+  --probe` on a V6 ECO over HTTP reported `1 Tx`, a full TX channel
+  section and `Full-duplex: YES`; an application that believed it failed
+  on the first write. `getNumChannels` did guard on holding a sink, but
+  `aaronia_sink_build` allocates unconditionally — it succeeds on a build
+  carrying no TX code at all, and only `aaronia_sink_initialize` fails —
+  so the guard was never false. A sink is now built only when the new
+  `aaronia_sink_supported()` reports this binary carries the native-SDK
+  TX path *and* the source is that backend, which means a `serial=` open
+  with no `url=`/`file=` overriding it. The probe now reads `0 Tx` and
+  `Full-duplex: NO`.
+
+  Still not a device capability check: a native-SDK build opened by
+  serial against a V6 ECO would advertise TX, since the ECO has no
+  transmitter and nothing here asks the SDK.
+- **Restored a clean CI run.** Three clippy lints had been failing
+  `cargo clippy --workspace --all-features --all-targets` on Linux since
+  v0.7.7 — a collapsible `if let` in `UnifiedSink::initialize`, a needless
+  borrow in `native_sdk`, and a `field_reassign_with_default` in a
+  `sdk_source` unit test. All three sit in code gated to Windows and
+  Linux, so a macOS `cargo clippy` compiles none of it and reports
+  success; only CI's `--all-features` run sees them.
+
+### Documentation
+- **What several clients on one HTTP Server block cost, measured.** The
+  block accepts any number of concurrent `/stream` clients and serves
+  each one a full copy, so *n* clients cost the server *n* times the
+  egress. Two clients at 15.36 MS/s ran contiguous at 61.8 MB/s each;
+  five saturated the 2.5GbE path at 293.9 MB/s — the same ceiling a
+  single fast stream hits — and the loss fell on an arbitrary two of the
+  five, moving to a different pair on a repeat run. Two consequences a
+  client cannot escape: a clean stream is not evidence of being alone,
+  and a gap is not evidence of company. `/info`, `/healthstatus`,
+  `/remoteconfig` and the `/stream` response headers were all checked and
+  none counts connections.
+- **Corrected the free-licence claim in `docs/HTTPSPEC.md`.** It read
+  that running this crate alongside a second client would meet the
+  one-connection limit. Five simultaneous clients were served on a system
+  holding one HTTP Server block licence, with no error and no refusal:
+  the limit is on block instances in the mission graph, not on
+  connections to one block.
+- **The link a device actually needs, measured.** `link_budget`'s module
+  docs gain a 2.5GbE table beside the gigabit one, and the README a
+  requirements section. A 44 MHz real-time-bandwidth device — an ECO 100 —
+  has to run the 61.44 MS/s rung, and that rung costs 245.8 MB/s at 4 bytes
+  a sample, which gigabit cannot carry; 2.5 Gbps Ethernet is the floor for
+  those devices, and the wire format has to stay at 4 bytes a sample
+  because 8 asks 491.5 MB/s and loses 41 % of the stream. Two controls came
+  out of the same measurement: the path saturates at 292 MB/s, 93 % of
+  2.5GbE line rate, so the wire is the limit and not the server; and two
+  configurations asking the same 245.8 MB/s by different routes — 8 bytes a
+  sample at 30.72 MS/s, 4 bytes at 61.44 — deliver the same 244 MB/s,
+  confirming that only the byte rate matters.
+
+## [v0.7.7] - 2026-09-06
+
+### Added
+- **`utils::IQ_RATE_CLOCK_RATIO` and `utils::iq_ladder_from_top`.** The
+  1.5 receiver-clock-cycles-per-sample rule was a bare literal in three
+  places; it has a name now, and the ladder's shape is available
+  without the clock rule for a caller that already holds the top rung
+  — the link budget's device-anchored remedy, which used to reconstruct
+  a clock only to divide it back out (not exact in floating point).
+  `PacketMetadata::sample_rate()` likewise names the rate a header
+  reports (`sampleFrequency`, else `samples / duration`), shared by
+  `StreamingSdrConfig::from_metadata` and the probe's sniff.
+- **A link budget, so a span that cannot fit is caught before the
+  capture instead of after it.** The span picks a rate off the
+  decimation ladder and at 4 bytes a sample that rate is a byte rate the
+  path has to sustain: `--span 10M` is 15.36 MS/s and 61.4 MB/s, which
+  measured contiguous over gigabit, while `--span 20M` is 30.72 MS/s and
+  122.9 MB/s, which measured 1024 skips and 1.84 s lost of 35 s. The new
+  `link_budget` module does the arithmetic in both directions —
+  `required_byte_rate` for what a span costs, `max_sustainable_span` for
+  the widest rung a measured rate affords, inverted through the existing
+  ladder rather than a second copy of it — and `measure_link_throughput`
+  measures the path end to end by counting bytes off `/stream`.
+  Deliberately end to end: the bottleneck may be the server, a switch,
+  the air or this host's own ingest, and the NIC's advertised link speed
+  sees none of them.
+
+  The probe discards a 500 ms settle window before counting
+  (`LINK_PROBE_SETTLE`). Without it a probe *lies*: the server hands over
+  its pre-connect backlog faster than real time — measured at ~0.27–0.35 s
+  of signal, all inside a 345 ms window at connect — so counting it reads
+  above the true link rate and waves through a span that cannot fit. Two
+  tests pin this, one driving the settle logic off synthetic instants
+  with a 200 MB/s burst ahead of a 10 MB/s stream, and one showing the
+  same trace measuring several times too fast with the settle window
+  removed.
+  An unreachable server, an idle mission or a stream that stops mid-window
+  is an error and never a rate, because "0 MB/s" would condemn every span
+  on the ladder.
+- **`HttpSource` runs that check passively and warns once**, on the
+  stream it is already reading — no second connection, no cost beyond
+  adding up chunk lengths. It compares the bytes arriving against what
+  the device's own reported rate needs and, if the path is short, names
+  the requested span, the rate it needs, what was measured, and the
+  widest span that would have fitted. Complementary to `DropDetector`,
+  which says the server *did* drop data after the fact; when both fire
+  the gap warning now says so, rather than reading as a second unrelated
+  fault. Silence is the answer whenever the measurement did not happen:
+  a warning never fires on a failed one.
+- **`StreamFormat::iq_bytes_per_sample`**, the one definition of the
+  constant the whole budget turns on. `calculate_binary_size` now reads
+  it instead of carrying its own copy of the same match.
+
+### Fixed
+- **The passive link-budget check now judges against the rate the device
+  reports, not the rate the caller asked for.** `current_sample_rate`
+  adopts a new rate only past a 10% hysteresis band (deliberately, to
+  keep the tuning target stable), so the check compared against a
+  *requested* rate the device merely came close to — under the builder's
+  own 1 MS/s default (served by the 0.96 MS/s rung, a 4% gap against a
+  2% tolerance) it warned "this path cannot carry the configured span"
+  on every healthy start. The device-reported rate is now tracked
+  separately, without hysteresis; no rate reported means no verdict. An
+  external mid-measurement retune (RTSA GUI/API, no stream restart)
+  restarts the meter, so mixed-rate bytes are never judged against one
+  rate's requirement.
+- **The passive meter counts decoded IQ payload, once per sweep,
+  instead of raw chunk bytes per chunk.** Per-chunk counting stamped a
+  whole drained batch at one instant, so the first post-settle sweep
+  counted the queued connect backlog at zero elapsed width — inflating
+  the measurement in exactly the case the settle window exists for, and
+  enough to wave through a genuinely short path. Raw bytes also counted
+  JSON headers and any spectra/histogram packets sharing the stream,
+  which under-warned on mixed missions. One payload observation per
+  sweep discards the backlog sweep whole (it becomes the meter's mark)
+  and compares like against like.
+- **A stall no longer dilutes the measurement, and the window's close is
+  exclusive.** The counting window used to run to whenever the next
+  observation happened to arrive, so an 8 s consumer stall averaged dead
+  time into the "sustained" rate and produced a spurious shortfall
+  warning; the observation that crosses the boundary is now excluded in
+  both directions. `ThroughputMeter::finish` also refuses to answer
+  before the window closes, instead of leaving that check as a
+  convention each caller must remember, and the reported settle interval
+  is the one actually discarded rather than the one configured.
+- **A configuration restart re-arms the check; a verdict survives
+  reconnects.** The `restart_pending` retune path never reset the
+  check's once-per-source flags, so a widened span was never measured
+  (the case the check exists for) and gap warnings kept citing a stale
+  verdict about a span no longer configured. The check's state is now a
+  single `LinkCheck` enum — unmeasured / measuring / done — reset to
+  unmeasured on configuration restarts only. A parse error in the sweep
+  that closes the window no longer discards the finished measurement
+  either: the verdict is reported before the error propagates into the
+  reconnect path.
+- **The shortfall remedy is computed from the device's own ladder and
+  format.** The "widest span that fits" now halves down from the
+  device-reported rate, so it is a rung the device actually has —
+  inverting through the default-clock ladder named wrong rungs for a
+  full V6 on a faster receiver clock — and the no-rung-fits fallback
+  computes its figures from the stream format instead of hardcoding
+  int16's "120 kS/s, 0.5 MB/s", which was self-contradictory for
+  float32. Float32 streams are also told that int16 would halve the
+  requirement.
+- **The probe validates its window and probes the capture's stream.**
+  `measure_link_throughput` refuses windows under a new
+  `MIN_PROBE_WINDOW` (100 ms): two adjacent socket-buffer reads
+  microseconds apart would otherwise "measure" gigabytes a second over
+  a link that cannot sustain one. `measure_link_throughput_with` now
+  takes the capture's `StreamParams` (format *and* input,
+  rate-reduction, scale — it used to probe the server's default input
+  at full rate whatever the capture would open) plus an explicit settle
+  window for servers whose connect backlog outlasts the default, and
+  its header sniff parses packet headers only — skipping degenerate
+  zero-rate status headers, logging when it gives up — instead of
+  running the full sample decoder on payloads it then threw away.
+- **Rate tracking and the meter listen only to IQ packets.** A
+  spectra/histogram header carries no `sampleFrequency`, so the parser
+  derives a *frame* rate orders of magnitude below the IQ rate; on a
+  mixed mission that ping-ponged the device-rate tracker (restarting the
+  check on every interleaved packet, so it never finished) and handed it
+  a nonsense yardstick. The meter also counted those packets' scalars at
+  IQ byte width — half their wire cost — inflating the measured rate.
+  Both trackers and the byte count now key on the packet's payload type,
+  and a sweep that decodes no IQ does not observe at all. The probe's
+  header sniff follows the same rule: `stream_sample_rate` is read from
+  an IQ header, never from a spectra frame rate that happened to come
+  first.
+- **A failed measurement re-arms the check instead of retiring it.** A
+  window that closed without a usable count, or before the device ever
+  reported a rate, used to become "checked, no verdict" — permanently,
+  on no evidence, so the configuration streamed unjudged forever. It now
+  starts a fresh window, reserving the no-verdict terminal state for
+  configurations that genuinely cannot be measured. A device retune
+  arriving *after* the verdict re-arms too (the verdict described the
+  old rate's budget), and `ThroughputMeter::finish` refuses a window
+  that actually observed less than half its configured span — a couple
+  of packets plus a stray late closing observation say nothing about
+  what the path sustains.
+- **`rate_reduction(0)` is rejected at the boundary.** Both builders
+  accepted it and sent `?rate_reduction=0` to the server, while the
+  link check's measurable gate read `n <= 1` as "no decimation" and
+  computed a full-rate requirement against a wire the server was
+  decimating by whatever it made of zero. `HttpSourceBuilder::build`,
+  `HttpEndpointsClient::start_stream` and the probe now refuse it with
+  `Error::Config` (new `StreamParams::validate`), and the gate accepts
+  exactly 1.
+- **The shared client builder no longer forces HTTP/1.1.** The
+  consolidation carried the endpoints client's `.http1_only()` (which
+  the probe had copied) into `rtsa_client_builder`, where it also
+  pinned `HttpSource`'s streaming client — which had never had it, and
+  streamed through TLS-terminating proxies whose ALPN offers only h2.
+  Over plain `http://` reqwest speaks HTTP/1.1 regardless, so the pin
+  protected nothing there; over `https://` ALPN now negotiates for
+  every client, control plane included, with HTTP/2's adaptive
+  flow-control window enabled so a negotiated h2 stream is not capped
+  at hyper's default 2 MiB window per round trip — a ceiling the link
+  check would otherwise measure and blame on the path.
+- **One framing implementation, shared by the parser and the probe's
+  header sniff.** The probe's rate sniff re-scanned its whole
+  accumulation on every chunk and resynced a failed header parse past
+  the separator where the stream parser resyncs one byte past the `{`
+  — binary payloads contain separator bytes, so the two could disagree
+  about which header speaks first. `StreamParser` and the sniff now
+  frame packets through the same `scan_packet_header`, which finds each
+  region's terminator once rather than once per `{` candidate (the old
+  loop was quadratic in brace-dense garbage: 256 KiB of `{` took 20 s
+  of a tokio worker), honours the hardware-verified LF+RS two-byte
+  separator, and reports rejected candidates so the parser's
+  `parse_errors` counter is unchanged. The sniff drops bytes as they
+  are ruled out and retains at most one candidate awaiting its
+  terminator.
+- **An HTTP source starts again after `stop_streaming`.** The reader
+  task is spawned at construction and stopping it left nothing to
+  restart, so a SoapySDR deactivate/activate cycle (and seify's
+  `deactivate_at`/`activate_at`) failed with "HTTP streaming not
+  properly initialized". `start_streaming` now reconnects.
+- **A packet whose body cannot be decoded no longer wedges the stream.**
+  The parser returned the error but left the packet in its buffer, so
+  every later chunk failed on the same bytes while the buffer grew
+  without bound. The packet is now skipped. `HttpSource` also resets the
+  parser and the drop detector on every reconnect, so a retune no longer
+  decodes the new connection's first bytes as the old packet's payload.
+- **`read_samples` returns a partial block on timeout instead of losing
+  it.** Samples already moved into the caller's buffer went out with the
+  error, an unflagged gap through the C and Python APIs.
+- **`IqPacket.sample_rate_hz` reports the rate the device streams.** The
+  `sdr-source` adapter captured the requested rate before the first
+  packet and never looked again, so a rate the device snapped to another
+  ladder rung was mis-stamped for the whole session.
+- **RTSA files: `mSampleSize` counts values per sample, not bytes.** The
+  captures under `tests/` carry 2 for float32 IQ and 1024 for spectra.
+  Seeking within a chunk used it as a byte stride, so a second partial
+  read of a chunk landed mid-sample, and a spectra read returned one
+  scalar per spectrum. Both now use the sample type's width.
+- **The native SDK is shut down by the last client, not the first.**
+  `AARTSAAPI_Shutdown` is process-wide, but each source and sink called
+  it from its own `Drop`, so re-initialising a source, or pairing a
+  source with a sink, tore the SDK down under the survivor.
+- **A bare `spectranv6eco` opens `spectranv6eco/rtsa`.** The ECO has no
+  `/raw` mode; `SdkConfig` appended one anyway. SDKSPEC's mode list said
+  the same and now agrees with its own V6-vs-ECO table.
+- **Clippy passes on Rust 1.98.** The new `chunks_exact_to_as_chunks`
+  lint failed the workspace check at eight decode sites.
+- **The remote-config licence probe can report `Active`.** It looked for
+  a bare `reflevel` under a group named `main`; a V6 exposes `reflevel0`
+  in its receiver block, so the probe always answered `NotLicensed`. It
+  now writes the discovered block, as the retune path does.
+- **`HttpSource` built outside a Tokio runtime errors at build.** It used
+  to panic inside `init()` when it spawned its reader.
+- **`HttpSink` with `buffer_size(0)` no longer spins forever**; the size
+  is clamped to one.
+- **A quiet dwell in hop mode is an empty read**, not a read error
+  counted toward the source-dead bailout.
+- **The first packet after a failed initial connection is not flagged as
+  an overrun**; nothing was lost.
+- **seify: `sample_rate()` reports the observed rate**, and the range
+  starts at the ladder's 120 kS/s floor instead of 10 kHz.
+- **C API: `aaronia_get_error_message` takes an `int`** and answers
+  unknown codes, where an out-of-range enum was undefined behaviour. C
+  callers are unaffected (an enum converts to `int`); a Rust caller of
+  the `ffi` module's function passes `code as i32`.
+- **Native SDK:** `aaronia_source_read_samples_timeout` honours its
+  deadline (it polled for up to 500 ms regardless); spectra reads honour
+  the packet stride; an SDK call that returns no object is an error
+  rather than a null pointer; opening a second device on a live source
+  is refused; the device is closed on drop.
+- **RTSA files:** a negative DSFT stream offset no longer overflows the
+  header search, and `seek_to_sample` works on reverse-order files.
+- **Spectrum decompression caps the output size** taken from packet
+  metadata.
+
+### Performance
+- The stream parser drops an over-cap payload as it arrives instead of
+  buffering it; uncompressed spectra packets decode without a copy;
+  spectra file reads decode in place; the C API reserves the caller's
+  length before a read; `sample_rate_hz` is an atomic load, so stamping
+  it on every packet takes no lock.
+
+### Changed
+- **Byte-rate helpers answer `Option<f64>`, never a `0.0` sentinel.**
+  `required_byte_rate`, `max_sustainable_span` and friends returned
+  `0.0` for "unknown / nothing fits", a convention every comparison site
+  had to remember — `required <= measured` on a garbage rate reads
+  "fits". `None` now makes the compiler enforce it, and
+  `StreamFormat::iq_bytes_per_sample` returns `Option<usize>` (`None`
+  for JSON) for the same reason. New `max_sustainable_sample_rate_below`
+  answers remedy queries anchored to the device's reported rate.
+- **The link-budget verdict is data, not just a log line.** New
+  `LinkBudgetVerdict` (measured rate, requirement, fit span, shortness)
+  is published as `StreamStats::link_budget`, so a GUI or orchestrator
+  can auto-narrow the span without scraping logs; the stream-gap warning
+  restates the verdict's actual figures from it. `StreamFormat` gained
+  `CAPTURE_DEFAULT`, the one definition behind `HttpSourceBuilder`'s
+  default, `StreamStats::default` and `DEFAULT_LINK_FORMAT`, which were
+  three separately written `Int16` literals.
+- **One copy each of the RTSA client plumbing.** The probe re-used
+  hand-rolled copies of the endpoints client's construction, auth
+  application, base-URL validation, `/stream` query serialization and
+  status-to-error mapping — five drift risks (the three reqwest clients
+  had already drifted to three different setting subsets). All are
+  shared now: `AuthMethod::apply_to` owns the `RToken` header,
+  `rtsa_client_builder` owns the client settings (the streaming client
+  gains the keepalive/nodelay/HTTP-1.1 compatibility settings the
+  endpoints client always had), and `StreamParams::stream_url`
+  serializes every `/stream` URL, including `HttpSource`'s.
+- **`LinkBudgetVerdict::judge` is the verdict's one producer.**
+  Requirement, shortness-against-tolerance and the remedy rung were
+  assembled by hand at each caller; the constructor now owns that
+  arithmetic (so the struct's invariants — fit fields populated only on
+  a shortfall, span matching the fit rate — hold by construction), the
+  verdict carries `bytes_per_sample` for report text, and
+  `ThroughputMeasurement::max_sustainable_span_hz` takes the stream
+  format instead of silently assuming int16. The no-rung-fits warning
+  cites the device ladder's actual last rung rather than a hardcoded
+  1/512.
+- **`HttpSource`'s stream-open failure is the typed error the rest of
+  the crate returns.** A non-success status on `/stream` is now
+  `Error::Http { status, context }` — the same variant the endpoints
+  client and the probe produce, with `context` naming the stream URL —
+  instead of `Error::Protocol("Stream endpoint returned error: …")`.
+  Anything matching on that text will need the new form.
+- **`work()`'s output copy is two bulk `copy_from_slice` calls** over the
+  deque's contiguous halves instead of a `pop_front` per sample, whose
+  per-element wrap-around check the compiler cannot lift. Factored into
+  `copy_out` and unit-tested, including the wrapped-deque case.
+
+### Documentation
+- **Measured the HTTP transport on WiFi 7 and recorded where the
+  ceiling actually is.** `curl` on `/stream` sustains ~75 MB/s
+  (0.6 Gbit/s) station-to-station at a 2.4 Gbps PHY — both ends on air
+  halves the medium — and the figure is the same for all three wire
+  formats, so the encoding is not the limit. Two parallel connections
+  measured less in aggregate (63.9 vs 74 MB/s), so a single connection
+  is optimal and nothing smarter is available to the client. Against
+  that, the crate's full framing-plus-decode path measures ~3 GB/s and
+  the individual decoders 0.8–10 GS/s: the parser has fortyfold
+  headroom and is never the bottleneck. What the link buys at 4 bytes a
+  sample is ~19 MS/s — the 15.36 MS/s rung fits, 30.72 does not, and
+  full span (246 MB/s) needs a wired path to the RTSA host. Two ignored
+  throughput-meter tests (`decode_throughput_meter`,
+  `framing_throughput_meter`) keep these numbers re-measurable in one
+  command.
+- README and PLUGINS pinned `sdr-aaronia-rs = "0.6"`, a major behind
+  the crate, so nothing they describe resolved. Now `"0.7"`.
+- `cumulative_drops` counts client-detected timestamp gaps; four docs
+  called them server-reported drops. Bandwidth figures now use the
+  61.44 MS/s top rate rather than the 92 MHz clock. The examples table
+  and the QUICKSTART verification link were corrected.
 
 ## [v0.7.6] - 2026-08-15
 

{python_aaronia-0.7.6 → python_aaronia-0.8.0}/CONTRIBUTING.md

@@ -120,7 +120,7 @@ open target/llvm-cov/html/index.html   # xdg-open on Linux, start on Windows
 
 ### 7. Criterion Benchmarks (`benches/`)
 
-Three benchmark harnesses track the hot paths across releases. Benchmarks are run on demand to investigate performance implications of a PR.
+Four benchmark harnesses track the hot paths across releases. Benchmarks are run on demand to investigate performance implications of a PR.
 
 ```bash
 cargo bench                                       # Run all benchmarks

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

@@ -1275,7 +1275,7 @@ source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "39cab71617ae0d63f51a36d69f866391735b51691dbda63cf6f96d042b63efeb"
 dependencies = [
  "libc",
- "windows-sys 0.61.2",
+ "windows-sys 0.52.0",
 ]
 
 [[package]]
@@ -1669,9 +1669,9 @@ dependencies = [
 
 [[package]]
 name = "h2"
-version = "0.4.15"
+version = "0.4.19"
 source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "6cb093c84e8bd9b188d4c4a8cb6579fc016968d14c99882163cd3ff402a4f155"
+checksum = "ef8e5e5a340588f4452631496976cf8636d4a7ecf600239fdc27615d2530bc16"
 dependencies = [
  "atomic-waker",
  "bytes",
@@ -2041,7 +2041,7 @@ checksum = "3640c1c38b8e4e43584d8df18be5fc6b0aa314ce6ebf51b53313d4306cca8e46"
 dependencies = [
  "hermit-abi",
  "libc",
- "windows-sys 0.61.2",
+ "windows-sys 0.52.0",
 ]
 
 [[package]]
@@ -3027,7 +3027,7 @@ dependencies = [
 
 [[package]]
 name = "python-aaronia"
-version = "0.7.6"
+version = "0.8.0"
 dependencies = [
  "arrow",
  "num-complex",
@@ -3098,7 +3098,7 @@ dependencies = [
  "once_cell",
  "socket2",
  "tracing",
- "windows-sys 0.61.2",
+ "windows-sys 0.52.0",
 ]
 
 [[package]]
@@ -3404,7 +3404,7 @@ dependencies = [
  "errno",
  "libc",
  "linux-raw-sys",
- "windows-sys 0.61.2",
+ "windows-sys 0.52.0",
 ]
 
 [[package]]
@@ -3461,7 +3461,7 @@ dependencies = [
  "security-framework",
  "security-framework-sys",
  "webpki-root-certs",
- "windows-sys 0.61.2",
+ "windows-sys 0.52.0",
 ]
 
 [[package]]
@@ -3556,7 +3556,7 @@ checksum = "94143f37725109f92c262ed2cf5e59bce7498c01bcc1502d7b9afe439a4e9f49"
 
 [[package]]
 name = "sdr-aaronia-rs"
-version = "0.7.6"
+version = "0.8.0"
 dependencies = [
  "anyhow",
  "bitflags 2.13.1",
@@ -4135,7 +4135,7 @@ dependencies = [
  "getrandom 0.4.3",
  "once_cell",
  "rustix",
- "windows-sys 0.61.2",
+ "windows-sys 0.52.0",
 ]
 
 [[package]]
@@ -4792,7 +4792,7 @@ version = "0.1.11"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "c2a7b1c03c876122aa43f3020e6c3c3ee5c05081c9a00739faf7503aeba10d22"
 dependencies = [
- "windows-sys 0.61.2",
+ "windows-sys 0.52.0",
 ]
 
 [[package]]

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

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

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

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: python-aaronia
-Version: 0.7.6
+Version: 0.8.0
 Classifier: Programming Language :: Rust
 Classifier: Programming Language :: Python :: Implementation :: CPython
 Classifier: License :: OSI Approved :: GNU General Public License v3 or later (GPLv3+)
@@ -211,7 +211,7 @@ silently defaulting.
 | `read_samples_arrow(count)` | PyArrow `FixedSizeListArray` of `[re, im]` float32 pairs |
 | `read_samples_dual_numpy(count)` | `(rx1, rx2)` NumPy arrays (dual-channel captures) |
 | `set_center_frequency(hz)` / `set_sample_rate(hz)` / `set_reference_level(dbm)` | Live retuning |
-| `cumulative_drops()` | Total server-reported dropped samples |
+| `cumulative_drops()` | Timestamp gaps detected in the stream so far (gap events, not samples) |
 | `take_overrun()` | True once per detected receive-side overrun |
 | `last_timestamp_ns()` | Epoch-ns timestamp of the last received block (HTTP backend; 0 otherwise) |
 

{python_aaronia-0.7.6 → python_aaronia-0.8.0}/PLUGINS.md

@@ -12,7 +12,7 @@ To use the Seify plugin, enable the `seify` feature in your `Cargo.toml`:
 
 ```toml
 [dependencies]
-sdr-aaronia-rs = { version = "0.6", features = ["seify"] }
+sdr-aaronia-rs = { version = "0.7", features = ["seify"] }
 ```
 
 Instantiate the device with `AaroniaSeifyDevice::from_args` and use it directly (or via `seify::dev::DynDeviceBackend`). The backend is **not** part of seify's built-in enumeration registry — `seify::enumerate()` will not discover it.
@@ -136,11 +136,11 @@ Both the native Rust API and the Python/C++ bindings expose critical metrics to
 
 - **Hardware Timestamps**: You can retrieve the precise hardware timestamp (in nanoseconds) of the last received block using `last_timestamp_ns`.
 - **Overruns**: The `take_overrun()` function checks if the internal buffer has overflown since the last check, allowing you to react to drops on the client side.
-- **Cumulative Drops**: The `cumulative_drops()` function reports the total number of blocks dropped by the Aaronia server itself due to network backpressure.
+- **Cumulative Drops**: `cumulative_drops()` counts the timestamp gaps the client's drop detector has seen in the stream. Each is one gap event, however many samples it spanned.
 
 In SoapySDR, you can access these metrics via the `readSensor()` API:
 ```python
-# Check for server-side drops
+# Check for gaps in the stream
 drops = sdr.readSensor("cumulative_drops")
-print(f"Dropped blocks: {drops}")
+print(f"Gaps seen: {drops}")
 ```