more updates

CLAUDE.md

@@ -36,7 +36,7 @@ Classes:
 1. Anything to do with sending anything to the display. Needs to be on the
 same thread as the main function
 
-2. Communications with outside sources; ais and ads-bl for targets
+2. Communications with outside sources; ais and ads-b for targets
 
 3. Operator controls
 
@@ -56,18 +56,27 @@ for the a scope. The ppi scope
 will be on the right side of the screen and the a scope will be on the left
 hand side of the screen. 
 
-Suggest  one window with viewports. Lets have window the entire screen. For develpment
-I would  need some sort of escape the esscape the full screen and go back to the
-desktop.
+Use one window with viewports covering the entire screen. For development,
+F11 toggles fullscreen, Escape exits the program entirely.
 
-Suggest that the radar itself is at the location of the Community Boating
-Center dock in Bellingham, Washington, That should be 0,0 in local cartesian
-coordinates or 0 in range for vectoring. North on radar needs to be north in
-reality. 
+The radar is fixed at the Community Boating Center dock in Bellingham,
+Washington. That location is 0,0 in local Cartesian coordinates. North on
+the radar display is true north.
 
-GPS for tagets should be converted to local cartesian reference to this
-location. I don't know if I have to be concerned with vector data. Please
-comment.
+GPS coordinates from targets are converted to local Cartesian coordinates
+referenced to this origin using a flat-earth equirectangular projection,
+which is accurate enough for harbor radar ranges (0-24 nautical miles):
+
+  x = (lon - origin_lon) * cos(origin_lat) * R
+  y = (lat - origin_lat) * R
+
+Where R is Earth's radius (6,371,000 m). Result is in meters from the origin.
+No need to be concerned with spherical or vector geometry at these ranges.
+
+Coordinate conversion belongs in the main application, not in the Raspberry Pi
+communication class. The RPi class delivers raw lat/lon; the main app converts
+to local Cartesian. This keeps the RPi code simple and means a change to the
+radar origin only requires changing one place.
 
 Notes for controls the user can play with
 
@@ -110,7 +119,7 @@ for how many pulses received and in what direction. That would be permanent.
 Temporary code necessary for changing control selection and value via the
 keyboard until I get the necessary hardware for the controls.
 
-Also please note that thill will need to be flexible as encoders can
+Also please note that this will need to be flexible as encoders can
 be expensive, especially robust ones that kids cannot break.
 
 Shaders:
@@ -172,11 +181,13 @@ The PPI display will need shaders for the following:
 4. facility to include shore lines. This will change with range settings. If possible, can
    we include docks and tall buildings? Immediate is blue white same as targets.
 
-5. Persistance (green yellow) for targets, clutter, and shore lines. Persistance should
-   be ping pong. Lets suggest for persistance to be about 3 seconds.
+5. Persistence (green yellow) for targets, clutter, and shore lines. Persistence uses
+   ping-pong framebuffers with a decay multiplier each frame. Target persistence is
+   approximately 3 seconds, matching the P7 phosphor decay to 10% brightness.
 
-6. The pulse repitition time should be the same as a multiple of the screen update rate
-   so that we would have no aliasing. 
+6. The pulse repetition frequency (PRF) is a simulation parameter. At 24 RPM antenna
+   rotation, one full sweep takes 2.5 seconds and produces ~150 frames at 60 fps —
+   smooth with no aliasing concern.
 
 Communication:
 
@@ -188,33 +199,30 @@ ports. AIS requires a separate Raspberry Pi with its own SDR tuned to VHF 161/16
 
 Each Raspberry Pi will act as a server fielding requests from this program.
 
-Lets try to have each raspberry pi as a separate instantiation of a class
-called raspberry pi. Those classes will use a common data structure:
+Each Raspberry Pi is a separate instantiation of a class called RemoteTargetSource.
+Those classes will use a common target data structure:
 
 1. double longitude
 2. double latitude
-3. std::string *vessel_name
-4. std::string *registration
-5. float *vessel_size
-6. float course
-7. float speed
-8. time_t timestame
-9. float altitude (0 for boats)
-10. Target type
+3. std::string vessel_name
+4. std::string registration
+5. float length_meters
+6. float beam_meters
+7. int vessel_type         (AIS type code; aircraft type for ADS-B/UAT)
+8. uint32_t mmsi           (AIS unique identifier; ICAO hex address for aircraft)
+9. float course            (course over ground, degrees)
+10. float speed            (speed over ground, knots)
+11. time_t timestamp       (time of last fix; used to age out stale targets)
+12. float altitude         (meters; 0 for surface vessels)
+13. TargetType type        (enum: vessel, aircraft, etc.)
 
-Looking for suggesions
-
-Each of these raspberry pis will called by a main function (running as its own thread)
-to gather this data structure if there are any  targets received since the last
-call.
+The RPi communication thread blocks on a socket read until data arrives, then
+writes to a shared target queue protected by a mutex and signals a condition
+variable. The main application consumes from that queue.
 
 The Raspberry Pi code will live in a separate git repository with its own CLAUDE.md
 and its own CMakeLists.txt, since it targets a different architecture (ARM) and has
 a different toolchain and dependencies. Do not mix it into this repository hierarchy.
-The code will work on a blocking basis to block until something becomes available
 
-It should be up to this piece to convert the global latitude and longitude to 
-cartesian coordinates for the display. Unless you suggest otherwise
-
-Right  now, I just want to make sure that the structure is okay and that the CMakeFile.txt
-looks okay. I am  not ready to ask you to create any code
+Right now, I just want to make sure that the structure is okay and that the
+CMakeLists.txt looks okay. I am not ready to ask you to create any code