Drogheda/06-Testing-Validation/2026-06-20_Drogheda_Bench-Log-Analysis_v1.0.md

234 lines
13 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: "Drogheda HBOX — Bench Log + Config Analysis (20 Jun 2026)"
created: 2026-06-20
revised: 2026-06-20 (rev 2 — corrected swap labels + config files)
owner: Leo Rodriguez (Helgen)
status: draft-for-review
type: test-evidence
scope: 7 swap-matrix bench captures + NTRIP-caster & u-blox config files, v1 firmware
source_logs: "Drive: 06-Testing-Validation/Logs Prueba 20JUN26 (*_GPS.ubx, *_NTRIP.log, 4G_NTRIP_HelgenSRV-NMEA.txt, configuration_GNSS.txt)"
tooling: "06-Testing-Validation/log-analysis/analyze_logs.py + dashboard.html"
tags: [drogheda, hbox, rtk, ntrip, gnss, bench-test, rca, thermal, config]
---
# Drogheda HBOX — Bench Log + Config Analysis
**One-line verdict (rev 3):** Of 7 bench captures, 4 pass the comms chain and
**only 1 is a confirmed fault** — `RTK21NTRIP21` (master 21: modem won't register,
511 AT errors). The two "no-forward" captures are **indeterminate**, not failed: the
NTRIP-master console can't prove forwarding either way (the healthy RTK14 baseline
logs the same sparse console). The confirmed fault reproduces cold → not heat. The
u-blox config is correct (GGA on UART2 @1 Hz); corrections come from the **free public
rtk2go caster**, and no unit reached RTK fix (SPS only — bench sky + corrections rarely
applied).
> **Rev-3 correction (post-baseline, 2026-06-20).** A healthy RTK14 capture
> (`RTK14NTRIP14_440`) — **proven forwarding 1 Hz to the server by tcpdump and live in
> Wialon** — logs the *same* sparse NTRIP-master console (only `NET`; no `State main` /
> `UDP Bytes sent`) as the captures I had called "no-forward." **Absence of those console
> lines does not mean a unit failed.** So the earlier **"master-14 ingest fault" is
> withdrawn** (master 14 demonstrably forwards — it *is* the baseline). Only
> `RTK21NTRIP21` is a confirmed fault; `RTK14NTRIP14` and `RTK21NTRIP14` are
> **indeterminate**. §§3–4 below predate this and are superseded on the no-forward point.
> The structural fix: make the **Blackpill log fix + packets + state** so health is
> unambiguous — see `04-Source-Code/firmware/docs/LOGGING-SPEC.md`.
> **Baseline (RTK14NTRIP14_440), 3 views:** receiver `.ubx` = 341 epochs, 100% valid,
> **12 sats, HDOP 0.75, SPS** (C/N0 ~20); server tcpdump = **984 pkts, steady 1 Hz, max
> gap 0.86 s, zero dropouts** to `…:5010`; master console = registered only. Healthy
> end-to-end **but SPS, not RTK** (corrections not applied). Use as the healthy-GNSS
> baseline; raise the bar to a fix≥4 capture once corrections work.
> **Rev-2 note:** two captures were re-labelled by their swap pair —
> `RTK04NTRIP24 → RTK24NTRIP04` and `RTK14NTRIP21 → RTK21NTRIP14` (byte-identical,
> md5-verified). This **moved the no-forward fault from "board 14" to "master 14"**
> (the element common to both no-forward captures). Earlier drafts said board 14.
---
## 1. Executive summary
Two log streams were captured per unit on the Querétaro bench (20 Jun 2026):
`*_GPS.ubx` (the ZED-F9P over USB, via u-center) and `*_NTRIP.log` (the 4G NTRIP
Master console). Filenames `RTK<bb>NTRIP<mm>` = RTK board `bb` + NTRIP master `mm`,
forming a **swap matrix** that isolates board vs master faults. Two config files
were also analysed: the 4G master config and the F9P config dump.
**What the bench can / cannot show:** it validates the **integration/comms chain**
(boot → GNSS position → cell registration → UDP forwarding). It does **not** validate
RTK accuracy (needs open sky + live corrections) and **cannot** measure heat (v1 has
no temperature channel; the bench runs cold).
| Outcome | Captures | Why |
|---|---|---|
| **Healthy (bench)** | RTK17NTRIP17, RTK24NTRIP04, RTK24NTRIP24, RTK25NTRIP25 | boot → GNSS alive → TELCEL registered → UDP forwarding |
| **Failed — no forwarding** | RTK14NTRIP14, RTK21NTRIP14 | GNSS valid on USB, modem registered, but **0 UDP** and no state machine — **both use master 14** |
| **Failed — modem** | RTK21NTRIP21 | modem **never registers** (`0xFFFFF`, **511× AT-parser errors**), stuck in init |
**Isolated faults:**
1. **NTRIP master 14 — GGA ingest.** With *two different* GPS boards (14 and 21),
master 14 forwarded **nothing** while the F9P produced valid NMEA on USB. The
common element is the master → **master 14's serial input / NMEA ingest**, not the
board. (See config note: GGA *is* enabled on UART2, so it is not a message-rate
error.)
2. **NTRIP master 21 — LTE modem.** Will not register on Telcel; continuous
AT-parser errors. The GPS feeding it (board 21) is fine.
Neither is the GNSS receiver; neither needs heat.
---
## 2. The heat question (headline for the deck)
**These logs do not prove the field failures are thermal — and that is useful.**
They are room-temperature bench captures with no thermal instrumentation, yet they
reproduce hard faults **cold** (master-14 ingest, master-21 modem). A fault you can
reproduce cold is **not** caused by heat → the fleet problem is **not a single
thermal cause**, matching the RCA's "don't collapse everything into heat."
This neither confirms nor refutes the **field** thermal hypothesis (18650 / boost / modem
in a sealed cabinet in Veracruz sun, RCA H1/H7) — that needs a **thermocouple soak**
of a representative cabinet and/or **v2 MCU-temp logging**.
---
## 3. Per-device findings
Bench context is common: indoor/obstructed sky → **C/N0 ≈ 17–21 dB-Hz**, high HDOP,
**zero RTK fixes** anywhere. Read the GNSS columns as "is the receiver alive and
emitting valid NMEA," not as a positioning grade.
| Capture | Board / Master | Status | GNSS (USB) | Cell | UDP out | dBm | AT err | Headline |
|---|---|---|---|---|---|---|---|---|
| **RTK24NTRIP04** | 24 / 04 | 🟢 Healthy | alive, SPS, 98% valid | TELCEL | **1555 dg** | −51 | 0 | full chain OK (master 04 good) |
| **RTK24NTRIP24** | 24 / 24 | 🟢 Healthy | alive, SPS, 85% valid | TELCEL | **1831 dg** | −51 | 0 | full chain OK |
| **RTK25NTRIP25** | 25 / 25 | 🟢 Healthy | alive, SPS, 100% valid | TELCEL | **2413 dg** | −51 | 0 | best forwarder |
| **RTK17NTRIP17** | 17 / 17 | 🟢 Healthy | alive, 12% valid (poor sky this run) | TELCEL | **2267 dg** | −63 | 0 | comms healthiest; GNSS had no sky |
| **RTK14NTRIP14** | 14 / 14 | 🔴 Failed | **alive, SPS, 100% valid** | TELCEL | **0** | −75 | 0 | registered but forwards nothing |
| **RTK21NTRIP14** | 21 / 14 | 🔴 Failed | **alive, SPS, 100% valid, 10 sats** | TELCEL | **0** | −83 | 0 | same master-14 symptom, other board |
| **RTK21NTRIP21** | 21 / 21 | 🔴 Failed | alive, SPS, 97% valid | **NOT reg** | **0** | −113 | **511** | modem never attaches |
---
## 4. Swap-matrix analysis (isolation)
**By NTRIP master:**
| Master | Captures | Result |
|---|---|---|
| 04, 17, 24, 25 | one each | **healthy** — forwards position |
| **14** | RTK14NTRIP14 (board 14) **and** RTK21NTRIP14 (board 21) | **both fail to forward** despite valid USB NMEA |
| **21** | RTK21NTRIP21 (board 21) | modem **not registered**, AT errors |
→ Master 14 fails with two different boards → **fault is master 14's NMEA ingest**
(serial input), confirmed common factor. Master 21 is a modem-registration fault.
Masters 04/17/24/25 are good.
**By RTK board:**
| Board | Captures | Read |
|---|---|---|
| 24 | NTRIP04 (✓), NTRIP24 (✓) | **healthy with two masters** → board 24 GNSS + UART2 output good |
| 17, 25 | one each (✓) | healthy |
| 21 | NTRIP14 (master-14 fault), NTRIP21 (master-21 fault) | GNSS alive on USB; its failures belong to the masters it was paired with |
| 14 | NTRIP14 only (master-14 fault) | GNSS alive on USB; **board-14 UART2 output unproven** — only ever paired with the bad master 14 |
**Open item:** test board 14 (and board 21) with a *known-good* master to clear/convict
their UART2 output; test master 14 with a known-good board to confirm the ingest fault.
---
## 5. Configuration findings (from the two config files)
### 5.1 4G NTRIP Master (`4G_NTRIP_HelgenSRV-NMEA.txt`)
| Item | Value | Note |
|---|---|---|
| NTRIP caster | **rtk2go.com : 2101**, mountpoint **HelgenTestStation** | **free public community caster — best-effort, no SLA** |
| APN | internet.itelcel.com (Telcel) | correct |
| UART baud (to F9P) | 115200 | matches F9P UART2 baud |
| NTRIP restart timer | **300 s** | matches "NTRIP DELAY n/300" in the logs |
| Telemetry out | UDP → Helgen server :5010, device **H0014** | position forwarding path |
| PointPerfect | configured but disabled | not in use |
> **Flag:** corrections from a **free public caster (rtk2go)** is a reliability risk
> for a production fleet and a plausible reason the correction client rarely connected
> and no unit reached RTK. Move production to a **dedicated/own caster (HelgenSRV)**.
### 5.2 ZED-F9P (`configuration_GNSS.txt`, UBX CFG-VALGET dump)
| Item | Value | Note |
|---|---|---|
| Model / FW | ZED-F9P, HPG 1.32 | rover-grade |
| Mode | **Rover** (TMODE=0) | correct (not a base) |
| Update rate | **1 Hz** (1000 ms) | correct |
| **GGA on UART2** | **ENABLED (1/epoch)** | the feed the master needs — **correctly configured** |
| RMC on UART2 | ENABLED (1/epoch) | not required by NTRIP, harmless |
| UART2 | enabled · NMEA-out + RTCM3-in · 115200 | textbook 4G-NTRIP rover wiring |
| USB | full NMEA (GGA/GLL/GSA/GSV/RMC/VTG) | matches the `.ubx` captures |
| **Dump layer** | **RAM only** | **flash persistence NOT verified** |
> **Two implications:**
> 1. **The message config is correct** — GGA *is* on UART2 @1 Hz. So master 14's dead
> feed is **not** a missing-GGA setting → it's the master's ingest (or a per-unit
> deviation), reinforcing §4.
> 2. **The dump is RAM-layer only.** A RAM-only config is **lost on every power cycle**
> (the classic "forgot Save Config to flash" trap). Confirm the **FLASH layer** on
> each unit — a unit that boots without GGA-on-UART2 would feed the master nothing.
---
## 6. Recommendations / next steps
1. **Master 14 — bench the ingest.** Feed master 14 a known-good GGA stream (or pair
with a healthy board) and watch for `State main` + `UDP Bytes sent`. If still zero,
the master's serial-in / firmware is the fault → swap/repair the master.
2. **Master 21 — modem triage.** Re-test registration with a known-good SIM + antenna;
511 AT-parser errors + `0xFFFFF` point at the LTE modem / its AT link / power. Swap
the modem to confirm.
3. **Persist & verify the F9P config to FLASH** on every unit (u-center → Save Config),
then dump the **flash layer** to prove GGA-on-UART2 survives a power cycle. Check the
simpleRTK2B Pro **XBEE↔UART2 switch** too (UART2 is off by default).
4. **Move corrections off rtk2go** to a dedicated caster (HelgenSRV) with uptime, then
**re-run outdoors** with open sky to actually grade RTK (quality 4/5).
5. **Close the heat question separately** — thermocouple soak of a sealed cabinet in
full sun and/or v2 MCU-temp logging.
6. **Retranslator log (separate effort)** — pair this unit-side analysis with the
backend (HOL-stall / anti-jump) evidence for the full RCA picture.
---
## 7. Method & reproducibility
- **Tool:** `log-analysis/analyze_logs.py` (Python stdlib). Parses NMEA (GGA/RMC/GSV) +
UBX from `.ubx`, and the GPTXT diagnostic stream (`State main`, `NET`, `UDP Bytes
sent`, `NTRIP DELAY`, `SM_REG`, AT errors) from `.log`. Emits per-device metrics,
a swap-matrix with **common-factor isolation**, and per-device time-series.
- **Dashboard:** `log-analysis/dashboard.html` — dark (GitHub Dark-Dimmed),
self-contained: config summary, signal-flow diagram (marks the break + names the
common master), zoomable time-series, status board, swap matrix.
- **Config decode:** 4G master `$$$AS+` params; F9P UBX **CFG-VALGET** keys
(CFG-MSGOUT-NMEA_ID_GGA_UART2, CFG-UART2*, CFG-RATE*, CFG-TMODE-MODE).
- **Re-run:** `python3 analyze_logs.py --in raw_cur --out out && python3 build_dashboard.py`
- **Validation:** classification spot-checked vs raw logs; the two relabels were
md5-verified byte-identical to the originals.
**Caveats:** ~10-min captures; indoor bench sky; v1 (no temperature); F9P config dump
is RAM-layer only; `ntr/tcp/pp` enum values inferred from behavior. None affect the
pass/fail conclusions, which rest on presence/absence of UDP forwarding, cellular
registration, and the swap-matrix common factor.
---
## 8. Glossary
- **GGA fix quality:** 0 no-fix · 1 SPS · 2 DGPS · **4 RTK-fixed** · **5 RTK-float**.
- **C/N0 (dB-Hz):** satellite carrier-to-noise; ~35–50 open sky, ~20 indoors.
- **NTRIP master state `main,ntr,tcp,pp,ntr_srv,udp`:** main=4 operational / 1 init;
udp=1 forwarding position out; ntr = correction-client state (0 idle … 2 active).
- **`NET,<op>,<dBm>,<MCCMNC>`:** TELCEL = registered; **`0xFFFFF` = not registered**.
- **NTRIP DELAY n/300:** seconds since last correction vs the 300 s restart watchdog.
- **GGA→UART2:** whether the F9P's GGA is reaching the 4G master over UART2 (XBee
socket). Inferred from the master running its loop + forwarding UDP.