Add police boat stuff. Now ready for lidar stuff
This commit is contained in:
@@ -1,127 +0,0 @@
|
||||
1. Radar Equation in Shaders
|
||||
|
||||
Good idea overall, but the phrase "keep a copy of the data in the shaders" needs clarification. Shaders are stateless
|
||||
per-invocation — they don't store data between frames. What you actually want is:
|
||||
|
||||
- A CPU-side target array (mirroring the DB subset of known targets) that gets uploaded to the GPU each frame via a
|
||||
Shader Storage Buffer Object (SSBO) or uniform array.
|
||||
- The shader reads per-target RCS + range, computes P_r from the radar equation, and maps it to brightness/amplitude.
|
||||
|
||||
Blooming cannot be done in a single render pass. It requires a post-processing pass — render targets to an FBO at full
|
||||
brightness, then apply a Gaussian blur/threshold to bright spots and blend back. This is a separate shader pair and
|
||||
should be in the file layout.
|
||||
|
||||
The radar equation belongs naturally in the phosphor.frag shader or a dedicated radar_equation.glsl include file
|
||||
shared across scopes.
|
||||
|
||||
---
|
||||
2. PostgreSQL Database Schema — Issues to Address
|
||||
|
||||
24-bit field widths (width, length, height) don't map to standard SQL types. PostgreSQL has SMALLINT (16-bit), INTEGER
|
||||
(32-bit), and BIGINT (64-bit). You'll want INTEGER or SMALLINT. Define units explicitly — feet or meters — and
|
||||
document it in the schema, or you'll regret it later.
|
||||
|
||||
The "need update" enumeration is really just a boolean. Consider BOOLEAN need_update DEFAULT TRUE rather than an enum
|
||||
with two values. Simpler, and PostgreSQL handles it natively.
|
||||
|
||||
The schema is missing a few things worth adding now:
|
||||
- A timestamp for when the record was last seen (for staleness tracking)
|
||||
- A timestamp for when the record was last updated by an operator
|
||||
- Units annotation (feet vs meters) on dimensional fields
|
||||
|
||||
Missing from the schema: any position/track history. That's probably intentional for v1, but worth noting — the DB
|
||||
only stores identity and physical characteristics, not track data. Track data lives in TargetBuffer (Thread 2/4),
|
||||
which is correct for real-time use.
|
||||
|
||||
---
|
||||
3. Default Sizes for Unknown Targets
|
||||
|
||||
The proposal to default unknown AIS/ADS-B targets to a standard size with need_update = TRUE is practical and
|
||||
well-conceived. Two observations:
|
||||
|
||||
- For aircraft, "50 feet long, 10 feet wide" covers a narrow-body airliner but not small GA aircraft (Cessna 172 =
|
||||
~27ft long, ~36ft wingspan). A GA default would be more realistic for BLI traffic. Consider two aircraft defaults: GA
|
||||
and commercial.
|
||||
- For boats, fiberglass is a good default for pleasure craft. However, if targets are coming from AIS, they are
|
||||
legally required commercial/commercial-sized vessels, which are more likely steel. You may want separate defaults for
|
||||
AIS-sourced vs simulator-sourced marine targets.
|
||||
|
||||
---
|
||||
4. Command Line Database Panel
|
||||
|
||||
This is architecturally sound — separating the museum exhibit mode from the operator database management mode via a
|
||||
command line flag keeps the exhibit clean. A few things to think through:
|
||||
|
||||
- The DB panel will need a UI toolkit. GLFW is minimal — it gives you an OpenGL window and keyboard/mouse but no
|
||||
widgets. Consider using Dear ImGui for the DB panel; it's header-only, integrates directly with GLFW/OpenGL, and would
|
||||
give you form fields, dropdowns, and tables without a heavy dependency.
|
||||
- The additions file mentions DESIGN.md as a place to document settings alongside settings.h. That file doesn't exist
|
||||
in the current layout in CLAUDE.md — it should be added to the file list.
|
||||
|
||||
---
|
||||
5. Radar Parameters — Technical Notes
|
||||
|
||||
Marine (X Band, 9225 MHz, 30 kW): Parameters are solid for a coastal surveillance radar. Horizontal beam of 0.5° is
|
||||
tight and realistic for a 15-foot slotted waveguide antenna at that frequency. The 50-foot antenna height is important
|
||||
for the radar horizon calculation — with a 50-foot antenna and a target at sea level, the radar horizon is roughly 9
|
||||
miles, which fits your 6-mile max range well.
|
||||
|
||||
ATC (S Band, 3 GHz, 25 kW): Correct band for terminal area surveillance (ASR-type). The 1.4° horizontal beamwidth from
|
||||
a 20-foot antenna at S band is consistent. One note: real ASR radars (like ASR-9 at airports like BLI) typically run
|
||||
1.2–1.4 MW peak power, not 25 kW. 25 kW is closer to a gap-filler or small terminal radar. For a museum exhibit this
|
||||
is fine — just be aware if the radar equation simulation produces unexpectedly short realistic ranges at those power
|
||||
levels.
|
||||
|
||||
Chain Home (30 MHz, 500 kW, bistatic): Historically accurate. Your Gt formula (G = 30000 / (beamwidth_az ×
|
||||
beamwidth_el) ≈ 7.5 linear) is a standard approximation and appropriate here. The note about resonant scattering is
|
||||
correct and important: at 30 MHz (λ = 10 meters), aircraft with wingspans of 10–30 meters are in the Mie/resonant
|
||||
region, not the optical region. RCS can be 2–5× the physical cross section. This is why Chain Home could detect
|
||||
aircraft that would have been invisible to shorter-wavelength systems. This is a great museum talking point and should
|
||||
be in the explainer text. For settings.h, you'll want a CHAIN_HOME_RCS_RESONANCE_FACTOR constant.
|
||||
|
||||
PAR (X Band, ~3 cm, 100 kW, 5-meter antenna): At 10 GHz and 5 meters, beamwidth = λ/D ≈ 0.03/5 = 0.006 radians ≈
|
||||
0.34°. That's extremely tight — correct for a precision approach system. The 20° horizontal × 10° vertical scan
|
||||
coverage is accurate for PAR. The very high gain implied by the 5-meter aperture is what makes PAR work at short range
|
||||
with high resolution. The simulation of blooming at close range (< 2 miles) will be visually dramatic with 100 kW
|
||||
into a high-gain antenna.
|
||||
|
||||
---
|
||||
6. DESIGN.md Reference
|
||||
|
||||
The additions file mentions DESIGN.md in the last line. That file does not currently exist in the project layout in
|
||||
CLAUDE.md. When you're ready to integrate these additions, add DESIGN.md to the root-level file list.
|
||||
|
||||
---
|
||||
Summary of Things That Need Resolution Before Coding
|
||||
|
||||
┌────────────────────────────────────┬───────────────────────────────────────────────────────────┐
|
||||
│ Issue │ Action Needed │
|
||||
├────────────────────────────────────┼───────────────────────────────────────────────────────────┤
|
||||
│ "Copy in shaders" language │ Clarify as CPU-side SSBO/uniform array │
|
||||
├────────────────────────────────────┼───────────────────────────────────────────────────────────┤
|
||||
│ Bloom post-processing │ Add to shader file layout (separate FBO pass) │
|
||||
├────────────────────────────────────┼───────────────────────────────────────────────────────────┤
|
||||
│ 24-bit DB field types │ Replace with SQL-standard INTEGER/SMALLINT │
|
||||
├────────────────────────────────────┼───────────────────────────────────────────────────────────┤
|
||||
│ DB units (feet vs meters) │ Pick one, document it │
|
||||
├────────────────────────────────────┼───────────────────────────────────────────────────────────┤
|
||||
│ need_update as enum │ Simplify to BOOLEAN │
|
||||
├────────────────────────────────────┼───────────────────────────────────────────────────────────┤
|
||||
│ GA vs commercial aircraft defaults │ Decide on one or two aircraft defaults │
|
||||
├────────────────────────────────────┼───────────────────────────────────────────────────────────┤
|
||||
│ Dear ImGui for DB panel │ Evaluate vs rolling your own with GLFW │
|
||||
├────────────────────────────────────┼───────────────────────────────────────────────────────────┤
|
||||
│ DESIGN.md │ Add to file layout in CLAUDE.md │
|
||||
├────────────────────────────────────┼───────────────────────────────────────────────────────────┤
|
||||
│ Chain Home RCS resonance factor │ Add to settings.h constant list │
|
||||
├────────────────────────────────────┼───────────────────────────────────────────────────────────┤
|
||||
│ ATC power level realism │ Decide if historically accurate power matters for display │
|
||||
└────────────────────────────────────┴───────────────────────────────────────────────────────────┘
|
||||
|
||||
✻ Sautéed for 1m 11s
|
||||
|
||||
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
|
||||
❯ 000
|
||||
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user