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

move back to get rid of code

Browse Source
This commit is contained in:
Mark Allyn
2026-05-21 20:40:26 -07:00
parent 65348fd596
commit 0cc2a4a4e4
5 changed files with 0 additions and 2010 deletions
Download Patch File Download Diff File Expand all files Collapse all files

145
DESIGN.md
View File

@@ -1,145 +0,0 @@
# Radar Exhibit — Design Document
## Hardware target
- Geekom A8 Max: AMD Ryzen 9 8945HS, Radeon 780M (Mesa/RADV), 32 GB RAM
- Ubuntu 25.10, g++ 15.2.0, C++20, OpenGL 4.3 Core
---
## Screen layout
Three fixed regions rendered with `glViewport` + `glScissor`:
| Region | Content |
|--------|---------|
| Left panel | Text description, control list (white text; red labels; pink keystrokes) |
| Right panel — upper | Radar scope |
| Right panel — lower | Status bar: range, bearing, scope ID (yellow text) |
---
## Scope sequence (cycled with keys 1 / 2)
1. Exhibit introduction (text only)
2. Chain Home A-Scope (1940s)
3. Marine A-Scope (1940s)
4. PPI — stationary marine traffic control
5. PPI — on-board boat
Each scope's control state is **independent** and **resets on re-entry**.
---
## Radar equation
$$P_r = \frac{P_t G^2 \lambda^2 \sigma}{(4\pi)^3 R^4}$$
Signal strength falls off with $1/R^4$. Each radar type has fixed hardware loop gain baked into its shader set as a constant.
---
## Controls (keyboard until physical panel is built)
| Key | Action |
|-----|--------|
| 1 / 2 | Next / previous scope |
| 3 / 4 | Intensity down / up |
| 5 / 6 | Receiver sensitivity down / up |
| q / w | STC sensitivity down / up |
| e / r | STC range down / up |
| t / y | Radiogoniometer left / right (Chain Home only) |
| u / i | Max range down / up (all except Chain Home) |
| o / p | Range cursor down / up (PPI only) |
| a / s | Bearing cursor CCW / CW (PPI only) |
| d / f | Antenna bearing CCW / CW (Marine A-Scope only) |
Notes:
- Radiogoniometer, marine antenna bearing, and PPI bearing cursor share one physical knob on the eventual panel; kept separate in software.
- Range cursor ≠ max range: max range is the radar's selected range setting; range cursor is the measurement cursor on the PPI display.
---
## Scope specifications
### Chain Home A-Scope
- Fixed range: 200 miles
- No graticule; crystal-oscillator range pips every 20 miles (operator cannot change)
- Bearing via radiogoniometer simulation: operator finds null point; bearing shown as text below scope
- Two perpendicular antenna sets (N-S, E-W); radiogoniometer angle determines which target pip goes to null
### Marine A-Scope
- Ranges: 1.5 / 3.0 / 6.0 / 12.0 miles
- Range pips: every 0.25 / 0.5 / 1.0 / 2.0 miles respectively (fixed oscillator; not affected by range setting)
- No graticule
- Bearing by rotating simulated dish/horn antenna (d/f keys)
- Pip shape: finite rise, fixed-width pulse, finite fall — curved waveform, not a vertical line
### PPI scopes (both)
- 360° sweep with phosphor persistence via FBO (semi-transparent black quad each frame; no full clear)
- Range cursor and bearing cursor overlay
#### Stationary (marine traffic control)
- Fixed observer position; targets move relative to scope center
#### On-boat
- Observer is scope center; heading-up display — world rotates as boat heading changes
- Boat position/heading supplied from GDAL/PostgreSQL data
---
## Architecture
### Class hierarchy (State pattern)
```
BaseScope — intensity, sensitivity, STC vars, virtual render/update
├── AScope — horizontal sweep, curved pip waveform
│ ├── ChainHomeScope — radiogoniometer, fixed 200 mi range, 20 mi pips
│ └── MarineAScope — antenna bearing knob, 4 range settings
└── PPIScope — 360° sweep, FBO persistence, range/bearing cursors
├── StationaryPPI
└── OnBoatPPI — heading offset passed into shader
```
### Threading model
| Thread | Responsibility |
|--------|---------------|
| Render (main) | OpenGL loop, GLFW input, all `glDraw*` calls — never blocks |
| Simulation | Polls `target_data` (PostgreSQL) and GDAL; updates shared `std::vector<Target>` under `std::mutex` |
### FBO phosphor decay
- Render sweep into FBO each frame
- Blit FBO to screen
- Do **not** clear color buffer between frames; draw full-screen quad at very low alpha (~0.05) to decay old sweeps
### Shader notes
- GL_DEBUG_OUTPUT + `glDebugMessageCallback` enabled at startup (GPU robustness protocol)
- No NVIDIA-specific extensions; Mesa/RADV only
- $1/R^4$ attenuation computed in fragment shader; hardware loop gain is a per-scope `uniform` constant
---
## File structure
```
new-radar/
├── CMakeLists.txt
├── src/ — .cpp source files
├── include/ — .h/.hpp headers
│ ├── glad/
│ └── KHR/
├── glad/src/ — glad.c (bundled)
├── shaders/ — .vert / .frag files
├── data/ — patrol_route.json, etc.
└── map/
├── charts_enc/ — ENC .000 and GeoTIFF files
└── lidar_raw/ — LIDAR zips
```
---
## Database
- PostgreSQL, database `radar`, user `radar`, password `radar`
- Table `target_data`: polled by simulation thread for live target positions

0
build_progress.md
View File

1733
claude.save
View File

File diff suppressed because it is too large Load Diff

80
possible-claude.md-changes
View File

@@ -1,80 +0,0 @@
Implementation: Use a Frame Buffer Object (FBO). Instead of clearing the screen each frame, draw a full-screen quad with a very low alpha (e.g., 0.95) to slowly "dim" previous sweeps.
Threading for PostgreSQL and LIDAR
Reading from PostgreSQL (targets) and GDAL (LIDAR terrain) can cause "micro-stuttering" if done on the main render thread.
The Simulation Thread: Create a background thread that polls the target_data table and updates a thread-safe std::vector<Target>.
The Render Thread: The OpenGL loop should simply read the latest target positions and render them at 60 FPS (or higher) to keep the "sweep" of the PPI radar smooth.
Class Hierarchy and PPI SpecificsSince you have four distinct scopes (Chain Home A-Scope, Marine A-Scope, Stationary PPI, and On-boat PPI), a State Pattern is ideal.BaseScope Class: Handles the universal Intensity and Sensitivity variables.AScope Subclass: Implements the horizontal sweep and the "curved waveform" logic for the marine version.PPIScope Subclass: Implements the $360^\circ$ rotation logic. For the "On-boat" version, you will need to pass the boat's own GPS/Heading coordinates (from GDAL/LIDAR) into the shader to offset the target positions.
Deepseek:
Mathematical Logic vs. Contextual UnderstandingDeepSeek's Strength: DeepSeek is often more "aggressive" with mathematical optimization. It will likely give you very efficient GLSL code for the $1/R^4$ calculations.The "DeepSeek.md" file: You should rename your instructions to DEEPSEEK.md. DeepSeek models are trained to look for specific instructions in the root directory, similar to how Claude looks for CLAUDE.md.
Explicit Hardware Prompting
While Claude is currently aware of the AMD Radeon 780M and Ubuntu 25.10 nuances through our conversation, DeepSeek may require more explicit "reminders" about:
Mesa Drivers: Remind it to avoid vendor-specific (NVIDIA) extensions.
C++20 Strictness: DeepSeek sometimes defaults to older C++ standards; ensure your CMakeLists.txt is the first thing it reviews to lock it into your C++20 requirement.
Coding Style Enforcement
DeepSeek is generally good at following style guides, but it can be "talkative." You may need to add a directive:
"Provide code only. Do not explain standard C++ features unless they relate directly to the OpenGL 4.3 Core specification or the Geekom A8 Max hardware."
Suggested Additions to your .md file
To help either AI (Claude or DeepSeek) write better code for the PPI scopes, I recommend adding these details to your file:
PPI Rotation Speed: Specify the "RPM" for the marine traffic control (e.g., 12-24 RPM).
The "North-Up" vs "Head-Up" display: For the on-boat radar, will the display rotate as the boat turns (Head-Up), or will "North" always be at the top?
LIDAR Resolution: Define how many LIDAR data points should be converted into "clutter" on the radar screen.
This setup on your Geekom A8 Max should provide plenty of power to handle both the PostgreSQL queries and the complex OpenGL fragments required for a realistic "vintage" look.
Proposed Addition: > [THREADING MODEL]
Main/Render Thread: Handles the OpenGL loop, GLFW input, and glDraw calls. It must remain non-blocking to ensure a smooth 60 FPS sweep.
Simulation/Data Thread: A background thread that polls the target_data table and updates a thread-safe shared state (using std::mutex or atomics) for the Render thread to consume.
The PPI Scope Particulars
Since you are ready to define the two PPI modes (Stationary and On-Boat), adding these "Rules of Behavior" will prevent the AI from guessing.
Proposed Addition:
[PPI SCOPE SPECIFICS]
Persistence (Phosphor Decay): Implement using a Frame Buffer Object (FBO). Do not clear the color buffer every frame; instead, draw a semi-transparent black quad to simulate 1940s-60s CRT decay.
Marine Traffic Control (Stationary): Fixed location. Targets move relative to the center of the scope.
Police Boat (On-Boat): The center of the scope is the boat. Integrate boat heading (heading-up display) so the "world" rotates around the observer as the boat turns.
File Structure & CMake Prep
To make the two-step CMakeLists.txt generation easier, add a section for organization.
Proposed Addition:
[PROJECT STRUCTURE]
/src: All .cpp source files.
/include: All .hpp header files.
/shaders: External .glsl files for vertex and fragment shaders.
/data: Location for GDAL LIDAR and ENC chart files.
pdated Logic for DeepSeek/Claude SelectionOnce you add these, the transition will be seamless:Claude will be better at setting up the Class Hierarchy (the BaseScope and its derivatives) because it follows the "System Engineer" logic of your persona very well.DeepSeek will be excellent if you need to optimize the GLSL Shaders for the $1/R^4$ logic or the GDAL coordinate transformations, as it tends to be very mathematically rigorous.How to proceed:Go ahead and update your CLAUDE.md with these details. Once you're ready, paste the updated content here (or just tell me it's done), and we can generate that Foundation CMakeLists.txt to get your Geekom A8 Max environment ready for the first "Hello Radar" sweep.

52
sec-stuff
View File

@@ -1,52 +0,0 @@
LOcked key method on backup linode
from="PROD_IP_HERE",command="/usr/local/bin/run-backup.sh",no-agent-forwarding,no-port-forwarding,no-X11-forwarding,no-pty ssh-rsa AAAAB3... (rest of your key)
Create a simple script at /usr/local/bin/run-backup.sh on the backup machine:
#!/bin/bash
# 1. Sync the Gitea Database (assuming it was dumped to a file)
# 2. Re-run the Git Clone/Pull for your radar & website projects
cd /path/to/backup/folder
git pull origin main || git clone http://your-gitea-url/repo.git .
# Optional: Log the backup time
echo "Backup successful: $(date)" >> /var/log/backup_history.log
from="PROD_IP",command="/usr/share/doc/rsync/scripts/rrsync -ro /mnt/backups/ilovearthur/",restrict ssh-rsa AAAAB3...
#!/bin/bash
# Sync critical system and user data
rsync -az --delete /etc /var /home root@backup.ilovearthur.org:/
Wrapper script on backup server
#!/bin/bash
case "$SSH_ORIGINAL_COMMAND" in
rsync*)
# Allows rsync to only touch the designated backup folder
$SSH_ORIGINAL_COMMAND
;;
"git-sync")
# Custom command to refresh your Gitea mirrors
cd /home/backups/radar-repo
git pull || git clone http://your-gitea-url/repo.git .
;;
*)
echo "Access Denied: Command not permitted."
exit 1
;;
esac
Authorized keys file:
from="PROD_IP",command="/usr/local/bin/backup-handler.sh",no-agent-forwarding,no-port-forwarding,no-pty ssh-rsa AAAAB3...
from="192.0.2.1,2001:db8::1",command="/usr/local/bin/backup-handler.sh",no-pty ... [your-ssh-key]