Helgen-Services/Drogheda
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
2b03a7ee02
Drogheda/06-Testing-Validation/2026-06-20_Drogheda_GNSS-Findings-Summary.md

6.2 KiB
Raw Blame History

title created owner type purpose scope tags
Project Drogheda — GNSS Findings Summary (Beamer source) 2026-06-20 Leo Rodriguez (Helgen) findings-summary source material for a later LaTeX Beamer deck 20 Jun 2026 bench captures + RTK14_440 healthy baseline + config files
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.