25,759 Stars, a $3,991 Bare-Board Quote and a '20 km' Figure That Is Really a Timing Limit: Auditing the Open-Source AERIS-10 Radar

A GitHub repository called PLFM_RADAR currently has 25,759 stars, 5,886 forks and a one-paragraph pitch that would be remarkable even if half of it were true: an open-source, low-cost 10.5 GHz phased array pulse-LFM radar, published with schematics, Gerbers, BOMs, FPGA Verilog and a Python GUI. Two versions — a 3 km “Nexus” and a 20 km “Extended”. The press picked it up in April with the headline “Open-source DIY radar that’s 95% cheaper than $250k commercial offerings”.

That framing is where the trouble starts, because the repository itself is a very different document from the marketing. It is also, on balance, a more interesting one: a 225 MB open-hardware project where you can watch a solo engineer, an AI-assisted contributor pipeline and a group of strangers on the issue tracker try to converge on a buildable X-band radar at the same time.

This audit is based on the repository at commit 749bd0f8 (17 June 2026), its engineering docs site, four BOM/CPL spreadsheets parsed cell by cell, its own co-simulation parameters, its own antenna-pattern code re-run locally, 12 issues and their comment threads, and the maintainer’s Hackaday page and company site. Where I make a calculation, I show the inputs, because the point of this piece is that the missing inputs are the story.

What is actually in the repository

GitHub labels the repository’s primary language as PLSQL. There are zero .sql files in the tree. That is not a scandal — it is GitHub’s linguist guessing from file extensions it does not recognise — but it is a fair summary of how well the packaging matches the contents.

Two things in that table matter more than the rest. First, 35% of a 225 MB repository is redistributed vendor PDFs: Analog Devices, Qorvo and Murata datasheets, some of them 10 MB scans, checked into an open-hardware project whose licence covers design documentation. Second, the committed FPGA bitstreams are for the wrong module. They are named te0713-te0701-heartbeat-2026-03-21.bit and te0713-te0701-umft601x-dev-2026-03-21.bit — Trenz TE0713 carrier boards, which carry an XC7A200T. The repository’s own README says the production board has an XC7A50T.

Finding 1: the board does not know which FPGA it has

This is not a small ambiguity, and it is unresolved in public.

• The README lists “XC7A50T FPGA — Handles RADAR Signal Processing on the upstream FTG256 board”.
• The BOM inside the CAD/production set lists XC7A50T-2FTG256I at reference U42.
• The engineering docs site states, twice, “the current production target remains xc7a200t-2fbg484i” and “Build 25 is the current production baseline for the XC7A200T target”.
• The constraints README resolves nothing: it documents four targets — “50T production board”, “200T premium dev board”, two Trenz developer modules — and admits in the header of the 50T file that “The README and prior version of this file incorrectly referenced XC7A100TCSG324-1”. That is three different device families named in one repository’s own documentation.

The two packages cannot be confused physically. An FTG256 is 17 × 17 mm with 256 balls; an FBG484 is 22 × 22 mm with 484 balls. In issue #186 a third-party reviewer did the arithmetic from the Eagle files: the footprint on the board is 256 balls at 1 mm pitch, so the board is a 50T board “and there is no 200T version of this layout. The xc7a200t_fbg484.xdc file must belong to something else”. The reporter then ran the 200T target for completeness and found “its constraints file has unassigned pins, which fits your conclusion that no 200T board has ever existed.”

The maintainer has not answered. Issue #186 asked, on 22 August, “Which FPGA is the production part — 50T or 200T?” Five weeks later the question is still open, and the maintainer’s only activity in that period is a 21 September post titled “I’m back”, apologising for the silence.

Why does it matter? Because it decides whether you can build the thing at all, and the answer is currently no — see next.

Finding 2: the documented firmware does not fit the board it is documented for

The project’s own engineering report for its current production baseline, Build 25, lists utilisation as 9,252 LUTs, 12,488 flip-flops, 17 BRAM tiles and 142 DSP48E1 slices at 19.19% — of an XC7A200T. An XC7A50T has 120 DSP48 slices and 150 RAMB18 tiles in total.

A prospective builder checked independently, in issue #186, by assembling “the latest state of the code (the feat/dual-range-v2 line plus the unmerged fixes from develop and integration/fft-2048-on-p0)” and running the repository’s own scripts/50t/build_50t.tcl in Vivado 2025.2:

DRC fails before placement: 129 DSP48 required vs 120 available, and 188 RAMB18-equivalents vs 150. That was the 3 km configuration with the long-range switch off. So a board fabbed today runs the older 3 km firmware, but not the current three-waveform architecture.

Their follow-up found the practical fix: the XC7A100T-2FTG256I is the same 256-ball footprint and fits with timing met (DSP 54%, block RAM 77%, LUTs 38%). Which is genuinely useful information — arrived at by a stranger, published in the issue tracker, five weeks unanswered by the maintainer, and nowhere in the README.

There is a second, quieter capacity problem. radar_system_top_50t.v opens with this comment:

The XC7A50T-FTG256 has only 69 usable IO pins, but radar_system_top declares many port bits (including FT601 USB 3.0, debug outputs, and status signals that have no physical connections on the 50T board).

The constraints README confirms the consequence: USB 3.0 via FT601 is USB_MODE 0, “200T premium dev board”; the 50T production board defaults to USB_MODE 1, an FT2232H over USB 2.0, 8-bit at 60 MHz. So the “production” configuration ships data over a 1990s-era parallel FIFO bridge, and the USB 3.0 path is exercised on a developer module that the repo also cannot confirm exists.

Finding 3: the published BOM is a fab conversation, not a controlled release

The README’s Getting Started section tells a builder to “Source Components: BOM/CPL files are co-located under /4_Schematics and Boards Layout/4_7_Production Files”. Here is what is in the main-board BOM spreadsheet, exhaustively:

• 103 lines, 93 distinct part numbers.
• 29 remark cells left in the file — these are messages from the assembly house to the maintainer.
• 9 lines marked [DNP不要贴] — do not populate, in Chinese, in the file you are told to order from.
• 14 lines carrying Chinese annotations, including [Supplied by customer客供] on the SMA connectors, the four ADAR1000 phase shifters and all sixteen ADTR1107 front-ends (consigned parts).
• 7 value or package corrections the fab flagged, each ending “Please confirm”: MLASU063SCG101JFNA01 listed as “103pF” but “indeed 100pF”; GRM0335C1H111GA01D listed as “106pF” but “indeed 110pF”; MLG0603PR11JTD25 listed as “107.3nH” but “indeed 110nH”; GJM0335C1E330JB01D as “32.8pF” but “indeed 33pF”; a resistor as “5Ω” but “indeed 5.1Ω”; a crystal whose package is “SMD2520-4P, not CRYSTAL-12MHZ…SMD-2X2.5MM”.
• 3 unconfirmed substitutions: “The part we will supply is GRM033R61A472KA01D OK?” and two more.
• 2 lines reading “The part we can get here was made in the year of 2022+ OK?” — aged stock, offered as a choice.
• 1 line reading “[Price is changing higher, final price should be subjected to the real price when order!]”
• 1 line reading “information on chip will be removed” — the assembly house offering to grind the markings off the XC7A50T. In an open-hardware project, that is a remarkable thing to have preserved verbatim in the shipped file.
• And two literal MPN values of Do Not Put and Not a component.

Note the pattern in those value corrections: 103 pF, 106 pF, 107.3 nH. Those are EIA three-digit codes (103 = 10 nF, 106 = 10 µF, 110 = 11 × 10¹) misread as direct values. The BOM’s value column has been partly derived by mis-parsing part numbers, which is exactly the failure mode a reviewer described in the same issue:

on the main board only 27 BOM lines have a part number inside the CAD, mostly the ICs. All the passive part numbers exist only in the spreadsheets.

And the spreadsheets disagree with each other. I counted five production-file sets; the PA board ships BOM.xlsx and BOM_PA.xlsx (one without part numbers), the power board ships three BOM-ish files, and the frequency-synthesis board two. A reviewer’s summary: “there are several BOM style files per board and they do not agree with each other. In the end I generated my own BOM and placement file straight from the .brd, because the board file is the only one that cannot be out of date with itself.”

That is the correct instinct, and it is the single most actionable sentence in the issue tracker.

Finally, the schematic and production directories in the repository were deleted and re-uploaded through the GitHub web UI during May and June 2026 — commits titled “Add files via upload” alternating with “Delete 4_Schematics and Boards Layout/4_6_Schematics/MainBoard directory” and “Delete …/Gerber_Main_Board directory”. That is why the last commit to a hardware repository reads “Add files via upload” and why nobody, including the maintainer, can currently state which Gerber set matches which schematic. A previous incident, referenced in issue #186, is instructive: a released package “can sit there looking current while actually being stale files from another project”.

Finding 4: the only published price covers bare PCBs — $3,991 of them

The project never publishes a build cost. The only figure anywhere in the public record is the maintainer’s own answer, in issue #150, to a builder asking what the boards cost (MOQ 2 per PCB, PCB fabrication only, no components):

Excluded from that number: every component, PCBA and pick-and-place, the 32 × 16 dielectric-filled slotted waveguide array (machined alumina — the repo ships its OpenEMS model and slot-tap data, not a quote), the slip ring, stepper motor, 16 PA housings, cooling, enclosure, and the XC7A50T on a $1,000-class board. The MOQ of 2 means a first order is about $7,982 before a single component.

The 3 km “N” configuration is $1,303 of bare boards (main + power + synthesis; no PA boards). Set against the “90-95% below commercial alternatives” line the maintainer uses on his Hackaday project page — where the comparator is “more than $250,000” — the honest headline is: you can start ordering X-band hardware for four figures, and the repository gives you no way to know the final number.

Finding 5: “20 km” is the unambiguous-range ceiling, not a detection range

This is the calculation I most wanted to do, and the repository makes it possible because its co-simulation scene generator publishes the waveform:

F_CARRIER      = 10.5e9    CHIRP_BW = 20e6     # 30 MHz -> 10 MHz at IF
FS_ADC         = 400e6     ADC_BITS = 8
T_LONG_CHIRP   = 30e-6     T_LISTEN = 137e-6
CHIRPS_PER_FRAME = 32
MAX_UNAMBIGUOUS_RANGE = C_LIGHT * T_LISTEN / 2   # ~20.55 km

That last line is the whole story. c × 137 µs ÷ 2 = 20.54 km — the same number as the README’s “20 km” spec for the Extended variant. The headline range of the flagship product is the unambiguous range of the listen window, a timing property of the waveform, not a statement about what the radar can see. It is a hard ceiling: no amount of transmit power moves it.

What the radar can actually see is a link-budget question, and the repository never answers it — there is no link budget document anywhere (a code-wide search for “link budget” returns zero files). So I built one from its own parameters, stating every assumption:

Solving for the range that yields a 13 dB post-processing SNR:

Read that table carefully, because it is genuinely informative and it is not a debunking. The two advertised numbers are internally consistent — but with two different target classes. The N’s 3 km matches a 0.01 m² drone; the X’s 20 km matches a 1 m² target, and it happens to coincide with the waveform’s ceiling. For the drone use case the README names first (“designed for researchers, drone developers”), the X configuration’s realistic detection range is around 8-11 km, not 20 km. Nothing in the repository, the docs site or the marketing states the RCS, probability of detection or false-alarm rate that would let a reader tell which number applies to them.

Two more consequences of the same waveform, both checkable: range resolution is 7.5 m (c/2B with B = 20 MHz) — fine for airspace surveillance, coarse for classifying small targets; and the converters are 8-bit throughout, an AD9708 8-bit DAC generating the chirps and an AD9484 8-bit 500 MSPS ADC digitising them. An 8-bit ADC has an ideal SNR of about 50 dB. That is a defensible low-cost choice, and it is also why the link budget above is dominated by processing gain rather than by receiver headroom.

Finding 6: the steering claim, and what the repo’s own array code says

The README promises “Full Electronic Beam Steering — ±45° electronic steering in elevation and azimuth”. The maintainer’s own Hackaday project page (39.6k views, 326 followers) says something different about the prototype:

The prototype uses the 16 antenna elements to steer the Elevation beam and the Azimuth is performed using a stepper motor; but the designed system can be hacked to control both Elevation and Azimuth electronically.

That is a meaningful gap between “electronic in both axes” and “electronic in elevation, mechanical in azimuth”, and it is not reconciled anywhere else.

Separately, the array geometry in the repository has a physical boundary condition worth knowing before ordering a 32 × 16 waveguide array. In 5_Simulations/array_pattern_Kaiser25dB_like.py, the element spacing is:

M, N = 16, 32
dy = 14.275831333333334e-3   # 0.5000 lambda at 10.5 GHz
dz = 16.915e-3               # 0.5924 lambda at 10.5 GHz

dz is λg/2 for an alumina-filled guide (εr = 9.8 → λg = 33.83 mm), which is correct for in-phase slot excitation — and it is 0.592 free-space wavelengths. I re-ran the file’s own array-factor code with those numbers:

• Grating lobes enter visible space in the 32-slot axis at a scan of ±43.5°. At a scan of 45°, the highest non-main lobe is at −9.7 dB; at 60° it is at 0.0 dB, i.e. as strong as the main beam.
• The two axes are weighted very differently: the 32-element axis is a Kaiser β = 1.65 taper (peak sidelobe −21.8 dB), the 16-element axis is uniform (np.ones(16), peak sidelobe −13.3 dB). The file is named Kaiser25dB_like; the realised, best-case peak sidelobe across both planes is −13.3 dB.
• The slot table and the code agree exactly (the CSV weights equal np.kaiser(32, 1.65) to 0.0 difference). But every slot has the same length (15.9 mm) and width (0.571 mm), while the coupling control — the slot offset — varies only from 1.8 mm to 2.1 mm, a 1.17× range, against an intended amplitude taper of 1.81×.

And the script itself only evaluates theta0_deg = 0.0 — broadside. The repository’s own beam-steering verification is an open request: issue #147, titled “Antenna Simulation”, asks an outsider to re-check “3D radiation pattern… then we need to integrate the entire array (16 waveguides) to check the beam steering capabilities”, with the maintainer publishing OpenEMS runs in August and offering the code.

So: the ±45° claim is bounded by grating-lobe physics at 43.5° in one plane, unverified off-broadside in the repo, and contradicted for the prototype on the maintainer’s own project page.

Finding 7: the licence does not say what the README says it says

The README’s licence section is unusually careful for this genre — hardware under CERN-OHL-P, software under MIT — and it ends with:

The complete CERN-OHL-P license text is in the LICENSE file.

The file is named Licence (British spelling, no extension). LICENSE returns 404. The practical consequence is visible on the repository’s own page: GitHub reports the licence as NOASSERTION, because its detector cannot match the file. And because the README’s top badge advertises “License: MIT” while there is no MIT text anywhere in the repository, the honest description is: the CERN-OHL-P text is present, the MIT grant the README promises for all FPGA, firmware and GUI code is not. A downstream user who wants to reuse the firmware commercially has the README’s word for it and nothing else.

Two related points a builder should price in:

• Third-party material is not covered. 50 vendor datasheet PDFs (35% of the repository by size) are redistributed under no licence at all. CERN-OHL-P’s “Documentation” definition covers design documentation, not Analog Devices’ or Qorvo’s application notes.
• One required component is export-restricted. The 20 km variant’s PA board is built around the Qorvo QPA2962 GaN amplifier; the maintainer’s own words in issue #175: “The QPA2962 is very difficult to buy since it is tagged as exportation restricted. I’m planning to use the QPA1010 on the new design, but I need to go through all the technical documentation.” As of today the published PA design is still the one with that part, and the replacement is an intention, not a file. If you are outside the relevant jurisdiction, the flagship 20 km variant is not buildable from the published design — and that is a supply-chain fact, not a criticism of the project.

There is also no regulatory content at all: nothing about spectrum authorisation, duty cycle, power limits or EMC for a 160 W 10.5 GHz transmitter. The Hackaday page says “Regulatory certification (FCC/CE) in progress”; the repository says nothing. For a system advertised to drone developers — the use case is literally target-tracking radar — the absence of any guidance on where you may legally radiate is the gap I would fix first.

Finding 8: the information layer around the project is worse than the project

Three artefacts surround this repository, and all three are more confident than the files they describe.

An AI-generated “deep dive” with a 90/100 score. On 6 May 2026 the README gained a badge: Starlog — Deep Dive, linking to starlog.is/articles/data-knowledge/nawfalmotii79-plfm-radar. Starlog describes itself as “offsec tools & AI agents. Decoded”, claims 14,037,760 stars tracked and 1,842 articles, and publishes machine-generated, scored reviews of repositories — this one rated 90/100, dated 7 May 2026, and it says the project is “★ 19.5k”. Its technical section names an AD9172 DAC (not in the BOM; the board carries an AD9708AR), AD9208 ADCs (the board carries AD9484BCPZ-500), sampling “up to 250 MSPS” (the ADC runs 400 MSPS, decimated by 4), “USB 3.0” (the production default is FT2232H on USB 2.0), a “3-pulse canceller” (the repo’s MTI is a 2-pulse canceller, H(z) = 1 − z⁻¹) and a “PyQt5” GUI (the repo ships a Tk GUI and a PyQt6 rewrite). A scoring system that rates this 90/100 is scoring the prose, not the file tree. The badge was later removed from the README — but the page remains the top search result for the project’s name, and it is the version of AERIS-10 that most people will read.

A frozen thank-you note. The README still contains a section titled “19,000 stars – Thank you”, explaining that “Today, 19,000 engineers on GitHub have starred it.” The repository has 25,759. The section dates from the same week as the Starlog badge; it is a six-month-old snapshot presented in the present tense.

A defence-electronics product line. The README’s contact section signs off with “Nawfal Motii, ABAC INDUSTRY” and a company URL. ABAC INDUSTRY describes itself as developing “advanced radar systems, RF warfare solutions, secure communications and embedded technologies designed for modern defense and aerospace operations”, from an address in Casablanca, and sells a product line that overlaps the open project by name: AERIS 10N (up to 3 km), AERIS 10X (up to 20 km), AERIS 10X CUSTOM (“up to 50 km… True AESA architecture with X-Band operation (10.5 GHz), full electronic beam steering ±45° azimuth and elevation”), plus OCULUS F-AESA, RF jamming systems, SIGINT spectrum analyzers and jamming-equipped drones, with an FAQ entry comparing itself to China’s AESA radars. One product table row reads “China AESA — 20+ KM”.

None of that is illegal or unusual: open hardware plus a commercial integrator is a legitimate business model, and CERN-OHL-P explicitly permits selling Products. But set the site’s “FIELD PROVEN / DEPLOYED INNOVATION” and “we deliver a fully characterized system” next to the open repository, whose own documentation site reports its current phase as “Pre-Hardware Readiness”, whose bring-up guide warns that “board-specific integration unknowns… remain partially unproven until first assembly”, and whose issue tracker cannot establish whether a single board has ever been powered on. In August, asked “How far did manufacturing actually get?”, the best-informed non-maintainer reply was: “Sorry, no idea. I would also like to know.”

The maintainer’s crowdfunding plan, on the same Hackaday page, was “a Q3 2026 campaign launch, with first deliveries in late 2026”, with “House order: Crowd Supply will likely match backer orders with their own purchase, doubling production scale” and “Mouser distribution post-campaign”. Q3 2026 ended this week. There is no campaign. The last commit to the repository was 17 June.

What the project gets right

I want to be precise here, because a lot of this audit reads as hostile and that is not the correct conclusion.

• Publishing complete hardware design files at all is rare. Schematics, Gerbers, pick-and-place, BOMs, constraints, testbenches: for a 10-layer X-band phased array, this is more than almost anyone else publishes. The RF simulation work is real and scripted — wg_alumina_slotted_openems.m is a genuine OpenEMS FDTD model with an alumina fill (εr 9.8, tanδ 1e-4), a TE10 cutoff assertion and a Kaiser-fed slot offset derivation. That is an engineer’s file, not a marketing asset.
• The verification culture is real. 348 commits, 23/23 FPGA regression suites, 20/20 MCU host tests, 3/3 real-data co-simulations with 5,137 bit-exact data checks, a documented timing baseline (WNS +0.132 ns, DRC 0 errors) and a build-over-build comparison table. Static analysis is enforced with 17 ruff rule sets chosen with pointed comments about LLM-generated code (“stray print() calls — LLMs leave debug prints”, “commented-out code — LLMs leave ‘alternatives’ as comments”).
• The AI policy is the best I have seen in this genre. Asked directly in issue #106 whether AI contributions were permitted, a maintainer answered with four rules: human accountability for every commit, mandatory review, full CI before commit, and no raw AI output committed unread. Whether or not it is followed perfectly, it is the right policy and it is written down.
• The safety architecture is thoughtful. A hybrid AGC across FPGA/STM32/GUI, closed-loop per-channel bias calibration against measured Idq (16 INA241A current-sense amps, 16 DAC5578 Vg controls), 8 thermistors with a fan control GPIO, an IWDG watchdog, an emergency PA rail cutoff, and an explicit rule that RF transmit paths stay disabled during first power-on. Someone thought about what happens when 160 W of GaN misbehaves.
• The maintainer is candid in public. “I just took a break and kind of stepped back from the project in order to rest up.” “I’m trying to do the things the right way and it takes time.” That is more honesty than most projects offer, and it is why I trust the parts of the documentation that say “pre-hardware”.

If you are thinking about building one

Based on everything above, this is the order of operations I would use.

1. Do not order the 20 km stack. Its PA design depends on an export-restricted amplifier and its replacement is unannounced. Start with the 3 km “N” configuration: main, power and frequency-synthesis boards, $1,303 of bare PCBs at MOQ 2.
2. Decide the FPGA question first, and plan for the XC7A100T-2FTG256I — the community-verified drop-in that fits the current firmware in the same 256-ball footprint. Ask the maintainer in the issue tracker, but assume the answer will not arrive.
3. Generate your own BOM from the .brd and re-derive every passive value from the part number rather than the value column. Treat the spreadsheets as correspondence, not data. Budget for substitutions; the fab has already proposed three.
4. Verify the Gerbers against the schematic by CAM re-export before paying, because the file set was assembled by deletion-and-reupload commits and nobody has confirmed which set matches which schematic.
5. Expect the converters to be the limiting factor (8-bit DAC and ADC) and plan your processing gain budget explicitly: 42.8 dB is available from a 30 µs, 20 MHz chirp with 32-pulse integration, and you need most of it.
6. Assume a 7.5 m range cell and a ~20.5 km unambiguous range ceiling; size your target expectations by RCS, not by the headline.

And if your requirement is a working radar this quarter rather than an education in X-band hardware: this repository is not that, and — given that its own documentation says pre-hardware readiness — it does not claim to be.

FAQ

Is AERIS-10 a real project or a fake one? It is real and unusually open: schematics, Gerbers, BOMs, constraints, testbenches and simulated RF results, with a 348-commit history and a documented verification baseline. The problems are not authenticity but completeness — the file set has not converged, and no measured performance data has been published.

Has anyone ever built and tested an AERIS-10? Nothing in the public record establishes it. The docs site’s current phase is “Pre-Hardware Readiness”; the bring-up guide speaks of what is “unproven until first assembly”; in May the maintainer said boards were days away; in July he said new designs would be uploaded “within 10 days”; in August builders asked what had actually been manufactured and received no answer from him. The one direct answer in the tracker, from the most experienced contributor: “My prototypes will take a few more weeks.”

Where does the 20 km figure come from? From the waveform: with a 137 µs listen window, c × 137 µs / 2 = 20.54 km, the maximum unambiguous range. It is a timing ceiling, and — for a 1 m² target with the full 42.8 dB of processing gain — it is also approximately reachable. For a 0.01 m² drone the same link budget gives roughly 9 km.

Why do third-party builders say the firmware does not fit? Because the documented production baseline (Build 25, 142 DSP48E1) and the board’s FPGA (XC7A50T, 120 DSP48) are from different configurations, one of which apparently never existed as hardware. The reported failure is 129 DSP48 required versus 120 available before placement, in the 3 km configuration.

Can I sell a product based on this design? CERN-OHL-P expressly permits manufacturing and selling, requiring only that notices be preserved and that modifications to the design be published under the same licence if you distribute the design files themselves. But the firmware’s promised MIT licence text is absent from the repository, so get the MIT grant in writing before you depend on it.

What should I read before anything else? Issue #186. It is four questions from a prospective builder, answered in detail by two other engineers and never by the maintainer, and it contains more engineering truth about this project than the README, the docs site and the press coverage combined.

The close

AERIS-10 is a solo engineer’s attempt to publish an X-band phased array, and the fact that 25,759 people starred it is a statement about how badly the world wants that to exist — not evidence that it works. The repository’s own documents are the honest version: an FPGA that may or may not be the 50T, firmware that does not fit it, a BOM that reads like a fab email thread, “Pre-Hardware Readiness” as the current phase, and range figures that turn out to be a timing limit and a target-class assumption that were never written down.

Set against that, the parts that are real are genuinely valuable: 894 files of design work, an OpenEMS model you can run, a verification discipline most open hardware never reaches, and 42.8 dB of processing gain available from a 30 µs chirp if you are willing to do the bookkeeping yourself. The 20 km on the tin is the ceiling of the waveform. Whether that is a disappointment depends entirely on what you expected to detect — which is precisely the number nobody has published.