working on target handling

CLAUDE.md

@@ -127,6 +127,7 @@ 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
    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
@@ -164,7 +165,7 @@ Data synchronization between threads must be managed explicitly using std::mutex
 
 [TRAFFIC COP OPERATIONAL TIMING PROTOCOL]
 1. Processing Loop: Aggregated targets are packaged into a uniform array and dispatched 
-   as a batch operation precisely when the PPI radar sweep line crosses 0.0 radians (True North).
+   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.
@@ -1011,18 +1012,21 @@ Here is the data items for the table in the Postgres database:
 1. float length
 2. float beam
 3. float height
-4. enum material
-6. time_t timestamp
-7. binary may_need_update   (this if a randome value is applied to any part of the target
+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
                              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.
-8. int vessel_type (AIS type code or aircraft type)
-9. uint32_t mmsi   (unique identification for boat or ICAL for aircraft
-10. binary police_boat (this indicates that this is for the police boat
+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)
+
+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 not that the handling for the police boat's cruising around Bellingham Bay
+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
 target is for the police boat. If the target is the police boat, the police boat radar
@@ -1033,7 +1037,14 @@ used to update the ppi display so that the center of the display will reflect th
 indicated in the target data for this target. All other radars will treat this just as regular
 target.
 
-Now, first thing is discussion of the threads. There will be four threads:
+This also means that there would be the following uniform variables in the shaders for the
+police boat:
+
+1. Heading
+2. Location (local coordinates) which will have to be derived by the traffic cop from the
+   original latitude and longitude from the simulator
+
+Now, lets discuss the threads. There will be five threads:
 
 Thread 1 = Operation of setting up the system; ie; initializeing Opengl,
        compiling, building, and loading all of the shaders. It also handles
@@ -1045,16 +1056,28 @@ Thread 1 = Operation of setting up the system; ie; initializeing Opengl,
 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 mutes before handing radar traffic to the Thread 1 software
+       The traffic cop will need to set a mutex 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:
 
           1. Convert the GPS longitude information to the local coordinates for each radar.
           2. Check and discard targets that are outside the range of the radar that is
              currently being used. 
-          3. Discard targets that I have not moved for 1 hour.
-===============================================================
+          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
+
+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
+        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.
+
+===============================================================
 
 Sections still to be worked on: