Adding more to CLAUDE
This commit is contained in:
55
CLAUDE.md
55
CLAUDE.md
@@ -31,8 +31,18 @@ control radar with precision approach radar, but not now.
|
||||
Another class would be used for simulating targets, like for example
|
||||
a sailboat regatta race.
|
||||
|
||||
The classes for communications and the simulating targets have not been
|
||||
defined yet.
|
||||
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
|
||||
|
||||
3. Operator controls
|
||||
|
||||
4. Internal target simulation
|
||||
|
||||
5. All of these have to use mutex for anything going into the display class
|
||||
|
||||
There may be more classes TBD
|
||||
|
||||
@@ -61,6 +71,14 @@ Here are the controls that I am proposing
|
||||
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)
|
||||
|
||||
|
||||
(Please suggest other controls I may have missed.)
|
||||
|
||||
@@ -77,6 +95,26 @@ 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
|
||||
be expensive, especially robust ones that kids cannot break.
|
||||
|
||||
Shaders:
|
||||
|
||||
Please read and suggest what different shaders set to be used for reliability
|
||||
and make approprate changes to this file. 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
|
||||
5. Have operator switch graticules on the vintage a scope
|
||||
6. Shoreline; tricky as shoreline has hills.
|
||||
7. This may be overkill, but something for notable buildings and docks. The
|
||||
curved south bay trail and taylor dock comes to mind, also the squalicum
|
||||
marina and the breakwaters.
|
||||
|
||||
|
||||
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
|
||||
@@ -90,8 +128,7 @@ graticule lit with an equivalent color. Horizontal is range, vertical is strengt
|
||||
of the return blip. The phosphor of the A scope is green, similar to P1, which was
|
||||
used on oscillosopes.
|
||||
|
||||
Please note that there will be two sets of shaders. Once for the actual trace and the
|
||||
other is used for the graticule. It will be used to change the graticule range and
|
||||
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
|
||||
@@ -121,5 +158,15 @@ The PPI display will need shaders for the following:
|
||||
|
||||
5. Persistance (green yellow) for targets, clutter, and shore lines.
|
||||
|
||||
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. I need comments on uat; does it need separate
|
||||
SDR and raspberry PI? I am hoping that each raspberry pi would act as a server to field
|
||||
requests from this program I plan to use a separate git repository and a CLAUDE.md of its own
|
||||
since the build is for a different architecture and its own CMakeFile.txt file. Any comments?
|
||||
Can I put the raspberry pi stuff in this same file heirarchy but with separate CMakeFile.txt,
|
||||
includes, etc.
|
||||
|
||||
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
|
||||
|
||||
Reference in New Issue
Block a user