maallyn/updated-radar
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Removed duplicate section about traffic cop and fixed some issues

Browse Source
This commit is contained in:
Mark Allyn
2026-05-28 10:49:10 -07:00
parent 06ac71f910
commit 466b214cbf
1 changed files with 31 additions and 108 deletions
Download Patch File Download Diff File Expand all files Collapse all files

139
CLAUDE.md
View File

@@ -127,14 +127,14 @@ struct target_data_structure {
std::string registration; // will be null for no registration
float length; // in meters
float beam; // in meters
float height; // in meters
float altitude; // in meters
int vessel_type; // AIS type code or aircraft type
uint32_t mmsi; // AIS unique identifier; ICAO hex address for aircraft
float course; // course over ground, degrees, based on true north
float speed; // speed over ground, knots
time_t timestamp; // time of last fix; used to age out stale targets
float altitude; // meters, but 0 for boats
TargetType type; // type of target; vessel or aircraft
int type; // type of target; vessel or aircraft; 0 = vessel
};
Of this heavy structure, only the following lean mathematical footprint is submitted
@@ -146,12 +146,13 @@ struct target_data_to_shader_structure {
float length; // Vessel length bounds (meters)
float beam; // Vessel beam bounds (meters)
float course; // Course over ground vector (radians relative to True North)
float altitude; // Target altitude profile (meters)
float altitude; // Target altitude profile (meters = 0 for boats)
time_t timestamp; // Data aging tracking identifier
float reflectivity; // derivied from TargetType (see table below)
float height_estimate; // derived from TargetType (see table below)
float noiseglint; // derived from TargetType (see table below)
binary police_boat // this indicates that the target is for the roaming police boat.
float reflectivity; // derivied from vessel_type (see table below)
float height_estimate; // derived from vessel_type (see table below)
float noiseglint; // derived from vessel_type (see table below)
int32_t police_boat // this indicates that the target is for the roaming police boat. 1 = police boat
int type // target type (0 for boat 1 for aircraft)
};
Please note that height and material are not included in the data received from the simulator
@@ -159,90 +160,6 @@ nor the raspberry pis. This has to be derived. That will be discussed when I tal
traffic cop later in this document.
Suggested code for deriving target height, reflectivity
(derived from material) and noiseGlint (derived from material)
struct RadarMaterialProfile {
float reflectivity; // 0.0 (stealth/fiberglass) to 1.0 (massive steel)
float heightEstimate; // in meters, to calculate radar horizon cutout
float noiseGlint; // simulated signal scintillation
};
RadarMaterialProfile getMaterialProfile(int aisTypeCode) {
RadarMaterialProfile profile;
switch(type) { // type is in the target_data_structure
case 30: // Fishing (often wooden/fiberglass hulls, low sitting)
profile.reflectivity = 0.35; profile.heightEstimate = 4.0; profile.noiseGlint = 0.2;
break;
case 36: // Sailing Vessel (tall aluminum mast, but low fiberglass hull)
profile.reflectivity = 0.25; profile.heightEstimate = 15.0; profile.noiseGlint = 0.4; // High mast glint!
break;
case 37: // Pleasure Craft (fiberglass speedboats, yachts)
profile.reflectivity = 0.20; profile.heightEstimate = 3.0; profile.noiseGlint = 0.1;
break;
case 52: // Tugboats (dense, heavy low-sitting steel blocks)
profile.reflectivity = 0.85; profile.heightEstimate = 6.0; profile.noiseGlint = 0.15;
profile.reflectivity = 0.95; profile.heightEstimate = 35.0; profile.noiseGlint = 0.05; // Perfect metal reflector!
break;
default: // Catch-all / Code 0 - some owners neglect setting this in their transponders
profile.reflectivity = 0.50; profile.heightEstimate = 8.0; profile.noiseGlint = 0.2;
break;
}
return profile;
}
The segment handling asynchronous target ingestion is called traffic_cop.
The traffic_cop runs on a dedicated background execution thread separate from the rendering loop.
Data synchronization between threads must be managed explicitly using std::mutex blocks.
Using this data, the traffic cop can derive the time varying fluctuations of the target
(note that this is suggested code; may not be the actual code you generate)
// Inside your C++ target loop (running every frame or every radar sweep)
float baseReflectivity = target.materialProfile.reflectivity;
float glintFactor = target.materialProfile.noiseGlint;
// Generate a random float between -1.0 and 1.0
float randomNoise = ((float)rand() / RAND_MAX) * 2.0f - 1.0f;
// Calculate the dynamic, fluctuating reflectivity for THIS frame
float dynamicReflectivity = baseReflectivity + (randomNoise * glintFactor);
// Clamp it so it doesn't drop below 0 or overshoot 1.0
dynamicReflectivity = std::max(0.0f, std::min(1.0f, dynamicReflectivity));
// Pass 'dynamicReflectivity' to your GLSL shader uniform array
glUniform1f(glGetUniformLocation(shaderProgram, "targetReflectivity[i]"), dynamicReflectivity);
The segment handling asynchronous target ingestion is called traffic_cop.
The traffic_cop runs on a dedicated background execution thread separate from the rendering loop.
Data synchronization between threads must be managed explicitly using std::mutex blocks.
[TRAFFIC COP OPERATIONAL TIMING PROTOCOL]
1. Processing Loop: Aggregated targets are packaged into a uniform array and dispatched
as they arrive to the traffic cop from the simulator or the receiver handling the raspberry pis.
2. Range Filtering: Discard any targets residing outside the active radar's
designated maximum operational range.
3. Altitude Restriction: Enforce a strict <= 40-meter restriction for marine nodes (Marine Chain Home
and all PPI Marine radars). Discard any aircraft violating this ceiling.
4. Precision Alignment: Latitude and longitude coordinate conversions into local meters relative to
the radar origin must be handled on the CPU thread within traffic_cop
to protect against FP32 structural precision rounding errors inside the GPU.
6. The determination of the reflectivity, height estimate, and the noiseglint must
be processed by the traffic cop
7. The traffic cop needs to know the longitude and latitude of the chain home ascope, the marine ascope,
and the marine traffic control radars. It will already have the longitude and latitude of the
police boat radar as it will be processing the location of the police boat radar from the
simulator.
5. Critical Section: Assert a std::mutex to gain safe writing access to the
double-buffered array driving the SSBO, copy the structural contents, and
clear the mutex immediately.
=============================================================================
Please note that the first iteration of the project will have only minimal controls.
@@ -1079,19 +996,18 @@ Here is the data items for the table in the Postgres database:
1. float length
2. float beam
3. float height
4. int32_t material - 1 for metal, 2 for wood, 3 for fiberglass
5. float elapsed_seconds - seconds sing jan 1 1970
6. binary may_need_update (this if a randome value is applied to any part of the target
3. int32_t material - 1 for metal, 2 for wood, 3 for fiberglass
4. timestamp elapsed_seconds
5. binary may_need_update (this if a randome value is applied to any part of the target
and that the user may want to update the database. This
will not force the user to do the update, a later
database editing program will use this.
7. int vessel_type (AIS type code or aircraft type)
8. uint32_t mmsi (unique identification for boat or ICAL for aircraft
9. float reflectivity (derived from target type)
10. float height_estimate (derived from target type)
11. float noiseglint (derived from target type_
12. int32_t police_boat (this indicates that this is for the police boat - 1 is true)
6. int vessel_type (AIS type code or aircraft type)
7. uint32_t mmsi (unique identification for boat or ICAL for aircraft
8. float reflectivity (derived from target type)
9. float height_estimate (derived from target type)
10. float noiseglint (derived from target type_
11. int32_t police_boat (this indicates that this is for the police boat - 1 is true)
Please note that this database is only for the physical characteristics. Dynamic
information which is created by the simulator (or raspberry pis) as that data changes.
@@ -1105,7 +1021,10 @@ will not show the target as a target, but the direction and speed of the police
will be taken from the target information of the police boat. This means that the police
boat radar graticulel will be adjuste appropriately and that the location will need to be
used to update the ppi display so that the center of the display will reflect the location
indicated in the target data for this target. All other radars will treat this just as regular
indicated in the target data for this target. Therefore, the actual target information
for the police boat will not be sent to the shaders if the active radar is for the
police boat. The location and heading will be sent to the shaders as uniform values.
All other radars will treat this just as regular
target.
This also means that there would be the following uniform variables in the shaders for the
@@ -1189,7 +1108,7 @@ struct RadarMaterialProfile {
RadarMaterialProfile getMaterialProfile(int aisTypeCode) {
RadarMaterialProfile profile;
switch(type) { // type is in the target_data_structure
switch(vessel_type) { // vessel_type is in the target_data_structure
case 30: // Fishing (often wooden/fiberglass hulls, low sitting)
profile.reflectivity = 0.35; profile.heightEstimate = 4.0; profile.noiseGlint = 0.2;
break;
@@ -1200,7 +1119,6 @@ RadarMaterialProfile getMaterialProfile(int aisTypeCode) {
profile.reflectivity = 0.20; profile.heightEstimate = 3.0; profile.noiseGlint = 0.1;
break;
case 52: // Tugboats (dense, heavy low-sitting steel blocks)
profile.reflectivity = 0.85; profile.heightEstimate = 6.0; profile.noiseGlint = 0.15;
profile.reflectivity = 0.95; profile.heightEstimate = 35.0; profile.noiseGlint = 0.05; // Perfect metal reflector!
break;
default: // Catch-all / Code 0 - some owners neglect setting this in their transponders
@@ -1241,9 +1159,11 @@ Data synchronization between threads must be managed explicitly using std::mutex
1. Processing Loop: Aggregated targets are packaged into a uniform array and dispatched
as they arrive to the traffic cop from the simulator or the receiver handling the raspberry pis.
2. Range Filtering: Discard any targets residing outside the active radar's
designated maximum operational range.
3. Altitude Restriction: Enforce a strict <= 40-meter restriction for marine nodes (Marine Chain Home
and all PPI Marine radars). Discard any aircraft violating this ceiling.
designated maximum operational range. Apply this if active radar is not Chain Home. Do not apply
if this is for Chain Home
3. Altitude Restriction: Enforce a strict <= 40-meter restriction for marine nodes (Marine A-scope
and all PPI Marine radars). Discard any aircraft violating this ceiling. Do not apply this
restriction if the active radar is Chain Home.
4. Precision Alignment: Latitude and longitude coordinate conversions into local meters relative to
the radar origin must be handled on the CPU thread within traffic_cop
to protect against FP32 structural precision rounding errors inside the GPU.
@@ -1259,7 +1179,10 @@ Data synchronization between threads must be managed explicitly using std::mutex
about once every screen update. However, the processing speed may not be
able to achieve this. Also bear in mind that data from the raspberry pis
and the simulator may not updata every screen update. If that's the case, the
traffic cop will not do anything.
traffic cop will not do anything. Also note that the SSBO maximum target capability
will be 200. Oldest targets shall not be sent to the SSBO if the limit is reached.
Lets include the maximum in memory copy of the database and SSBO shouse be
a value in the settings.h file.
===============================================================