Files
bf-infra/docs/tp25-runde-20260822-2330-auswertung.md

94 lines
4.4 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.
# TP25 — Rundgang 2026-08-22, 23:30–23:41: der Terrassen-Vergleich
**Rohdaten:** [`messdaten/tp25-runde-terrasse-vergleichbash/`](messdaten/tp25-runde-terrasse-vergleichbash/)
· erster Lauf mit **beiden** Ping-Strecken (3 065 / 3 067 Antworten), `beide-telefone.csv`,
eingefrorener `ap-map.txt`, per Stopp-Knopf beendet.
Vorgänger (Worst-Corner-Runde, 22:43): [`tp25-runde-20260822-auswertung.md`](tp25-runde-20260822-auswertung.md).
---
## ✅ Die Terrasse ist repariert — das Anheben von ap2 auf 2,5 m hat gewirkt
| | 2026-08-21 (ap2 tief) | 2026-08-22 (ap2 auf 2,5 m) |
|---|---|---|
| Verlust | **43 %** | **9 %** |
| längste Lücke | **20,4 s** | **1,0 s** |
| Signal | −72 dBm | −69,0 dBm ⌀ |
Beide Male dasselbe Gerät in derselben Rolle (iPhone, frei roamend). **1,0 s liegt unter der
Schwelle, ab der eine Unterbrechung im Videocall hörbar wird** (~2 s). Der Dead Spot, der TP25
seit dem 08-20 getragen hat, ist damit weg.
⚠️ Einschränkung: unterschiedliche Wege und Standzeiten, kein Laborvergleich. Aber 20,4 s → 1,0 s
ist zu groß, um Messrauschen zu sein.
Die Rückfallebene dort bleibt dünn: ap1 liefert auf der Terrasse −78,7 dBm und 19 % Verlust.
---
## 🔎 Der strukturelle Befund: das Netz ist gut, die Redundanz ist es nicht
Die Referenz (iPhone, frei roamend) ist in **17 von 21** Raumabschnitten bei **0 % Verlust**;
der schlechteste Wert im ganzen Haus sind die 9 % auf der Terrasse. Im Alltag ist die Abdeckung
also in Ordnung — überall.
Der Gegen-AP dagegen trägt fast nirgends:
| Raum | Referenz | Gegen-AP |
|---|---|---|
| Schlafzimmer | −68,1 · 4 % | **−84,6 · 38 %** |
| Bad | −61,8 · 0 % | **−82,3 · 24 %** |
| Küche | −71,1 · 1 % | **−82,0 · 23 %** |
| Terrasse | −69,0 · 9 % | **−78,7 · 19 %** |
| Wohnzimmer | −60,6 · 0 % | −73,9 · 14 % |
| Kinderzimmer | −59,0 · 0 % | −79,7 · 14 % |
Im UG trägt ap2 durchgehend nur noch 2,4 GHz, im OG erreicht ap1 die Terrasse nur über 2,4 GHz.
**Fällt einer der beiden APs aus, ist die halbe Wohnung unbrauchbar** — nicht offline, sondern
im Zustand „verbunden, aber tot".
---
## Korrektur zum Vorlauf: die Küche
Der Lauf vom 22:43 ergab „die Küche ist ein Loch für BEIDE APs" (iPhone 89 s getrennt, S22 57 %
Verlust). **Das reproduziert sich hier nicht:** die Referenz hat in der Küche **1 % Verlust bei
−71,1 dBm**. Der Unterschied ist der Weg — der 22:43-Lauf ging ausdrücklich „allen Mauern entlang
in die totesten Winkel", dieser nicht.
⇒ Richtig ist: **ap1 versorgt die Küche im normalen Aufenthaltsbereich gut**; in der äußersten
Ecke bricht sie weg, und ap2 kann sie dort nicht auffangen. Beide Aussagen gelten, sie messen
verschiedene Orte.
---
## Was das für die offenen Punkte bedeutet
**Dritter AP: nach Christophs eigener Randbedingung derzeit NICHT begründet.** „Kein neuer AP,
solange nicht alles aus den vorhandenen rausgeholt ist" — die Alltagsabdeckung ist gut, der
Dead Spot ist weg. Ein dritter AP würde jetzt **Redundanz** kaufen, keine Abdeckung. Das ist
eine andere, teurere Frage, und sie ist Christophs.
**Fund E (`signal-range`-Boden): weiter abgestuft.** Der Sticky-Client-Befund vom 08-20 hat sich
in diesem Lauf **nicht reproduziert** — auf der Treppe wechselt die Referenz sauber von ap2/5 GHz
auf ap1/5 GHz, 0 % Verlust über 57 s. Ein Boden bliebe wirkungslos bis schädlich, weil es in den
schwachen Räumen keinen besseren AP gibt, auf den er steuern könnte. **Nicht umsetzen, bevor ein
Sticky-Fall erneut gemessen ist.** (Ein Lauf widerlegt Fund B nicht — er zeigt nur, dass es nicht
der Normalfall ist.)
**5 GHz auf 20 MHz (+3 dB):** die letzte offene Funkmaßnahme. Sie würde vor allem die dünne
Rückfallebene stärken, nicht die Alltagsabdeckung — die braucht sie nicht mehr.
---
## Werkzeug-Nachtrag
Die Auswertung beschriftete die größte Lücke der Sonde auf der Treppe als „⚠️ eher Ruhezustand"
(4,6 s). **Das war unser eigener Eingriff:** um 23:35:10 wechselte der Pin von ap1 auf ap2, das
S22 war daraufhin von 23:35:12 bis 23:35:16 abgemeldet. Ein Messartefakt als „Gerät war
erreichbar, wollte nur nicht antworten" auszuweisen, ist doppelt falsch — die Auswertung erkennt
Pin-Wechsel jetzt und schreibt „⚠️ Pin-Wechsel".
Die `jserrors.log` des Laufs enthält nur `Script error.` und einen `window.ethereum`-TypeError —
das kommt von einer Browser-Erweiterung auf dem Telefon, nicht aus der Konsole. Ohne Belang.