Introduction:

This is a project for a museum to demonstrate a simulation of a 1950's to 1960's
vintage marine radar.

There will be two scopes. An early A Scope and a PPI scope.

The PPI scope will take up the entire right hand side of the display 
(1/2 inch margins on top,bottom, and right hand side) and the A Scope will 
be smaller, located in the center of the left hand
side of the display near the left margin.

Display should be whole screen. An escape, possibly with the escape key
needs to be provided to exit the program and go back to shell.

We have to simulate everything as we are not allowed to have an actual radar at
out location because because we are not on the water.

The proposed location of the radar antenna is at the dock of the Community
boating center in Bellingham, Washington.
Location is 48.72° N Latitude and -122.51° W Longitude

The proposed maximum range is 15 miles. 
Selectable ranges sould be 2, 5, 10, and 15 miles

The project will be implimented on on a Geekom A8 Max
with AMD AI chip R9-8945HS with 32 GB ram

The operating system is Linux (Ubuntu)
Details:

Distributor ID: Ubuntu
Description:    Ubuntu 25.10
Release:        25.10
Codename:       questing

The compiler is cpp (Ubuntu 15.2.0-4ubuntu4) 15.2.0

We plan to use the cmake for building.

Here is the directory structure with files already installed:

./shaders
./shaders/CLAUDE.md
./glad
./glad/src
./glad/src/glad.c
./include
./include/glad
./include/glad/glad.h
./include/CLAUDE.md
./include/KHR
./include/KHR/khrplatform.h
./new-claude
./README.md
./CMakeLists.txt
./build
./build/CLAUDE.md
./CLAUDE.md
./.new-claude.swp
./LICENSE
./src
./src/CLAUDE.md

The followng classes would be needed:

1. Operation of display; set up of display and any operation
   that feeds data to the display. This should be in the main
   context. It cannot wait for data or anything. It would
   require a mutex for each user sending data. 

2. Operator controls. These feed to control data input to the
   display class using appropriate mutexes. This would also
   include updating graticules sor changing range on the PPI
   scope and changing range and bearing for the a scope

3. Radar targets from receivers AIS, ADS-B, and UAT

4. Simulated (fake) radar targets

5. Any code needed to process topographical data for the shorline

Each of these can run as its own thread, but they all have to use
mutexes in order to send anything to the display. Perhaps they could
be polled by a dispatcher that will tell each one its turn to send
data to the display.
The simulator will use ads-b and ais and uat received on airspy 
SDR radios communicating wiht Raspberry pi 4 single board computers
running linux.

I plan to have a variety of phony targets simulated in addition to
those received on uat, ads-b, and ais. 

I prefer to have separate shader sets for each major function to facilitate
troubleshootng
Major functions:
1. A scope radar
2. A scope graticule operation
3. PPI scope active targets
4. PPI scope graticule Bearing marks
5. PPI scope graticule range rings
6. PPI scope handling of the shorline using some sort of topographical map
7. PPI scope persistance phosphor
8. Rain scatter
9. wave scatter

Display colors:
1. A Scope is P1 (same as oscilloscope)
2. A Scope graticule is incandescent color
3. PPI scope active targets including scatters, graticule range rings, shoreline,
   all p7 phosphor (active white blue)
4. All persistance for  PPI scope active targets including 
   scatters, graticule range rings, shoreline
5. PPI scope bearing ring and ticks is incandescent color.

Coordinates:

Please note that all target information furnished to the 
display be in local coordinates. Transition to local candidate
from AIS/ADS-B/UAT need to be converted to local coordinates.
Local coordinates have center (0,0) at location of radar
base at the community boating center. Maximum coordinate size
is 15 miles from the center.

Signal strength:

Need to have following fixed singnal strength:
1. large ship would be bright and blooming
2. yachts would be bright but not blooming
3. sailboats would be medium bright and not blooming
4. kayaks and roaboats would be small and dim

Details of each feature:

A scope:
1. Displays range, does not rotate. You must use control to set bearing.
   Range is horizontal axis and strength of signal is verical axis.
   Needs 

2. Graticule is tricky. In the day, the operator would have a stack of
   graticules for each range setting. To fake this out, We could have the
   graticule appear to move up and out and the replacement graticule move 
   in and down in place. The operator takes them out from a slot above the
   scope and inserts the replacement through the same slot. All these graticules
   are lighted with incandescent colors.

PPI Scope active targets
1. Active boats/planes; brightness determined by size as noted above
2. Blue white color

PPI Scope range rings
1. blue white (dim)
2. These change if operator changes max range

PPI Scope cursor (In the day, this was a moveable plastic
overlay on scope, back lit by incandescent lamp. We need to
simulate this. Movement of this is viy the Range and Bearing controls
cursor consistes of flat line for range and box for bearing.

PPI Scope Bearing ticks and ring

1. Tick mark every degree
2. 0 degrees is top of display
3. Degrees count clockwise.
4. Use text for every 10 degrees, but text on outside of ring.
5. Have ring around tick marks

Controls:

Here are the controls that I am proposing

1. Intensity
2. Focus
3. Astignatism
4. Range selection (for both a scope and ppi scope)
5. Sensitivity
6. Clutter elimination (I believe only ppi scope; please research)
7. There is some sort of control having to do with the mangatron
   but I don't know what its called and what it does.
8. Bearing (only for a scope) which in the old days uses a servo motor to
   rotate the antenna. I don't know what form of feedback (text on the
   screen or mechanical numbers on a dial)
9. Magnetron tune
10. Anti clutter rain (ftc)
11. Will not need heading (this will be a fixed radar location for
    the harbor master or lifeguard
12. Off-centering
13. Graticule brilliance
14. Reset (in case kids really mess things up)
15. Pulse length selection (short pulse for better range resolution,
    long pulse for better sensitivity at distance; operator selectable)


(Please suggest other controls I may have missed.)

Now, for controls, the tentative approach is to use encoders (that do not
have end stops so they cannot be broken by visitors at the museum) I will
need help on how to impliment them. I am guessing a few raspberry pies to
handle the encoders. I am thinking of encoders have one common terminal and
a clockwise pulse terminal and a counter clockwise pulse terminal.

Let do this like this. The control handling will be a different class and run
as a separate thread from the display. Each control function will have a parameter
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 this will need to be flexible as encoders can
be expensive, especially robust ones that kids cannot break.

Text Rendering:

Use stb_truetype (single-header library, stb_truetype.h from github.com/nothings/stb).
Drop stb_truetype.h into the src directory. No additional build dependencies required.
Used for graticule degree labels on the PPI bearing ring, range labels, and any
vessel name labels from AIS data. Build a font atlas texture at startup from a
TTF font file; render characters as textured quads in the shader.

Communication:

Communication:

All I know now is that I plan to use a combination of raspberry pi 4 and a Airspy
SDR for each of ais, ads-b, and uat. UAT (978 MHz) and ADS-B (1090 MHz) are different
frequencies and require separate SDRs, but a single Raspberry Pi 4 is powerful enough
to run both dump1090 (ADS-B) and dump978 (UAT) simultaneously with two SDRs on its USB
ports. AIS requires a separate Raspberry Pi with its own SDR tuned to VHF 161/162 MHz.

Each Raspberry Pi will act as a server fielding requests from this program.

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 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.)

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

			NOTE on my plan for coding

1. I want to test and debug the code feature by feature.
2. I do not want any code created on features until I am ready.

Order of testing features.

1. Generational initialization and set up basic boundaries of the two scopes
   on the screen. Now features on each scope yet.
2. Edge graticule on ppi scope (Bearing ticks and numbers)
3. Replaceable graticule on A Scope. Have it  update for each different range
   and hold for 5 seconds for each range
4. PPI scope range rings; both active display and persistance display - test
   for each range settings; hold for 5 seconds each
5. PPI scope cursor - test by slowing changing range and bearing
6. PPI scope weather noise - test by changing noise level slowly
7. PPI scope waves noise - test by changing noise level slowly
8. PPI scope handling of shorline - test by running for a few seconds

========================================================

Now, just comment on this, noting any errors or anything you think is smissing.
DO NOT GENERATE CODE
