Start on database and radar equation
This commit is contained in:
105
additions
Normal file
105
additions
Normal file
@@ -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
|
||||||
127
additions-comments
Normal file
127
additions-comments
Normal file
@@ -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
|
||||||
|
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
|
||||||
|
|
||||||
|
|
||||||
Reference in New Issue
Block a user