H-1: ft601_rd_n/ft601_oe_n IOB-packing block claimed "constant-1, USB read
not implemented" but the driver has had a full RD_OE_ASSERT/READING/DEASSERT
read FSM since the host-command path was added. Rewrote the comment to
describe the real FSM-driven traffic and explain that -quiet is now for
post-synthesis retiming/consolidation cases, not because the registers
don't exist.
H-2: production XDC (create_generated_clock ft601_clk_fwd + set_output_delay)
and FMC dev XDC (set_max_delay -datapath_only) implement two different but
deliberate timing strategies for the same FT601 output ports — production
forwards ft601_clk_out via ODDR, FMC UMFT601X-B has no return path. Added
cross-reference VARIANT STRATEGY blocks in both XDCs explaining the choice
and the no-mixing rule.
H-4: set_false_path -from ft601_txe -to clk_100m registers was undocumented.
Traced both capture paths: ft601_clk_in (write FSM in usb_data_interface.v)
and clk_100m (cdc_single_bit in radar_system_top.v driving status_reg[1]).
Added comment explaining the async port → clk_100m sync-FF path is what
this constraint covers.
Comment-only XDC change; regression 46/0/0 unchanged.
Guards against future drift between the two USB driver command paths
(USB_MODE=0 vs USB_MODE=1) and against 200T+long-range build breakage
in usb_data_interface.v.
tb/tb_system_opcodes_ft601.v — new (~397 LOC):
- Sibling of tb_system_opcodes.v with radar_system_top
#(.USB_MODE(0))
- FT601 RX BFM: 32-bit single-word read with 5-cycle word holds
(IDLE -> OE_ASSERT -> READING -> DEASSERT -> PROCESS)
- 28/0 PASS, same opcode coverage as the FT2232H sibling
run_regression.sh — adds 2 entries:
- "FT601 Driver Long-Range Compile (PR-AD AD.3)" in Phase 1:
inline iverilog -DSUPPORT_LONG_RANGE on usb_data_interface.v;
suppresses informational warnings (timescale / dangling / @*
sensitive) and fails on real warnings. Catches macro creep
that would break the 200T 20-km build before Vivado synthesis.
- "System Opcodes FT601 (tb_system_opcodes_ft601)" in Phase 2
(non-quick block).
radar_system_top.v — header doc block documenting the
USB_MODE x SUPPORT_LONG_RANGE 4-cell build matrix and clarifying
that the flags are orthogonal (200T+FT601 with 3-km-only DSP is a
valid bring-up baseline; 50T+FT2232H+LR is rare but must still
compile). Notes that both drivers emit the identical v2 bulk frame
and that byte-equality is enforced by tb_usb_drivers_parity.v.
Regression: 46/0/0 (44 + 1 system TB + 1 LR compile guard).
Lint: 0 errors, 2 advisory (pre-existing, unrelated).
tb/tb_usb_data_interface.v was on the obsolete pre-PR-G streaming
protocol (1-bit cfar_detection, 4-state FSM) — green CI gave false
confidence because TB and DUT were equally out of date. This rewrite
exercises the new v2 bulk FSM and adds a cross-comparison TB that
asserts byte-for-byte equality between the FT601 and FT2232H drivers
fed identical stimulus.
tb/tb_usb_data_interface.v — full rewrite (~370 LOC):
- Mirrors tb_usb_protocol_v2.v test groups for the FT601 path
- BE-aware byte capture using a single capture_idx integer with
blocking arithmetic + one non-blocking egress_count update
(four separate non-blocking assigns dropped 3 of 4 lanes — race
caught during development)
- 31/0 PASS, egress_count = 56330 bytes (matches FT2232H exactly)
tb/tb_usb_drivers_parity.v — new (~376 LOC):
- Instantiates both drivers in one TB, fed identical clk/reset/
streaming inputs, drained concurrently
- Captures each driver's byte stream into a 65536-byte ring buffer
- assert_parity task finds first byte mismatch index
- 3 scenarios: header-only (10 B), status packet (34 B), full
frame (56330 B)
- 9/0 PASS — drivers are now byte-equal across all scenarios.
Any future v2 protocol change on FT2232H must land on FT601 in
the same PR or this guard fires.
run_regression.sh — adds "USB Drivers Parity (PR-AD AD.2
cross-comparison)" entry in Phase 1 (changed-modules block).
Regression: 44/0/0 (43 baseline + 1 parity test).
The FT601 USB 3.0 driver was 5 PRs behind the FT2232H driver: still
emitting pre-PR-G 12-byte per-cell streaming packets with 1-bit
cfar_detection, no subframe_enable snapshot (M-8), no MEDIUM PRI
status readback (M-5 / PR-AC.1), no CFAR telemetry (PR-G). Host
parser only speaks v2 bulk, so a 200T+FT601 build couldn't talk to
the GUI. This commit closes that gap by cloning the FT2232H module
body verbatim and swapping the output stage from 8b/cycle to
32b+4b-BE/cycle.
usb_data_interface.v — full rewrite (~1300 LOC):
- 3 internal BRAMs (doppler_mag / range / detect), 3-cycle RMW
pipeline, Manhattan magnitude, all CDC chains, 8-state WR FSM
copied from FT2232H reference verbatim
- status_words[0..7] 34-byte packet (M-5 parity with PR-AC.1
21bf7a0): medium_chirp_cycles + medium_listen_cycles in word 7
- subframe_enable_snapshot in frame byte 2 bits[5:3] (PR-U / M-8)
- 2-bit cfar_detect_class (PR-F)
- PR-G CFAR telemetry (detect_count_cand + detect_threshold_soft
in status word 6)
- AUDIT-C12 wr_done_toggle handshake + frame_drop_count
- PR-Z A6 Bug C fix (detect_clearing on wr_done_pulse)
- PR-AA fix (BRAM addr advance at phase 0 / MSB, not phase 1)
- PR-Z A6 Bug B preload (detect_rd_addr=1 at WR_DETECT entry)
- Output stage: byte_now combinational generator + 4-lane pack-emit
accumulator. Full words BE=1111, partials BE=0001/0011/0111 at
section ends. Byte-order convention: byte 0 -> ft601_data[7:0],
byte N+1 -> next lane up (preserves MSB-first FT2232H wire order)
- ODDR clock forwarding preserved (ft601_clk_out)
- Vestigial ft601_txe_n / ft601_rxf_n outputs kept tied 1'b1
(200T board has physical pins routed; removing breaks the build)
radar_system_top.v — 9 new connections to the FT601 instance
(no new top-level signals — all driven from already-existing internal
wires the FT2232H instance was already using):
- cfar_detection (1-bit) -> cfar_detect_class (2-bit)
- range_bin_in, doppler_bin_in (rx_detect_valid mux)
- frame_complete, subframe_enable
- status_medium_chirp, status_medium_listen, status_cfar_alpha_soft
- status_detect_threshold_soft, status_detect_count_cand
Final cleanup pass for the PR-AB.b expanded bundle.
chirp_scheduler.v / radar_receiver_final.v: delete the unused subframe_pulse
output + its sibling subframe_id port. Both were declared on the scheduler
and bound at the radar_receiver_final.sched instance, but no downstream
module read them -- doppler_processor counts sub-frame boundaries
internally from new_chirp_frame + CHIRPS_PER_SUBFRAME=16. The stale
"// doppler picks up in PR-F" comment was aspirational; PR-F never wired
it. subframe_id demoted from output port to internal reg (still consumed
by the FSM's next_enabled_subframe helper).
tb_chirp_scheduler_handshake.v: drop the matching observer wires + port
bindings.
main.cpp: replace the F-2.1 "host_radar_mode = 2'b01 (auto-scan, FPGA-owned
chirp dispatch)" boot DIAG + 8-line comment block with a short comment
noting the mode register was retired in commit 1. The DIAG was asserting a
register that no longer exists.
Regression:
- FPGA iverilog: 43/0/0 (tb_chirp_scheduler_handshake 16/16)
- MCU: 51/0 (GPS) + 34/0 (AGC/safety/gap-3)
Closes the PR-AB.b expanded bundle (commits 1-6) on feat/dual-range-v2.
Wire a per-frame MCU→FPGA "beam pattern ready" handshake so the chirp
scheduler can stall between 48-chirp frames until the MCU finishes
writing the next ADAR1000 pattern. The legacy unused stm32_new_chirp
input on PD8 is repurposed as stm32_beam_ready; chirp_scheduler.v gets
a new S_BEAM_WAIT state entered after each frame_pulse and an 80 ms
watchdog so a missed MCU toggle degrades to wall-clock cadence with a
sticky telemetry bit rather than stalling the radar.
Cold-reset defaults the handshake off (host_handshake_enable=0, new
opcode 0x1A); the GUI opts in once the MCU PD8 wiring is verified on
the bench. Both the FT601 and FT2232H status word 4 paths get the new
beam_handshake_watchdog_fired sticky at bit [1] (reclaimed from the
range_mode retirement in commit 1).
RTL:
- chirp_scheduler.v: 2-FF ASYNC_REG sync on beam_ready_async; 1-cycle
edge detect (any transition, MCU side uses HAL_GPIO_TogglePin); new
S_BEAM_WAIT state entered at frame_pulse when host_handshake_enable=1;
23-bit beam_watchdog counter with BEAM_WATCHDOG_MAX = 8_000_000 (~80 ms
at 100 MHz, ~10 nominal frames); beam_handshake_watchdog_fired output
sticky across mixers_enable cycles, cleared only by reset_n; mid-wait
disable releases the FSM so dropping the opcode never strands the
radar between frames.
- radar_receiver_final.v: thread stm32_beam_ready_async +
host_handshake_enable + beam_handshake_watchdog_fired through the
scheduler instance.
- radar_system_top.v: rename input port stm32_new_chirp → stm32_beam_ready;
add host_handshake_enable register (cold-reset = 1'b0); opcode 0x1A
dispatch (value[0]); add rx_beam_handshake_watchdog wire; pack into
status_words[4][1] in both USB paths.
- radar_system_top_50t.v: rename wrapper port + sub-instance wiring.
- usb_data_interface.v + usb_data_interface_ft2232h.v: add
status_beam_handshake_watchdog input + 2-FF level CDC (same convention
as F-6.4 / F-1.2 stickies); refresh word-4 layout doc comment; pack
beam_handshake_wd_sync_1 into status_words[4][1].
XDC:
- xc7a50t_ftg256.xdc + xc7a200t_fbg484.xdc: rename stm32_new_chirp port
references to stm32_beam_ready (same PD8 pin, F13 on 50T / L18 on
200T).
MCU:
- main.h: add FPGA_BEAM_READY_Pin = GPIO_PIN_8 + FPGA_BEAM_READY_GPIO_Port
= GPIOD alongside the existing FPGA_FRAME_PULSE alias.
- main.cpp:runRadarPulseSequence: insert HAL_GPIO_TogglePin(GPIOD,
GPIO_PIN_8) after each setCustomBeamPattern16(RX) — once after the
per-azimuth broadside (vector_0), once after matrix1, once after
matrix2 — between the SPI burst completion and waitForFramePulse.
GUI:
- radar_protocol.py: Opcode.HANDSHAKE_ENABLE = 0x1A;
StatusResponse.beam_handshake_watchdog = 0 default; parse word 4 bit
[1] in parse_status_packet; update word-4 layout comment.
- test_GUI_V65_Tk.py: add beam_handshake_watchdog kwarg to
_make_status_packet (sets bit [1] of word 4); refresh
test_parse_status_word4_layout_co_spec to cover the new bit (used+9=32);
add test_parse_status_beam_handshake_watchdog round-trip;
test_handshake_enable_opcode pins 0x1A; defaults / chirps_mismatch /
agc-coexist tests gain a watchdog==0 assertion; bump
test_all_rtl_opcodes_present expected set to include 0x17/0x18/0x19/0x1A.
TB:
- new tb_chirp_scheduler_handshake.v (16 checks): legacy open-loop, edge
exit (rising + falling), 200-cycle idle hold, watchdog auto-advance
via force on dut.beam_watchdog, sticky-survives-mixers_disable,
mid-wait disable release, reset_n clears sticky.
- run_regression.sh: register the new TB in PHASE 1.
- tb_radar_receiver_final.v: tie the 3 new receiver ports off
(beam_ready_async=0, handshake_enable=0, watchdog unconnected).
- tb_system_mechanics.v / tb_system_opcodes.v: explicit
.stm32_beam_ready(1'b0) connection (the cold-reset
host_handshake_enable=0 keeps the FSM out of S_BEAM_WAIT).
- tb_usb_data_interface.v / tb_usb_protocol_v2.v / tb_e2e_dsp_to_host.v /
tb_ft2232h_frame_drop.v: tie .status_beam_handshake_watchdog(1'b0).
Ride-along ruff sweep (14 → 0 across the repo):
- tb/cosim/compare_independent.py: RUF003 — '5×' → 'at least 5x'.
- tb/cosim/gen_e2e_expected.py: noqa: E402 on the post-sys.path import;
drop unused EXPECTED_RANGE_BIN + EXPECTED_DOPPLER_BIN_PER_SF imports;
fold the detect-class slot if/else into a ternary (SIM108).
- tb/cosim/gen_e2e_stimulus.py: drop int() wrapping round() at four
call sites (RUF046 — round() already returns int in Python 3);
rewrite the range-bin derivation comment block from code-like
`# range_bin = ...` to prose (ERA001); strip stray f from
placeholder-free error string (F541).
- tb/cosim/tb_e2e_dsp_to_host_parse.py: open(path, 'r') → open(path)
(UP015).
- v7/dashboard.py: '3×' → '3x' (RUF003); drop quotes from
'StatusResponse | None' annotation (UP037, file already has
`from __future__ import annotations`).
CI summary (all suites green pre-commit):
- ruff: All checks passed!
- FPGA regression (iverilog): 43 / 0 / 0 (incl. new handshake TB 16/16).
- MCU tests: 51 / 0 + 34 / 0 + 13 / 13 ADAR1000_AGC.
- GUI Tk (test_GUI_V65_Tk): 120 / 0.
- GUI v7 (test_v7): 152 / 0.
Production rollout note: bitstream cold-resets with host_handshake_enable=0
so existing flashes keep their open-loop cadence until the GUI sends
opcode 0x1A=1. Once enabled, the per-pattern dwell tracks both the chirp
ladder (PD14 frame_pulse from commit-3 work) and the MCU pattern-write
completion (PD8 toggle from this commit), eliminating drift from the SPI
burst timing.
Strip the host-side parser/dashboard/test references for the FPGA
registers retired in commit 1: host_radar_mode (opcode 0x01),
host_trigger_pulse (opcode 0x02), and host_range_mode (opcode 0x20).
The v7 backend (models.py / software_fpga.py / processing.py) had no
references — only the parser, dashboard, and Tk test file did.
- radar_protocol.py: drop Opcode.RADAR_MODE / TRIGGER_PULSE / RANGE_MODE
enum members; rebuild the doc table around the surviving opcodes; drop
StatusResponse.radar_mode and StatusResponse.range_mode fields; drop
the two parse-status assignments (sr.radar_mode = words[0]>>22 and
sr.range_mode = words[4] & 0x03); update the layout comments on words
0 + 4 to mark the freed bits as reserved-0. Acquisition loop log line
switches from "mode=X stream=Y" to "stream=Y chirps/elev=Z" — radar
mode is no longer a runtime concept.
- v7/dashboard.py: delete the "Radar Mode Off" (0x01) and "Trigger Chirp"
(0x02) QPushButtons from the operations group; remove "Mode:" and
"Range Mode:" fields from _update_status_display.
- test_GUI_V65_Tk.py: drop mode + range_mode kwargs from the
_make_status_packet helper; update the word-4 layout co-spec test
(range_mode entry deleted, reserved span widened from [9:2] to [9:0],
sanity-check sum bumped from used+8 to used+10); delete
test_parse_status_range_mode + test_radar_mode_names; rename
test_agc_and_range_mode_coexist → test_agc_fields_coexist_with_mismatch
with chirps_mismatch replacing range_mode as the coexisting field;
drop 0x01 / 0x02 / 0x20 from test_all_rtl_opcodes_present's expected
set.
GUI tests: 118/0 (test_GUI_V65_Tk) + 152/0 (test_v7). FPGA regression
unchanged at 42/0/0.
Strip the FPGA-side pin constraints and MCU-side GPIO init+toggles for
the two STM32→FPGA beam-step GPIOs that the commit 1 RTL strip rendered
unreachable. The MCU was toggling PD9 once per beam_pos iteration and
PD10 once per azimuth step; both edges fed FPGA edge_detector_enhanced
instances that drove elevation_counter / azimuth_counter regs in
plfm_chirp_controller_v2 — counters that were never consumed (status
pack didn't carry them; on 50T they went to _nc; on 200T to
unconstrained outputs). GUI already uses MCU-side software counters
m/n/y via USB-CDC.
- constraints/xc7a50t_ftg256.xdc: delete PACKAGE_PIN E16 (PD9) +
D16 (PD10); tighten stm32_new_* wildcard to explicit stm32_new_chirp.
- constraints/xc7a200t_fbg484.xdc: delete PACKAGE_PIN N18 (PD9) +
N19 (PD10); tighten wildcard same as 50T.
- main.cpp:633: delete HAL_GPIO_TogglePin(GPIOD, GPIO_PIN_9) inside the
matrix1/matrix2 beam_pos loop.
- main.cpp:655: delete HAL_GPIO_TogglePin(GPIOD, GPIO_PIN_10) at the
azimuth-step / stepper-rotate boundary.
- main.cpp:3118 (MX_GPIO_Init output level): drop PD9 + PD10 from the
GPIOD WritePin OR-mask.
- main.cpp:3172-3174 (MX_GPIO_Init pin config): drop PD9 + PD10 from
the GPIOD pin OR-mask + comment. PD9 + PD10 now default to high-Z
inputs after MCU reset — no leakage path because the FPGA-side ports
are gone.
MCU regression: 51/51 + 34/34 suites green. FPGA regression unchanged
at 42/0/0 (XDC isn't consumed by iverilog).
The remaining DIG_0..DIG_3 bus pins are PD8 stm32_new_chirp (kept until
commit 5 renames it to stm32_beam_ready), PD11 stm32_mixers_enable, and
PD12 reset_n.
Restore regression to green after commit 1's RTL strip. Drop dead-signal
references from 10 TBs to match the post-strip RTL surface:
- chirp TBs: drop clk_100m / reset_100m_n / new_elevation / new_azimuth
port wiring on plfm_chirp_controller_v2; drop elevation/azimuth counter
wires + check() assertions; retire Group 9 (Beam steering counters) in
tb_chirp_controller and C3 (stm32 toggle non-drive) in tb_chirp_contract.
- system TBs: drop stm32_new_chirp / stm32_new_elevation / stm32_new_azimuth
regs + DUT port wiring; drop current_elevation / current_azimuth wires;
delete stm32_chirp_toggle helper task; retire G6.1 (radar_mode opcode
0x01), G6.6 (trigger_pulse opcode 0x02), G7.1 (STM32->FPGA chirp CDC
stress), and G14.1/.2/.3 (range_mode opcode 0x20) test groups; replace
stm32_chirp_toggle calls in G2 with passive waits (scheduler auto-scans).
- receiver TB: drop .host_mode / .host_range_mode / .host_trigger ties.
- usb TBs: drop status_radar_mode / status_range_mode regs + DUT port
wiring + apply_reset init + per-test setup; update word[4][1:0] expected
value from 2'b10 (range_mode=2) to 2'b00 (now reserved) in
tb_usb_data_interface; refresh T3.7 comment in tb_usb_protocol_v2
(assertion value 0x60 unchanged because range_mode was already 2'd0).
- adc pwdn TB: strip host_radar_mode dummy reg + opcode 0x01 dispatch from
the local dispatch_block mirror; rewrite T5 with unknown opcode 0x05 to
preserve the dispatch-isolation case after 0x01 retirement.
Regression: 42/0/0 (was 37/0/6 in the pre-strip baseline where scipy was
unavailable; with radar_venv on PATH all 42 phases run and pass).
Flatten chirp_scheduler.v to single-FSM auto-scan. Mode 00 (STM32 pass-through),
mode 10 (single-chirp debug) and mode 11 (track dwell) FSM branches were all
half-implemented and unreachable in production: MCU dispatcher was deleted in
F-2.1; mode 11 inputs were tied to constants in radar_receiver_final; mode 10
debug_wave_sel was hardcoded to SHORT. The case-switch wrapper, watchdog,
effective_mode mux, and all host_track_* / host_debug_wave_sel / host_trigger
plumbing are removed.
Strip host_radar_mode (opcode 0x01), host_trigger_pulse (opcode 0x02), and
host_range_mode (opcode 0x20). The mode register had no consumer after the
single-mode flatten; the range_mode register was already write-only telemetry
(declared as input in radar_receiver_final but never read). The runtime 3km vs
20km presentation on a 200T build is driven by host_subframe_enable (0x19) +
per-waveform chirp/listen cycles (0x10-0x18) — no separate mode field needed.
Strip stm32_new_elevation / stm32_new_azimuth GPIOs and the elevation_counter /
azimuth_counter regs in plfm_chirp_controller_v2. The FPGA-side counters had no
consumer (status pack never carried them; on 50T they went to _nc; on 200T to
unconstrained outputs). MCU software counters n/y reach the GUI via USB-CDC
on a separate channel.
USB status word 0 bits [23:22] (was radar_mode) and word 4 bits [1:0] (was
range_mode) are now reserved zeros — host parser keeps the same byte offsets.
Files modified:
chirp_scheduler.v - flatten to single FSM (~155 LOC delta)
plfm_chirp_controller_v2.v - strip counter blocks + ports
radar_transmitter.v - strip elev/azim CDC + edge detectors + ports
radar_receiver_final.v - strip host_mode/range_mode/trigger + STM32 toggle ports
radar_system_top.v - strip regs, opcodes 0x01/0x02/0x20, status_*_mode wiring, top-level ports
radar_system_top_50t.v - strip _nc wires + stm32_new_elev/azim + tie-offs
radar_system_top_te0713_umft601x_dev.v - strip status_radar_mode/range_mode ties
usb_data_interface.v - drop status_*_mode ports, reserve word 0 [23:22] + word 4 [1:0]
usb_data_interface_ft2232h.v - same as above
radar_params.vh - strip RP_MODE_* / RP_RANGE_MODE_* / RP_OP_RADAR_MODE / RP_OP_TRIGGER_PULSE / RP_OP_RANGE_MODE / RP_DEF_TRACK_*
Regression will fail at this commit due to TB references to deleted signals
(host_radar_mode, status_range_mode, etc.) — TB cleanup follows in commit 2.
Cleanup of the four cosmetic items flagged in the PR-AB.b layout audit:
- Settings tab: the "Host-Side Signal Processing" group note used DARK_WARNING
(orange) but is purely explanatory, not a caution — converted to italic
DARK_INFO (blue) so it matches the equally-informational Bench-mode note
in the next group.
- AGC group ALWAYS-ON badge: added margin-bottom so it reads as a header
rather than sitting flush against the first AGC Target row.
- Detected Targets table: "Velocity (m/s)" header was clipping its leading
V against the column divider under Stretch resize mode (column width
~92 px, header text ~140 px). Header text shortened to "Vel (m/s)" so
it sits comfortably alongside Range/Confidence/Magnitude/SNR/Track ID;
QHeaderView::section padding bumped 10→12 px for general daylight.
- AGC Monitor strip: Gain/Peak/Total Saturations labels now share a uniform
DARK_FG colour. Only the value text on the AGC mode label still carries
colour (green ALWAYS-ON / AUTO, blue MANUAL), so colour means state
rather than label-decoration.
Regression: GUI v7 150/150.
FPGA (Phase 1+2):
- gpio_dig6 (PD14) now carries chirp_scheduler frame_pulse, FPGA-stretched
to ~100 ns so the STM32 EXTI on PD14 can latch reliably.
- gpio_dig7 (PD15) returns to its pre-PR-AB.b role: control-fault OR
(range_decim_watchdog | CDC overrun); MCU stuck-high sampler unchanged.
- rx_range_decim_watchdog gains a sticky in source clock domain so a slow
status poll cannot miss a 1-cycle assertion (Phase 1).
- New tb_dig6_frame_pulse.v (13 checks); tb_status_words_stickies.v extended
with DIG_7 fault-OR coverage (14 checks); retired tb_audit_s10_gpio_split.v.
- Port comments in radar_system_top.v / _50t.v and XDC roles refreshed.
MCU (Phase 3):
- PD14 reconfigured to GPIO_MODE_IT_RISING + GPIO_PULLDOWN; new
EXTI15_10_IRQHandler in stm32f7xx_it.c dispatches to HAL_GPIO_EXTI_Callback
that bumps a volatile g_frame_pulse_count.
- runRadarPulseSequence dwell loop replaces 3x HAL_Delay(8) with
waitForFramePulse(20) — per-pattern dwell now tracks the actual mask-aware
ladder length (drift-free, mask-aware), with a 20 ms timeout safety net.
- AGC outer loop is ALWAYS-ON in production (compile-time policy); bench
builds compile the body out via -DMCU_AGC_FORCE_DISABLED. The runtime
enable/debounce + DIG_6 polling that previously gated AGC are removed.
- main.h adds FPGA_FRAME_PULSE_* aliases pointing at FPGA_DIG6_*.
GUI (Phase 4):
- Settings tab gains a Bench / Diagnostics group with a BENCH-MODE checkbox
(off by default, persisted via QSettings).
- AGC group header swaps between a green "AGC: ALWAYS-ON" badge (production)
and Enable/Disable AGC buttons (bench), pinned to the top of the group.
The redundant 0/1 spinbox row for opcode 0x28 is removed — buttons send
the same opcode and cannot accept invalid input.
- Both the FPGA Control AGC Status box and the AGC Monitor strip share a
helper that honours bench-mode in production (always shows ALWAYS-ON in
green so the two views never disagree with the badge).
- _add_fpga_param_row uses setFixedWidth on label and Set button + explicit
stretch=1 on the hint, so all rows align column-wise whether they sit
directly in a QVBoxLayout or inside a wrapper QWidget.
Regression: FPGA 42/0/0 (PR-M.4 baseline) - MCU 34/34 - GPS extended 51/51
- GUI v7 150/150 - BENCH-MODE flip behaviorally verified.
Hardware-blocked steps deferred: bench-scope verify (PD14 dwell pulse,
counter advance, PD15 stuck-high recovery still triggers).
Closes#182.
runRadarPulseSequence used to fire vector_0 (broadside reference)
between every matrix1 and matrix2 pattern, i.e. 15 times per azimuth.
That dwell × 8 ms × 15 = 120 ms per azimuth × 50 azimuths = ~6 s of
the 18.4 s revisit time was burned on redundant broadside frames.
Pull vector_0 out of the loop and fire it once per azimuth before the
sweep. Each azimuth now produces 1 broadside frame + 30 steered frames
(matrix1 + matrix2 across 15 beam_pos), down from 15 + 30 = 45 frames.
Revisit time drops from 18.4 s to ~12.8 s (31% improvement).
If multiple per-position broadside frames are ever needed, gate them
behind a runtime switch — the comment block flags this.
test_bug16_runradar_shadows_globals updated to mirror the new
1-outside + 2-inside m-counter pattern; 13/13 PASS, full MCU
regression 51/0 + 34/0.
The WR_DOPPLER_DATA emit advanced mag_rd_addr at end of phase 1 (LSB byte)
but BRAM has 1-cycle read latency, so phase 0 of the next pair re-read
the prior cell. Result: wire pair K = (HIGH(bram[K-1]), LOW(bram[K])) —
adjacent cells silently swapped their high bytes whenever the high byte
differed. Footprint was 30 of 24576 cells (peak rows + high-byte
transitions in the noise floor); max diff 6656 LSB on the target row.
Fix: advance the BRAM read address at end of phase 0 (MSB) so BRAM has
2 cycles between addr-set and the next pair's MSB read. Same pattern
existed in WR_RANGE_DATA — silently broken (regression skips range
stream); fixed for symmetry. After fix, both iverilog and remote
Vivado 2025.2 xsim emit a bit-exact match against the Python golden.
Tighten E12.14 / E12.6.b to strict zero tolerance and rename the
"PR-AA pending" notes to indicate the fix has landed. Target-cell
window check (E12.15) now points at the exact (rb, db) bin.
Verification:
* iverilog A6 in-TB: doppler_mismatches=0/24576 (16/16 PASS)
* iverilog A6 parse strict: 28/28 PASS
* Vivado 2025.2 xsim A6 in-TB: doppler_mismatches=0/24576 (16/16 PASS)
* Vivado 2025.2 xsim A6 parse strict: 28/28 PASS
* Full regression: 41 passed, 0 failed, 0 skipped / 41 total
Bundles audit items unblocked by the AERIS-10 end-to-end audit:
S-1 (radar_system_top.v) — DC notch off-by-one at width=7
Audit S-1: ±W around DC in a 16-bin FFT covers bins {0..W, 16-W..15}
(2W+1 total, bin 8 the only one excluded at W=7). The previous form
`< W || > 15-W+1` missed both boundaries: at W=1 it notched only {0}
(skipping 1 and 15); at W=7 it missed 7 and 9. Replaced with inclusive
comparators against 5-bit limits (`<= notch_lo || >= notch_hi`) which
hit the intended set for all W ∈ {1..7}. Cosim DC golden
(tb/cosim/rtl_bb_dc.csv) regenerated against the corrected behaviour.
S-7 (rx_gain_control.v) — reg→wire for combinational helpers
`wire_frame_sat_incr` / `wire_frame_peak_update` were declared `reg`
and blocking-assigned inside the clocked always block. They are pure
combinational functions of the registered inputs — promoted to
module-scope continuous assigns. Behaviour is bit-identical (the read
inside the always still reflects the prior-cycle latched values) but
the iverilog warnings disappear and the sim/synth correspondence is
unambiguous.
M-9 (formal/fv_radar_mode_controller.sby) — delete orphan
radar_mode_controller.v was retired in PR-D in favour of
chirp_scheduler.v; the .sby was never updated and pointed at a
non-existent module. Deleted.
M-10 (radar_receiver_final.v) — document `data_sync_error` unconnected
In production AD9484 produces a single 8-bit stream that the DDC mixes
into matched I/Q paths with symmetric pipelines, so `ddc_valid_i` and
`ddc_valid_q` rise on the same cycle and `data_sync_error` cannot
fire by construction. The check is retained inside
ddc_input_interface for the standalone tb_ddc_input_interface
unit-test (which intentionally drives valid_i ≠ valid_q). Adds
comments explaining the unconnected port at both call sites; no
functional change.
M-11 (radar_receiver_final.v) — `force_saturation_pulse` symmetric hook
The DDC has a `force_saturation` debug input that previously was tied
1'b0 directly. Routed through a new `force_saturation_pulse` wire
alongside the existing `clear_monitors_pulse` so a future host opcode
surface for "diagnostic force/clear" lands both at the same dispatch
point. Still tied 1'b0 today — RTL change is a placeholder for the
opcode plumbing.
PR-X.3 F-7.5 (formal/fv_cdc_adc.{v,sby}) — retarget to cdc_async_fifo
Prior wrapper instantiated `cdc_adc_to_processing`, retired by
AUDIT-C11 in favour of `cdc_async_fifo` (the production CIC→FIR
boundary CDC, see ddc_400m.v line 646). Wrapper rewritten with
FIFO-shaped equivalents of the original Gray-CDC properties:
P1 reset behaviour, P2 no spurious dst_valid, P3 overrun semantics,
P4 data integrity (cooldown-spaced, FIFO-equivalent of the
original single-element latch property),
P5 bounded liveness (depth 100 gclk),
P6 cover sequences for the basic write→read pipeline.
P4's true multi-in-flight FIFO order proof is left as Option B work;
for the AERIS-10 use case the upstream ddc_400m CIC→FIR consumer
operates below FIFO-fill rate by design, so the cooldown-spacing
assumption is a tight model.
Verification: full FPGA regression 41 / 0 / 0.
The PR-Z A6 e2e test (tb_e2e_dsp_to_host) exposed that the wire-format
cfar_dense map emitted by usb_data_interface_ft2232h was all-zero for
our deterministic single-target stimulus, even though cfar_ca's
in-flight outputs showed CONFIRMED at the expected cells (verified via
in-TB capture, E5/E6 PASS).
Deep instrumented debug (BRAM-WRITE, BRAM-READ, EGRESS-CAP probes)
revealed THREE independent bugs that combined to produce the all-zero
wire output. Each bug alone would have been visible; the way they
compounded made the symptom look like a single coarse failure.
Bug A — stale write address (radar_system_top.v):
usb_inst.range_bin_in/doppler_bin_in were tied to notched_*_bin
(= rx_*_bin = doppler_processor outputs). After doppler returns to
S_IDLE its `output reg`s hold their last-driven values (511, 47).
cfar_ca's CMP-phase emit (cycles ~520..73520 after frame_complete)
fires cfar_valid with detect_range/detect_doppler set to its own
per-cell scan counters, but those outputs were dangling — usb's
RMW saw the doppler stale (511, 47) and slammed every cfar write
to byte_addr {511, 47[5:2]} = bram[8187], past the 6144-byte wire
range entirely.
Fix: register cfar_detect_range/doppler in lockstep with the existing
rx_detect_valid/rx_detect_class registration block (clk_100m_buf
domain), then mux them into usb_inst.range_bin_in/doppler_bin_in on
rx_detect_valid. doppler-magnitude write path is unaffected because
doppler_valid and rx_detect_valid are mutually exclusive (BUFFER vs
CMP phases of cfar_ca).
Bug B — BRAM read pipeline lag (usb_data_interface_ft2232h.v):
The detect_rd_data <= detect_bram[detect_rd_addr] BRAM read port has
1-cycle latency. WR_DETECT_DATA's emit FSM advanced detect_rd_addr
and read detect_rd_data in the SAME edge — so cycle K read bram[K-2]
(the addr from cycle K-1's commit) instead of bram[K-1]. Result:
every cfar wire byte = bram[N-1] instead of bram[N], shifting the
entire 6144-byte detect section +1 byte = +4 doppler bins. Doppler
hides this naturally because its 2-byte-per-cell rhythm gives BRAM a
free settling cycle between addr-set and emit-read.
Fix: pre-load detect_rd_addr <= 1 and det_doppler_byte_idx <= 1 at
every WR_DETECT_DATA entry transition (HDR direct, RANGE direct,
DOPPLER → DETECT). BRAM produces bram[0] for the first emit cycle
(settled since reset because detect_rd_addr was 0 throughout the
preceding section) while the addr advance schedules bram[1] for the
second emit cycle — and from then on the FSM's natural advance
pattern keeps the pipeline aligned, including across the per-range
boundary (det_doppler_byte_idx == DET_BYTE_LAST_PER_RANGE).
Bug C — detect_clearing window overlaps cfar's first 4 columns:
detect_clearing fired 1 cycle after frame_complete and ran for 8192
clk cycles (1 byte/cycle). cfar_valid writes were gated on
`!detect_clearing` (line 512). cfar's CMP-phase emits start at
frame_complete + ~520 cycles and run for ~73000 cycles, so the
first ~7672 cycles (≈ 4 doppler columns) of cfar pulses were
silently dropped. Test stimulus lit (67, 2/3) for sub-frame 0, all
inside the clearing window → bytes lost. (67, 18/19) and (67, 34/35)
for SF1/SF2 fell after clearing → captured correctly. Visible as
one-byte mismatch (0x0A expected, 0x00 captured) at offset 49965
(= cfar byte 804 = range 67, doppler 0..3) once Bugs A and B were
fixed.
Fix: move detect_clearing trigger from "1 cycle after frame_complete"
to wr_done_pulse (USB-transfer-complete edge already CDC'd into clk
via the AUDIT-C12 wr_done_sync chain). Clearing now runs in the dead
zone after USB has finished reading frame N's BRAM, well before
frame N+1's cfar starts CMP (~480k cycles of margin at 178 fps).
First frame after reset relies on BRAM init=0 — added explicit
initial block under `ifdef SIMULATION so iverilog matches Vivado's
synthesis default.
Test infrastructure:
- tb/tb_e2e_dsp_to_host.v new — deterministic single-target stimulus
fed through the back-half of the radar pipeline (range_decim → MTI
→ doppler → DC-notch → cfar → registered sync → usb), 16 in-TB
asserts + bit-exact byte capture.
- tb/cosim/gen_e2e_stimulus.py / gen_e2e_expected.py new — Python
deterministic stim + bit-exact frame golden.
- tb/cosim/tb_e2e_dsp_to_host_parse.py new — parses captured frame
via radar_protocol, runs 12 strict-bit-equality checks plus 16
semantic checks (target == CONFIRMED, neighbors == NONE,
DC-notched bins == NONE, etc).
- run_regression.sh — A6 hookup + retired the two zero-assertion
radar_system_tb USB_MODE=0/1 smoke runs and the 3-liveness-only
tb_system_dataflow (subsumed by A6's stronger checks). Saves
~7 min wall.
Verification:
- Local iverilog: in-TB 16/16 PASS, parser strict 28/28 PASS.
- Remote Vivado 2025.2 xsim (Artix-7 target): in-TB 16/16 PASS,
parser strict 28/28 PASS.
- Full regression: 41 / 0 / 0.
The MODEL_USB_CFAR_BUG bug-model flag (used to keep the regression
green during development against buggy production) is removed — the
test is now strict bit-exact against the post-fix wire format.
Header (line 6, 11): "(IBUFDS, BUFG, IDDR)" → "(IBUFDS, BUFIO, BUFG,
MMCME2_ADV)"; "IDDR Q2 (falling-edge) data capture in
SAME_EDGE_PIPELINED mode" → "Falling-DCO-edge IOB-packed IFF capture
(post-AUDIT-C4 SDR shape; no IDDR, no rise/fall demux)".
$display banner: "(IBUFDS, BUFG, IDDR)" → "(IBUFDS, BUFIO, BUFG, MMCME2)".
Group 8 inline comment: "captures Q2 of the IDDR (falling-edge…)"
→ "captures the IOB-packed IFF on the falling DCO edge".
Test Group 4 retired. The block drove 0xAA on rising DCO and 0x55 on
falling DCO. Post-AUDIT-C4 the IFF only samples the falling edge —
every captured value was 0x55 — so the assertion
`saw_aa > 0 || saw_55 > 0` was trivially true and `cap_count > 0`
duplicates Group 5 / Group 8's stronger checks. Block replaced with
a tombstone comment; group numbering preserved for git-blame
continuity.
Two "IDDR" references intentionally retained inside negations
(line 12, line 186) — they explicitly contrast the current SDR
topology against the broken pre-C-4 shape so a reader who finds the
old vocabulary in git history understands what changed.
Verification: remote Vivado 2025.2 xsim → 15 / 15 PASS
(was 17 / 17; the lost 2 are Group 4's trivial-pass and existence
checks, both now subsumed by Groups 5 / 8).
Constraint values are unchanged — only the explanatory comments are
refreshed to match the post-AUDIT-C4 (2026-05-01) RTL.
- "IDDR outputs" → "IFF Q output"
- "adc_data_{rise,fall}_bufg" → "adc_data_iff_bufg"
- "the IDDR ~1.4ns before the clock" → "the IOB-packed IFF ~1.4ns
before the clock"
- hold-waiver header "BUFIO-clocked IDDR" → "BUFIO-clocked IFF, SDR"
- "BUFIO/IDDR domain" → "BUFIO/IFF domain"
The 3.000 ns set_max_delay (BUFIO ↔ clk_mmcm_out0), the
set_false_path -hold on adc_d_p[*]/adc_or_p, the LOCKED-pin
through-waiver, and the 0.150 ns set_clock_uncertainty all remain
bit-identical — the IFF capture has the exact same source-synchronous
timing argument as the prior IDDR did.
One reference to "IDDR" deliberately kept inside a negation
("no IDDR, no rise/fall demux") — explicitly contrasts the current
SDR topology with the broken pre-C-4 shape so a reader who finds the
old vocabulary in git history understands what changed.
adc_clk_mmcm_integration.md was a 164-line "Step 1: modify
ad9484_interface_400m.v / Replace the BUFG instantiation with
adc_clk_mmcm" walkthrough for an integration that is already
shipped in the production RTL.
ad9484_interface_400m.v lines 68-102 already document the BUFIO/BUFG/
MMCME2 topology inline ("MMCME2 jitter-cleaning wrapper replaces the
direct BUFG. The PLL feedback loop attenuates input jitter from ~50 ps
to ~20-30 ps..."). adc_clk_mmcm.v has the wrapper itself with its own
header. constraints/adc_clk_mmcm.xdc carries the timing rationale.
A future engineer reading the integration recipe could mistake the
already-integrated feature for unfinished work and try to redo the
"Step 1: modify" edits — actively harmful.
Bench-verify the F-7.4 MMCM-lock gating (commit 6738f12) under real
Xilinx UNISIM primitives, not just the iverilog stub.
ad9484_interface_400m.v
Add `timescale 1ns / 1ps. Lone RTL file missing it; xelab refused
to elaborate alongside TB+wrapper that both declared a timescale.
tb/tb_ad9484_xsim.v
Test Group 2 ("adc_dco_bufg toggles") moved below the first
wait_for_adc_ready() — adc_dco_bufg now sources MMCM CLKOUT, which
is gated until the MMCM SIM model locks (~4096 DCO cycles after
reset deassert). Sampling pre-lock saw a stuck output, not a real
BUFG defect.
Test 17 SDR-ramp "no skips" tolerance 0 → 1 — Test 15 already
grants a 6-sample startup-transient window for diff_one_count.
Observed delta-other = 1 of 63 is the same pipeline-startup
transient (first valid sample arrives before ramp launch
aligns), not a demux bug.
scripts/50t/run_ad9484_xsim.sh (new)
xvlog + glbl.v + xelab -L unisims_ver -L secureip + xsim --runall.
Mirrors run_xfft_xsim.sh / run_mf_chain_xsim.sh pattern.
Verification:
remote Vivado 2025.2 xsim → 17 / 17 PASS (** ALL TESTS PASSED **)
local iverilog regression → 43 / 0 / 0 (was 37 / 0 / 6)
Closes PR-N #86 on the real simulator path.
Three sub-checks in compare_independent.py were red because the test
inputs assumed an UNSCALED FFT but PR-O moved both the RTL xFFT path
and fpga_model.FFTEngine to LogiCORE v9.1 Scaled mode (one >>>1 per
butterfly stage with conv-rounding, total /N applied across LOG2N
stages). At small input amplitudes the per-bin output rounded to zero
and the test invariants no longer described meaningful behaviour.
The fpga_reference.py side already mirrors the scaled-mode convention
(np.fft.fft(x)/n on forward, ifft on inverse — see line 104, 137-138,
207). The fix is purely in the test inputs:
- FFT-2048(impulse): amp 1000 → 32000 (≈ Q15 max). Expected per-bin
is now round(amp/N) = round(32000/2048) = 16 (banker's). The
impulse has b=0 at every butterfly so there is no twiddle
interaction; banker's rounding keeps every bin within ±1 LSB.
Tightened tolerance from 5 to 2.
- MF peak position + MF peak-to-median: amp 200 → 4000. Chain
output peak under scaled-mode is correlation/N² ≈ pulse_len*amp²
/N² = amp²/16384 (256 / 4_194_304). At amp=200 the peak collapsed
to 2.4 (mostly Q15 quantization noise — argmax wandered to bin 2);
at amp=4000 the peak rises to ≈ 977 with sidelobes near LSB
floor. Peak-to-median ratio observed: 974 vs threshold 5.
Runtime verification: compare_independent.py 13/13 PASS standalone.
Full FPGA regression: 36/1/6 → 37/0/6 (the single FAIL was this test;
no other tests touched).
Stage-7 ADC chain audit. radar_receiver_final.v's
adc_overrange_sticky_400m had no clear path other than full system
reset_n — once latched, the only way to acknowledge the AD9484
overrange flag was a reboot. The DDC's analogous diagnostic flags
(cdc_cic_fir_overrun_sticky, mixer_saturation) already clear on the
DDC's `reset_monitors` port; the OR sticky in the receiver wrapper
was the lone outlier.
Introduce a shared `clear_monitors_pulse` wire at the receiver scope
and route it both to the OR sticky's clear branch and to the DDC's
`reset_monitors` port (replacing the literal `1'b0`). Today the
wire is tied 1'b0, preserving the prior reset_n-only behaviour bit-
for-bit. When a future host opcode for "clear diagnostic stickies"
lands, both the receiver-level OR sticky and the DDC's internal
sticky flags clear from the same pulse — no per-flag re-plumbing.
Local FPGA regression 36/1/6 unchanged (1 FAIL = pre-existing T-6
drift, deferred PR-M.4).
Stage-7 ADC chain audit. ddc_400m.v line 273-274 converted AD9484
offset-binary 8-bit codes to MIXER_WIDTH-bit signed via
`(adc << 9) - (8'hFF << 8)`. The right operand evaluates to
`0xFF / 2 = 0x7F` (integer divide drops 0.5), so the formula
subtracted 65280 instead of the correct mid-scale offset 65536:
- code 0x80 (0V analog, mid-scale) → +256 (expected 0)
- code 0x00 (-fs) → -65280 (expected -65536)
- code 0xFF (+fs - 1 LSB) → +65280 (expected +65024)
A 0.5-LSB DC bias on the AD9484 stream is functionally invisible
in production: after the 120 MHz NCO mixer it lands at ±120 MHz,
which the CIC + FIR LPF (~50 MHz rolloff) rejects. But the offbin
and twoc paths disagreed on the same analog input, and any reuse
of `adc_signed_offbin` outside the mixer chain would carry the
bias.
Replace with an MSB-flip + sign-extend + 9-zero pad that mirrors
the twoc branch: `{~msb, ~msb, low7, 9'b0}`. Mid-scale code 0x80
now produces 0 exactly, matching the twoc path bit-for-bit.
Local FPGA regression 36/1/6 unchanged (1 FAIL = pre-existing
T-6 drift, deferred PR-M.4).
Stage-7 ADC chain audit. The MMCM SIMULATION model in adc_clk_mmcm.v
takes 4096 DCO cycles (~10 µs at 400 MHz) to assert mmcm_locked. The
existing TB waited only ~5 cycles after each reset deassert, so the
gated reset_n_400m never released and adc_data_valid_400m stayed low
for every test group past the initial reset checks.
Expose mmcm_locked as a new module output on ad9484_interface_400m
(real path) and ad9484_interface_400m_stub (sim path; tied high one
DCO cycle after reset deassert since the stub has no MMCM). Connect
it through to tb_ad9484_xsim.v and add a `wait_for_adc_ready` task
that waits on the lock signal plus 6 DCO cycles for the 2-FF
lock-sync, 2-FF reset-sync, and pipeline drain. Apply the task at
each of the five reset cycles in the testbench.
radar_receiver_final.v: tie the new port off (.mmcm_locked()) — host
status pipeline doesn't surface lock yet, deferred for a future
status-word widening.
Local iverilog regression (36/0/7) clean. xsim verification of the
xsim-only TB itself is pending (remote Vivado host).
API hygiene. setADTR1107Mode flips ADTR1107 PA/LNA bias registers but
does NOT touch the per-channel ADAR1000 RX/TX enable bits. Production
always reaches it through setAllDevicesTXMode / setAllDevicesRXMode,
which emit both halves. Leaving setADTR1107Mode public after F-6.1
removed the other public mode-switch wrappers invited a future caller
to invoke it directly and end up in a mismatched bias-vs-enable state.
Move the declaration to the private section with a short comment
explaining why the wrappers are the only sanctioned entry point.
Latent bit-mask hygiene gap. setADTR1107Mode(TX) was asserting BIAS_EN
(bit 5) without first clearing LNA_BIAS_OUT_EN (bit 4); the RX branch
mirrored the bug. On any TX→RX→TX (or symmetric) transition through
this register both PA and LNA bias outputs would end up enabled
simultaneously. Production today only ever calls one direction at boot
and the opposite at shutdown — never both during normal operation —
so the bug was unreachable, but a future per-chirp SPI mode switch
would trip it.
Now each branch resetBit's the opposite enable before asserting its
own. 1 line per branch loop (not 1 per device — used the existing
for-dev loop).
Stage-6 ADTR1107 audit cleanup. Delete 4 unused public methods plus
their 2 internal helpers from ADAR1000_Manager.cpp/h. Production boot
goes through main.cpp's C-style systemPowerUpSequence(), so the C++
ADAR1000Manager::powerUpSystem / powerDownSystem / switchToTXMode /
switchToRXMode wrappers had zero call sites; the same was true of the
setPABias / setLNABias helpers, only ever invoked from the dead
switchTo* paths. -130 LOC, no behavioral change.
kPaBiasRxSafe is intentionally KEPT — it is live-used inside
setADTR1107Mode(RX) as the safe PA bias when transitioning to RX.
Drop 5 antenna sims that were either dead-end topologies or got superseded
by validated v3 designs. The kept set documents the path the project
actually took: edge-fed series-fed row on 0.508 mm RO4350B (drop-in
old-Gerber replacement, 100 MHz BW), with the single-element edge-fed
inset and probe-fed comparators kept as design-space reference points,
and production_beams_verify retained as the D-series audit artifact for
the ADAR1000 setBeamAngle() dead-code finding.
Removed:
Quartz_Waveguide.py
openems_quartz_slotted_wg_10p5GHz.py
Early waveguide explorations, abandoned when the project moved
to a planar patch array.
aperture_coupled_aeris10_v2.py
First openEMS attempt at the AERIS-10 design point. Achieved
60 MHz BW with residual reactance; superseded by the v3 paths
(probe-fed 180 MHz BW, edge-fed-inset 180 MHz BW, edge-fed
series-fed row 100 MHz BW) that landed shortly after.
array_factor_adar1000_aeris10.py
Pure-numpy ADAR1000 phase-quantization sim used to find that
setBeamAngle()'s 4-elem broadcast produces grating lobes and
that the function is dead in production (replaced by
initializeBeamMatrices + setCustomBeamPattern16). Findings
already actioned in commit 38ee73a (D1/D6/D7 tombstone removal)
and recorded in project_aeris10_setBeamAngle_bug_2026-05-04.md.
probe_fed_array_aeris10_v3.py
4×4 probe-fed multi-port openEMS array for mutual-coupling
characterisation. Mooted now that the chosen production path
is the 1×8 edge-fed series-fed row, not a probe-fed array.
Kept:
edge_fed_row_aeris10_v3.py — chosen production design (1×8 row)
edge_fed_row_nf2ff_aeris10_v3.py — far-field for the row
edge_fed_aeris10_v3.py — single-element baseline for the row
probe_fed_aeris10_v3.py — alt-design comparator (180 MHz BW)
production_beams_verify_aeris10.py — D-series audit artifact
Lint: ruff full-repo still clean. No cross-imports between kept and
dropped scripts (verified pre-removal).
Closeout pass for the G-series 3-ladder chirp + adaptive-escalation work.
Cleanup, watchdog/fallback, lint, full regression — final sign-off.
Cleanup + watchdog/fallback: already wired during earlier audit waves
(track watchdog in chirp_scheduler RP_DEF_TRACK_WATCHDOG_FRAMES, RESERVED
fallback in plfm_chirp_controller_v2, range-decim watchdog in
radar_system_top with gpio_dig7 surfacing, F-3.* MCU error path).
Verified — no residual TODO/FIXME in production RTL or MCU.
Regression infra: tb/cosim/compare_independent.py SKIP-detection bug —
importlib.util.find_spec("scipy.signal") raises ModuleNotFoundError when
the parent scipy package is itself absent (instead of returning None as
the surrounding logic assumed). Wrap in try/except so the regression
runner gets the intended rc=2 SKIP marker rather than a crash that masks
the rest of the script.
Lint sweep: ruff full-repo → 0 errors. Two changes:
- pyproject.toml broadens 5_Simulations/Antenna/**.py exemption from
just T20+ERA to the full set of script-ergonomics rules
(RUF001/002/003 Greek µ/λ/π/θ in physical-units strings, E501 long
matplotlib/numpy lines, RUF005/015/046, E70x one-line setup, B007
tuple-unpack loop vars, B905, BLE001 diag try/except, C401, RET504,
SIM118, PERF40x, ARG001, E402). These are sim/analysis scripts, not
production code — keep substantive bug rules (F unused, B core
bugbears) but drop stylistic noise.
- Auto-fix sweep: 31x F541 (f-string-no-placeholder), 3x F401 (unused
sys import), 2x F841 (dead leftover ref_pat / phases_quant in
array_factor_adar1000_aeris10.py).
.gitignore: cover 9_Firmware/9_2_FPGA/tb/cosim/mf_chain_autocorr.csv
(matched_filter cosim writes here now; was already covered for tb/ but
not tb/cosim/).
Regression baseline (radar_venv):
FPGA : 42/43 — 1 pre-existing T-6 drift cosim fail surfaced by the
SKIP fix above. Three sub-checks now red because PR-O moved
xFFT/MF chain to LogiCORE v9.1 *Scaled* mode (1/2 per stage,
1/2^11 total for N=2048) but compare_independent.py's invariants
(FFT-impulse uniform-spectrum, MF peak-at-injected-delay, MF
peak/median ≥ 5) were written assuming UNSCALED FFT. Not
introduced by this PR — was hidden by the SKIP-detection crash.
Defer to PR-M.4: redesign T-6 invariants (or input amplitudes)
to match scaled-mode arithmetic.
MCU : 34/34 binary suites pass.
GUI : test_v7 150/150 pass.
uv.lock: scipy resolution catch-up (declared in pyproject dev group all
along; lock just hadn't been refreshed after pyproject edits landed).
Bench-side checks: none — this PR is repo hygiene, no firmware/RTL
behaviour change.
Adapts Serhii's TestLiveReplayPhysicalUnitsParity (f895c02 on develop) to
the post-PR-Q.6 worker structure on feat/dual-range-v2.
The original f895c02 fix was for a bug where RadarDataWorker._run_host_dsp
read self._settings.velocity_resolution (RadarSettings default 1.0 m/s/bin)
while ReplayWorker used WaveformConfig (~5.343 m/s/bin) — live GUI under-
reported velocity by ~5.34x vs replay. PR-Q.6 unified both paths through
extract_targets_from_frame_crt(frame, self._waveform, ...) so the
functional bug is already gone here, but no regression test guarded the
contract until now.
Adapted assertions: AST walk of workers.py asserts that
RadarDataWorker._run_host_dsp and ReplayWorker._emit_frame both
- call extract_targets_from_frame_crt (or self._extract_targets, which
ReplayWorker.__init__ binds to it) with self._waveform as an arg, AND
- do not read self._settings.{velocity,range}_resolution.
Headless-CI-safe via ast.parse on workers.py — no v7.workers import,
no PyQt6 dependency in the test path.
Test result: 4/4 new tests pass; full test_v7 150/150 pass (19 skipped,
PyQt6-gated as expected).
Co-Authored-By: Serhii <jshmitz@me.com>
F-5.1: revert PWM scaffolding to binary DELADJ. Schematic-verified:
PG7/PG13 on STM32F746ZGT7 have no TIM3 alternate function (Port G AFs are
FMC/ETH/USART6/SAI2/SDMMC2 — no TIMx routes), and the FreqSynth-board
DELADJ net has only a 200 kOhm pulldown (R22, R35) — no series-R +
shunt-C LPF for PWM-to-DC. The 3979693 (Bug #5) + c466021 (B15) PWM
scaffolding was a false-fix; 5fbe97f's original honest TODO matched the
actual hardware. Delete htim3, MX_TIM3_Init, start/stop_deladj_pwm,
phase_ps_to_duty_cycle. Rewrite test_bug5 for binary; delete test_bug15.
F-5.2: split ADF4382A ref_div per device. RX 10.38 GHz / 300 MHz = 34.6 is
fractional mode, but ADF4382_PFD_FREQ_FRAC_MAX = 250 MHz — driver does
not reject the out-of-spec config, ldwin_pw silently left at 0. Set
rx_param.ref_div = 2 -> PFD = 150 MHz, in spec. TX unchanged (integer).
F-5.3: free prior tx_dev/rx_dev in Manager_Init before re-allocating. The
recovery dispatch on TX/RX unlock calls Manager_Init again; previous
adf4382_dev allocations were leaking. Mirrors F-4.5 fix for AD9523.
F-5.4: fix upstream adf4382_remove() — only freed dev struct on FAILED SPI
removal (success path leaked) and always returned 0. Now: NULL guard,
unconditional free, propagate ret.
F-5.8: lock-detect uses register reg[0x58] LOCKED bit as authoritative.
GPIO disagreement still logged via DIAG_WARN but no longer flips the
result — a mis-routed GPIO LKDET would otherwise trigger false-unlock
recovery loops.
F-5.10: drop stale "EZSYNC" diagnostic string (post-C-14a residue).
Bench-side checks for first power-on:
- Scope PG13 (TX_DELADJ) and PG7 (RX_DELADJ) — both should be HIGH (3.3V)
after SetPhaseShift(500,500) runs at boot.
- Confirm both ADF4382A LOs lock with PFD=150 MHz on RX (was 300 MHz).
Lock-time may be slightly longer; phase-noise sidebands shift.
- Confirm no false-unlock storms on the recovery path — the GPIO LKDET
disagreement DIAG_WARN should no longer flip the lock decision.
Regression: tests/ make test 34/34 PASS (was 35/35 baseline; -1 from
test_bug15 deletion as planned).
The F-4.1+4.2+4.7 patch (ddc0df4) made ad9523_init() run before the
user pdata overrides, which means pll1_bypass_en=0 (the previous
override) is now actually honoured by the driver. Combined with the
fact that pll1_charge_pump_current_nA and pll1_feedback_div were
never set in main.cpp, PLL1 would be expected active but couldn't
lock (CP=0) — ad9523_status() with bypass_en=0 checks PLL1+REFA+REFB
bits, so the failure surfaces, returns -1, and configure_ad9523()
halts boot at main.cpp:1742.
Option A: set pll1_bypass_en=1. VCXO free-runs on its own crystal
stability; ad9523_status() skips PLL1 checks. Boot path is now
clean. Trade-off: VCXO frequency drifts with temperature (~±20 ppm
over -40°C..+85°C for typical XO) — acceptable for first-flight
checkout, but eventual production should re-enable PLL1 (Option B,
deferred to F-4.3/4.4 with measured loop-filter values).
Comment notes the deferral and what's needed before flipping to
bypass=0 (CP current + loop filter rzero tuned to VCXO Kvco).
Regression: 86/0.
F-4.5: ad9523_setup() malloc's both an ad9523_dev and a no_os SPI
descriptor (ad9523.c:430,435). Previously the dev pointer was local
to configure_ad9523() and fell out of scope on return — every
recovery cycle (ERROR_AD9523_CLOCK → re-run configure_ad9523) leaked
one struct + one SPI desc. STM32F7 heap is bounded; sustained
brown-out flapping would eventually exhaust it. Move dev to a file-
scope `g_ad9523_dev` and call ad9523_remove() at the top of
configure_ad9523() to free the previous instance before re-setup.
Initial boot path is unaffected (g_ad9523_dev=NULL → remove call
gated by NULL check).
F-4.6: ad9523_setup() called ad9523_calibrate() but discarded its
return value (ad9523.c:707). VCO calibration can fail silently — if
the target VCO is outside the 3.6-4.0 GHz band (e.g. F-4.1 wipe left
PLL2 N=16, target 1.6 GHz), calibrate would report failure but setup
still proceeded to ad9523_status(), where PLL2_LD might pass
spuriously. Capture and propagate the calibrate return so a failed
calibration aborts setup with a clear non-zero status code instead
of being absorbed.
Both fixes are mechanical and don't change correct-path behaviour.
Regression: 86/0 (mocks bypass real driver, so F-4.6 is not covered
by tests; F-4.5 changes are in main.cpp and don't trip mocked
configure_ad9523).
Three coupled bugs in configure_ad9523() that together prevented the
AD9523 from producing the labelled output frequencies:
F-4.1: ad9523_init() unconditionally overwrites every field in the
caller's pdata (vcxo_freq=0, pll1_bypass_en=1, pll2_ndiv_b_cnt=4,
all channel fields). Calling it AFTER customization wiped every user
value. Reorder: call ad9523_init() before the pdata.X = Y block; user
overrides land on top of ADI defaults instead of being wiped.
F-4.2: pll2_vco_diff_m1 / m2 are required (range 3..5 per datasheet)
but were left at 0 from memset. The driver's AD_IFE() macro promotes
m=0 to M_PWR_DOWN_EN, killing channels 4-9 (ADC, SYNC, FPGA system
clock, DAC). Set m1=m2=3 explicitly.
F-4.7: AD9523 has no VCO-direct path for OUT4-OUT9; channels source
M1 or M2 only (datasheet + ad9523_vco_out_map register definitions
confirmed). With VCO 3.6 GHz and m1=3, channel dividers see 1.2 GHz,
not 3.6 GHz — every channel_divider in main.cpp was 3x too large.
Updated values:
OUT0/1 (ADF4382A REF, 300 MHz): /12 -> /4
OUT4/5 (ADC + FPGA_ADC, 400 MHz): /9 -> /3
OUT6 (FPGA SYSCLK, 100 MHz): /36 -> /12
OUT7 (FPGA TEST, 20 MHz): /180 -> /60
OUT8/9 (SYNC, 60 MHz): /60 -> /20
OUT10/11 (DAC, 120 MHz): /30 -> /10
m1=3 is the unique choice for this labelled frequency set (m1=4 fails
OUT4, m1=5 fails OUT0/1).
PLL1 (F-4.3/4.4) is not addressed here — pll1_bypass_en=0 with
pll1_charge_pump_current_nA still 0 means PLL1 won't lock and status()
will report it. Decide bypass strategy before bench.
Test mocks (ad_driver_mock.c) bypass the real driver, so this is not
caught by make. Regression: 86/0 (unchanged).
Bench-verify OUT4=400MHz and OUT6=100MHz with scope before trusting
downstream. F-1.10 (which crystal is fitted on X5/X6) goes in the
same bench session — F-4.7 resolution shows 100 MHz VCXO is the only
math-coherent choice regardless of BOM document.
v2 covers the new Stack_Hybrid stackup re-simulation: probe-fed v3
(180 MHz BW, drilled vias) and edge-fed row v3 (100 MHz BW, drop-in
old-Gerber replacement) — both validated on 0.508 mm RO4350B, with
4-panel summary dashboards per variant + NF2FF / array-factor
verification.
reports.html updated to point all three filename references to the
v2 PDF.
Previously the array sim only excited a single inner element
(DRIVEN_X / DRIVEN_Y). Adds DRIVEN_PORTS env var accepting a
comma/semicolon-separated list of "i,j" pairs that are all excited
in-phase with equal amplitude — models a perfect 1:N corporate
splitter feeding an N-patch sub-array.
Example: DRIVEN_PORTS="0,0;1,0;2,0;3,0;0,1;1,1;2,1;3,1" excites a
4-cols × 2-rows sub-array anchored in the corner.
S-parameter post-processing reframed for the multi-driven case:
each excited port reports active-S11 (uf_ref/uf_inc with all driven
ports active); each non-excited port reports S relative to a
representative driven port's incident wave (all driven ports have
equal amplitude so any reference works).
Backwards-compatible: empty DRIVEN_PORTS reverts to single-port
DRIVEN_X / DRIVEN_Y behaviour.
The v1-era tb_cross_layer_ft2232h.v cosim TB no longer matches
production after the protocol-v2 / opcode dispatch rework (PR-G).
Equivalent v2 coverage now lives in the FPGA regression's
tb_usb_protocol_v2.v and tb_system_opcodes.v.
Removed:
- tb_cross_layer_ft2232h.v (716 lines)
- Tier 2 (Verilog cosimulation) from test_cross_layer_contract.py
- iverilog/vvp tool detection and CI install step in ci-tests.yml
Tier 1 (static parser) and Tier 3 (C stub execution) remain. CI
no longer needs apt-get install iverilog.
contract_parser.py updated to reflect the slimmer two-tier model.
Production firmware never used SYNC_METHOD_EZSYNC — both callsites
(main.cpp:938 recovery, main.cpp:1955 boot) pass SYNC_METHOD_TIMED.
The original audit C-14 flagged TX/RX SPI skew in EZSync's trigger
sequence, but the path was dead from production; only test_bug3
referenced it for spy-harness regression coverage.
Removed:
- SYNC_METHOD_EZSYNC enum value
- ADF4382A_SetupEZSync function (and declaration)
- ADF4382A_TriggerEZSync function (and declaration)
- EZSync branch in ADF4382A_Manager_Init (collapsed to unconditional
SetupTimedSync call)
- test_bug3_timed_sync_noop.c Test C (EZSync regression coverage)
Production header and test shim header both cleaned. SyncMethod enum
kept as single-value to avoid touching the 7 other test callers that
pass SYNC_METHOD_TIMED.
Residual concern (separate from original C-14): ADF4382A_TriggerTimedSync
uses the same TX-then-RX sw_sync SPI sequencing pattern as the deleted
EZSync trigger. ~5 µs SPI gap between TX-armed and RX-armed means TX
and RX may capture different SYNCP/SYNCN edges (60 MHz cycle = 16.7 ns,
~300 edges in the gap). External SYNCP only provides simultaneity if
both devices are armed before a common edge. Hardware bench-test
required to confirm operational tolerance; cannot fix in firmware
without DMA SPI burst rewrite.
Regression: 86/0 (matches baseline).
Audit of how the ADAR1000 is actually steered in production. Reproduces
main.cpp:initializeBeamMatrices() (PHASE_DIFFERENCES, matrix1, matrix2,
vector_0) verbatim in Python and runs the patterns through the same array-
factor pipeline used for the firmware-vs-correct comparison.
Key findings — context for fixing the setBeamAngle() bug without regression:
1) setBeamAngle() is DEAD CODE in production. grep for callers across the
whole tree returns only the definition itself (ADAR1000_Manager.cpp:215),
the header declaration (line 58), and one comment in ADAR1000_AGC.cpp
referencing the sign convention. main.cpp does NOT call it. The 4-phase
broadcast bug exposed in commit 2f4d45c is therefore latent, not active.
Fixing setBeamAngle() has zero risk of changing production behaviour.
2) Production path: initializeBeamMatrices() (main.cpp:467) computes
matrix1[bp][el] = degTo7Bit(el * phase_differences[bp]) for all 16
elements properly (no 4-broadcast). main.cpp's runRadarPulseSequence()
then calls setCustomBeamPattern16(matrix1[bp], TX/RX) → 16-element
progressive phase reaches the chips correctly. This part is right.
3) HOWEVER — the production tables themselves have separate concerns:
a) SIGN CONVENTION MISLABEL: comment says "matrix1 = positive steering
angles" but math+sim show positive phase_diff steers to NEGATIVE θ.
matrix1[bp=0] (phase_diff=+160°) → actual peak -62°.
Either the comment is wrong, or hardware wiring inverts what's
labeled "+elevation" — needs a hardware test to confirm.
b) ASYMMETRIC INDEXING: matrix2 uses phase_differences[bp + 16] which
gives matrix2[bp=0]=-3.4° while matrix1[bp=0]=-62°. So as bp goes
0→14, matrix1 zooms in toward broadside (-62°→-4°) while matrix2
zooms out (+4°→+62°) — they're NOT mirror images. Symmetric mirror
would be phase_differences[30 - bp].
c) NON-UNIFORM COVERAGE: phase_differences[] follows 160/n pattern
(160, 80, 53.33, 40, 32, ...). After sin⁻¹ this gives 17 unique
scan angles spanning -62°..+62° with a 36° GAP between -62° and
-26°, but 2° spacing near broadside. May be intentional (oversample
near nominal target line) but flag for confirmation.
d) WORST-CASE SLL at extreme scan (matrix1[0] → -62°): only -2.9 dB.
Main beam barely clears sidelobes — typical at near-grazing scan
due to embedded element pattern roll-off.
e) initializeBeamMatricesWithSteeringAngles() (main.cpp:1611) is also
dead code. It computes the same thing two different ways. Safe to
remove or merge during cleanup.
Recommendation for fix sequence (low → high risk):
i. Fix setBeamAngle() to call setCustomBeamPattern16() with proper
16-element table (or mark deprecated). Zero production risk.
ii. Add unit test that runs setBeamAngle and verifies the resulting
phase codes match a known-good 16-element progression.
iii. Update the misleading comments in initializeBeamMatrices() to say
what the matrices ACTUALLY do (the sign convention).
iv. Hardware test BEFORE touching matrix2 indexing or phase_differences
distribution — these may be deliberately tuned to platform mounting.
PART 1 — edge_fed_row_nf2ff_aeris10_v3.py:
Far-field analysis of the 1x8 series-fed row at 10.520 GHz to discriminate
broadside from scanned operation. Adds an nf2ff probe box to the verified
TX-centered design point (CONN_LEN=8.15) and computes the radiation pattern.
Result: E-plane (along array y) main lobe at θ=0.0°, BW3dB=14°
H-plane (perpendicular) main lobe at θ=0.0°, BW3dB=44°
First sidelobe -12 dB at ±18° (theoretical N=8 uniform: -13 dB)
→ BROADSIDE CONFIRMED at the operating mode.
openEMS NF2FF API notes baked into the script:
- CalcNF2FF expects theta/phi in DEGREES, converts internally.
- Prad/Dmax are sign-buggy in this version; pattern shape (E_norm) is
what we use for broadside identification.
- EndCriteria is 10·log10 energy ratio (so -40 dB → EndCriteria=1e-4).
PART 2 — array_factor_adar1000_aeris10.py:
Phased-array beam-forming verification using the ADAR1000 firmware's actual
phase-shifter codes. Combines the cached single-row embedded-element pattern
with a 16-element x-axis array factor at d=λ/2=14.286 mm pitch (matches
firmware's `element_spacing = wavelength/2` constant).
Replicates ADAR1000_Manager.cpp:714-729 (calculatePhaseSettings) and the
setBeamAngle() loop that broadcasts the 4-phase pattern to all 4 chips.
Compares against the correct 16-element progressive phasing.
CRITICAL FIRMWARE BUG SURFACED BY THE SIM:
setBeamAngle(angle) computes only 4 phases (one per chip channel), then
applies the same 4-phase pattern to all 4 chips. The intended 16-element
beam-steering never actually happens.
At cmd 15°, the firmware writes: [0, 17, 33, 50] × 4 = repeating pattern
Correct 16-elem progression: [0, 17, 33, 50, 66, 83, 99, 116, 5, 21,
38, 54, 71, 87, 104, 120]
Sim consequences (H-plane peak vs commanded):
cmd +0° → fw peaks +0° (correct) / correct +0°
cmd +5° → fw peaks +0° (NO STEERING) / correct -4°
cmd +10° → fw peaks +0° (NO STEERING) / correct -10°
cmd +15° → fw peaks +0° (NO STEERING) / correct -14°
cmd +20° → fw peaks -28° (locked grating) / correct -20°
cmd +30° → fw peaks -30° (coincidence) / correct -30°
cmd +45° → fw peaks -30° (locked) / correct -44°
Why: the same 4-elem pattern broadcast to 4 chips = effective super-pitch
d_super = 4d = 2λ, which generates grating lobes at sin(θ_g)=±0.5±sin(θ_0).
For |cmd|<18° those grating lobes coincide with the fixed broadside peak,
so the array radiates broadside regardless of commanded angle. For larger
commands the beam jumps to ±30° (the grating-lobe direction), not the
intended target.
The proper function setCustomBeamPattern16() (ADAR1000_Manager.cpp:636)
exists but isn't called by setBeamAngle(); fix is to either route through
it from a host-computed 16-element table, or extend calculatePhaseSettings
to produce 16 phases. Tracking under a separate beam-forming PR (not
antenna sim).
Other radar-engineer checks (all PASS for the antenna with proper phasing):
- Phase quantization: 7-bit (2.8125°/LSB) adds <0.2 dB SLL degradation
- Grating lobes: d=λ/2 → none in real space at any scan angle 0..90°
- Scan loss: matches cos(θ) ideal up to ~45°, then EEP roll-off dominates
- Beam pointing: sign-flipped cmd↔peak (cmd +X° peaks at -X°) — wiring
convention; either negate phase_shift in firmware or invert in host
- Null steering: phase-only synthesis places -30 dB null at θ=20° while
keeping main beam at broadside — confirmed feasible
Sweep CONN_LEN at PROFILE=balanced to land the operating-mode dip on the
chirp-band center instead of 60 MHz above it. Sensitivity is df/dCONN ≈
-0.20 GHz/mm (longer line → lower op freq).
CONN=8.00 → dip 10.560 GHz, S11@10.520 = -12.6 dB (above TX)
CONN=8.15 → dip 10.520 GHz, S11@10.520 = -18.8 dB (TX-centered)
CONN=8.20 → dip 10.510 GHz, S11@10.510 = -18.4 dB (TX low edge)
CONN=8.25 → dip 10.500 GHz, S11@10.500 = -18.4 dB (LO-centered)
CONN_LEN=8.15 wins because the radar TX 10.510-10.530 GHz sees -17 to -19 dB
symmetrically across the band, with -15 dB margin at the LO frequency. -10 dB
BW spans 10.470-10.580 GHz (110 MHz). Pitch 15.10 mm vs old Gerber 15.01 mm.
Daisy-chain validation for 2-layer 0.508 mm RO4350B stackup. Row of 8 patches
edge-connected via 8.0 mm microstrip segments (pitch 14.95 mm matches old
Gerber). With direct edge feed on patch 0 (no inset; inset would drop the row
input Z to ~6 Ω), the natural input impedance at the operating mode is ~80 Ω,
close enough to 50 Ω for direct match without a quarter-wave transformer.
Topology behaves as a finite periodic resonator with N=8 modes (~0.5 GHz
spacing) and a stopband centered on the patch self-resonance. Operating point
is the top-below-stopband mode at 10.56 GHz: S11 = -22.5 dB, Zin = 79.9 - j3 Ω.
-10 dB BW spans 10.51-10.61 GHz (100 MHz), covering the 10.510-10.530 GHz
chirp band with S11 = -10.4 to -14.6 dB across that interval.
Mesh sensitivity: sanity profile (lambda/18) gave a misleading deepest-dip at
11.4 GHz; balanced (lambda/25) is required to land the operating-mode
characterization correctly. PROFILE=balanced is now the documented run mode.
Validates the "Option C" hardware path: keep the old 8x16 Gerber's series-fed
edge-fed topology, just thicken the patch substrate from 0.102 mm to 0.508 mm
RO4350B. Single-element edge-fed with inset notch matched to 50 Ω microstrip.
Verified at PROFILE=balanced (λ/25 mesh):
W = 7.854 mm (preserved from old Gerber → array compatible)
L = 6.95 mm (tuned for f_res = 10.5 GHz on 0.508 mm sub)
inset_depth = 3.40 mm (~49 % of L)
inset_gap = 0.30 mm (each side of feed line, in the inset notch)
feed_W = 1.16 mm (50 Ω microstrip on 0.508 mm RO4350B)
feed_lead = 15.5 mm (= 1·λ_g at 10.5 GHz → port sees true antenna Z)
Result:
f_res = 10.509 GHz, S11 @ 10.5 = -18.5 dB, VSWR = 1.27
Z @ 10.5 = 61.8 + j3.2 Ω
-10 dB BW = 180 MHz (10.41-10.59 GHz, 1.71 %)
This is identical BW to probe_fed_v3 — confirming BW is set by substrate
thickness alone, not feed method. Edge-fed Option C is therefore the simpler
2-layer hardware path: same series-fed-row architecture as the old Gerber,
single PCB stackup, no probe vias / antipads / back-board splitter complexity.
Next step: extend to a 1x8 series-fed row to verify the daisy-chain topology
still gives in-phase feeding at the new substrate's λ_g.
Single-port-driven, 15-port-terminated FDTD sim built on the same v3 patch
design point (W=7.854, L=6.56, FEED_OFFSET=2.14) at the Gerber pitch
(14.27 mm X / 15.01 mm Y). Reads out S_jd for all elements when port
(DRIVEN_X, DRIVEN_Y) is excited. Configurable array size + driven port via
env vars; default = 4x4, drive inner element (1,1).
Result at PROFILE=balanced, drive (1,1):
Active S11 @ 10.5 GHz : -16.7 dB, Z = 45.7 + j13.5 Ω
Active -10 dB BW : 190 MHz (10.44-10.63 GHz; ≈ single-element 180)
Nearest-neighbour coupling:
-x edge neighbour (0,1): -18.3 dB (strongest — edge element loads less)
-y/+y in-array : -22 dB
+x interior neighbour : -24.7 dB
Diagonal : -32 dB
Far corners : -45 to -53 dB
Outputs: coupling_grid.png heatmap + S_matrix.csv (all S_jd full sweep) +
S11_data.csv (driven-port only).
Known limitation: port box must align with mesh lines; SmoothMeshLines may
sub-cell-shift seed lines, causing some DRIVEN_X/DRIVEN_Y choices to give
"Unused primitive" warning + zero excitation. Default (1,1) is verified;
other choices are best-effort. Documented inline.
Single-element OpenEMS sim for a 2-layer probe-fed patch on 0.508 mm RO4350B.
Verified at PROFILE=balanced (λ/25 mesh): f_res = 10.51 GHz, S11 = -21.8 dB,
VSWR 1.18, -10 dB BW = 180 MHz (10.40-10.58 GHz). Direct 50 Ω match — no port
matching cap needed.
Design point baked into defaults:
PATCH_W = 7.854 mm (preserved from old 8x16 Gerber → array compatible)
PATCH_L = 6.56 mm (tuned for f_res = 10.5 GHz at 0.508 mm sub)
FEED_OFFSET = 2.14 mm (probe via, from -y radiating edge)
Why probe-fed: aperture-coupled v2 (4-layer Stack_Hybrid) capped at ~60 MHz BW
because the 0.11 mm L4 acts as a near-short reflector — beneficial for slot
coupling but creates an L2-L4 cavity that's the BW ceiling. Tested removing L4
(open-back aperture-coupled): coupling collapsed, R stayed >1000 Ω regardless
of patch tuning. Probe-fed has no slot bottleneck; physics BW = 1.7% on h=0.508
matches sim 180 MHz directly.
Hardware change required to deploy: 2-layer stackup (patch on top, ground on
bottom, probe vias with antipads). Old 8x16 Gerber was edge-fed; v3 is probe-
fed → top-layer feed network goes away, ADAR1000 carrier on a separate board
with SMP RF launches. Stackup signoff with antenna designer needed before PCB.
aperture_coupled_v2 retained as the 4-layer fallback (with the 0.043 pF cap)
if 2-layer redesign isn't approved.
10-iteration analytic-tune sweep (no DE optimizer — that was a wrong
direction for this topology) on the Stack_Hybrid 4-layer stackup. Key
findings from the sweep are baked into the script defaults and header.
Best design point @ 10.5 GHz (now the env-var defaults):
patch W=9.55 mm L=7.77 mm
slot L=3.00 mm W=0.50 mm (centered under patch)
stub L=4.16 mm (= λ_g/4 in feed sub at f0)
feed lead=12.34 mm W=0.25 mm
total feed length = 1·λ_g at 10.5 GHz, line transparent at f0
Result: Z ≈ R + j350 Ω at 10.5 GHz, R = 33–51 across reruns (sanity-profile
convergence drift; X is stable). R is within matching range; the +j350
inductive residual is fundamental to the topology (L4 backshort under the
antenna footprint), not a tuning artifact. Two production-grade fixes:
(a) Series cap at port C ≈ 0.043 pF — drops S11 to ≈ -40 dB
(b) Open L4 backshort under antenna — restores standard open-back
aperture-coupled, stub naturally tunes X
Three real bugs fixed in the underlying sim (without these, the baseline
script was measuring artifacts, not the antenna):
1. Z mesh under-density. Default SmoothMeshLines at λ/18 gave the 0.11 mm
feed substrate ~0.1 cells vertically — microstrip Z0 was a pure mesh
artifact. Now built explicitly with ≥5 substrate-interior lines per
dielectric (bypassing SmoothMeshLines collapse for z-axis only). Fine
substrate cells visible via MESH_DEBUG=1.
2. SLOT_Y_OFF_MM env var was read but never applied to the L2 slot box,
silently making the parameter inert. Slot is now correctly offset in y.
3. FEED_LEAD_L was hardcoded at 14.0 mm, making total feed length 18.16 mm
= exactly 1·λ_g at 9.5 GHz (in feed substrate). This created a parasitic
feed-line full-wave standing wave in-band that masked the patch as a
persistent "9.4 GHz resonance" regardless of patch dimensions. Now
parameterized via FEED_LEAD_L_MM with default 12.34 mm so total feed =
1·λ_g at 10.5 GHz instead — line is transparent at the operating freq
and sim measures the actual antenna impedance at the port.
Sweep grids updated to span ±1 step around the iter #6 design point.
Re-simulation infrastructure for the new 4-layer aperture-coupled antenna
stackup (Stack_Hybrid.png, committed 1de2296). Renders the full multilayer
geometry (L1 patch / L2 slot ground / L3 microstrip feed / L4 backplane)
on the actual substrate stack (RO4350B 0.508 mm + RO4450F 1.2 mm + RO4350B
0.11 mm) and runs FDTD via openEMS to characterize S11 vs frequency.
Geometry interpolated from existing 2-layer Gerber:
patch W from Gerber (7.854 mm, set by εr only)
patch L re-tunable for new substrate (env var PATCH_L_MM, default 7.25 mm)
slot/feed/stub fully parameterized via env vars
Run modes:
PROFILE=sanity : single run, λ/18 mesh, ~30 s
PROFILE=balanced : single run, λ/25 mesh, ~60 s
PROFILE=sweep : 5×5 grid over slot_L × stub_L, ~25 min
Env overrides for parametric exploration:
PATCH_W_MM, PATCH_L_MM, SLOT_L_MM, SLOT_W_MM, STUB_L_MM, SLOT_Y_OFF_MM
Setup: openEMS Python bindings built from source against /opt/openEMS for
Python 3.12 in radar_venv; run with
DYLD_LIBRARY_PATH=~/opt/openEMS/lib ~/radar_venv/bin/python
under cwd != openEMS-Project/openEMS/python (avoids CSXCAD shadow import).
Status: simulation infrastructure verified end-to-end; patch resonates at
10.4 GHz with W=9.0 / L=5.5–6.0 mm. Full 50 Ω impedance match not yet
converged — the L4 backplane (non-standard for aperture-coupled) reduces
slot coupling vs textbook formulas; needs proper EM optimizer (scipy
wrapping or CST/HFSS handoff) to fully tune. ~150 MHz baseline BW
predicted from substrate physics; 30/40 MHz chirp target comfortably
under any plausible match outcome.
Jason