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

package/CHANGELOG.md

@@ -7,6 +7,12 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [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,9 +1,13 @@
 # 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 ([reported by Yachting Monthly](https://www.yachtingmonthly.com/news/mca-tells-maritime-sector-to-plan-for-life-without-gps-106566), 1 Oct 2025) 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 exactly that contingency for Signal K vessels: the fallback is always running, and the trusted-GPS period is spent training it.
+
 ## Requirements
 
 * This plugin installed and configured
@@ -19,7 +23,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 +34,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.13.4",
   "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-map-view.js

@@ -1088,6 +1088,15 @@ class DrMapView extends HTMLElement {
       : [
           { label: ` Bearing to ${what}`, mode: "bearing" },
           { label: ` Distance CPL at ${what}`, mode: "vertical" },
+          // Radar range (work doc #33): the GNSS-independent range
+          // instrument — a radar range to a charted object, or to an
+          // AIS target (whose position is itself GNSS-derived; the
+          // radar form's note says so).
+          { label: ` Radar range at ${what}`, mode: "radar" },
+          // Horizontal sextant angle (work doc #35): the compass-free
+          // fix. Successive picks fill the form's object slots A → B
+          // → C.
+          { label: ` Horizontal angle at ${what}`, mode: "hangle" },
           { label: " Measure from here…", mode: "_measure" },
           { label: " New note at…", mode: "_note" },
         ];