294 lines
11 KiB
Markdown
294 lines
11 KiB
Markdown
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 implemented 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.
|
|
|
|
Note that directions shall be true, not magnetic
|
|
|
|
Note that shoreline data is from noaa maps
|
|
(NOAA provides free ENC (Electronic Nautical Chart) data in S-57 format covering
|
|
Bellingham Bay and surrounding waters.)
|
|
|
|
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 (also p7 greenish yellow 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
|
|
5. May consider fading small boats like kayaks
|
|
and sail bots above 3 miles
|
|
|
|
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.
|
|
|
|
Note on screen update vs pulse repition frequency. We need to be careful
|
|
since we have no control of the display update frequency and need
|
|
to do whatever is needed to reduce aliasing or flickering
|
|
|
|
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. astigmatism
|
|
4. Range selection (for both a scope and ppi scope)
|
|
5. Sensitivity
|
|
6. Sensitivity time control STC / sea clutter
|
|
7. There is some sort of control having to do with the magnetron
|
|
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. FTC / Rain Clutter
|
|
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)
|
|
16. Pulse repition frequency
|
|
|
|
|
|
(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.
|
|
Prefer TCP.
|
|
|
|
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 missing.
|
|
DO NOT GENERATE CODE
|