@meri-imperiumi/signalk-dead-reckoning 0.13.3 → 0.14.0

package/CHANGELOG.md

@@ -7,6 +7,23 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [0.14.0] - 2026-10-18
+
+### Added
+- **The DR webapp hosts chart layers: plotter-extension map overlays (work doc #27, chart-layer phase).** The webapp's plotter-extension host — so far widgets and panels only — gains the surface a map layer needs, with [signalk-livedepth-plugin](https://github.com/night199uk/signalk-livedepth-plugin) as the first consumer: soundings recorded by the LiveDepth plugin draw as a shaded, isobath-contoured depth surface on the DR chart, live-extended while sailing. New host capabilities: `background.iframe` (headless 1×1 sandboxed iframes running extension runtimes off-viewport, torn down with the extension), `overlays.image` (the `overlay.request` → `overlay.frame` cycle — the host sends the viewport's EPSG:3857 extent, bounds, pixel ratio clamped to the overlay's `preferredPixelRatio`, resolution, zoom and `liveInterval`; the runtime answers with a transferred `ImageBitmap` the host composites into a pane above the charts and below the chartwork/vessel, refusing `overlays.superseded` frames and pacing live ones at `overlays.throttled`; frames stay georeferenced through panning via their own extent, and world copies on either side of the antimeridian are covered), `map` (`map.getView`/`map.center`/`map.fitBounds` plus settled `map.view` events), `units` (`units.get` with the preferred depth unit, default `m`), and `buttons` (`mapToolbar` entries rendered into a stack above the bottom-left controls, toggling panels). Layer affordances: a ▤ **Plugin layers** control opens a dialog with per-layer show/hide, opacity, and the layer's settings panel (`configPanel`) — layer state persists in `dr.plotterext.overlays.v1` like the chart layers' own prefs, extensions' `state.get/set`/`state.changed` storage shared with their settings panel, and `events.publish` routing (scope `all`/`extension`). The vendored `signalk-plotterext-bus` moves 0.11.0 → 0.21.0 for the `overlay.*` and `map.view` wire surface (0.12–0.18 lack it). Nothing is needed server-side: LiveDepth registers its own `plotterExtensions` provider, and the host discovers it through the same collection polling; the same `overlays.image` surface is what a future radar-overlay provider would plug into for DR fixes.
+
+### Fixed
+- **The GPS/override bar no longer sits in the middle of a phone screen** (`public/dr-ext-host.js`): on the ≤600 px phone layout the top band stacks vertically, and every `<dr-ext-widget-area>` reserves its full 2×2 widget footprint even while empty — so the empty top-left area inflated the tools column to ~323 px and pushed the GPS status + Engage OVERRIDE panel down to y≈337 of an 844 px viewport, mid-screen. The reservation exists only for the chart context-menu placement hit-test, so it now collapses inside the area's own phone media query; a placed grid still sizes itself through its rows, and placement simply isn't offered on an empty phone area. Phone top band drops from ~656 px to ~260 px with the GPS bar back at the top. `doc/dr-mobile.png` regenerated with the fixed layout.
+
+### Changed
+- **Passage replay gains a blind variant — the GPS-loss backtest the tier-2 circularity demanded** (`tools/replay-passage.js`): the derived tier-2 current is fitted to the very GPS track a replay scores against, so "derived beats everything" over a fully-GPS-fed passage is a tautology, not a result. The new `--blind-from ISO` variant simulates the actual use case — GPS dies mid-passage: fixes stop feeding the derived-current state at the cutoff while snapshots keep being taken, so the shadow boat navigates on the carried EWMA current decaying at its 24 h time constant and lapsing to tier 5 after the TTL, with divergence still scored against the hidden GPS track. First blind run on the Niue→Vava'u passage (2026-09-11→14, 253 nm, GPS lost at hour 24 of 60): DR stayed within ~10 nm of truth through the entire 24 h carry window, then degraded at ~1 nm/h once the current support vanished — 22.5 nm final vs 10.0 nm with GPS live and 38.2 nm cold. Also fixed on the way: the derived-current provider returned no `tier` field, so the §6.2 training gate read every tick as unresolved and the learning variant silently never trained (0 matrix bins, learn ≡ derived); it now stamps `tier: 2`, the leeway-synthetic test's threshold is recalibrated to the post-gate semantics (the old bound was met by the current, not by learning), and the `scudLearn` variant is vestigial by design — the gate deliberately blocks training on model currents.
+
+## [0.13.4] - 2026-10-16
+
+### Added
+- **Horizontal sextant angle fixes: the compass-free three-point fix (work doc #35).** The sight panel gains an **H. Angle** tab: measure the horizontal angle between two charted objects with the sextant, and the inscribed-angle circle of position through both objects is derived against the current DR position (the mirror-image circle ambiguity resolves by which circle actually passes near the boat); a second angle to a third object resolves the classic three-point fix directly. One angle alone combines with any bearing, range, or celestial LOP through the pending list as before. The chart pick menu gains "Horizontal angle at…" — successive picks fill the form's object slots A → B → C. Degenerate inputs (angles beyond 0.5–179.5°, coincident objects, missing DR) refuse with navigator-facing messages instead of producing planet-sized circles. The measured angle is stored raw (`raw_angle_deg`) for backtesting, and observations log to the vessel's logbook through the `logentries` resource provider ("Lighthouse / Tower horizontal angle 45.5°").
+- **Radar fixes: radar range and radar-bearing observations (work doc #33).** Radar is the one ranging instrument on a typical boat that does not depend on GNSS, and the MCA's GNSS-resilience guidance (Note 719) names radar fixing among the practices to maintain. The sight panel gains a **Radar** tab — object name, measured range in NM, the shared sight-time/stopwatch entry, and a chart-pick-pre-filled object position — posting a `radar-range` circular position line; the chart pick menu gains "Radar range at…" alongside the bearing and distance-CPL entries (works on AIS targets too, with a note that a target's position is itself GNSS-derived — charted fixed objects are the spoof-resistant choice). The bearing form gains an **instrument** selector (hand compass / radar): a radar-derived bearing is stored as a `radar-bearing` LOP — identical geometry (a ray to the object, enforced by the resolver's observer-ray guard) with instrument provenance. Radar ranges carry a range-proportional error model: the default uncertainty is the larger of `radarRangeErrorPct`% of the measured range (default 1.5, schema-configurable) and an absolute floor (default 20 m), applied server-side when the client doesn't supply its own estimate; range + bearing to the same object at the same timestamp resolve through the pending list as the classic two-instrument radar fix. Radar ranges log to the vessel's logbook through the `logentries` resource provider as observations ("Cape Rocks radar range 4.2 NM"), and radar entries edit in the radar tab like the other observation types.
+
 ## [0.13.3] - 2026-10-15
 
 ### Changed

package/README.md

@@ -1,14 +1,19 @@
 # Signal K Dead Reckoning
 
-An offline-first dead reckoning and sensor fusion engine for Signal K that maintains a continuously computed "shadow boat" position from water-track sensors (speed through water, compass heading, and learned leeway and current corrections), so you always have a navigational fallback when GPS becomes unreliable — whether from jamming, spoofing, or plain receiver failure. While GPS is trusted, the engine learns vessel-specific calibration corrections against ground truth and watches for GPS anomalies; when it isn't, the same learned model keeps the dead-reckoned position, its uncertainty polygon, and a water-track log going. Fixes from celestial sights, compass bearings, and vertical angles are entered through a unified pipeline and can snap dead reckoning back on track, with optional write-through to `signalk-logbook`.
+An offline-first dead reckoning and sensor fusion engine for Signal K that maintains a continuously computed "shadow boat" position from water-track sensors (speed through water, compass heading, and learned leeway and current corrections), so you always have a navigational fallback when GPS becomes unreliable — whether from jamming, spoofing, or plain receiver failure. While GPS is trusted, the engine learns vessel-specific calibration corrections against ground truth and watches for GPS anomalies; when it isn't, the same learned model keeps the dead-reckoned position, its uncertainty polygon, and a water-track log going. Fixes from celestial sights, compass bearings, radar ranges, vertical angles, and horizontal sextant angles are entered through a unified pipeline and can snap dead reckoning back on track, with optional write-through to the vessel's logbook (any Signal K `logentries` resource provider, such as `signalk-logbook`).
 
 **Note:** This is just a toy. Make your own navigation calculations and decisions.
 
+## Why
+
+Planning for life without GPS is no longer hypothetical: the UK Maritime and Coastguard Agency's [Guidance Note 719](https://www.gov.uk/government/publications/mgn-719-mf-operating-in-gnss-denied-and-degraded-environments/mgn-719-mf-operating-in-gnss-denied-and-degraded-environments) ([reported by Yachting Monthly](https://www.yachtingmonthly.com/news/mca-tells-maritime-sector-to-plan-for-life-without-gps-106566), 1 Oct 2026) reports a marked increase in GNSS jamming and spoofing worldwide and asks mariners to review contingency arrangements, maintain resilient navigation practices, and practice navigating without satellite positioning — naming dead reckoning, visual bearings, and celestial fixing as valid methods. This plugin implements a contingency for Signal K vessels.
+
 ## Requirements
 
 * This plugin installed and configured
 * Some chart source available to Signal K
 * Hand bearing compass and/or sextant
+* A heading source independent of GNSS — a fluxgate or inertial compass feeding `navigation.headingMagnetic`, not a satellite (GNSS) compass. A satellite compass shares the jamming and spoofing failure mode of the position fix, so a vessel whose only heading source is satellite-derived cannot dead-reckon through GNSS denial. Be careful checking this: on N2K networks a single physical device often provides both compass and position data, and display list entries do not necessarily reflect that (a device may publish both PGN 127257 heading and PGN 129029 position under one source)
 
 ## Getting started
 
@@ -19,7 +24,7 @@ An offline-first dead reckoning and sensor fusion engine for Signal K that maint
    * Wind data — used by the calibration model and the polar speed fallback
 3. Just sail. While GPS is reliable and you're under sail (propulsion stopped), the engine continuously learns vessel-specific leeway and speed-loss corrections against GPS ground truth. There is nothing to activate: the "shadow boat" runs at all times, and the uncertainty polygon tightens over a season as the calibration bins fill up. Early on, expect conservative uncertainty estimates.
 4. Optional integrations, configured in the plugin settings:
-   * `signalk-logbook` — write confirmed fixes and maneuvers to the vessel's logbook
+   * `signalk-logbook` (or any other `logentries` resource provider) — writes confirmed fixes and maneuvers to the vessel's logbook
    * `signalk-polar-performance-plugin` — polar-derived speed when the paddlewheel is fouled or silent
    * `@meri-imperiumi/signalk-autostate` — keeps the navigation state (anchored, sailing, motoring) accurate, which gates training
    * Signal K Weather API — point-forecast current vectors for the DR solution
@@ -30,8 +35,10 @@ Open the webapp from your Signal K server's *Web apps* menu. It shows the vessel
 
 **Entering fixes.** Open *⊕ Sight / LOP* and pick the method:
 
-* **Bearing** — compass bearing to a known object (lighthouse, tower) gives a line of position
+* **Bearing** — bearing to a known object (lighthouse, tower) gives a line of position; the instrument selector records whether it came from a hand-bearing compass or the radar
 * **Vert. Angle** — vertical angle to a known object of known height gives a circular position line
+* **Radar** — range to a known object gives a circular position line — the one ranging instrument that does not depend on GNSS. Range + bearing to the same object is the classic two-instrument radar fix. A range to an AIS target rests on the target's own GNSS-derived position, so under suspected interference prefer charted fixed objects
+* **H. Angle** — horizontal sextant angle between two charted objects gives a circle of position with no compass involved; a second angle to a third object gives the classic three-point fix
 * **Celestial** — sextant sight of the Sun, Moon, or an almanac star
 
 You can right-click an object on the map to pre-fill its coordinates. Sights can be entered with a stopwatch delay ("minutes ago") instead of clock time. Observations accumulate in the pending list; select two or more, *Preview selected* to resolve the candidate fix, then *Confirm fix* to snap dead reckoning to it. A single line of position can also be advanced to a later sight (running fix).

package/SPEC.md

@@ -23,7 +23,7 @@ The three motivations are causally linked: (1) generates the fix data and crew e
 - Learns vessel-specific leeway, speed-loss, and heading-deviation corrections via a binned EMA matrix, trained against GPS ground truth during normal sailing.
 - Detects GPS anomalies (sudden jumps, implausible-at-anchor/moored displacement, corroborating third-party AIS/ADS-B inconsistency) and alerts the watchkeeper — it does **not** auto-switch navigational authority; a human always decides when to trust DR over GPS.
 - Supports a unified concept of "fix" that spans GPS, celestial sights, compass bearings, vertical-angle-to-known-object, and future methods (Starlink-constellation positioning, radio direction finding), each contributing either a point, a line-of-position, or a circular position line to a common fix-resolution model.
-- Integrates with `signalk-logbook` (the `logentries` Signal K v2 Resources API, in-process) as an optional, gracefully-degrading write-through layer, so fixes and DR events become part of the vessel's actual logbook record.
+- Integrates with the vessel's logbook through the `logentries` Signal K v2 Resources API (in-process) as an optional, gracefully-degrading write-through layer, so fixes and DR events become part of the vessel's actual logbook record. Provider-agnostic: any plugin registering a `logentries` resource provider works — `signalk-logbook` is the known-good one, not a requirement.
 - Supports offline historical backfill and backtesting against 4–5 years of Signal K History API data, optionally enriched with reanalysis weather/current data and logbook records when broadband is available.
 
 \* "Zero-dependency" here means no external services required for core operation; the SQLite persistence layer should target Node's built-in `node:sqlite` (or an equivalent no-native-build option) rather than a compiled native binding, given the ARM/Raspberry-Pi-class hardware most Signal K installs run on.
@@ -135,7 +135,7 @@ CREATE TABLE IF NOT EXISTS fixes (
     estimated_error_radius REAL,
     confirmed_by TEXT,                -- crew name; simple free-text picker, no auth model assumed
     logged_to_logbook BOOLEAN NOT NULL DEFAULT 0,
-    logbook_entry_ref TEXT,           -- UUID of the corresponding signalk-logbook `logentries` resource, if written
+    logbook_entry_ref TEXT,           -- UUID of the corresponding `logentries` resource, if written
     resets_dr_origin BOOLEAN NOT NULL DEFAULT 0,
     notes TEXT
 );
@@ -247,7 +247,7 @@ CREATE TABLE IF NOT EXISTS gps_anomalies (
 
 ```
 Main Thread (Signal K Event Loop)
-  N2K/N0183 Ingest → Delta Router → signalk-logbook Resources API (in-process, optional)
+  N2K/N0183 Ingest → Delta Router → logentries Resources API (in-process, optional)
                                    → GRIB Provider Service
                                    → AIS/ADS-B target tracking
 
@@ -394,15 +394,15 @@ On every confirmed fix that resets the DR origin (symmetric across NORMAL and OV
 
 ### 9.4 Automatic Tack/Gybe Logbook Entries
 
-The rate-of-turn detection already built for matrix-training suppression (§6.4) is a free source of a routine, easily-forgotten logbook event: reuse the same tack/gybe detection to auto-generate a `signalk-logbook` entry (`category: navigation`, `origin: auto` — pure automation, no human in the loop; see §9.5) whenever a completed tack or gybe is detected — direction (tack→tack or gybe), new heading, and timestamp are all already available from the same signal.
+The rate-of-turn detection already built for matrix-training suppression (§6.4) is a free source of a routine, easily-forgotten logbook event: reuse the same tack/gybe detection to auto-generate a `logentries` entry (`category: navigation`, `origin: auto` — pure automation, no human in the loop; see §9.5) whenever a completed tack or gybe is detected — direction (tack→tack or gybe), new heading, and timestamp are all already available from the same signal.
 
 - No watchkeeper confirmation step is needed for this entry type — unlike fixes, there's no ambiguity or human judgment involved in "a tack happened," so it can write directly rather than going through the confirm-first pipeline used for fixes.
 - Should respect the same "avoid flooding the logbook" concern raised for routine GPS fixes (§9.1) — a beat to windward with frequent short tacks could generate a lot of entries; consider a minimum-interval debounce (e.g. don't log a second tack within some short window, treating rapid back-to-back direction changes as one transient event) rather than logging every single rate-of-turn crossing.
 - This is incidental to the core DR/matrix purpose but effectively free, since the detection work is already required for §6.4.
 
-### 9.5 `signalk-logbook` Field Mapping
+### 9.5 Logbook (`logentries`) Field Mapping
 
-Logbook entries are written through the Signal K v2 Resources API — in-process `app.resourcesApi.setResource("logentries", <uuid>, entry)` against the provider signalk-logbook registers (the contract is documented in signalk-logbook's `docs/logentries-resource.md`). No REST, no tokens: the server gates in-process plugin access at nothing, which dissolves the access-request/token apparatus the deprecated v1 plugin routes forced. The `logentries` schema has no dedicated fix-type or celestial-specific fields — a required free-text `text`, logbook metadata fields, and an optional `telemetry` array of delta-shaped pathvalues in Signal K SI units. `fixes` remains the local source of truth; the logbook write is a formatted export, not the canonical record.
+Logbook entries are written through the Signal K v2 Resources API — in-process `app.resourcesApi.setResource("logentries", <uuid>, entry)` against whatever plugin registers a `logentries` resource provider. The contract is provider-agnostic: signalk-logbook is the reference implementation (its `docs/logentries-resource.md` documents the schema), but any provider answering the type works, and the plugin probes for the type — not for a plugin name. No REST, no tokens: the server gates in-process plugin access at nothing, which dissolves the access-request/token apparatus the deprecated v1 plugin routes forced. The `logentries` schema has no dedicated fix-type or celestial-specific fields — a required free-text `text`, logbook metadata fields, and an optional `telemetry` array of delta-shaped pathvalues in Signal K SI units. `fixes` remains the local source of truth; the logbook write is a formatted export, not the canonical record.
 
 | `fixes` / DR field | `logentries` field | Notes |
 |---|---|---|
@@ -429,7 +429,7 @@ Two distinct jobs, both explicit, user-triggered, broadband-gated (Starlink) ope
 Replays History API data (4–5 years) through the same bin/EMA logic as live training mode, to seed `dr_matrix_bins` before significant live sailing accumulates.
 
 - **Weather/current enrichment:** when run with broadband available, fetches historical reanalysis current/wind data (e.g. Copernicus Marine Service / ERA5-class products — license/attribution terms to be confirmed before committing to a specific provider) for the dates/positions actually visited, rather than relying solely on climatological pilot-chart averages. Query set is deduplicated to distinct (date, grid-cell) tuples before fetching, batched and rate-limited/backed-off per the provider's documented limits, with a persisted progress checkpoint (`dr_state_store` high-water-mark) so an interrupted run can resume. Bins trained with reanalysis current get a higher `historical_confidence_tier` weight than climatology-only bins (§4.1).
-- **Logbook enrichment:** where `signalk-logbook` entries exist for the historical window (likely not the full 4–5 years), read them tokenlessly in-process via `app.resourcesApi.listResources("logentries", {from, to})` and join by nearest-timestamp (~±30min) to recover `sail_state`/sea state for spans that would otherwise fall to `'unknown'` (entry telemetry carries SI pathvalues — `environment.water.seaState` is Beaufort, convert back to the Douglas code DR stores). Historical `navigation`-category entries carrying a `navigation.position` pathvalue are additionally ingested into `fixes` (`source_type = 'backfill'`), so passage review isn't blank for the pre-plugin era.
+- **Logbook enrichment:** where `logentries` entries exist for the historical window (likely not the full 4–5 years), read them tokenlessly in-process via `app.resourcesApi.listResources("logentries", {from, to})` and join by nearest-timestamp (~±30min) to recover `sail_state`/sea state for spans that would otherwise fall to `'unknown'` (entry telemetry carries SI pathvalues — `environment.water.seaState` is Beaufort, convert back to the Douglas code DR stores). Historical `navigation`-category entries carrying a `navigation.position` pathvalue are additionally ingested into `fixes` (`source_type = 'backfill'`), so passage review isn't blank for the pre-plugin era.
 - **Resolution/provenance caveats, explicitly documented rather than silently absorbed:** ~10s History API resolution under-represents instantaneous heel/AWA response (gust/roll dynamics) versus live 1Hz IMU data; paddlewheel fouling status is essentially unknown for historical data and must be inferred via the STW≈0-while-moving heuristic (§6.3) applied retroactively; `navigation.log`/`navigation.trip.log`/logbook `navigation.log` telemetry are GPS-track-derived, not water-track, and must never be used as an STW proxy or ground truth during backfill.
 - **Outlier rejection:** a max-plausible-speed/position-jump filter, plus the fouling heuristic, applied before samples enter training — historical GPS glitches are otherwise uncorrected and would poison bins.
 - Also used to build `anchor_swing_stats` and `moored_position_stats` (§7.1, §7.2), each with their own drag-exclusion / settle-window preprocessing. Recomputed periodically (e.g. quarterly) rather than live-updated, since these have no need for 1Hz reactivity.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@meri-imperiumi/signalk-dead-reckoning",
-  "version": "0.13.3",
+  "version": "0.14.0",
   "description": "Offline-first dead reckoning and sensor fusion engine for Signal K",
   "main": "plugin/index.js",
   "scripts": {

package/plugin/db.js

@@ -638,7 +638,8 @@ function getDeviationRateStats(db, q = {}) {
 }
 
 /**
- * Marks a `fixes` row as written to the signalk-logbook, storing the
+ * Marks a `fixes` row as written to the logbook (`logentries` resource),
+ * storing the
  * entry reference (its datetime key). A failed write leaves the row
  * unmarked — visible in `fixes`, never blocking the fix flow.
  *

package/plugin/fix-pipeline.js

@@ -31,6 +31,7 @@
  */
 
 const { resolveFix, advanceObservation } = require("./fixes.js");
+const { METRES_PER_NM } = require("./geo.js");
 
 /**
  * The helpers the orchestrator needs, injected by the caller. In
@@ -506,6 +507,33 @@ function defaultOriginErrorNm(sourceType) {
   return sourceType === "gps" ? 0.05 : 5;
 }
 
+/**
+ * Radar-range error model (work doc #33): a consumer radar's range
+ * accuracy is spec'd around 1% of range (beamwidth + pulse timing),
+ * so the uncertainty grows with the measured distance — plus an
+ * absolute floor for the short-range case where the percentage term
+ * collapses below what marker/plot resolution can support (20 m is
+ * already inside a 2 m cell's display). Configurable: `errorPct`
+ * (percent of range) and `floorM` (metres).
+ *
+ * Pure — unit-testable without Signal K; the POST /fix/cpl route
+ * applies it as the default `radius_uncertainty_nm` for
+ * `cpl_type: 'radar-range'` when the client doesn't supply one.
+ *
+ * @param {number} rangeNm - measured range, nm
+ * @param {object} [opts]
+ * @param {number} [opts.errorPct=1.5] - error as percent of range
+ * @param {number} [opts.floorM=20] - absolute floor, metres
+ * @returns {number} uncertainty radius, nm
+ */
+function radarRangeUncertaintyNm(rangeNm, opts = {}) {
+  const errorPct = Number.isFinite(opts.errorPct) ? opts.errorPct : 1.5;
+  const floorM = Number.isFinite(opts.floorM) ? opts.floorM : 20;
+  const range = Number.isFinite(rangeNm) && rangeNm >= 0 ? rangeNm : 0;
+  const pctNm = (range * errorPct) / 100;
+  return Math.max(pctNm, floorM / METRES_PER_NM);
+}
+
 /**
  * Maximum implied vessel speed (kn) for an observation to be physically
  * plausible: how fast the boat would have had to travel from the last
@@ -565,6 +593,7 @@ module.exports = {
   loadObservationsById,
   advanceToLatest,
   defaultOriginErrorNm,
+  radarRangeUncertaintyNm,
   evaluateObservationPlausibility,
   fixSanityCapNm,
   MAX_IMPLIED_SPEED_KN,

package/plugin/fixes.js

@@ -562,7 +562,10 @@ const RAY_TOLERANCE_M = 100;
  * the line is equally valid.
  *
  * @param {object} obs - resolver-shaped LOP observation (needs
- *   `lop_type`, `assumed_lat/lon`, `azimuth_true`)
+ *   `lop_type`, `assumed_lat/lon`, `azimuth_true`). Bearings to known
+ *   objects are ray-constrained — `bearing` (hand-bearing compass) and
+ *   `radar-bearing` (radar heading-marked bearing, work doc #33) alike:
+ *   same geometry, different instrument.
  * @param {{latitude:number, longitude:number}} projectionCenter
  * @param {{x:number, y:number}} p - candidate point, local plane
  * @param {number} [toleranceM=RAY_TOLERANCE_M] along-ray slack
@@ -570,7 +573,8 @@ const RAY_TOLERANCE_M = 100;
  *   the observation is not a bearing — no constraint)
  */
 function onObserverRay(obs, projectionCenter, p, toleranceM = RAY_TOLERANCE_M) {
-  if (obs.lop_type !== "bearing") return true;
+  if (obs.lop_type !== "bearing" && obs.lop_type !== "radar-bearing")
+    return true;
   const anchor = projectToLocal(projectionCenter, {
     latitude: obs.assumed_lat,
     longitude: obs.assumed_lon,

package/plugin/index.js

@@ -88,6 +88,7 @@ const {
   confirmFix,
   evaluateObservationPlausibility,
   fixSanityCapNm,
+  radarRangeUncertaintyNm,
 } = require("./fix-pipeline.js");
 const { reduceSight, reduceNoonSight } = require("./celestial.js");
 const starAlmanac = require("./star-almanac.js");
@@ -377,6 +378,15 @@ const DEFAULT_CONFIG = {
    */
   fixes: {
     maxDisplacementNm: 100,
+    /**
+     * Radar-range error model (work doc #33): consumer radar range
+     * accuracy is ~1% of range plus display/marker resolution; the
+     * default uncertainty for a `radar-range` CPL is the larger of
+     * `radarRangeErrorPct`% of the range and `radarRangeErrorFloorM`
+     * metres.
+     */
+    radarRangeErrorPct: 1.5,
+    radarRangeErrorFloorM: 20,
   },
   weatherCurrent: {
     enabled: true,
@@ -414,6 +424,7 @@ const deps = {
   confirmFix,
   evaluateObservationPlausibility,
   fixSanityCapNm,
+  radarRangeUncertaintyNm,
   computeRadius,
   createDivergenceState,
   divergenceTick,
@@ -781,7 +792,7 @@ module.exports = (app) => {
         },
         "logbook.enabled": {
           type: "boolean",
-          title: "Write fixes and maneuvers to signalk-logbook",
+          title: "Write fixes and maneuvers to the vessel's logbook",
           default: DEFAULT_CONFIG.logbook.enabled,
         },
         "logbook.retryBackoffMs": {
@@ -832,6 +843,24 @@ module.exports = (app) => {
           title: "Shadow vessel label",
           default: DEFAULT_CONFIG.shadowVessel.name,
         },
+        "fixes.radarRangeErrorPct": {
+          type: "number",
+          title: "Radar range error (% of range)",
+          description:
+            "Default uncertainty radius for a radar-range observation: this percentage of the measured range, or the absolute floor below — whichever is larger. Consumer radar range accuracy is typically ~1%.",
+          minimum: 0,
+          maximum: 20,
+          default: DEFAULT_CONFIG.fixes.radarRangeErrorPct,
+        },
+        "fixes.radarRangeErrorFloorM": {
+          type: "integer",
+          title: "Radar range error floor (m)",
+          description:
+            "Absolute floor for the radar-range uncertainty: at short ranges the percentage term collapses below what marker resolution on the display supports.",
+          minimum: 0,
+          maximum: 500,
+          default: DEFAULT_CONFIG.fixes.radarRangeErrorFloorM,
+        },
       },
     },
 
@@ -2187,8 +2216,8 @@ module.exports = (app) => {
   }
 
   /**
-   * Initializes the logbook write path when enabled: probes the
-   * `logentries` resource provider (registered by signalk-logbook) with
+   * Initializes the logbook write path when enabled: probes for any
+   * registered `logentries` resource provider (e.g. signalk-logbook) with
    * a minimal listing — a cheap, complete-window query under the
    * contract's "no silent windows" rule. Plugin start order isn't
    * guaranteed, so a missing provider isn't fatal: writes queue (SQLite)
@@ -2218,7 +2247,7 @@ module.exports = (app) => {
         logbookProbing = false;
         logbook = null;
         setStatus(
-          "signalk-logbook logentries provider not available — entries queued",
+          "No logentries resource provider available — logbook entries queued",
         );
         scheduleLogbookRetry();
       });
@@ -2919,7 +2948,17 @@ module.exports = (app) => {
         center_lat: b.center_lat,
         center_lon: b.center_lon,
         radius_nm: b.radius_nm,
-        radius_uncertainty_nm: b.radius_uncertainty_nm ?? null,
+        radius_uncertainty_nm:
+          b.radius_uncertainty_nm ??
+          // Radar ranges carry a range-proportional error model (work
+          // doc #33) — applied as the default when the client doesn't
+          // send its own estimate.
+          (b.cpl_type === "radar-range"
+            ? deps.radarRangeUncertaintyNm(b.radius_nm, {
+                errorPct: config.fixes.radarRangeErrorPct,
+                floorM: config.fixes.radarRangeErrorFloorM,
+              })
+            : null),
         source_object: b.source_object ?? null,
         confirmed_by: b.confirmed_by ?? null,
         // Raw inputs (schema v2) for backtesting.
@@ -2929,7 +2968,12 @@ module.exports = (app) => {
       const obsBy = b.confirmed_by || usernameFromCookies(req.cookies) || null;
       writeLogbookEntry(
         deps.composeObservationEntry({
-          kind: "vertical",
+          kind:
+            b.cpl_type === "radar-range"
+              ? "radar"
+              : b.cpl_type === "horizontal-angle"
+                ? "hangle"
+                : "vertical",
           datetime: b.timestamp ?? new Date().toISOString(),
           body_or_object: b.source_object ?? null,
           confirmed_by: obsBy,
@@ -2937,6 +2981,7 @@ module.exports = (app) => {
           latitude: engine.origin?.latitude,
           longitude: engine.origin?.longitude,
           radius_nm: b.radius_nm,
+          angle_deg: b.angle_deg ?? null,
           sea_state:
             resolveSeaState() !== "unknown" ? Number(resolveSeaState()) : null,
         }),

package/plugin/logbook.js

@@ -1,5 +1,6 @@
 /**
- * Logbook integration: write-through to `signalk-logbook` (SPEC §9.4, §9.5).
+ * Logbook integration: write-through to the `logentries` resource provider
+ * (e.g. `signalk-logbook`; SPEC §9.4, §9.5).
  *
  * `fixes` remains the canonical record; logbook entries are formatted
  * exports. Entries are written through the Signal K v2 Resources API
@@ -329,18 +330,19 @@ function composeTackEntry(t) {
 
 /**
  * Composes a `NewEntry`-shaped body for a standalone observation
- * (SPEC §9.5): a bearing LOP, a vertical-angle CPL, or a celestial
- * sight. Logged when the observation is recorded — independent of
- * whether it ever resolves into a fix — because taking the sight is
- * itself a navigational event. The vessel's position (DR at the time
- * of the sight) rides the `navigation.position` telemetry pathvalue —
- * the logbook UI renders it separately, so it stays out of `text`;
- * `text` carries only what was observed (object, bearing/radius/
- * reduction).
+ * (SPEC §9.5): a bearing LOP, a vertical-angle CPL, a radar range
+ * (work doc #33), or a celestial sight. Logged when the observation
+ * is recorded — independent of whether it ever resolves into a fix —
+ * because taking the sight is itself a navigational event. The
+ * vessel's position (DR at the time of the sight) rides the
+ * `navigation.position` telemetry pathvalue — the logbook UI renders
+ * it separately, so it stays out of `text`; `text` carries only what
+ * was observed (object, bearing/radius/reduction).
  *
  * @param {object} o
- * @param {"bearing"|"vertical"|"celestial"} o.kind
- * @param {string} [o.body_or_object] - body name (celestial) or object label
+ * @param {"bearing"|"vertical"|"radar"|"hangle"|"celestial"} o.kind
+ * @param {string} [o.body_or_object] - body name (celestial), object label,
+ *   or "A / B" (horizontal-angle CPLs)
  * @param {string} o.datetime - ISO timestamp
  * @param {string|null} [o.confirmed_by] - watchkeeper (author)
  * @param {number} [o.latitude] - vessel position to anchor the entry
@@ -348,7 +350,10 @@ function composeTackEntry(t) {
  * @param {object} [o.reduction] - celestial reduction (Hc/Ho/Zn/intercept)
  * @param {number|null} [o.azimuth_true] - true bearing to the object, deg
  *   (bearing LOPs — the observed angle is the event, it belongs in text)
- * @param {number|null} [o.radius_nm] - CPL radius, nm (vertical-angle CPLs)
+ * @param {number|null} [o.radius_nm] - CPL radius, nm (vertical-angle / radar
+ *   range CPLs)
+ * @param {number|null} [o.angle_deg] - measured horizontal angle, deg
+ *   (horizontal-angle CPLs, work doc #35)
  * @param {number|null} [o.sea_state] - Douglas sea state code 0-9
  * @returns {object} setResource body
  */
@@ -372,6 +377,14 @@ function composeObservationEntry(o) {
       ? ` ${o.radius_nm.toFixed(1)} NM`
       : "";
     text = `${o.body_or_object ?? "object"} CPL${r}`;
+  } else if (o.kind === "radar") {
+    const r = Number.isFinite(o.radius_nm)
+      ? ` ${o.radius_nm.toFixed(1)} NM`
+      : "";
+    text = `${o.body_or_object ?? "object"} radar range${r}`;
+  } else if (o.kind === "hangle") {
+    const a = Number.isFinite(o.angle_deg) ? ` ${o.angle_deg.toFixed(1)}°` : "";
+    text = `${o.body_or_object ?? "objects"} horizontal angle${a}`;
   } else {
     // The observed angle is the event — a bearing entry without it
     // isn't navigable after the fact. Zero-padded like the tack text;
@@ -410,9 +423,11 @@ function composeObservationEntry(o) {
 
 /**
  * Creates a logbook write client over the Signal K v2 Resources API —
- * the in-process `app.resourcesApi` interface, with the `logentries`
- * provider registered by signalk-logbook. No REST, no tokens, no auth
- * of any kind: in-process plugin access passes no security middleware.
+ * the in-process `app.resourcesApi` interface, against whatever plugin
+ * registers a `logentries` resource provider (signalk-logbook is the
+ * reference implementation, not a requirement). No REST, no tokens, no
+ * auth of any kind: in-process plugin access passes no security
+ * middleware.
  *
  * @param {object} opts
  * @param {object} opts.resourcesApi - the server's resources API

package/public/dr-app.js

@@ -903,7 +903,18 @@ class DrApp extends HTMLElement {
     this.extHost = new PlotterExtHost({
       stream: window.drSignalkStream,
       mount: root,
+      // The chart, once it exists — map overlays composite onto it and
+      // the map capability reads/drives its viewport.
+      getMap: () => this.map?.map ?? null,
     });
+    // The host hooks the Leaflet events itself, but discovery can land
+    // before the chart exists — forward the element's own view-change
+    // event and kick once so the first overlay frames are requested
+    // even without a user pan.
+    this.map?.addEventListener("dr-view-changed", () =>
+      this.extHost.viewChanged(),
+    );
+    setTimeout(() => this.extHost.viewChanged(), 250);
     for (const el of root.querySelectorAll("dr-ext-widget-area")) {
       this.extHost.attachArea(el);
     }