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