diff --git a/CLAUDE.md b/CLAUDE.md index 42d218f..809d22c 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -147,10 +147,11 @@ struct target_data_to_shader_structure { float course; // Course over ground vector (radians relative to True North) float altitude; // Target altitude profile (meters = 0 for boats) time_t timestamp; // Data aging tracking identifier - float reflectivity; // derivied from vessel_type (see table below) + float current_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 + uint32_t mmsi; // AIS unique identifier; ICAO hex address for aircraft int type; // target type (0 for boat 1 for aircraft) }; @@ -995,17 +996,16 @@ Here is the data items for the table in the Postgres database: 1. float length 2. float beam -3. int32_t material - 1 for metal, 2 for wood, 3 for fiberglass -4. int32_t may_need_update (this if a randome value is applied to any part of the target +3. int32_t 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. -5. int vessel_type (AIS type code or aircraft type) -6. uint32_t mmsi (unique identification for boat or ICAL for aircraft -7. float reflectivity (derived from target type) -8. float height_estimate (derived from target type) -9. float noiseglint (derived from target type_ -10. int32_t police_boat (this indicates that this is for the police boat - 1 is true) +4. int vessel_type (AIS type code or aircraft type) +5. uint32_t mmsi (unique identification for boat or ICAL for aircraft +6. float reflectivity (derived from target type) +7. float height_estimate (derived from target type) +8. float noiseglint (derived from target type_ +9. 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. @@ -1037,13 +1037,13 @@ Thread 1 = Operation of setting up the system; ie; initializeing Opengl, compiling, building, and loading all of the shaders. It also handles the keyboard operation of the radar controls as those are callbacks from the OpenGL. Accepting target traffic from the Traffic Cop will be performed, - however, the Traffic Cop will need to assert a mutex in order to write any + however, the Traffic Cop will need to assert mutex-target-data in order to write any target data to this Thread 1. Thread 2 = Traffic Cop. The Traffic Cop will accept Target Data from the Simulator (which will be discussed here) ; and the AIS and ADS(b) data from the raspberry pis. At this time, we need to provide only a stub withing the traffic cop to access the Raspberry pis. - The traffic cop will need to set a mutex before handing radar traffic to the Thread 1 software + The traffic cop will need to set a mutex-target-data before handing radar traffic to the Thread 1 software which will send the radar data on to the shaders. Note that the traffic cop needs to do the following processing with target data: @@ -1053,16 +1053,17 @@ Thread 2 = Traffic Cop. The Traffic Cop will accept Target Data from the Simulat 3. Discard targets whose timestamp is older than 1 hour Thread 3 = Simulator. The simulator creates and manages the simulated targets. It needs to - assert a mutex to transfer target information to the Traffic cop + assert mutex-simulator-to-traffic-cop to transfer target information to the Traffic cop Thread 4 = Physical controls, knobs and switches. This has not been developed and will not be developed with the current version of the project. It will be developed later. It - does need to set a mutex in order to send control information to Thread 1 so that thread + does need to set a mutex-control-data-to-shaders in order to send control + information to Thread 1 so that thread can set the state variables and the uniforms for the controls in the shaders. Thread 5 = Raspberry pi data recever = this receives the data from the raspberry pis. It will 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. + need to set mutex-raspberry-pi in order to transfer target data to the traffic cop. ================================================================================ @@ -1103,38 +1104,46 @@ struct target_data_to_shader_structure { float course; // Course over ground vector (radians relative to True North) float altitude; // Target altitude profile (meters = 0 for boats) time_t timestamp; // Data aging tracking identifier - float reflectivity; // derivied from vessel_type (see table below) + float current_reflectivity; // derived from calculation based on material - is dynamic 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) - time_t timestamp; // time of last fix; used to age out stale targets + uint32_t mmsi; // AIS unique identifier; ICAO hex address for aircraft }; Target Processing suggestion: -1. Determing which radar is in operation -2. Receive target information from simulator or raspberry pi. +1. Determing which geographic area is in operation; bellingham bay, or Vetnor Isle of Wight +2. Receive target information from simulator or raspberry pi. Both these used the target_data_structure 3. Is target already in the memory table for the current radar in use (memory-bellingham-bay for marine a-scope, marine traffic control ppi, and marine police boat) (memory-ventnor for chain home) 3a: Yes, replace location, course, altitude, timestamp, police_boat into the memory table; - leave all other data alone + calculate current_reflectivity using the sample code below; leave all other data alone 3b: No, initialize new entry for memory data. Bring over location, course, altitude, - timestamp, police_boat + timestamp, police_boat; note that if we alredy have 300 entries; determine which + entry is the least used and replace that entry with the new one - 3c: Is this target in the postgres data base? - 3c1: no - Create database entry. Perform calculation for reflectivity as noted below + 3b1: Is this target in the postgres data base? + 3b1a: no - Create database entry. Perform calculation for reflectivity as noted below based on vessel_type, length, type, and beam from the target data structure from the simulator data or raspberry pi data; and then bring over lengh, beam, - altitude, police_boat from the target data structure - 3c2: yes - bring over, from database, followng: location, length, beam, course, altitude, - timestamp, reflectivity, height_estimate, noiseglint, timestamea to the memory - table. - 3. After all incoming targets processed, wait for next update cycle, - assert mutex, and pass the table to cpu thread 1 to pass onto the shaders. + altitude, police_boat from the target data structure, and bring over the heigh_estimate, + and noiseglind from the getMaterialProfile calculation above. + 3b1b: yes - bring over, from database, followng: length, beam, + reflectivity, height_estimate, noiseglint, to the memory + table. This is for the new table created by step 3b. + 3b1c: recalculate the current_reflectivity and insert into table; this is dynamic + + 4. After all incoming targets processed, wait for next update cycle, + assert mutex-target-data, and pass the table to cpu thread 1 to pass onto the shaders. - 4. Update cycles shall be 1/25 seconds for chain home and 30 microseconds for the ppi + 5. As we are updating, check for the target that is the police boat, if so, check to + see if the radar in use is for the police boat, then fill in unforms for heading and location + but don't send targets as active data tot he shader. + + 6. Update cycles shall be 1/25 seconds for chain home and 50 milleseconds for the ppi scopes. Suggested code for deriving target height, reflectivity, and noiseGlint when target is not @@ -1193,9 +1202,9 @@ 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); -but is not written to the database. It is to be passed to the shaders as a uniform. +// Enter the baseReflectivity into the database entry for the target as reflectivity +// Enter the dynamicReflectivity int the target memory table as current_reflectivity + note that this is to be calculated for each update. It is dynamic unlike reflectivity