diff --git a/additions b/additions new file mode 100644 index 0000000..9bfe674 --- /dev/null +++ b/additions @@ -0,0 +1,105 @@ +I would like to have this project use the radar equation to determine +brightness and possible blooming on targets. + +I want the radar equation to be implemented within the shaders. + +I want a postgres database (I did install postgresql and set up a database named radar with +a postgresql user named radar with password radar with full priveleges to database radar. + +DATABASE Schema: + +1. Type of target (Enumeration AIS, ADS-B, Local (simulator) +2. ID a. MMID for marine; b. ICAO 24 bit aircraft address; for simulator we can use the same MMID + and aircraft address +3. width (24 bits) +4. length (24 bits) +5. Height above water (24 bits) +6. Material (Enumeration fiberglass, wood, aluminum, steel +7. Enumeration: need update for size and material, does not need update for size and material + +Keep a copy of the data in the shaders. Don't just copy the entire database; when the +system starts up, there would be nothing in the copy; but as we get targets, either from +AIS, ADS-B, or simulator, add each target encountered to the copy in the shaders. This means +that we don't have to copy all of the data into the database. It will grow to a size up to the +current target count in a simulation session. + +The items in the database (to start with) would be the Enumeration, The ID, width, height, +and material. + +Maybe, if I simulate a modern system, I may want a field to describe the target (passenger, cargo, +oil, fishing; and maybe specifics for the targets. I know that the coast guard has a lot of +contextual data on targets that are from external sources. For now, lets now worry about this. + +PROPOSAL: + +Since ADS-b and AIS may not have material and size data, I would like to propose +That the initial running of the system upon detecting a target that has no size +determinatioin, we use a default size, say, 20 feet long 20 feet wide and fiberglass +for boats; 50 feet long 10 feet wide fusalage for planes; and set the need update parameter +to need update. + +Add an option (command line option) for system. Command line options would be 'database' +which would open a graphical panel suitable for updating the postgres database. +At the begining of the life of this project, almost all targets seen except for those +from the simulator will need database updating; as life of the system gets older there would +be fewer targets that need operation. + +END OF PROPOSAL + +Marine radar equation stuff: + +For this purpose, the marine radar will use the X Band (9225 MHZ) and 30 KW power for +maratime traffic system radar (our a-scope marine and PPI scope marine) + +For Marine, horizontal beam width is 0.5 degrees; vertical beam width is 20 degrees. +For Marine, the antenna size is 15 feet in length. +For Marine, the antenna height is 50 feet off surface + +Air traffic radar equation stuff: + +For this purpose, the air traffic control radar at BLI frequency 3 ghz or S Band; +power 25 KW + +For Air Traffic Control, the beam width is 1.4 degrees for horizontal and 5 degrees for vertical +For Air Traffic Control, the antenna size is 20 feet wide +For Air Traffic Control, the antenna is on a tower 50 feet high from the runway. It is not +mounted on the control tower. + +Chain Home radar equation stuff: + +For Chain Home, this will be a bit different: (this is AMES type 1) + +Frequency is 30 MHZ +Powwer is 500 KW +Pulse width is 20 US + +TRANSMIT GAIN (Gt) +Note that the transmit beam is not a beam, but a floodlight. +Pulse repitation frequency is 25 HZ or 12 HZ as selected by operator +Use Transmit G from beam width (floodlight) something like +G = 30000/100 degrees * 40 degrees +about 8.7 dBI (linear value of 7.5 + +Note that this is Bistatic; we need both Gt and Gr + +RECEIVE GAIN (Gr) is about 4 to 10 (6–10 dBi) + +System loss due to transmission line about 8 DB + +Target RCS larger RCS due to resonant scattering (I need help; please lookup + +Precision Approach Radar Equation Stuff: + +Peak power is about 100 kw +Very high antenna gain +X Band (3 cm for wavelength) Operation allow higher antenna gain +PAR must reliably small aircraft +High pule repition rate +Sweep about 20 degrees horizontal and 10 degress vertical +Short pulse width for range resolution +Beamwidth is determined by wavelength/antenna size with antenna size of about 5 meters. + +GENERAL NOTE FOR EQUATION STUFF + +We will need these key variables to be able to be changed via the settings.h file +and DESIGN.md and CLAUDE.md diff --git a/additions-comments b/additions-comments new file mode 100644 index 0000000..3aad156 --- /dev/null +++ b/additions-comments @@ -0,0 +1,127 @@ + 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 +──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── + +