node-red-contrib-ntrip 0.2.10 → 0.2.11

package/.github/workflows/release.yml

@@ -1,65 +0,0 @@
-# Release pipeline.
-#
-# Trigger: push of a version tag matching v* or V* (e.g. v0.2.7, V1.0.0).
-# Stages:
-#   1. test — runs the full lint/format/test matrix on the tagged commit.
-#   2. publish-npm — publishes the package to the npm registry.
-#   3. github-release — creates a GitHub Release with auto-generated notes.
-#
-# Requires the `NPM_TOKEN` secret to be configured in the repository.
-
-name: Release
-
-on:
-    push:
-        tags:
-            - 'v*'
-            - 'V*'
-
-jobs:
-    test:
-        runs-on: ubuntu-latest
-        strategy:
-            matrix:
-                node-version: [18.x, 20.x, 22.x]
-        steps:
-            - uses: actions/checkout@v7
-            - name: Use Node.js ${{ matrix.node-version }}
-              uses: actions/setup-node@v6
-              with:
-                  node-version: ${{ matrix.node-version }}
-                  cache: 'npm'
-            - run: npm ci
-            - run: npm run lint
-            - run: npm run format:check
-            - run: npm test
-
-    publish-npm:
-        needs: test
-        runs-on: ubuntu-latest
-        steps:
-            - uses: actions/checkout@v7
-            - uses: actions/setup-node@v6
-              with:
-                  node-version: 20
-                  registry-url: 'https://registry.npmjs.org/'
-            - run: npm ci
-            - run: npm publish
-              env:
-                  NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
-
-    github-release:
-        needs: publish-npm
-        runs-on: ubuntu-latest
-        permissions:
-            contents: write
-        steps:
-            - uses: actions/checkout@v7
-              with:
-                  fetch-depth: 0
-            - name: Create GitHub Release
-              uses: softprops/action-gh-release@v3
-              with:
-                  tag_name: ${{ github.ref_name }}
-                  name: ${{ github.ref_name }}
-                  generate_release_notes: true

package/.prettierignore

@@ -1,20 +0,0 @@
-# Generated / vendored
-node_modules/
-package-lock.json
-
-# Node-RED flow files — re-formatting would change diff noise without value
-examples/
-
-# Editor UI HTML has Node-RED-specific structural conventions
-# (data-template-name script blocks, x-red script blocks) that Prettier
-# can mangle. Touch only with care.
-ntrip/99-ntrip.html
-
-# Markdown is kept hand-formatted (line-wrapped prose, ASCII diagrams).
-# Re-flowing it would produce a large noisy diff.
-*.md
-doc/
-
-# Editor / agent local state — not checked in
-.claude/
-.vscode/

package/.prettierrc.json

@@ -1,9 +0,0 @@
-{
-    "trailingComma": "es5",
-    "tabWidth": 4,
-    "semi": true,
-    "singleQuote": true,
-    "bracketSpacing": true,
-    "endOfLine": "auto",
-    "printWidth": 160
-}

package/CLAUDE.md

@@ -1,73 +0,0 @@
-# CLAUDE.md
-
-This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
-
-## Project overview
-
-`node-red-contrib-ntrip` is a Node-RED contribution package providing four GNSS-related nodes: an NTRIP client (download/upload), an RTCM decoder, an NMEA decoder, and an NMEA encoder. It is published to npm and consumed by users via Node-RED's palette manager — there is no application entry point of its own. Runtime target is Node.js >= 7.6 (CI matrix: 18.x, 20.x, 22.x).
-
-## Commands
-
-This package has no build step. Linting (ESLint flat config) and formatting (Prettier) are wired in:
-
-```bash
-npm test                                  # run all specs (mocha + node-red-node-test-helper)
-npm run lint                              # eslint, treats warnings as warnings
-npm run lint:fix                          # eslint --fix
-npm run format                            # prettier --write .
-npm run format:check                      # prettier --check . (used in CI)
-
-npx mocha test/nmea-decoder.spec.js       # run one spec file
-npx mocha test/**/*.spec.js -g 'regression'  # run only regression specs
-```
-
-CI runs `npm ci`, `npm run build --if-present`, `npm run lint`, `npm run format:check`, then `npm test` across Node 18/20/22 (see [.github/workflows/node.js.yml](.github/workflows/node.js.yml)).
-
-Prettier settings live in [.prettierrc.json](.prettierrc.json) (4-space indent, single quotes, trailing-commas-es5, printWidth 160). [.prettierignore](.prettierignore) skips `examples/` (Node-RED flow files), `ntrip/99-ntrip.html` (Node-RED-specific structural conventions), markdown, and `doc/`. ESLint config is [eslint.config.js](eslint.config.js) (flat config, `@eslint/js` recommended + `eslint-config-prettier`).
-
-To exercise changes manually, install this directory into a local Node-RED:
-
-```bash
-cd <node-red userDir, e.g. ~/.node-red>
-npm install <path-to-this-repo>
-```
-
-Then start Node-RED and import a flow from [examples/](examples/) (e.g. `ntripclient.json`, `sapos.json`, `upload.json`, `tcp.json`, `nmea-decode.json`, `nmea-encode.json`) to drive the nodes against a real NTRIP caster.
-
-## Architecture
-
-Node-RED contribution packages follow a strict structure that this repo conforms to:
-
-- [package.json](package.json) `node-red.nodes` points at a single registration file [ntrip/99-ntrip.js](ntrip/99-ntrip.js).
-- That registration file is the only entry Node-RED loads. It `require`s each node implementation from [ntrip/nodes/](ntrip/nodes/) and calls `RED.nodes.registerType(...)` for each.
-- Each Node-RED node is a pair: a `.js` runtime file in [ntrip/nodes/](ntrip/nodes/), plus the editor UI (HTML + inline `<script>`/`<template>`) co-located in [ntrip/99-ntrip.html](ntrip/99-ntrip.html). All four nodes' editor definitions share this single HTML file.
-- Credentials (NTRIP username/password) are declared in both the registration call ([ntrip/99-ntrip.js:13-16](ntrip/99-ntrip.js#L13-L16)) and the HTML `credentials` block — they must stay in sync, otherwise Node-RED will not persist them.
-
-Node responsibilities:
-
-- **NtripClient** ([ntrip/nodes/ntrip-client-node.js](ntrip/nodes/ntrip-client-node.js)) — wraps [ntrip/lib/ntrip-client.js](ntrip/lib/ntrip-client.js), which extends the upstream `ntrip-client` package to add an *uploader* variant. The uploader's `_connect()` switches the handshake string by `authmode` (`legacy`, `hybrid`, `ntripv1`, `ntripv2`) — see [ntrip/lib/ntrip-client.js:45-66](ntrip/lib/ntrip-client.js#L45-L66). Special inbound bytes are intercepted and turned into status/error rather than forwarded: `ICY 200 OK` (connected), `ICY 406` (rejected), `SOURCETABLE 200 OK` (mountpoint missing). When `msg.payload` is an `Array`, it is treated as an `[x, y, z]` coordinate triple and forwarded via `client.setXYZ(...)` (used by the Sapos flow to seed a GGA sentence); any other payload is written to the caster. `passthrough` controls whether written data is also re-emitted on the output.
-- **RtcmDecoder** ([ntrip/nodes/rtcm-decoder-node.js](ntrip/nodes/rtcm-decoder-node.js)) — loops `RtcmTransport.decode(buffer)` (from `@gnss/rtcm`), slicing the buffer by the returned `length` until empty, emitting one message per decoded RTCM frame. Two outputs: `[ok, error]`.
-- **NmeaDecoder** ([ntrip/nodes/nmea-decoder-node.js](ntrip/nodes/nmea-decoder-node.js)) — decodes via `NmeaTransport.decode` from `@gnss/nmea`. Accepts either a Buffer or a string, and either `msg.payload` directly or `msg.payload.nmeaMessage`. Two outputs: `[ok, error]`.
-- **NmeaEncoder** ([ntrip/nodes/nmea-encoder-node.js](ntrip/nodes/nmea-encoder-node.js)) — symmetric inverse, with a large `switch (messageType)` that maps NMEA sentence types (`GGA`, `RMC`, `GSV`, ...) to the corresponding `NmeaMessage*.construct(...)` factory before calling `NmeaTransport.encode`. When adding support for a new NMEA sentence type, add both the import at the top and the matching `case` in the switch.
-
-## Tests
-
-Specs live in [test/](test/) — one file per node. Each uses `node-red-node-test-helper` to load the registration file [ntrip/99-ntrip.js](ntrip/99-ntrip.js), wires the node under test to two `helper` sink nodes (one per output port), and asserts on `msg.payload` shape.
-
-Two patterns to reuse when adding tests:
-
-- **`regression:` tag in the test name** — for any spec that locks in a previously-shipped bug. Future maintainers can run `mocha -g regression` to verify the fix is still in place.
-- **`node.error` spy** — replace `n1.error` with a wrapper that flips a boolean, then assert the boolean stayed false. Used to prevent regressing the "decoder floods the Node-RED error log when fed mismatched binary" bug.
-
-Known-good test fixtures embedded in the specs:
-
-- NMEA: `$GPGGA,123519,4807.038,N,01131.000,E,1,08,0.9,545.4,M,46.9,M,,*47`, `$GPGLL,4916.45,N,12311.12,W,225444,A,*1D`
-- RTCM: a real 25-byte type 1005 frame as hex `D300133ED7D30202980EDEEF34B4BD62AC0941986F33360B98`
-
-NTRIP client integration tests are not yet written; the recommended approach is a fake TCP server via `net.createServer` that returns `"ICY 200 OK\r\n\r\n" + rtcmBytes` to exercise the handshake-state machine.
-
-## Conventions worth knowing
-
-- All four nodes follow the same pattern: increment a `messagesReceived`/`invalidMessagesReceived` counter and call `node.status({...})` after each input, set `node.status({})` on `close`. Keep this consistent when adding nodes.
-- The package version printed at load time is read from `package.json` at [ntrip/99-ntrip.js:8-9](ntrip/99-ntrip.js#L8-L9) — bumping `version` in package.json is the only source of truth.
-- Releases are tracked in [CHANGELOG.md](CHANGELOG.md) using "Keep a Changelog" headings; each entry typically references the GitHub issue number that motivated it.

package/doc/architecture/README.md

@@ -1,19 +0,0 @@
-# Architecture documentation
-
-Architectural analysis of `node-red-contrib-ntrip`. Start with
-[overview.md](overview.md) for a high-level orientation.
-
-| Chapter | Read when |
-|---------|-----------|
-| [Overview](overview.md) | First contact — what this package is and how the pieces fit. |
-| [Structural Design](structural-design.md) | You need to find or change a specific file / module. |
-| [Behavioural Design](behavioural-design.md) | You're changing runtime behaviour — state machines, error paths, lifecycle hooks. |
-| [Architecture Decisions](architecture-decisions.md) | You're about to revisit a load-bearing decision. Individual ADRs live in [adr/](adr/). |
-| [Errors and Weaknesses](errors-and-weaknesses.md) | You're triaging a bug report — check whether it's already known. |
-| [Refactoring Recommendations](refactoring-recommendations.md) | You have spare cycles and want to invest them in code health. |
-| [Future Improvements](future-improvements.md) | You're planning the next minor release. |
-| [Statistics](statistics.md) | You want a quantitative read on size, test coverage, and quality. |
-
-This documentation lives alongside the code and is versioned with it. When
-you change behaviour that contradicts a statement here, update the doc in the
-same commit.

package/doc/architecture/adr/0001-single-registration-file.md

@@ -1,64 +0,0 @@
-# ADR-0001: Single registration file for all nodes
-
-## Status
-
-Accepted (original design).
-
-## Context
-
-Node-RED loads a contribution package via the `node-red.nodes` map in
-`package.json`. That map can point at one or many entry files: each entry file
-is run once at startup and is expected to call `RED.nodes.registerType(...)`
-for the node types it owns.
-
-Two viable patterns exist:
-
-- **One entry per node.** `package.json` lists four entries; each file
-  registers exactly one type. Pro: a node's entire definition is in one place.
-  Con: four entries to keep in sync, four loader invocations.
-- **One entry for the whole package.** `package.json` lists one entry; that
-  file `require`s each node implementation and registers them all. Pro:
-  centralised; package version logging happens once.
-
-## Decision
-
-Use a single registration entry file: [ntrip/99-ntrip.js](../../../ntrip/99-ntrip.js).
-The `99-` prefix is a convention seen across published `node-red-contrib-*`
-packages — it sorts late alphabetically, making the file easy to find.
-
-Each node implementation lives under [ntrip/nodes/](../../../ntrip/nodes/) and
-exports a factory function that the registration file imports.
-
-The four node types' editor UIs share one HTML file
-([ntrip/99-ntrip.html](../../../ntrip/99-ntrip.html)) — Node-RED's loader picks
-up the `.html` next to the registered `.js`.
-
-## Consequences
-
-**Positive**
-
-- One place to read the full inventory of nodes.
-- Package version logging happens exactly once at load time (read from
-  `package.json`).
-- New nodes are added by a one-line `require` + one-line `registerType` in the
-  entry file, plus a new file under `nodes/` and a new `<script>` block in the
-  HTML.
-
-**Negative**
-
-- The HTML file is large (~470 lines) because it must hold form templates and
-  help text for all four nodes. Adding a fifth node means appending another
-  ~100 lines to the same file.
-- A typo in `registerType` names (e.g. `NtripClinet` instead of `NtripClient`)
-  is silently fatal — the JS side and HTML side must agree exactly.
-
-**Trade-offs**
-
-- Choosing the single-entry pattern prioritises *package coherence* over
-  *per-node isolation*. If the package ever grows to a dozen+ nodes, splitting
-  would become attractive.
-
-## Related
-
-- Code: [ntrip/99-ntrip.js](../../../ntrip/99-ntrip.js), [ntrip/99-ntrip.html](../../../ntrip/99-ntrip.html)
-- Configured via: [package.json](../../../package.json) `node-red.nodes`

package/doc/architecture/adr/0002-ntrip-uploader-extension.md

@@ -1,71 +0,0 @@
-# ADR-0002: NTRIP uploader as full-replacement extension of the upstream client
-
-## Status
-
-Accepted in 0.2.0.
-
-## Context
-
-The upstream `ntrip-client` npm package implements the *download* side of
-NTRIP only — it connects to a caster and emits received bytes. We needed the
-*upload* side too: open a socket, send a SOURCE / POST handshake, then forward
-locally-produced bytes to the caster (e.g. RTCM from an RTKBase station).
-
-Four authentication-mode handshakes are commonly seen in the wild:
-
-- `legacy` — `SOURCE <mp>` over plain TCP, rtk2go accepts this.
-- `hybrid` — `SOURCE <mp>` plus a Basic Auth header. SNIP accepts this.
-- `ntripv1` — `POST` over HTTP/1.0.
-- `ntripv2` — `POST` over HTTP/1.1 with `Ntrip-Version: Ntrip/2.0`.
-
-The upstream client's `_connect()` method handles only the download handshake.
-Three options to add upload:
-
-1. **Fork the upstream package.** Maintain a copy in this repo. Heavy
-   maintenance burden.
-2. **Submit a PR upstream.** Slow turn-around; upstream may not accept the
-   shape we need.
-3. **Subclass the upstream client locally** and override the connection method
-   to write a different handshake. Light footprint.
-
-## Decision
-
-Subclass locally. [ntrip/lib/ntrip-client.js](../../../ntrip/lib/ntrip-client.js)
-defines `NtripClientUploader extends NtripClient` and overrides `_connect()`
-to emit the right handshake string per `authmode`.
-
-The constructor also validates CR/LF in `mountpoint`/`username`/`password` to
-prevent header injection — the rejection happens at instance construction so
-malicious config never reaches the wire.
-
-## Consequences
-
-**Positive**
-
-- No fork to maintain. Upstream upgrades flow through (`npm update`).
-- All upload-specific logic is in one file, easy to audit.
-- The CR/LF guard is co-located with the only code that interpolates those
-  fields, minimising the chance of a future caller bypassing it.
-
-**Negative**
-
-- `_connect()` is a *full replacement*, not a delegation. Any improvement
-  upstream makes to the connection lifecycle (timeout handling, IPv6, keep-
-  alive, TLS upgrade) will not propagate into our uploader path.
-- The subclass depends on internal-ish state of the parent (`this.client`,
-  `this.timeout`, `_onError`, `_onData`). A breaking refactor upstream would
-  surface as a runtime error in this package.
-- The fork-by-extension makes a future TLS migration harder than it would be
-  in a from-scratch implementation.
-
-**Trade-offs**
-
-- Picking this over a full fork chose *easy upstream upgrades* over *insulation
-  from upstream API churn*. The upstream package has been stable for years, so
-  the bet has paid off so far.
-
-## Related
-
-- Code: [ntrip/lib/ntrip-client.js:1-100](../../../ntrip/lib/ntrip-client.js#L1-L100)
-- Referenced in: [Refactoring Recommendations §3](../refactoring-recommendations.md)
-- Related ADRs: [ADR-0004](0004-stateful-handshake-interception.md) (handshake state machine sits on top of this subclass)

package/doc/architecture/adr/0003-two-output-decoder-design.md

@@ -1,73 +0,0 @@
-# ADR-0003: Two-output `[ok, error]` convention for decoders / encoder
-
-## Status
-
-Accepted in the original design, **reaffirmed in 0.2.6** after a brief
-deviation in 0.2.5 that added `node.error()` calls inside the catch blocks.
-
-## Context
-
-Each of `RtcmDecoder`, `NmeaDecoder`, `NmeaEncoder` can fail per message —
-unexpected payload type, malformed bytes, unknown sentence/message ID. There
-are two idiomatic Node-RED patterns to report such failures:
-
-- **`node.error(err, msg)`** — logs to the Node-RED `[error]` log and, with the
-  `msg` second argument, hands the message off to any wired Catch node.
-- **A second output port** — `node.send([okMsg, errMsg])`. Flows wire the
-  second port to a debug node, MQTT publish, in-memory queue, etc.
-
-Both are legitimate. The choice matters when the decoder is fed high-rate
-mismatched binary — for example, the README's own demo flow wires an
-`NmeaDecoder` onto an `NtripClient` download output as an illustration of
-"the stream can be split", even though RTK2Go only emits RTCM. Every byte that
-arrives produces a NMEA decode failure.
-
-In 0.2.5 the catch blocks called both `node.send` *and* `node.error`. Users
-running the demo immediately saw a flood of:
-
-```
-12 May 19:20:21 - [error] [NmeaDecoder:fa8…] Error: NMEA decode exception: Invalid delimiter (expected $ or !, got �)
-```
-
-— one per chunk, several per second. The log became unusable.
-
-## Decision
-
-Per-message decode failures are reported on the **second output only**, never
-via `node.error`. `node.error` is reserved for unhandled-state conditions
-(node construction failure, unsupported configuration) where the node can no
-longer make forward progress.
-
-If a downstream flow wants centralised error handling, it should wire the
-second output to its own Catch-equivalent — typically a Function node that
-logs and forwards.
-
-## Consequences
-
-**Positive**
-
-- Decoders fed mismatched binary stop polluting the Node-RED error log.
-- The error output port is opt-in: ignore it and errors are silently dropped
-  (the decoder still bumps `invalidMessagesReceived` and updates the status
-  badge, so the user can tell from the editor that something is wrong).
-- Behaviour is consistent across all three transformer nodes.
-
-**Negative**
-
-- Users coming from packages that use `node.error` for everything need to wire
-  the second output explicitly — a small learning-curve cost.
-- The Catch-node integration that `node.error` provides is lost. A workaround
-  is to chain a Function node that calls `node.error()` if the user wants
-  Catch firing.
-
-**Trade-offs**
-
-- This favours **operability over discoverability** — a quiet error log is
-  more important than out-of-the-box Catch integration, given the documented
-  demo wiring.
-
-## Related
-
-- Code: [ntrip/nodes/nmea-decoder-node.js:33-42](../../../ntrip/nodes/nmea-decoder-node.js#L33-L42), [ntrip/nodes/rtcm-decoder-node.js:35-55](../../../ntrip/nodes/rtcm-decoder-node.js#L35-L55), [ntrip/nodes/nmea-encoder-node.js:155-166](../../../ntrip/nodes/nmea-encoder-node.js#L155-L166)
-- Regression spec: [test/nmea-decoder.spec.js](../../../test/nmea-decoder.spec.js) `does not call node.error on decode failure (regression: log flood)`
-- CHANGELOG: 0.2.6 "Fixed regressions introduced in 0.2.5"

package/doc/architecture/adr/0004-stateful-handshake-interception.md

@@ -1,74 +0,0 @@
-# ADR-0004: Stateful handshake interception in the NtripClient
-
-## Status
-
-Accepted in 0.2.5.
-
-## Context
-
-The NTRIP caster replies to a successful connection with one of:
-
-- `ICY 200 OK\r\n\r\n` followed immediately by the correction stream.
-- `ICY 406 ...\r\n\r\n` (rejected — bad credentials, etc.).
-- `SOURCETABLE 200 OK\r\n\r\n` followed by the source table (returned when the
-  client did not specify a mountpoint, or specified an invalid one).
-
-These first-byte replies need to drive the node's status badge: green
-"connected", red "rejected", red "no mountpoint". After the handshake is
-processed, all subsequent bytes are application data (RTCM in download mode,
-mountpoint advertisements in upload reverse channel).
-
-Up to 0.2.4 the `'data'` listener ran `data.toString().startsWith('ICY 200 OK')`
-on every incoming chunk. This was wrong for two reasons:
-
-1. **The check inflated the message counter.** Each control reply bumped
-   `messagesReceived`, polluting the status badge.
-2. **It could drop RTCM bytes.** TCP is byte-stream — when the caster sent
-   `"ICY 200 OK\r\n\r\n" + firstRtcmFrame` in one segment, the prefix match
-   succeeded and the whole chunk (including the RTCM tail) was discarded
-   instead of forwarded.
-
-## Decision
-
-Maintain a `connected: boolean` flag on the node instance. The `'data'`
-listener checks the flag:
-
-- **`!connected`** — look at the first ~64 bytes of the chunk for an `ICY`
-  or `SOURCETABLE` prefix. If found, update status accordingly and consume the
-  handshake. If `ICY 200 OK` was found, also split at `\r\n\r\n` and forward
-  the trailing bytes as the first real data frame. Either way, set
-  `connected = true` (or, for rejection paths, leave `connected = false` and
-  log the error).
-- **`connected`** — every byte is application data; just forward it and bump
-  the counter.
-
-The flag is reset to `false` on the `'close'` event so the next reconnect
-re-enters the handshake state.
-
-## Consequences
-
-**Positive**
-
-- No byte loss at the handshake boundary.
-- Counter reflects application data only.
-- Behaviour after reconnect matches behaviour on first connect — no special
-  case for reconnects.
-
-**Negative**
-
-- Two paths in the data listener that future maintainers must keep aligned.
-- A spec for the trailing-bytes split would need a fake caster — currently
-  covered by manual testing only. See
-  [Future Improvements](../future-improvements.md).
-
-**Trade-offs**
-
-- Choosing a state-machine over a "stateless prefix check every time" approach
-  trades minimal code complexity (one extra boolean) for correct behaviour on
-  the boundary case.
-
-## Related
-
-- Code: [ntrip/nodes/ntrip-client-node.js:75-115](../../../ntrip/nodes/ntrip-client-node.js#L75-L115)
-- CHANGELOG: 0.2.5 "Fixed NTRIP client node — Handshake detection is now stateful"
-- Related ADRs: [ADR-0002](0002-ntrip-uploader-extension.md) (the underlying client this layer sits on)

package/doc/architecture/adr/0005-rtcm-partial-frame-buffer.md

@@ -1,87 +0,0 @@
-# ADR-0005: Carry-over buffer for partial RTCM frames
-
-## Status
-
-Accepted in 0.2.5.
-
-## Context
-
-RTCM 3 frames are variable-length and routinely cross TCP packet boundaries.
-A typical RTCM 1077 (MSM7 GPS) frame is ~200 bytes; an MTU is ~1460 bytes
-payload — perfectly possible for a frame to span two TCP segments, and very
-common when many frames are sent back-to-back.
-
-The upstream `@gnss/rtcm` library's `RtcmTransport.decode(buffer)`:
-
-- Returns `[message, length]` if `buffer` starts with a complete frame.
-- Throws if the buffer starts with what looks like an RTCM frame but ends
-  before the frame does.
-
-Up to 0.2.4 the decoder consumed one chunk at a time without any
-buffer-carry-over: every throw inside the chunk caused the loop to break and
-any trailing bytes were discarded. With ~5 frames per packet boundary and
-~100 frames/s, this lost ~5 % of frames on a busy stream.
-
-## Decision
-
-Carry partial-frame bytes across input events:
-
-```javascript
-node.pendingBuffer = Buffer.alloc(0);
-
-on('input', msg) {
-    let buffer = pendingBuffer.length > 0
-        ? Buffer.concat([pendingBuffer, msg.payload])
-        : msg.payload;
-
-    while (buffer.length > 0) {
-        try {
-            [message, length] = RtcmTransport.decode(buffer);
-        } catch (ex) {
-            // Likely partial frame — keep buffer for next chunk.
-            if (buffer.length > 64KB) {
-                // Garbage cap — emit error and clear.
-                emit_error(); buffer = empty;
-            }
-            break;
-        }
-        if (length <= 0 || length > buffer.length) break;   // forward-progress guard
-        emit_decoded(); buffer = buffer.slice(length);
-    }
-    pendingBuffer = buffer;
-}
-```
-
-The 64 KB cap stops the buffer growing unboundedly when the upstream feeds
-non-RTCM bytes. The forward-progress guard stops a hypothetical infinite loop
-on a zero-length decode.
-
-## Consequences
-
-**Positive**
-
-- Frames that straddle TCP boundaries are decoded correctly — no frame loss
-  in normal operation.
-- The cap means a misconfigured flow (e.g. RTCM decoder fed NMEA) eventually
-  produces an error rather than running out of memory.
-- The forward-progress guard makes the loop terminate under any decoder
-  behaviour.
-
-**Negative**
-
-- The node now holds a per-instance buffer up to 64 KB. For 100 instances in
-  one flow that's 6.4 MB worst-case — not significant, but worth noting.
-- Decode latency at the chunk boundary is slightly higher: the decoder has to
-  retry as more bytes arrive. In practice this is one extra round of
-  `decode()` per chunk.
-
-**Trade-offs**
-
-- Chose **correctness on stream boundaries** over **per-call statelessness**.
-  A stateless decoder would be easier to reason about, but would lose frames.
-
-## Related
-
-- Code: [ntrip/nodes/rtcm-decoder-node.js:14-78](../../../ntrip/nodes/rtcm-decoder-node.js#L14-L78)
-- Regression spec: [test/rtcm-decoder.spec.js](../../../test/rtcm-decoder.spec.js) `reassembles a frame split across two input events (carry-over buffer)`
-- CHANGELOG: 0.2.5 "Fixed RTCM decoder node — Frames that straddle TCP packet boundaries are now buffered"

package/doc/architecture/adr/0006-nmea-multi-sentence-split.md

@@ -1,66 +0,0 @@
-# ADR-0006: Multi-sentence splitting in the NMEA decoder
-
-## Status
-
-Accepted in 0.2.5.
-
-## Context
-
-A serial GNSS receiver typically emits several NMEA sentences as a batch each
-cycle (e.g. `$GPGGA…\r\n$GPRMC…\r\n$GPGSA…\r\n$GPGSV…\r\n`). Likewise, a TCP
-producer of NMEA data may pack multiple sentences into one segment.
-
-Pre-0.2.5 the decoder called `NmeaTransport.decode(buffer)` exactly once on
-whatever it received. If the input contained more than one sentence, only the
-first decoded successfully — the trailing sentences were either lost
-(`NmeaTransport` silently took the prefix) or caused the whole call to throw
-(if the parser was strict). The README claimed the decoder accepted "either a
-single or multiple NMEA messages" — that was untrue.
-
-Two approaches to fix:
-
-1. **Buffer-and-split.** Treat the input as a string, split on `\r\n` (or
-   `\n`), trim each piece, decode each non-empty piece.
-2. **Push-down to the library.** Ask `@gnss/nmea` to handle multi-sentence
-   input. Out of scope — would require upstream changes.
-
-## Decision
-
-Split-and-decode locally. The decoder splits on `/\r?\n/`, trims each chunk,
-skips empty ones, and decodes each remaining sentence individually. Each
-successful decode produces its own output message — so a batch of four
-sentences emits four output messages, not one.
-
-Errors are reported per-sentence. The error output uses the original
-`msg.payload` (or `msg.payload.nmeaMessage`) as `input` so a downstream
-debugger sees the raw bytes that arrived, not the per-sentence string that
-failed (see [Behavioural Design](../behavioural-design.md)).
-
-## Consequences
-
-**Positive**
-
-- Matches the documented behaviour ("accepts single or multiple sentences").
-- Downstream wiring is uniform: one decoded sentence = one output message,
-  regardless of how the producer chose to chunk.
-- Naturally handles trailing/leading whitespace and stray empty lines.
-
-**Negative**
-
-- A chunk that contains both valid and invalid sentences fans out a mix of ok
-  and error messages — downstream nodes that assumed "one input ⇒ one output"
-  need adjustment.
-- Per-sentence trimming adds a small amount of work compared to a single
-  parser invocation. For typical NMEA volumes this is negligible.
-
-**Trade-offs**
-
-- Picked **per-sentence semantics** (one in, N out) over **chunk semantics**
-  (one in, one out) because the value of getting structured per-sentence
-  output far outweighs the slight asymmetry.
-
-## Related
-
-- Code: [ntrip/nodes/nmea-decoder-node.js:50-89](../../../ntrip/nodes/nmea-decoder-node.js#L50-L89)
-- Regression spec: [test/nmea-decoder.spec.js](../../../test/nmea-decoder.spec.js) `splits a multi-sentence chunk into separate output messages`
-- CHANGELOG: 0.2.5 "Fixed NMEA decoder node — A single chunk containing multiple `\r\n`-delimited NMEA sentences is now decoded sentence by sentence"