# TP25 — Rundgang 2026-08-22, 22:43–22:56 (Gegen-AP-Messung) **Rohdaten:** [`messdaten/tp25-runde-20260822-2242/`](messdaten/tp25-runde-20260822-2242/) · 3 989 Pings (5/s vom Core), 762 Funkproben (1/s am Manager), 29 Raum-/Ereignismarken, `manager-log.txt` (Roaming beider Telefone), `ap-map.txt` (eingefrorene AP-Zuordnung). **Aufbau (neu, Christophs Entwurf):** das iPhone roamt frei und zeigt, welchen AP ein normaler Client wählt. Das S22 wird automatisch auf den **Gegen-AP** gezwungen. Gemessen wird der Ping auf das S22 — also **nicht die Alltagsabdeckung, sondern die Rückfallebene**. Christoph ist bewusst „allen Mauern entlang, in die totesten Winkel" gegangen; die Zahlen sind damit **Worst-Case je Raum**, nicht Durchschnitt. **Gepinnt / daraus rekonstruiert, welchen AP das iPhone hatte:** | Zeit | S22 gezwungen auf | ⇒ iPhone hatte | |---|---|---| | 22:43–22:47 (OG) | ap1 | **ap2** | | 22:47–Ende (Treppe + UG) | ap2 | **ap1** | **Messgüte:** nur **22 von 784** Funkproben „nicht angemeldet" (2,8 %). Die befürchteten Abweisungs-Artefakte des Pins sind praktisch nicht aufgetreten — die Verluste unten sind echte Funkschwäche, kein Messfehler. Keine `UNERREICHBAR`-Marke, kein Sampler-Abriss. --- ## 🔴 Hauptbefund: die KÜCHE ist ein Loch, und zwar für BEIDE APs gleichzeitig Der Dead Spot dieses Projekts galt bisher als die Terrasse. Der ist es nicht mehr — oder jedenfalls nicht allein. Zwischen **22:51:20 und 22:52:47** stand Christoph still in der Küche (Marke `ARRIVED` 22:51:16), und **beide** Telefone fielen dort gleichzeitig aus, unabhängig voneinander gemessen: **S22 auf ap2** — durchgehend *angemeldet*, aber unbrauchbar: | Totzeit | Dauer | |---|---| | 22:51:20–22:51:30 | 9 s | | 22:51:45–22:51:57 | 12 s | | **22:52:05–22:52:30** | **24 s** | | 22:52:37–22:52:47 | 11 s | | (+ 2 kürzere) | 6 s | **57 % Paketverlust** über zwei Minuten, Signal konstant **−79 bis −87 dBm**, dabei ununterbrochen zwischen ap2/5 GHz und ap2/2,4 GHz hin- und herspringend. 🔴 Das ist der Zustand „**verbunden, aber tot**" — kein Verbindungsabbruch, keine Fehlermeldung, nichts, was ein Nutzer als Ursache erkennen könnte. **iPhone auf ap1** — im selben Fenster schlicht weg: ``` 22:51:37 F2:62:…@cap-wifi3 (ap1/5GHz) disconnected, connection lost, signal strength -76 22:53:06 F2:62:…@cap-wifi3 (ap1/5GHz) connected, signal strength -65 ``` **89 Sekunden vollständig getrennt** — und wieder verbunden erst, als Christoph die Küche Richtung Wohnzimmer verlassen hatte. ⇒ **In der Küche gibt es keine Rückfallebene.** ap1 wirft das Gerät ab, ap2 hält es bei −85 dBm in einem Zustand, in dem mehr als die Hälfte der Pakete verschwinden. Ein Videocall ist dort über 24 Sekunden am Stück tot. Das ist schlimmer als alles, was am 08-21 gemessen wurde. --- ## Terrasse: besser, aber nicht gelöst — und der Beweis fehlt Am 08-21 (vor der Höhenänderung, iPhone frei roamend): **43 % Verlust, längste Lücke 20,4 s** bei −72 dBm. Heute: - **ap1 als Rückfallebene:** −79,4 dBm im Schnitt, **12 % Verlust**, längste Lücke 2,4 s — und das **nur über 2,4 GHz** (66 von 70 Proben auf `cap-wifi4`; ap1/5 GHz trägt dort nicht). - **iPhone auf ap2:** kein einziger Verbindungsabbruch im Log — aber **vier Bandwechsel in 49 Sekunden** (22:45:42 / 22:46:13 / 22:46:16 / 22:46:31) zwischen ap2/5 GHz und ap2/2,4 GHz, bei −64 bis −73 dBm. ⚠️ **Was hier NICHT belegt ist:** ob das Anheben von ap2 auf 2,5 m die Terrasse repariert hat. Der Ping lief nur auf das S22, und das war dort auf ap1 gezwungen. Für den direkten Vergleich mit den 43 % vom 08-21 fehlt die iPhone-Ping-Strecke. **Die Anzeichen sind gut** (kein Abbruch statt 43 % Verlust), **ein Beweis ist es nicht.** Nächster Lauf: beide Telefone pingen. Das Band-Ping-Pong (**Fund C**) ist damit auf der Terrasse reproduziert — nach der Höhenänderung, mit aktivem 802.11k/v und FT. --- ## Raumtabelle (S22 = jeweils der GEGEN-AP, Worst-Case-Weg) | Raum | Gegen-AP | Signal ⌀ | Verlust | längste Lücke | |---|---|---|---|---| | Arbeitszimmer | ap1/5G | −63,9 | 0 % | — | | Technik OG | ap1/5G | −69,0 | 9 % | 0,4 s | | Arbeitszimmer (Wand) | ap1 | −68,4 | 22 % | 4,2 s | | Diele OG | ap1 | −72,5 | 14 % | 2,0 s | | **Terrasse** | ap1/2,4G | **−79,4** | 12 % | 2,4 s | | Treppe | Übergang | −65,6 | 17 % | 5,2 s | | Wohnzimmer | ap2 | −74,3 | 4 % | 0,4 s | | Diele UG | ap2 | −72,7 | 9 % | 0,6 s | | **Bad** | ap2/2,4G | **−84,0** | 28 % | 1,0 s | | **Schlafzimmer** | ap2/2,4G | **−83,4** | 20 % | 1,0 s | | Klo | ap2/2,4G | −78,2 | 7 % | 0,6 s | | Technik UG | ap2/2,4G | −73,6 | 2 % | 0,2 s | | Kinderzimmer | ap2/2,4G | −80,8 | 4 % | 0,4 s | | **KÜCHE** | ap2 | **−82,3** | **57 %** | **24,0 s** | *(Der letzte Wohnzimmer-Block, 170 s, ist der Rückweg an den Schreibtisch und von der Auswertung als Ruhezustand markiert — nicht als Messpunkt lesen.)* **Muster:** im gesamten UG trägt der Gegen-AP (ap2) **nur noch 2,4 GHz** — 5 GHz kommt aus dem OG nicht durch. Bad, Schlafzimmer, Kinderzimmer und Küche liegen bei −80 bis −86 dBm. Die Redundanz ist dort also nominell vorhanden und praktisch wertlos. --- ## Was das für die offenen Punkte heißt **Fund E (`signal-range`-Boden) — Bewertung ändert sich.** Ein Boden steuert klebende Clients auf den besseren AP. Das setzt voraus, dass es einen gibt. Die Tabelle sagt: im UG gibt es ihn nicht (ap2 liefert dort −80…−86), im OG für die Terrasse ebenfalls nicht. **Fund E hilft auf der Treppe und im Übergangsbereich — nicht in den Problemräumen.** Er bleibt richtig, aber er ist nicht mehr die Antwort auf den Dead Spot. **Dritter AP — die User-Randbedingung ist jetzt prüfbar.** „Kein neuer AP, solange nicht alles aus den vorhandenen rausgeholt ist." Was noch nicht ausgereizt ist: 5 GHz auf 20 MHz (+3 dB, steht seit 08-21 offen). Was die Messung zeigt: in der Küche fehlen nicht 3 dB, sondern eher 15–20. **Ein AP im UG-Bereich Küche/Wohnzimmer würde dort zwei Probleme gleichzeitig lösen** (Küchenloch + fehlende Rückfallebene für Bad/Schlafzimmer). Das ist eine Empfehlung, keine Entscheidung — und sie steht unter dem Vorbehalt, dass 20 MHz vorher gemessen wird. **Fund F (5:05-Takt IoT-Trennungen)** — von diesem Lauf nicht berührt. --- ## Zwei Werkzeugmängel, die dieser Lauf aufgedeckt hat — ✅ beide behoben (2026-08-22) 1. 🔴 **Es gibt keinen Stopp-Knopf.** Christoph drückte 22:53:26 „📴 Call beendet" und „⛔ Last sofort stoppen" — beides schreibt nur Marken (`ABORT_killed=0`, es gab keine Lastflüsse). Die Aufzeichnung lief weitere ~2,5 Minuten weiter, bis sie von Hand beendet wurde; der Core pingte das Telefon derweil mit 5/s. Der Docstring von `tp25-walk-messung.sh` behauptet fälschlich, es gäbe einen Knopf. 2. 🔴 **Die iPhone-Werte wurden nicht mitgeschrieben.** Der Beobachter der Konsole liest beide Telefone, hält die Zahlen aber nur im Speicher für die Anzeige. Nachträglich ließ sich nur das *Roaming-Log* am Manager retten (`manager-log.txt`) — Ereignisse, keine Zeitreihe. Deshalb fehlt oben der direkte Terrassen-Vergleich. **Behoben.** Die Konsole hat jetzt einen echten `⏹ Aufzeichnung stoppen`, der die Messung beendet (`stop.flag`), und es werden **beide** Telefone gepingt (`walk-ping.csv` + `walk-ping-iphone.csv`) sowie beide im 2-s-Takt mitgeschrieben (`beide-telefone.csv`). Beim Testen fielen dabei zwei weitere Fehler auf, die beide diesen Lauf betroffen hätten: `PINGER=$(ping_lauf …)` blockierte (Kommandosubstitution wartet auf die stdout-Pipe, die der Hintergrundjob offen hält) — der zweite Ping wäre nie gestartet; und `kill $SAMPLER` traf nur den Wrapper, dessen Subshell samt SSH-Sitzung verwaist weiterlief. Jetzt wird der Prozessbaum kindzuerst beendet. ⇒ **Der nächste Lauf beantwortet die Terrassen-Frage.** Diesmal nicht.