The Problem

The repository contains ~87 source files (firmware, Python GUI, simulations) with no CI/CD pipeline and no test suite. Any change can introduce a regression that goes undetected, and the deep nesting, duplicated blocks, and large monolithic files make safe modification difficult.

What This Does

PLFM_RADAR is an open‑source 10.5 GHz phased‑array radar (AERIS‑10) available in two range versions.

  • Hardware (files under 4_Schematics and Boards Layout/, 9_Firmware/9_1_Microcontroller/) implements a complete front‑end: AD9523 clock generator, ADF4382 synthesizers, ADAR1000 phase shifters, ADTR1107 LNA/PA chips, and a Xilinx XC7A100T FPGA that performs pulse compression, Doppler FFT, MTI and CFAR processing.
  • Firmware (9_Firmware/9_1_Microcontroller/9_1_3_C_Cpp_Code/main.cpp) drives power‑up sequencing, FPGA communication, and GPS/IMU handling.
  • Python GUI (9_Firmware/9_3_GUI/GUI_V*.py) provides a user‑friendly interface: GUI_V4.py (56 functions, 10 classes) is the most‑connected entry point, calling list_devices, generate_map, polar_to_geographic and reading/writing files.
  • Simulation & utilities (5_Simulations/, 8_Utils/Python/) expose functions such as array_factor, element_factor, generate_radar_csv, and RADAR_eq.py’s main (reaches 3 functions).

How It Is Wired

Execution starts at two entry points:

Entry pointFileReaches
main8_Utils/Python/RADAR_eq.py:3033 function(s) (create_input_fields, create_calculate_button, create_results_display)
main9_Firmware/9_1_Microcontroller/9_1_3_C_Cpp_Code/main.cppfirmware initialization

The internal call graph (119 resolved edges) shows key hubs:

  • GPSData – called from 4 places
  • RadarTarget – called from 3 places
  • list_devices – called from 10 places (e.g., refresh_devices, start_radar)
  • RadarSettings – called from 8 places (__init__ of GUIs)

Representative edges: calculate_parameters → get_float_value (11 calls), refresh_devices → list_devices (10 calls), start_radar → open_device (10 calls).

The GUI files are the primary conduits: GUI_V4.py calls into 1 other file, reads/writes the filesystem, and defines the map‑display pipeline (generate_map, polar_to_geographic).

How To Use It

  • Clone the repository verbatim:
  git clone https://github.com/moses-y/PLFM_RADAR
  cd PLFM_RADAR
  • Python GUI: run the high‑level entry point
  python 8_Utils/Python/RADAR_eq.py

(The file defines main at line 303; no requirements.txt is present, so you may need to install common scientific Python packages (numpy, matplotlib, scipy) yourself.)

  • Firmware: the STM32 project lives under 9_Firmware/9_1_Microcontroller/9_1_3_C_Cpp_Code/. No build script is documented; you will need a toolchain (e.g., STM32CubeIDE, PlatformIO) and an appropriate debugger/programmer for the board.
  • Simulations: many .py files under 5_Simulations/ can be executed directly with Python; they import from numpy, matplotlib, and openems (external).

Real‑World Use

A drone‑software team wants to test beam‑steering algorithms. They launch python 8_Utils/Python/RADAR_eq.py, adjust the “frequency ramp” and “pulse length” sliders, and the GUI calls generate_multi_ramp_csv (not listed in the top‑level graph but present in the utils) to produce CSV data. The resulting CSV is fed into the FPGA‑embedded pulse‑compression pipeline, and the team visualises target tracks on the integrated map (generate_map in GUI_V4.py).

Code Health & Issues

Measured static‑analysis findings (75 total)

  • 24 high‑severity: deep nesting (x39, e.g., 9_Firmware/9_1_Microcontroller/9_1_1_C_Cpp_Libraries/BMP180.cpp, iio.c), duplicated 6‑line blocks (1498 repeats across 130 files), oversized files (1437 lines in adf4382.c, iio.c, main.cpp).
  • 51 medium‑severity: file opened without context manager (3 GUI files), broad exception handling (6 files), high branching density (5 files, 29 branches over 81 lines).

Code‑health audit (4 findings)

  • [HIGH] Add a test suite – evidence: 87 source files, no test files; any change ships with no signal that existing behaviour still holds.
  • [HIGH] Add a workflow that builds and tests this repository – evidence: 87 source files, no CI configuration; every merge runs untested.
  • [MEDIUM] Move large binaries to Git LFS or out of the repository – evidence: 5_Simulations/IF_BPF_Balanced/IF_BPF_Balanced.dat (19.1 MB) plus other >5 MB blobs; every clone pays for data nobody diffs.
  • [LOW] Add the repository convention files this project lacks – evidence: missing .editorconfig, .gitattributes, formatter config; inconsistent editor settings across contributors.

The Bottom Line

The repo delivers a functional, open‑source 10.5 GHz phased‑array radar with a capable Python GUI and solid firmware, but the absence of CI, tests, and large‑file management creates risk for any sustained development. It is well‑suited for hobbyists, researchers, or rapid prototyping where occasional manual verification is acceptable. Teams planning long‑term maintenance should budget time to add a test suite, CI workflow, and Git LFS for the simulation data dumps.