diff --git a/CLAUDE.md b/CLAUDE.md index c4116b9..42d218f 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -131,9 +131,9 @@ struct target_data_structure { 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 int type; // type of target; vessel or aircraft; 0 = vessel + time_t timestamp; }; Of this heavy structure, only the following lean mathematical footprint is submitted @@ -996,22 +996,20 @@ 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. time_t timestamp - use to check to see if this has already been processed -5. int32_t may_need_update (this if a randome value is applied to any part of the target +4. 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. -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) +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) 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. - Please also note that the handling for the police boat's cruising around Bellingham Bay will also be part of the job of the simulator. This is achieved by having an indicator in the target data, labeled police_boat, which is a binary value. True means that this @@ -1076,22 +1074,71 @@ Data synchronization between threads must be managed explicitly using std::mutex 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. +The database will be maintained for the life of the exhibit. So targets that were in the database +when the exhibit will still be there when the exhibit is powered back on. -This is to save processing time for stuff such as reflectivity. +In addition to the postgress database, there will be two active target tables within memory. +Those tables will have a fixed size of 300 elements. -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. +There will be one table for Bellingham Bay for the marine a scope, the marine traffic control +radar, and the police boat radar. This shall be called memory-bellingham-bay -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. +The other table will be for the chain home radar, which is centered on RAF Ventnor +(Isle Of Wight) This shall be called memory-ventnor + +These tables are for holding the active data. Data shall be active unless there is +no update from the raspberry pis nor the simulator for 1 hour. Essentially these +tables are for all living data. The postgress database will be used only once for each +target while the exhibit is running. Database access will become fewer the longer the +exhibit has been running. + +Those tables will have the same format (which is sent to the shaders): + + +struct target_data_to_shader_structure { + float target_x; // Pre-converted local Cartesian offset X (meters relative to radar) + float target_y; // Pre-converted local Cartesian offset Y (meters relative to radar) + 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 = 0 for boats) + time_t timestamp; // Data aging tracking identifier + 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) + time_t timestamp; // time of last fix; used to age out stale targets +}; + +Target Processing suggestion: + +1. Determing which radar is in operation +2. Receive target information from simulator or raspberry pi. +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 + 3b: No, initialize new entry for memory data. Bring over location, course, altitude, + timestamp, police_boat + + 3c: Is this target in the postgres data base? + 3c1: 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. + + 4. Update cycles shall be 1/25 seconds for chain home and 30 microseconds for the ppi + scopes. + +Suggested code for deriving target height, reflectivity, and noiseGlint when target is not +in the database Here is sample code for doing this; this is suggestion only. @@ -1151,66 +1198,6 @@ glUniform1f(glGetUniformLocation(shaderProgram, "targetReflectivity[i]"), dynami but is not written to the database. It is to be passed to the shaders as a uniform. -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. 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. -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. Instructions regarding chain home. If the current active radar is chain home, we - need to drop all boat target and any target that is not within 300 miles from the - latitude and longitude of the chain home radar station. Furthermore all traffic from the - raspberry PI's need to be discarded for chain home. All chain home target traffic will be - beyond range for all of the other radars; therefore all such targets shall be discarded if - the active radar is not chain home. -8. 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. 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 should be - a value in the settings.h file. -9. The traffic cop does need to check the variable that had which radar is active. - This can be accomplished by seting an additionall mutex strictly for reading the - active radar variable from thread 1. -10. If the timestamp in the database is over 1 hour from the current time, then - the target shall be skipped. -11. If police_boat == 1, then use uniforms to pass heading and location. Do not pass target data as the - police boat does not see itself. If police_boat == 0, then treat the police boat as any other target. - -Here is the database workflow. - -1. Receive target from simulator or raspberry pis -2. Is target in the memmory copy of the database -3. Yes - then update the timestamp -4. If not in memory, the try to pull from the database -4a. If memory is already full, then delete record with oldest timestamp. -4b. The do the pull from the database. -5. If pulled from database, then update the timestamp. -6. If it cannot be pulled from the database, then enter - net target into the database and memory copy. Then do - the calculations for RadarMaterialProfile, then pull - in other non vilitile target data (size, beam, etc) -