Drogheda/06-Testing-Validation/2026-06-20_Drogheda_GNSS-Findings-Summary.md

110 lines
6.2 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

---
title: "Project Drogheda — GNSS Findings Summary (Beamer source)"
created: 2026-06-20
owner: Leo Rodriguez (Helgen)
type: findings-summary
purpose: source material for a later LaTeX Beamer deck
scope: 20 Jun 2026 bench captures + RTK14_440 healthy baseline + config files
tags: [drogheda, hbox, gnss, rtk, ntrip, findings, presentation]
---
# GNSS Findings Summary — Project Drogheda (20 Jun 2026)
> Presentation-ready. Each `##` is a candidate slide; bullets are speaker points.
> Full detail: `2026-06-20_Drogheda_Bench-Log-Analysis_v1.0.md`. Tooling: `log-analysis/`.
## 1 · What we did
- Analyzed three independent log views per unit from the 20 Jun bench: u-blox receiver
(`.ubx`), 4G-NTRIP-Master console (`.log`), and a server-side retranslator capture
(tcpdump). Decoded the NTRIP-caster and ZED-F9P config files.
- Built local tooling (in-browser **Log Explorer**, batch analyzer, dark dashboard) and
established a **healthy GNSS baseline**.
## 2 · Headline: the GNSS receivers are fine — RTK is not being achieved
- **Every board produces valid NMEA** — good satellite counts (6–12) and HDOP (≈0.75–1.5).
The **ZED-F9P is not the failure.**
- **No unit reached RTK fix.** Every epoch is **SPS (quality 1)**; zero quality 4/5.
Centimetre positioning was never delivered.
- **Why:** corrections are not being applied — a combination of (a) corrections sourced
from a **free public caster (rtk2go.com, no SLA)**, (b) the NTRIP correction client
rarely reaching "connected," and (c) bench/indoor sky. The F9P config is actually
**correct** (GGA on UART2 @1 Hz) — but the dump is **RAM-only; flash persistence is
unverified** (a config lost on power-cycle would silently break the feed).
## 3 · The healthy baseline (RTK14_440) — what "good" looks like today
- Proven **end-to-end**: **984 packets, steady 1 Hz, zero dropouts**, valid Querétaro
position delivered to the server — live in Wialon and the monitor.
- **12 sats, HDOP 0.75** — excellent geometry. **But SPS, not RTK.**
- So **"healthy delivery" ≠ "RTK."** The baseline is *healthy SPS + reliable delivery*;
raise the bar to a fix-≥4 capture once corrections work.
## Update — 22 Jun 2026: live field capture + two ceilings on RTK
> A fresh live `udp/5010` server capture (not the 20-Jun bench) caught two units at once.
- **Telemetry forwarding CONFIRMED.** Enabling `$PUBX` (u-blox *proprietary* `$P…`, the
same class as our planned `$PHLG`) on the F9P **UART2** → it reaches the server **intact**,
next to GGA/RMC. The 4G NTRIP Master is a **transparent forwarder**, so **in-band unit
health (`$PHLG`) to the server is viable** — proven with zero extra hardware.
- **A natural A/B on RTK** (same capture):
- **H0014 (Querétaro bench)** — RSSI **−93**, **SPS (quality 1)**. It sits in a **basement**.
- **H0017 (Veracruz / ICAVE field)** — RSSI **−51**, **DGPS (quality 2, RMC mode `D`,
base id 0133)** — i.e. it **is** applying corrections.
- **Two independent ceilings on RTK** (refines §2's "RTK not achieved"):
1. **Sky / antenna placement** — RTK fix is carrier-phase; a **basement caps it** no matter
how good the corrections are. (Per Leo: bench antenna placement — not fixable there.)
2. **Corrections pipeline** — H0017 has good sky + signal yet only reaches **DGPS, not RTK
(4/5)**, pointing back at the **free rtk2go caster + RAM-only F9P config** as a *separate*
limit present everywhere.
- **Cleanest next test:** one **open-sky capture** (roof/outdoors) with a **proper caster +
FLASH-saved config** — that isolates the two ceilings and shows whether a fix ≥4 is reachable.
- **Watchdog implication:** a healthy unit can legitimately sit at SPS/DGPS (basement, or field
on a weak caster) → **never power-cycle on no-RTK alone** (already enforced by the v2.1
SPS-thrash guard; the v2.2 `$PHLG` will make this visible per-unit).
## 4 · The diagnostic trap (and a retraction)
- The **4G-NTRIP-Master console is an unreliable health signal.** The provably-healthy
baseline logs the **same sparse console** (only cellular `NET` lines, no forwarding
lines) as units that *looked* failed.
- **Retraction:** the earlier "master-14 ingest fault" is **withdrawn** — master 14 is the
baseline and demonstrably forwards. **Only master 21 is a confirmed fault** (modem never
registers: `0xFFFFF` + 511 AT-parser errors).
- **Lesson:** per-unit health must come from a component that *parses the fix itself* — the
Blackpill — logged in a trustworthy form.
## 5 · Heat is not implicated by these logs
- Room-temperature bench captures, no thermal channel (v1). The faults reproduce **cold**,
so heat is **not** the cause of what we see here. The **field** thermal hypothesis stays
open — needs a thermocouple cabinet soak and/or v2 MCU-temp logging.
## 6 · Changes made this activity
- **Blackpill v2.1 logging spec** — replace the self-overwriting ANSI dashboard with a
**structured, timestamped, parseable** stream (state, fix, packets, battery, MCU temp,
recovery, **reset cause**). Makes per-unit health unambiguous from the unit's own log.
- **Log tooling** — `hbox-log-tools` repo on `git.helgen.dev`: in-browser Log Explorer
(parse + auto-plot + compare to baseline + PNG/SVG export), batch analyzer, dark dashboard.
- **Corrected analysis + findings doc** (the master-14 retraction above).
## 7 · Next steps
1. **Persist the F9P config to FLASH and verify** (RAM-only is a power-cycle risk); check
the simpleRTK2B Pro `XBEE↔UART2` switch.
2. **Move corrections off rtk2go** to a dedicated caster (HelgenSRV) with uptime.
3. **Open-sky RTK retest** with a verified caster → confirm fix ≥4/5.
4. **Connect the Blackpill** with v2.1 logging → capture a true per-unit health log
(drops into the Log Explorer as a fifth view).
5. **Modem triage master 21** (known-good SIM/antenna; swap to confirm).
6. **Thermal soak test** to settle the field heat hypothesis.
## One-line takeaway
> The radios work; we are delivering a **standalone-GPS** position reliably, **not RTK**.
> The blockers are the **correction source/persistence** and **observability** — both now
> addressed by config/caster changes and the new Blackpill logging + tooling.