TP25: Gehweg-Messung -- was eine WLAN-Uebergabe wirklich kostet

Die "~4 Sekunden je Wechsel" aus der Nachtmessung waren als Obergrenze markiert,
und die Vorsicht war berechtigt: 5 Pings/s auf das Telefon zeigen bei -48 bis
-55 dBm Uebergabekosten von 0 bis 2,6 s, meist unter einer halben Sekunde. Fast
Transition funktioniert. Der Zaehlerstand nach einer Neuanmeldung hatte die
Luecke vorgetaeuscht.

Der wahre Befund ist schlimmer und liegt woanders: bei -69 bis -77 dBm ist das
Telefon 6 bis 45 s nicht erreichbar, zweimal ueber 20 s am Stueck. Die Trennlinie
laeuft sauber entlang der Signalstaerke, nicht entlang der Wechsel -- es ist kein
Roaming-Problem, es ist ein Dead Spot.

Ehrlich dazu: ueber den ganzen Weg gingen 44 % der Pings verloren, und das ist
nicht alles Funk -- ein iPhone mit gesperrtem Display beantwortet ICMP verzoegert
oder gar nicht (RTT-Median 3,7 ms, Maximum 8,2 s). Power-Save haengt aber am
Display, nicht am Ort; dass alle langen Luecken in der schwachen Zone liegen und
alle kurzen in der starken, erklaert es nicht. Fuer eine exakte Zahl braucht es
ein waches Telefon.

tp6-monitor-core.sh bekommt eine Reconnect-Schleife: die SSH-Sitzung ist mitten
in der Messung weggebrochen und die Funkdaten endeten 2,5 Minuten vor dem
Ping-Mitschnitt -- ausgerechnet im interessanten Teil.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/messdaten/tp25-gehweg-20260821/markers.csv

@@ -0,0 +1,3 @@
+ts_epoch,ts_local,marker
+1787317400,15:03:20,WALK
+1787317722,15:08:42,CALL_END

docs/teilprojekte.md

@@ -1214,7 +1214,7 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
 - **Abh.:** keine harten. **TP15 ✅** (die zu versorgende Hardware steht und hat DC-Eingänge). Verwandt: **TP18** (Garage-Nodes brauchen je Site eine Stromversorgung), **TP11** (USV-Zustand ins Monitoring). **Kein Blocker für TP5/TP6.**
 - **Historie:** war bis 2026-08-16 Unterpunkt von TP15 („🔋 DC-USV: MeanWell LRS-150-48 + DDR-120-48 + LiFePO4 20Ah (~€190), 48V-Bus; CRS326 DC-input passt"). Vollständige Recherche inkl. Schaltbild, Effizienzvergleich und Gerätetabelle: `docs/hw-refresh-requirements.md §9` (+ §10 D/E/F für die offenen Fragen).
 
-### TP25 — WLAN-Stabilisierung ▸ 🔴 **JETZT KRITISCHER PFAD (2026-08-21) — Roaming gemessen, Befund liegt vor** — Sammel-TP für Christophs Beobachtungen 1–6
+### TP25 — WLAN-Stabilisierung ▸ 🔴 **JETZT KRITISCHER PFAD — Roaming gemessen (08-20), Übergabekosten gemessen (08-21): Dead Spot statt Roaming-Problem** — Sammel-TP für Christophs Beobachtungen 1–6
 > 🆕 **Messung 2026-08-20/21: [`tp25-wlan-roaming-messung-20260820.md`](tp25-wlan-roaming-messung-20260820.md)**
 > (Nebenprodukt der TP6-Messreihen, Core-Sampler im 2-s-Takt über 2,5 h, teils mit laufendem Videocall).
 > Drei Befunde:
@@ -1223,9 +1223,12 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
 > den Telefonier-Orten bei **−75 bis −80 dBm**.
 > **(B)** **Sticky Client:** ein Weg Küche → Kinderzimmer → Schlafzimmer → Terrasse, dreimal direkt an
 > ap1 vorbei (−43 dBm), **eine einzige Übergabe** — und die erst oben bei −73 dBm.
-> **(C)** **Band-Ping-Pong: 12 Wechsel in 9 Minuten** am selben Ort, immer ap2 5↔2,4 GHz. Je Wechsel
-> bis zu **4 s ohne Durchsatz** (⚠️ Obergrenze, s. Doku §5 — der saubere Test `ping -i 0.2 10.40.10.196`
-> während eines Spaziergangs steht aus).
+> **(C)** **Band-Ping-Pong: 12 Wechsel in 9 Minuten** am selben Ort, immer ap2 5↔2,4 GHz.
+> **(D) 2026-08-21 nachgemessen** (Gehweg, 5 Pings/s auf das Telefon, `docs/tp25-walk-messung.sh`):
+> die „~4 s je Wechsel" waren **Zählerartefakt** — bei **−48…−55 dBm** kostet eine Übergabe
+> **0 bis 2,6 s**, meist unter einer halben Sekunde, **Fast Transition funktioniert also**. Der wahre
+> Befund ist schlimmer und liegt woanders: bei **−69…−77 dBm** ist das Telefon **6 bis 45 s** nicht
+> erreichbar, zweimal über 20 s am Stück. **Nicht die Übergabe ist teuer, sondern die schwache Zone.**
 > **Und das passiert TROTZ aktivem 802.11k/v und FT** — live geprüft: `st-main` mit `rrm=yes`/`wnm=yes`,
 > `ft-over-ds=yes`. Die Merkregel `ref_ft_is_not_roaming` („11k/v fehlen") ist damit **historisch**.
 > **Reihenfolge der Maßnahmen** (Doku §6, respektiert die User-Randbedingung „kein neuer AP, solange

docs/tp25-wlan-roaming-messung-20260820.md

@@ -97,26 +97,59 @@ bisher an lokalen Ursachen geprüft wurde.
 
 ---
 
-## 5. Was die Lücke kostet — und was daran noch ungemessen ist
+## 5. Was die Lücke kostet — GEMESSEN am 2026-08-21
 
-Bei **jedem** beobachteten Wechsel steht in den Zählern des Managers für **rund 4 Sekunden** kein
-Durchsatz, danach folgen ~10 Sekunden mit halber PHY-Rate.
+**Methode:** `docs/tp25-walk-messung.sh` — 5 Pings/s **auf das Telefon** (`10.40.10.196`) plus
+Funk-Sampler im 1-s-Takt, während Christoph den Weg abgeht, den er beim Telefonieren wirklich geht.
+Kein Call, keine Last. 22 Minuten, 6.590 Pings, 10 AP-/Bandwechsel.
+Rohdaten: `docs/messdaten/tp25-gehweg-20260821/`.
 
-⚠️ **Diese 4 Sekunden sind eine Obergrenze, kein Beweis.** Nach einer Neuanmeldung beginnen die Zähler
-der Registration-Table bei null; ein Teil der Lücke kann Zähler-Artefakt statt echter Funkstille sein.
-Auch der Rücksprung von `uptime` auf `00:00:00` beweist **nicht**, dass keine Fast Transition stattfand —
-auch eine FT erzeugt am Zielradio einen neuen Eintrag.
+### 5.1 Das Ergebnis trennt sauber nach Signalstärke
 
-**Der saubere Test, der das entscheidet** (eine Zeile, read-only, beim nächsten Spaziergang mitlaufen
-lassen — vom Core, damit der Weg kurz ist):
+| Zeit | Wechsel | Signal | echter Paketverlust |
+|---|---|---|---|
+| 14:52:27 | ap2/5 → ap1/5 | −48 dBm | **2,6 s** |
+| 14:53:57 | ap1/5 → ap2/5 | −51 dBm | **keine messbare Lücke** |
+| 15:03:45 | ap2/5 → ap1/5 | −55 dBm | **0,2 s** |
+| 15:06:59 | ap1/5 → ap2/5 | −53 dBm | **2,0 s** |
+| 15:07:47 | ap2/2,4 → ap2/5 | −76 dBm | 0,4 s |
+| 15:07:07 | ap2/5 → ap2/2,4 | −76 dBm | **6,4 s** |
+| 15:08:17 | ap2/5 → ap2/2,4 | −69 dBm | **20,0 s** |
+| 15:08:30/33 | ap2 5↔2,4 (zweimal) | −77 dBm | **44,6 s** |
+| 15:09:28 | ap2/2,4 → ap2/5 | −76 dBm | **20,0 s** |
 
-```bash
-ping -i 0.2 10.40.10.196
-```
+🔴 **Die Trennlinie ist nicht der Wechsel, sondern das Signal.** Bei **−48 bis −55 dBm** kosten
+Übergaben **0 bis 2,6 s**, meist unter einer halben Sekunde — **Fast Transition funktioniert also.**
+Bei **−69 bis −77 dBm** kostet jeder Wechsel **6 bis 45 s**. Dort wechselt das Telefon nicht, es
+verliert die Verbindung.
 
-Ein Wechsel zeigt sich dann als **echter Paketverlust über N×200 ms**. Fällt dabei nichts aus, ist die
-Übergabe schnell und die 4 Sekunden waren Buchhaltung. Fallen 20 Pakete aus, ist es real — und dann ist
-es die Ursache für die Aussetzer im Call.
+### 5.2 Korrektur des Vorbefunds
+
+Die „~4 Sekunden je Wechsel" aus §4 waren als Obergrenze markiert — zu Recht: bei gutem Signal sind es
+**0,2 s**. Der Zählerstand nach einer Neuanmeldung hat die Lücke vorgetäuscht. **Was bleibt, ist der
+schlimmere Befund:** in der schwachen Zone ist das Gerät zweimal **über 20 Sekunden** nicht erreichbar.
+Ein Call ist da nicht gestört, er ist tot.
+
+### 5.3 Was diese Messung NICHT kann
+
+Über den ganzen Weg gingen **44 % der Pings** verloren — das ist nicht alles Funk. Ein iPhone mit
+gesperrtem Display beantwortet ICMP verzögert oder gar nicht; die RTT-Verteilung zeigt es (Median
+**3,7 ms**, 95. Perzentil **124 ms**, Maximum **8,2 s** = Aufwachen aus dem Ruhezustand).
+
+**Warum die Zuordnung oben trotzdem trägt:** Power-Save hängt am Displayzustand, nicht am Ort. Dass
+**alle** langen Lücken bei −69…−77 dBm liegen und **alle** kurzen bei −48…−55, lässt sich damit nicht
+erklären. Für eine Zahl auf zwei Stellen bräuchte es ein waches Telefon — am einfachsten mit laufendem
+Call, oder indem die Klick-Konsole **auf dem iPhone** offen bleibt (sie hält per Wake Lock das Display
+an und pollt alle 3 s).
+
+⚠️ **Werkzeug-Fund:** die SSH-Sitzung des Samplers ist um 15:09:57 weggebrochen
+(`Can't assign requested address`), die Funkdaten enden 2,5 Minuten vor dem Ping-Mitschnitt.
+`tp6-monitor-core.sh` hat deshalb jetzt eine Reconnect-Schleife und schreibt `RECONNECT` in die CSV.
+
+### 5.4 Die offene Frage an Christoph
+
+Die teure Zone liegt zeitlich bei **15:07–15:09**. **Wo warst du da?** Das ist der Dead Spot, und mit
+dem Raumnamen wird aus dem Befund eine Maßnahme.
 
 ---
 

docs/tp6-monitor-core.sh

@@ -77,8 +77,19 @@ echo "Sampler laeuft -> $OUT   (Takt ${INTERVAL}s${MAC:+, Client $MAC})"
 
 # Lokaler Zeitstempel beim Eintreffen der Zeile. Bewusst kein awk: das BSD-awk auf macOS
 # kennt systime()/strftime() nicht (das ist gawk).
-sshpass -p "$PW" ssh -o StrictHostKeyChecking=no -o ConnectTimeout=8 \
-        -o ServerAliveInterval=15 "admin@${ROUTER_IP}" "$ROS" 2>"${OUT%.csv}.stderr.log" \
-  | while IFS= read -r line; do
-      printf '%s,%s,%s\n' "$(date +%s)" "$(date +%H:%M:%S)" "$line" >> "$OUT"
-    done
+#
+# 🔴 Mit Reconnect-Schleife: die SSH-Sitzung ist am 2026-08-21 mitten in einer Gehweg-Messung
+#    weggebrochen ("Can't assign requested address"), und die Funkdaten endeten 2,5 Minuten vor
+#    dem Ping-Mitschnitt — ausgerechnet im interessanten Teil. Ein Sampler, der still stirbt,
+#    ist schlimmer als keiner.
+while true; do
+  sshpass -p "$PW" ssh -o StrictHostKeyChecking=no -o ConnectTimeout=8 \
+          -o ServerAliveInterval=15 -o ServerAliveCountMax=3 "admin@${ROUTER_IP}" "$ROS" \
+          2>>"${OUT%.csv}.stderr.log" \
+    | while IFS= read -r line; do
+        printf '%s,%s,%s\n' "$(date +%s)" "$(date +%H:%M:%S)" "$line" >> "$OUT"
+      done
+  printf '%s,%s,RECONNECT\n' "$(date +%s)" "$(date +%H:%M:%S)" >> "$OUT"
+  echo "$(date +%H:%M:%S) Verbindung weg -- neuer Versuch in 2 s" >> "${OUT%.csv}.stderr.log"
+  sleep 2
+done