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>
