maallyn/radar-simulation
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Updating CLAUDE for new information

Browse Source
This commit is contained in:
Mark Allyn
2026-04-01 23:30:44 -07:00
parent fc6705ec85
commit 2e72f5e590
2 changed files with 448 additions and 128 deletions
Download Patch File Download Diff File Expand all files Collapse all files

297
CLAUDE.md
View File

@@ -1,87 +1,171 @@
Hello, this is a project to create a simulation of a vintage marine radar before the
days of digital electronics and we had to use a cathode ray tube with p7 phosphor
Introduction:
I plan to use c++ and opengl and shaders for access to a GPU. I am in ubuntu 25.10.
This is a project for a museum to demonstrate a simulation of a 1950's to 1960's
vintage marine radar.
I wish the c++ be arranged as follows:
There will be two scopes. An early A Scope and a PPI scope.
All code in the src subdirectory
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.
The main program and the binary would be called radar-simulation.
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.
The shaders are in the shaders subdirectory
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.
We need to use classes. For now, I can see one class for all things
having to do with putting stuff on the screen. Includes initializing
OpenGL and put up two windows on the screen. One is for the PPI display,
locate on the right hand side of the screen with margins for the sides of
the monitor. The A Scope is a smaller window on the center of the left
side of the display.
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
All inputs to either display will be performed in that class. Data fields
for the methods of that class should be put into a header file in the
headers directory.
The proposed maximum range is 15 miles.
Selectable ranges sould be 2, 5, 10, and 15 miles
Another class would be used to communicate with the raspberry pies that
will obtain data from the ais and ads-b software defined radios. This
is for purposes of adding targets. Marine radar can pick up low flying
targets plus I may (in the future) add an option for a vintage air traffic
control radar with precision approach radar, but not now.
The project will be implimented on on a Geekom A8 Max
with AMD AI chip R9-8945HS with 32 GB ram
Another class would be used for simulating targets, like for example
a sailboat regatta race.
The operating system is Linux (Ubuntu)
Details:
Classes:
Distributor ID: Ubuntu
Description: Ubuntu 25.10
Release: 25.10
Codename: questing
1. Anything to do with sending anything to the display. Needs to be on the
same thread as the main function
The compiler is cpp (Ubuntu 15.2.0-4ubuntu4) 15.2.0
2. Communications with outside sources; ais and ads-b for targets
We plan to use the cmake for building.
3. Operator controls
Here is the directory structure with files already installed:
4. Internal target simulation
./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
5. All of these have to use mutex for anything going into the display class
The followng classes would be needed:
There may be more classes TBD
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.
The platform is a Geekom GEEKOM A8 Max, AMD Ryzen 9 8945HS 5.2GHz 32GB RAM
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
Now here is the overall project and proposed architecture
3. Radar targets from receivers AIS, ADS-B, and UAT
This project is to simulate a period 1950 to 1960 marine radar with a crt p7
phosphor for the ppi scope and a p1 phosphor (this is oscilloscope phosphor)
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.
4. Simulated (fake) radar targets
The maximum range should be enough to cover the entirity of Bellingham bay
as seen from the dock of the Community Boating Center.
5. Any code needed to process topographical data for the shorline
Use one window with viewports covering the entire screen. For development,
F11 toggles fullscreen, Escape exits the program entirely.
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.
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.
I plan to have a variety of phony targets simulated in addition to
those received on uat, ads-b, and ais.
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):
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
x = (lon - origin_lon) * cos(origin_lat) * R
y = (lat - origin_lat) * R
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.
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.
Coordinates:
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.
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.
Notes for controls the user can play with
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
@@ -91,7 +175,7 @@ Here are the controls that I am proposing
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
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
@@ -101,7 +185,7 @@ Here are the controls that I am proposing
11. Will not need heading (this will be a fixed radar location for
the harbor master or lifeguard
12. Off-centering
13. Graticule brilliance
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)
@@ -117,7 +201,7 @@ 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.
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.
@@ -133,71 +217,11 @@ 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.
Shaders:
Each of the following is a separate shader set. Keeping them separate is
intentional for easier debugging — each layer can be disabled, modified,
or tested independently without affecting the others. At least the following shader sets
1. PPI targets, current, in white blue
2. clutter for rain, in white blue
3. clutter for waves, in white blue
4. graticule for PPI for bearing ticks, numbers, and range rings that
will change with range selection (text rendered via stb_truetype atlas)
5. Have operator switch graticules on the vintage a scope
Details for A scope (predecessor to the PPI scope)
The a scope will have pulse amplitude on the vertical axis and the range on the horizontal
axis. There will be a graticule for the a scope. This will show range markings. In the
day, the operator would physically change the graticule overlay. What we can do is to
electronically change the overlay and put a brief message saying operator changes
the graticule.
graticule lit with an equivalent color. Horizontal is range, vertical is strength
of the return blip. The phosphor of the A scope is green, similar to P1, which was
used on oscillosopes.
On vintage a scope, the operator changes the graticule when range is changed. Suggest
briefly display the message "operator inserts new graticule manually". If possible for
realism, have the old graticule move up and off the screen and then the new graticule move
onto and down the screen until it is in place, simulating the operator changing the
graticule.
There are as of now, no shaders nor any c++ files created yet
Details for PPI display:
Located on right hand of the screen. Put 1/2 inch margins on the right and top and bottom.
The PPI display will need shaders for the following:
1. Active radar target echos (blue white phosphor) Have different brighness for
size and blooming for larger sizes
2. Graticule (warm incandescent color, it was a plastic overlay lit with lamps. Does
not get included with persistant phosphor. Can change if the operator changes the
range. Have ticks for bearing; each degree. Every 10 degrees have a small text label, put these
outside the ring. No range rings for now. Have to figure out how that is done with vintage
radars. Perhaps you can suggest. Does operator have to change the plastic graticule when they
change the range?
3. facility to change clutter, rain and waves. Immediate is blue white same as targets
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. 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 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:
Communication:
All I know now is that I plan to use a combination of raspberry pi 4 and a Airspy
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
@@ -228,11 +252,28 @@ 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.
a different toolchain and dependencies. Do not mix it into this repository hierarchy
Initial development build (no hardware required):
NOTE on my plan for coding
1. All controls default to center values.
2. Five fake targets at random locations within radar range, moving randomly
at normal boat speeds, with variety of sizes.
3. Must run without the controls hardware and without the Raspberry Pi units.
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

279
new-claude Normal file
View File

@@ -0,0 +1,279 @@
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