0
#112
bold textEPISTLES // THE HELM
Planetary Navigation Array — Systems Report
Status: Operational development build
Scope: ORBIT · LAND · SEA navigation architecture
Core principle: MEASURE → COMPARE → DISAGREE → VERIFY → RESOLVE
1. Navigation Array
The Helm now has a unified navigation station rather than a collection of unrelated instruments.
The current stack incorporates the Planetary Navigation Array, Helm compass, Hawaiian compass, 360° chronometer/navigation bezel, field orientation instruments, independent navigation validation, path correction, existing GPS/solar navigation, and the existing interplanetary Mission Plot.
The architecture also preserves an important rule we established: a calculated correction does not rewrite the underlying observation.
Raw position, raw track, device heading, planned course, and correction solution remain conceptually separate.
⸻
2. Helm Compass
The primary Helm compass is operational with:
* 360° graduated scale
* emphasized 5°/10° divisions
* cardinal references
* 0.1° course resolution
* ±0.1°, ±1°, and ±10° controls
* reciprocal bearing
* course synchronization
* ORBIT / LAND / SEA mode integration
It provides the commanded/planned bearing, rather than pretending that commanded bearing is necessarily the vessel’s measured heading.
⸻
3. Hawaiian Compass
The existing Hawaiian navigation instrument has been integrated directly beneath the Helm compass.
It retains its original 32-point Hawaiian navigation system and its own 360° graduation rather than replacing the terminology with invented labels.
It is tied into the Helm course architecture, giving the station both conventional degree navigation and the existing Hawaiian directional representation.
⸻
4. Ship Clock / 360° Chronometer
The analog chronometer is substantially more than a clock.
It now contains:
* live analog time
* 360 individual degree divisions
* 5° and 10° emphasized divisions
* optional 1–360 labels
* inner Roman numeral clock scale
* local time
* UTC
* date/time-zone information
* 12/24-hour local display
* independent rotating navigation bezel
* fixed lubber/index reference
* fixed precision ring
* forward bearing
* reciprocal bearing
* touch/pointer rotation
* FREE / SYNC COURSE / LOCK modes
The rotating bezel was physically tested on the phone and confirmed to spin correctly.
⸻
5. Field Compass / Inclinometer
Block 4E installed successfully.
The field sensor suite includes:
* device heading
* heading-source identification
* pitch
* roll
* bubble level
* horizontal roll level
* vertical pitch level
* HOLD / SIGHT
* ZERO LEVEL
* BEZEL → HEADING
* iOS sensor-permission handling
Critically, it distinguishes a direct iOS compass heading from generic device orientation when possible.
That matters because display precision is not the same thing as measurement accuracy.
⸻
6. GPS / Solar NAV FIX
The original Helm NAV FIX remains intact and has become one of the independent evidence sources.
Live GPS acquisition has been demonstrated in the screenshots.
One observed fix showed approximately:
Latitude: 19.50043°
Longitude: −155.08277°
Horizontal reported accuracy: ±5 m
Altitude: roughly 480 m at that observation
The position changed slightly between fixes, which is expected behavior for real GNSS measurements rather than evidence of a perfectly stationary mathematical point.
NAV FIX also provides:
* Maidenhead grid
* altitude
* speed
* GPS course/heading when supplied
* fix age
* solar elevation
* solar azimuth
* sunrise
* sunset
* solar noon
* day length
The GPS watch explicitly requests high accuracy.
One distinction remains important: GPS accuracy describes horizontal position uncertainty, not heading accuracy.
And GPS course can legitimately be absent while stationary—as seen in testing.
⸻
7. Independent NAV Validation
The validation system is operational and deliberately avoids hidden sensor fusion.
It exposes independent evidence including:
* planned course
* device heading
* GPS track / course over ground
* heading disagreement
* GPS horizontal accuracy
* speed
* fix age
* sample count
* track spread
* validation state
The live test correctly reported:
GPS ONLY
when GPS existed but another suitable independent heading source was not available.
That is exactly the behavior we wanted. It did not manufacture a stronger confidence state simply because one sensor was producing data.
⸻
8. Path Correction / Route Intercept
This is one of the most significant additions.
A live GPS position can be captured as the route start, with a destination entered separately.
The system now calculates/displays:
* planned course
* distance to destination
* cross-track error
* path side
* GPS track
* intercept course
* direct-to-destination bearing
* rejoin distance
* path solution
Our controlled northbound test produced:
Start: 19.50043°, −155.08277°
Destination: 19.51043°, −155.08277°
Planned course: 0.0°
Distance: 1.11 km
Cross-track error: 0 m
Path side: ON PATH
Direct destination: 0.0°
Intercept: 0.0°
Rejoin distance: 50 m
Solution: ON ROUTE
Those values are mutually consistent for a destination placed directly north on essentially the same longitude.
⸻
9. Precision Great-Circle Rejoin
Block 4F-C3 installed successfully.
This extends path correction from simply pointing toward a destination to calculating a route-rejoin solution.
Most importantly, the correction remains advisory.
The interface explicitly states:
CORRECTION IS ADVISORY · RAW POSITION AND TRACK REMAIN UNCHANGED
That’s an excellent architectural property for this system.
A navigation solution should never secretly alter the measurement that was used to calculate it.
⸻
10. APPLY INTERCEPT Safety Behavior
This also behaved correctly during the test.
When APPLY INTERCEPT was invoked without an available Helm course-control endpoint, the system reported:
INTERCEPT READY · HELM CONTROL UNAVAILABLE
rather than falsely displaying that the command had been applied.
That is fail-visible behavior.
Once the state returned to the tested route, it correctly displayed:
ON ROUTE
Because that experiment had 0 m cross-track error, there was no meaningful corrective turn to execute.
⸻
11. CLEAR BOARD Architecture
The navigation workspace now has an intentional clearing concept rather than casual deletion.
Your requirement was particularly good here:
top confirmation + bottom clear, both double-tap, forcing the operator to inspect the board before intentionally wiping it.
The remaining weakness we discovered is different:
browser reload persistence.
A reload can still discard temporary route/session information. That’s not the same operation as CLEAR BOARD and ultimately shouldn’t behave like one.
So persistence is still a worthwhile future improvement.
⸻
12. Existing Mission Plot / ORBIT
We did not build a duplicate orbital calculator.
The Helm’s existing Mission Plot remains the ORBIT system and already contains substantial interplanetary functionality, including:
* origin/destination bodies
* departure date
* time of flight
* parking/capture altitude
* launch site calculations
* rotational velocity
* C3
* departure/arrival V∞
* phase
* arrival
* estimated ΔV
* DLA
* launch azimuth
* departure/capture ΔV
* entry velocity
* porkchop plotting
* launch-window searching
* next-three-window calculations
* round-trip planning
* mission verdict
That was the right architectural decision: integrate proven systems instead of cloning them.
⸻
What is demonstrated vs. what remains
The core instrumentation, live GPS acquisition, GPS/solar display, route plotting, straight-route mathematics, path state, rejoin fields, bezel operation, and defensive APPLY INTERCEPT behavior have all produced visible working results.
Some capabilities should still be treated as installed but not exhaustively field-validated, particularly device-heading accuracy under real-world magnetic conditions, sustained heading-vs-GPS disagreement sampling while moving, an actual off-route great-circle interception in the field, and complete bidirectional command synchronization among every instrument.
That distinction matters given the purpose of this project.
Remaining major phases
The strongest next developments are session persistence, a proper off-route field validation run, final Helm-command wiring, and then the real LAND/SEA mapping layer.
LAND can eventually add offline-capable maps, waypoints, route geometry, terrain and known-reference calibration.
SEA can build on the same navigation core with marine chart/seamark information, ports, buoys, lights, anchorages and AIS where appropriate—while retaining NOT FOR PRIMARY NAVIGATION unless the system and data actually meet the necessary standards.
⸻
Current assessment
The Helm has moved beyond a decorative sci-fi interface.
It now has the beginnings of a genuine multi-source navigation laboratory: it measures independent sources, preserves their raw values, exposes disagreement, calculates a route independently of the GPS observation, generates a correction without rewriting the evidence, and refuses to claim that a command was executed when the receiving control is unavailable.
That is exactly the architecture we want if the objective is not merely to display more numbers, but to make those numbers challenge one another.
Every measure counts. Disagreement is evidence. The raw observation survives the solution.
Planetary Navigation Array — Systems Report
Status: Operational development build
Scope: ORBIT · LAND · SEA navigation architecture
Core principle: MEASURE → COMPARE → DISAGREE → VERIFY → RESOLVE
1. Navigation Array
The Helm now has a unified navigation station rather than a collection of unrelated instruments.
The current stack incorporates the Planetary Navigation Array, Helm compass, Hawaiian compass, 360° chronometer/navigation bezel, field orientation instruments, independent navigation validation, path correction, existing GPS/solar navigation, and the existing interplanetary Mission Plot.
The architecture also preserves an important rule we established: a calculated correction does not rewrite the underlying observation.
Raw position, raw track, device heading, planned course, and correction solution remain conceptually separate.
⸻
2. Helm Compass
The primary Helm compass is operational with:
* 360° graduated scale
* emphasized 5°/10° divisions
* cardinal references
* 0.1° course resolution
* ±0.1°, ±1°, and ±10° controls
* reciprocal bearing
* course synchronization
* ORBIT / LAND / SEA mode integration
It provides the commanded/planned bearing, rather than pretending that commanded bearing is necessarily the vessel’s measured heading.
⸻
3. Hawaiian Compass
The existing Hawaiian navigation instrument has been integrated directly beneath the Helm compass.
It retains its original 32-point Hawaiian navigation system and its own 360° graduation rather than replacing the terminology with invented labels.
It is tied into the Helm course architecture, giving the station both conventional degree navigation and the existing Hawaiian directional representation.
⸻
4. Ship Clock / 360° Chronometer
The analog chronometer is substantially more than a clock.
It now contains:
* live analog time
* 360 individual degree divisions
* 5° and 10° emphasized divisions
* optional 1–360 labels
* inner Roman numeral clock scale
* local time
* UTC
* date/time-zone information
* 12/24-hour local display
* independent rotating navigation bezel
* fixed lubber/index reference
* fixed precision ring
* forward bearing
* reciprocal bearing
* touch/pointer rotation
* FREE / SYNC COURSE / LOCK modes
The rotating bezel was physically tested on the phone and confirmed to spin correctly.
⸻
5. Field Compass / Inclinometer
Block 4E installed successfully.
The field sensor suite includes:
* device heading
* heading-source identification
* pitch
* roll
* bubble level
* horizontal roll level
* vertical pitch level
* HOLD / SIGHT
* ZERO LEVEL
* BEZEL → HEADING
* iOS sensor-permission handling
Critically, it distinguishes a direct iOS compass heading from generic device orientation when possible.
That matters because display precision is not the same thing as measurement accuracy.
⸻
6. GPS / Solar NAV FIX
The original Helm NAV FIX remains intact and has become one of the independent evidence sources.
Live GPS acquisition has been demonstrated in the screenshots.
One observed fix showed approximately:
Latitude: 19.50043°
Longitude: −155.08277°
Horizontal reported accuracy: ±5 m
Altitude: roughly 480 m at that observation
The position changed slightly between fixes, which is expected behavior for real GNSS measurements rather than evidence of a perfectly stationary mathematical point.
NAV FIX also provides:
* Maidenhead grid
* altitude
* speed
* GPS course/heading when supplied
* fix age
* solar elevation
* solar azimuth
* sunrise
* sunset
* solar noon
* day length
The GPS watch explicitly requests high accuracy.
One distinction remains important: GPS accuracy describes horizontal position uncertainty, not heading accuracy.
And GPS course can legitimately be absent while stationary—as seen in testing.
⸻
7. Independent NAV Validation
The validation system is operational and deliberately avoids hidden sensor fusion.
It exposes independent evidence including:
* planned course
* device heading
* GPS track / course over ground
* heading disagreement
* GPS horizontal accuracy
* speed
* fix age
* sample count
* track spread
* validation state
The live test correctly reported:
GPS ONLY
when GPS existed but another suitable independent heading source was not available.
That is exactly the behavior we wanted. It did not manufacture a stronger confidence state simply because one sensor was producing data.
⸻
8. Path Correction / Route Intercept
This is one of the most significant additions.
A live GPS position can be captured as the route start, with a destination entered separately.
The system now calculates/displays:
* planned course
* distance to destination
* cross-track error
* path side
* GPS track
* intercept course
* direct-to-destination bearing
* rejoin distance
* path solution
Our controlled northbound test produced:
Start: 19.50043°, −155.08277°
Destination: 19.51043°, −155.08277°
Planned course: 0.0°
Distance: 1.11 km
Cross-track error: 0 m
Path side: ON PATH
Direct destination: 0.0°
Intercept: 0.0°
Rejoin distance: 50 m
Solution: ON ROUTE
Those values are mutually consistent for a destination placed directly north on essentially the same longitude.
⸻
9. Precision Great-Circle Rejoin
Block 4F-C3 installed successfully.
This extends path correction from simply pointing toward a destination to calculating a route-rejoin solution.
Most importantly, the correction remains advisory.
The interface explicitly states:
CORRECTION IS ADVISORY · RAW POSITION AND TRACK REMAIN UNCHANGED
That’s an excellent architectural property for this system.
A navigation solution should never secretly alter the measurement that was used to calculate it.
⸻
10. APPLY INTERCEPT Safety Behavior
This also behaved correctly during the test.
When APPLY INTERCEPT was invoked without an available Helm course-control endpoint, the system reported:
INTERCEPT READY · HELM CONTROL UNAVAILABLE
rather than falsely displaying that the command had been applied.
That is fail-visible behavior.
Once the state returned to the tested route, it correctly displayed:
ON ROUTE
Because that experiment had 0 m cross-track error, there was no meaningful corrective turn to execute.
⸻
11. CLEAR BOARD Architecture
The navigation workspace now has an intentional clearing concept rather than casual deletion.
Your requirement was particularly good here:
top confirmation + bottom clear, both double-tap, forcing the operator to inspect the board before intentionally wiping it.
The remaining weakness we discovered is different:
browser reload persistence.
A reload can still discard temporary route/session information. That’s not the same operation as CLEAR BOARD and ultimately shouldn’t behave like one.
So persistence is still a worthwhile future improvement.
⸻
12. Existing Mission Plot / ORBIT
We did not build a duplicate orbital calculator.
The Helm’s existing Mission Plot remains the ORBIT system and already contains substantial interplanetary functionality, including:
* origin/destination bodies
* departure date
* time of flight
* parking/capture altitude
* launch site calculations
* rotational velocity
* C3
* departure/arrival V∞
* phase
* arrival
* estimated ΔV
* DLA
* launch azimuth
* departure/capture ΔV
* entry velocity
* porkchop plotting
* launch-window searching
* next-three-window calculations
* round-trip planning
* mission verdict
That was the right architectural decision: integrate proven systems instead of cloning them.
⸻
What is demonstrated vs. what remains
The core instrumentation, live GPS acquisition, GPS/solar display, route plotting, straight-route mathematics, path state, rejoin fields, bezel operation, and defensive APPLY INTERCEPT behavior have all produced visible working results.
Some capabilities should still be treated as installed but not exhaustively field-validated, particularly device-heading accuracy under real-world magnetic conditions, sustained heading-vs-GPS disagreement sampling while moving, an actual off-route great-circle interception in the field, and complete bidirectional command synchronization among every instrument.
That distinction matters given the purpose of this project.
Remaining major phases
The strongest next developments are session persistence, a proper off-route field validation run, final Helm-command wiring, and then the real LAND/SEA mapping layer.
LAND can eventually add offline-capable maps, waypoints, route geometry, terrain and known-reference calibration.
SEA can build on the same navigation core with marine chart/seamark information, ports, buoys, lights, anchorages and AIS where appropriate—while retaining NOT FOR PRIMARY NAVIGATION unless the system and data actually meet the necessary standards.
⸻
Current assessment
The Helm has moved beyond a decorative sci-fi interface.
It now has the beginnings of a genuine multi-source navigation laboratory: it measures independent sources, preserves their raw values, exposes disagreement, calculates a route independently of the GPS observation, generates a correction without rewriting the evidence, and refuses to claim that a command was executed when the receiving control is unavailable.
That is exactly the architecture we want if the objective is not merely to display more numbers, but to make those numbers challenge one another.
Every measure counts. Disagreement is evidence. The raw observation survives the solution.