86 lines
4.5 KiB
Markdown
86 lines
4.5 KiB
Markdown
---
|
||
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.
|
||
|
||
## 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.
|