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

Change traffic cop operation and dynamic data

Browse Source
This commit is contained in:
Mark Allyn
2026-05-31 19:58:04 -07:00
parent f79d70de9f
commit 353303c5c1
1 changed files with 70 additions and 83 deletions
Download Patch File Download Diff File Expand all files Collapse all files

153
CLAUDE.md
View File

@@ -131,9 +131,9 @@ struct target_data_structure {
uint32_t mmsi; // AIS unique identifier; ICAO hex address for aircraft
float course; // course over ground, degrees, based on true north
float speed; // speed over ground, knots
time_t timestamp; // time of last fix; used to age out stale targets
float altitude; // meters, but 0 for boats
int type; // type of target; vessel or aircraft; 0 = vessel
time_t timestamp;
};
Of this heavy structure, only the following lean mathematical footprint is submitted
@@ -996,22 +996,20 @@ Here is the data items for the table in the Postgres database:
1. float length
2. float beam
3. int32_t material - 1 for metal, 2 for wood, 3 for fiberglass
4. time_t timestamp - use to check to see if this has already been processed
5. int32_t may_need_update (this if a randome value is applied to any part of the target
4. int32_t may_need_update (this if a randome value is applied to any part of the target
and that the user may want to update the database. This
will not force the user to do the update, a later
database editing program will use this.
6. int vessel_type (AIS type code or aircraft type)
7. uint32_t mmsi (unique identification for boat or ICAL for aircraft
8. float reflectivity (derived from target type)
9. float height_estimate (derived from target type)
10. float noiseglint (derived from target type_
11. int32_t police_boat (this indicates that this is for the police boat - 1 is true)
5. int vessel_type (AIS type code or aircraft type)
6. uint32_t mmsi (unique identification for boat or ICAL for aircraft
7. float reflectivity (derived from target type)
8. float height_estimate (derived from target type)
9. float noiseglint (derived from target type_
10. int32_t police_boat (this indicates that this is for the police boat - 1 is true)
Please note that this database is only for the physical characteristics. Dynamic
information which is created by the simulator (or raspberry pis) as that data changes.
Please also note that the handling for the police boat's cruising around Bellingham Bay
will also be part of the job of the simulator. This is achieved by having an indicator
in the target data, labeled police_boat, which is a binary value. True means that this
@@ -1076,22 +1074,71 @@ Data synchronization between threads must be managed explicitly using std::mutex
Among its duties are to manage the database.
New targets (which have not ever been introduced to this system will be added to the
database. The purpose of the database is to remember physical characteristics of targets;
ie; the stuff that is not dynamic to the movement of the target.
The database will be maintained for the life of the exhibit. So targets that were in the database
when the exhibit will still be there when the exhibit is powered back on.
This is to save processing time for stuff such as reflectivity.
In addition to the postgress database, there will be two active target tables within memory.
Those tables will have a fixed size of 300 elements.
As target data is read from the database, it will also be copied to an in-memory copy
of the database so that processing can be more efficent. The maximum size of the in-memory
copy shall be limited to 200 targets. If the number of targets gets larger than 200 targets, the
targets that have not been updated for the longest time shall be overwritten by new targets.
Judging from the current traffic of bellingham bay, 200 targets for the caching memory copy of
the database should be enough.
There will be one table for Bellingham Bay for the marine a scope, the marine traffic control
radar, and the police boat radar. This shall be called memory-bellingham-bay
As you may notice, height and material have not been including in the table of data we get from
the simulator nor the raspberry pis taking in the ais and ads-b data from the sdr's. Those values
have to be derived by the traffic cop and then entered into the database.
The other table will be for the chain home radar, which is centered on RAF Ventnor
(Isle Of Wight) This shall be called memory-ventnor
These tables are for holding the active data. Data shall be active unless there is
no update from the raspberry pis nor the simulator for 1 hour. Essentially these
tables are for all living data. The postgress database will be used only once for each
target while the exhibit is running. Database access will become fewer the longer the
exhibit has been running.
Those tables will have the same format (which is sent to the shaders):
struct target_data_to_shader_structure {
float target_x; // Pre-converted local Cartesian offset X (meters relative to radar)
float target_y; // Pre-converted local Cartesian offset Y (meters relative to radar)
float length; // Vessel length bounds (meters)
float beam; // Vessel beam bounds (meters)
float course; // Course over ground vector (radians relative to True North)
float altitude; // Target altitude profile (meters = 0 for boats)
time_t timestamp; // Data aging tracking identifier
float reflectivity; // derivied from vessel_type (see table below)
float height_estimate; // derived from vessel_type (see table below)
float noiseglint; // derived from vessel_type (see table below)
int32_t police_boat; // this indicates that the target is for the roaming police boat. 1 = police boat
int type; // target type (0 for boat 1 for aircraft)
time_t timestamp; // time of last fix; used to age out stale targets
};
Target Processing suggestion:
1. Determing which radar is in operation
2. Receive target information from simulator or raspberry pi.
3. Is target already in the memory table for the current radar in use
(memory-bellingham-bay for marine a-scope, marine traffic control ppi, and marine police boat)
(memory-ventnor for chain home)
3a: Yes, replace location, course, altitude, timestamp, police_boat into the memory table;
leave all other data alone
3b: No, initialize new entry for memory data. Bring over location, course, altitude,
timestamp, police_boat
3c: Is this target in the postgres data base?
3c1: no - Create database entry. Perform calculation for reflectivity as noted below
based on vessel_type, length, type, and beam from the target data structure
from the simulator data or raspberry pi data; and then bring over lengh, beam,
altitude, police_boat from the target data structure
3c2: yes - bring over, from database, followng: location, length, beam, course, altitude,
timestamp, reflectivity, height_estimate, noiseglint, timestamea to the memory
table.
3. After all incoming targets processed, wait for next update cycle,
assert mutex, and pass the table to cpu thread 1 to pass onto the shaders.
4. Update cycles shall be 1/25 seconds for chain home and 30 microseconds for the ppi
scopes.
Suggested code for deriving target height, reflectivity, and noiseGlint when target is not
in the database
Here is sample code for doing this; this is suggestion only.
@@ -1151,66 +1198,6 @@ glUniform1f(glGetUniformLocation(shaderProgram, "targetReflectivity[i]"), dynami
but is not written to the database. It is to be passed to the shaders as a uniform.
The segment handling asynchronous target ingestion is called traffic_cop.
The traffic_cop runs on a dedicated background execution thread separate from the rendering loop.
Data synchronization between threads must be managed explicitly using std::mutex blocks.
[TRAFFIC COP OPERATIONAL TIMING PROTOCOL]
1. Processing Loop: Aggregated targets are packaged into a uniform array and dispatched
as they arrive to the traffic cop from the simulator or the receiver handling the raspberry pis.
2. Range Filtering: Discard any targets residing outside the active radar's
designated maximum operational range. Apply this if active radar is not Chain Home. Do not apply
if this is for Chain Home
3. Altitude Restriction: Enforce a strict <= 40-meter restriction for marine nodes (Marine A-scope
and all PPI Marine radars). Discard any aircraft violating this ceiling. Do not apply this
restriction if the active radar is Chain Home.
4. Precision Alignment: Latitude and longitude coordinate conversions into local meters relative to
the radar origin must be handled on the CPU thread within traffic_cop
to protect against FP32 structural precision rounding errors inside the GPU.
5. The determination of the reflectivity, height estimate, and the noiseglint must
be processed by the traffic cop
6. The traffic cop needs to know the longitude and latitude of the chain home ascope, the marine ascope,
and the marine traffic control radars. It will already have the longitude and latitude of the
police boat radar as it will be processing the location of the police boat radar from the
simulator.
7. Instructions regarding chain home. If the current active radar is chain home, we
need to drop all boat target and any target that is not within 300 miles from the
latitude and longitude of the chain home radar station. Furthermore all traffic from the
raspberry PI's need to be discarded for chain home. All chain home target traffic will be
beyond range for all of the other radars; therefore all such targets shall be discarded if
the active radar is not chain home.
8. Critical Section: Assert a std::mutex to gain safe writing access to the
double-buffered array driving the SSBO, copy the structural contents, and
clear the mutex immediately. May I suggest that this activity be performed
about once every screen update. However, the processing speed may not be
able to achieve this. Also bear in mind that data from the raspberry pis
and the simulator may not updata every screen update. If that's the case, the
traffic cop will not do anything. Also note that the SSBO maximum target capability
will be 200. Oldest targets shall not be sent to the SSBO if the limit is reached.
Lets include the maximum in memory copy of the database and SSBO should be
a value in the settings.h file.
9. The traffic cop does need to check the variable that had which radar is active.
This can be accomplished by seting an additionall mutex strictly for reading the
active radar variable from thread 1.
10. If the timestamp in the database is over 1 hour from the current time, then
the target shall be skipped.
11. If police_boat == 1, then use uniforms to pass heading and location. Do not pass target data as the
police boat does not see itself. If police_boat == 0, then treat the police boat as any other target.
Here is the database workflow.
1. Receive target from simulator or raspberry pis
2. Is target in the memmory copy of the database
3. Yes - then update the timestamp
4. If not in memory, the try to pull from the database
4a. If memory is already full, then delete record with oldest timestamp.
4b. The do the pull from the database.
5. If pulled from database, then update the timestamp.
6. If it cannot be pulled from the database, then enter
net target into the database and memory copy. Then do
the calculations for RadarMaterialProfile, then pull
in other non vilitile target data (size, beam, etc)