diff --git a/CLAUDE.md b/CLAUDE.md index f6873a7..9b97eb2 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -149,14 +149,19 @@ struct target_data_to_shader_structure { float altitude; // Target altitude profile (meters) time_t timestamp; // Data aging tracking identifier float reflectivity; // derivied from TargetType (see table below) - float heightestivate; // derived from TargetType (see table below) - fload noiseglint; // derived 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. }; -Plese note that height, reflectivity, and noiseglint have to be derived from the target type -in this table: (note that this is suggested code just to show you what should be happeneing) +Please note that height and material are not included in the data received from the simulator +nor the raspberry pis. This has to be derived. That will be discussed when I talk about the +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 @@ -237,7 +242,6 @@ Data synchronization between threads must be managed explicitly using std::mutex double-buffered array driving the SSBO, copy the structural contents, and clear the mutex immediately. -Note that the construction of the simulator will be discussed later in this document. ============================================================================= @@ -1084,7 +1088,10 @@ Here is the data items for the table in the Postgres database: 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. int32_t police_boat (this indicates that this is for the police boat - 1 is true) +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) 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. @@ -1141,13 +1148,124 @@ Thread 5 = Raspberry pi data recever = this receives the data from the raspberry not be developed for the current version of the project. The Raspberry PI receiver will need to set a mutex in order to transfer target data to the traffic cop. +================================================================================ + +The traffic cop - handling radar data and deriving reflectivity stuff + +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. + +Among its duties are to manage the database. + +New targets (which have not ever been introduced to this system will be added to the +database. The purpose of the database is to remember physical characteristics of targets; +ie; the stuff that is not dynamic to the movement of the target. + +This is to save processing time for stuff such as reflectivity. + +As target data is read from the database, it will also be copied to an in-memory copy +of the database so that processing can be more efficent. The maximum size of the in-memory +copy shall be limited to 200 targets. If the number of targets gets larger than 200 targets, the +targets that have not been updated for the longest time shall be overwritten by new targets. +Judging from the current traffic of bellingham bay, 200 targets for the caching memory copy of +the database should be enough. + +As you may notice, height and material have not been including in the table of data we get from +the simulator nor the raspberry pis taking in the ais and ads-b data from the sdr's. Those values +have to be derived by the traffic cop and then entered into the database. + +Here is sample code for doing this; this is suggestion only. + +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; +} + + +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; and +note that this data is not included in the database as it is active data) + + +// 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. +5. The determination of the reflectivity, height estimate, and the noiseglint must + be processed by the traffic cop +6. 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. +7. 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. May I suggest that this activity be performed + 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. + + =============================================================== Sections still to be worked on: -Details of the Traffic Cop and the PostGres database. These -two subjects are interrelated and will be discussed later - Details on the simulator will be discussed later. Details on the relationship between the simulator and the movement of the