The tests/ directory held 50 laboratory programs and no tests. They model
channels, run hundreds of repetitions and write CSV, PNG and reports;
calling that a test suite blocked introducing a real one, because any
pytest run would have collected the labs and re-executed every
experiment.
- move all 50 lab programs to experiments/ with git mv, preserving history
- rewrite the 38 cross-imports between labs from tests.labNNN to
experiments.labNNN
- leave tests/ empty for actual fast checks of protocol/
- point quick_gate and the hook at the new layout and add experiments/ to
the syntax sweep
- update the paths quoted in the Lab042 specification and the verifier
agent definition
This also defuses the import-time work finding without touching 41 files:
the labs still create directories and write files on import, but nothing
imports them now except the gate, which does so deliberately.
Gate passes: syntax clean, protocol imports, 15 lab modules import, 2
functional suites run.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Queried the Pluto over IIO before writing any code. Three findings, one
of which invalidated the specification.
The AD9361 will not sample below 2 083 333 Hz, so the 640 kHz taken from
Lab018 is unreachable by a factor of three. Going lower needs the on-chip
FIR decimator, which would add an untested mechanism to the very first
transmit. Instead raise oversampling from 32 to 128 samples per symbol:
the symbol rate stays at 20 000, rolloff, preamble, sync word and guard
are untouched, and the rate becomes 2 560 000 Hz. Only the device
interface changes, not the signal.
Consequence recorded: the shaping filter grows to 1281 taps, so the
convolution has to go through scipy.signal.fftconvolve.
Also from the device:
- it reports as PlutoSDR Rev.C (Z7010-AD9361) with a single RX and a
single TX buffer channel, so adi.Pluto is right and the adi.ad9361
fallback is unnecessary
- the chip is a full AD9361: RX tunes 70 MHz to 6 GHz, TX from 46.9 MHz,
so the sub-350 MHz target band is available without a firmware hack.
That closes the open question flagged for Lab044
- firmware is v0.32, left alone for now
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The TX cyclic buffer row pointed at section 7, which became the signal
parameters when the hardware and environment sections were inserted. It
means the traps section, now 9.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The project owner holds the permits for over-the-air work, so legality is
not a constraint this document should be reasoning about.
- retitle the section from "safety requirements" to what it actually
covers: circuit integrity and not destroying the hardware
- rewrite the antenna rule on its real technical ground. An antenna opens
a radiating path in parallel with the cable, so the level at the
receiver stops matching the budget and reflections appear; the value of
a cable loopback is that everything in it is known
- reframe "no over-the-air" as a scope boundary against Lab044 rather
than a prohibition
- note in the roadmap that Lab044 is purely a technical choice of band,
power and antenna
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The bench has an AT30S: 30 dB, SMA, rated to 200 W. That removes the last
hardware blocker and changes the safety analysis.
With 30 dB in line, TX at full 0 dB gain lands at about -23 dBm on the
receiver, some 25 dB below the +2.5 dBm damage threshold. The whole
tx_hardwaregain range is therefore safe, so the staged -60 dB start and
the -30 dB ceiling are no longer needed.
- record the attenuator in the inventory and note that its 200 W rating is
irrelevant here, attenuation does not depend on level
- replace the interim procedure with a level budget table and a starting
point of -30 dB, giving about -53 dBm at the receiver
- require a visual check that the attenuator is actually in the path
before the first transmit
- keep the ban on running without it: it guards against operator error,
not against the calculated level
Only the environment blocker is left: pyadi-iio and libiio are missing
from the interpreter on PATH.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Hardware confirmed from a photo of the bench: the device is a Pluto+
(2RX/2TX, Gigabit Ethernet), not the stock ADALM-PLUTO, plus an RTL-SDR
dongle and several antennas. No attenuator on hand.
- record the actual inventory and the Pluto+ differences that matter:
Ethernet transport, two channels, adi.Pluto first with adi.ad9361 as
the only permitted fallback
- replace "use an attenuator" with numbers: TX puts out about +7 dBm at
0 dB, the RX damage threshold is about +2.5 dBm, so give a staged gain
procedure starting at -60 dB and capped at -30 dB until an attenuator
arrives
- require the antennas to be physically removed from the bench rather
than merely left unplugged
- add the environment blocker found on inspection: the interpreter on
PATH is a standalone Python 3.13.1 without pyadi-iio, libiio or scipy,
while Lab024a clearly ran somewhere else; identifying and recording
that environment is now the first task
- renumber sections and align the TX gain figure with the safety section
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Specification for the first transmission through real hardware. The
project has no TX call anywhere across Lab001-Lab041, so the whole chain
exists but has never been connected to a transmitter.
Scope is deliberately minimal: get a JPEG through a cable loopback on a
single PlutoSDR and see the picture. Single device means TX and RX share
a reference clock, which removes the carrier offset and clock drift that
the receiver chain handles weakest.
- reuse Lab018 signal parameters unchanged, so hardware is the only new
variable
- reuse image_fragments, packet, build_radio_frame, find_radio_frame
- list the first-time traps: cyclic TX buffer, sample scaling, RX started
after TX, undersized RX buffer, automatic gain, receiver saturation
- define acceptance criteria and required measurements
- state explicitly what is out of scope: retransmission, erasure coding,
higher rate, two devices, over-the-air
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
