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
+4. int32_t material - 1 for metal, 2 for wood, 3 for fiberglass
-6. time_t timestamp
+5. float elapsed_seconds - seconds sing jan 1 1970
-7. binary may_need_update   (this if a randome value is applied to any part of the target
+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)
+7. int vessel_type (AIS type code or aircraft type)
-9. uint32_t mmsi   (unique identification for boat or ICAL for aircraft
+8. uint32_t mmsi   (unique identification for boat or ICAL for aircraft
-10. binary police_boat (this indicates that this is for the police boat
+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:
 

data/patrol_route.json

@@ -1,12 +0,0 @@
-{
-  "comment": "Police patrol boat route stub — boat PPI scope not yet implemented.",
-  "waypoints": [
-    { "lat": 48.7530, "lon": -122.5150, "speed_kt": 10.0, "zone": "Ferry lane — open waterfront" },
-    { "lat": 48.7480, "lon": -122.5050, "speed_kt":  4.0, "zone": "Near Squalicum breakwater" },
-    { "lat": 48.7460, "lon": -122.5120, "speed_kt": 10.0, "zone": "Open waterfront west" },
-    { "lat": 48.7380, "lon": -122.5200, "speed_kt": 10.0, "zone": "Boulevard Park approach" },
-    { "lat": 48.7340, "lon": -122.5150, "speed_kt":  4.0, "zone": "Taylor Dock area" },
-    { "lat": 48.7320, "lon": -122.5050, "speed_kt":  4.0, "zone": "Community Boating Center" }
-  ],
-  "loop": "reverse"
-}

work_note1

@@ -0,0 +1,59 @@
+What's Fixed (Good Work)
+  
+  - float height added to the master target_data_structure — now consistent with the SSBO and database.
+  - Thread count corrected to "five threads."
+  - Stale target rule fixed: "timestamp is older than 1 hour" — that's the right semantic.
+  - Database numbering gap (missing 5) is closed.
+  - int32_t police_boat properly typed in the database table.
+  - Database/dynamic state separation clarified — the note that the database holds only physical characteristics
+  is important and was missing before.
+  - patrol_route.json removed cleanly; simulator owns that logic now.
+  - Timing change resolves the A-scope problem I flagged — targets no longer have to wait for north crossing.
+
+  ---
+  One Significant New Issue
+
+  float elapsed_seconds will lose precision at current epoch.
+
+  float has roughly 7 significant decimal digits. The current Unix timestamp is about 1,748,000,000 seconds. At
+  that magnitude, a float can only distinguish values that are about 128 seconds apart — it cannot tell the
+  difference between two timestamps that are minutes or even an hour apart. Your 1-hour stale check would break
+  silently.
+
+  This should be int64_t elapsed_seconds (or simply keep the original time_t, which is int64_t on 64-bit Linux).
+  In the PostgreSQL column, this maps to BIGINT.
+
+  ---
+  Still Unresolved from Before
+
+  The SSBO struct (target_data_to_shader_structure, the block starting around line 142) still has the same
+  pseudo-types that were flagged earlier — enum material, binary police_boat, and time_t timestamp. The database
+  table was updated to proper types but the SSBO struct wasn't touched. Those three fields in the SSBO struct need
+   the same treatment:
+
+  - enum material; → int32_t material;
+  - binary police_boat → int32_t police_boat;
+  - time_t timestamp; → int64_t timestamp; — and note that std430 will align this to 8-byte boundaries, which may
+  pad the struct unexpectedly. Worth documenting.
+
+  Also: may_need_update in the database table still says "binary" rather than a typed value.
+
+  ---
+  One Question on the New Timing
+
+  With targets now dispatched "as they arrive," Thread 1 could receive a new target batch at any point during a
+  sweep — including mid-frame while the GPU is rendering. The mutex protects the write side, but you'll need to
+  decide when Thread 1 actually uploads the new data to the SSBO: at the start of each render frame (safest), or
+  immediately on receipt. "Immediately" is fine but should be stated, so the code is written with that in mind.
+  Recommend adding one sentence to the Thread 1 description about when it drains the incoming target buffer and
+  calls glBufferSubData.
+
+✻ Sautéed for 1m 1s
+
+※ recap: Museum radar simulator in C++/OpenGL. We're specifying the target data pipeline in CLAUDE.md. Next: fix 
+  the SSBO struct types — change enum material, binary police_boat, and time_t timestamp to proper int32_t and 
+  int64_t types. (disable recaps in /config)
+  
+──────────────────────────────────────────────────────────────────────────────────────────────────────────────────
+❯  
+───────────────────────────────────────────────────