4.5 KiB
4.5 KiB
| 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 |
|
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
NETlines, 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-toolsrepo ongit.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
- Persist the F9P config to FLASH and verify (RAM-only is a power-cycle risk); check
the simpleRTK2B Pro
XBEE↔UART2switch. - Move corrections off rtk2go to a dedicated caster (HelgenSRV) with uptime.
- Open-sky RTK retest with a verified caster → confirm fix ≥4/5.
- Connect the Blackpill with v2.1 logging → capture a true per-unit health log (drops into the Log Explorer as a fifth view).
- Modem triage master 21 (known-good SIM/antenna; swap to confirm).
- 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.