Auswertung der Verbindungsmessungen.
{{ fehler }}
{{ formatZeit(von) }} – {{ formatZeit(bis) }} · Messtakt {{ schwellen.taktSekunden }} s ·
Fachsystem {{ zielsystem.name }}
{{ fehler }}
Es ist noch kein Gerät gekoppelt oder es liegen für diesen Zeitraum keine Messungen vor. Unter Geräte legst du ein Telefon an und bekommst einen Kopplungscode.
In {{ prozent(w.prozent) }} der Messungen mit bestehender WLAN-Verbindung fehlen
Netzname und Sender-Kennung. Pegel und Erreichbarkeit kommen weiter
durch – deshalb fällt es in den Zahlen nicht auf. Nicht messbar sind dadurch:
welcher Zugangspunkt verbunden ist, Wechsel zwischen Sendern und das gesamte
Funkumfeld.
Die App meldet die Ursache:
Fast immer fehlt dafür die Standortfreigabe. Android liefert dann
stillschweigend Platzhalter statt Kennungen und einen leeren Umgebungsscan – ohne
Fehlermeldung. Am Gerät prüfen: Einstellungen → Apps → WifiPilot → Berechtigungen →
Standort → Immer zulassen.
(Diese App-Fassung meldet die genaue Ursache noch nicht.)
{{ ausgeblendet.join(', ') }} {{ ausgeblendet.length > 1 ? 'sind' : 'ist' }} als Testgerät geführt und {{ ausgeblendet.length > 1 ? 'bleiben' : 'bleibt' }} hier außen vor – {{ ausgeblendet.length > 1 ? 'sie messen' : 'es misst' }} weiter, zählt aber nicht in die Zahlen. Ein Telefon im Büro und eines an Bord zusammenzurechnen ergäbe einen Mittelwert, der für keinen der beiden Orte gilt. Oben gezielt auswählen, um {{ ausgeblendet.length > 1 ? 'sie' : 'es' }} doch zu sehen.
Bewusst getrennte Diagramme statt zwei Achsen in einem Bild: Signalstärke in dBm und Antwortzeit in Millisekunden haben nichts miteinander gemein, und übereinandergelegt suggerieren sie Zusammenhänge, die es nicht gibt. Untereinander mit gleicher Zeitachse sieht man denselben Zusammenhang, ohne ihn zu erfinden.
Für den Zeitregler fehlen noch verwertbare Positionen in diesem Zeitraum.
| Bereich | Vorgang geht durch | Messungen | Antwortzeit | Zeitraum |
|---|---|---|---|---|
| {{ f.mitteLat.toFixed(4) }}, {{ f.mitteLon.toFixed(4) }} | {{ prozent(f.quote) }} | {{ f.messungen }} | {{ f.latenzMedianMs != null ? f.latenzMedianMs + ' ms' : '–' }} | {{ formatZeit(f.von) }} – {{ formatZeit(f.bis) }} |
{{ ortungVerworfen.anzahl.toLocaleString('de-DE') }} Positionen wurden für die Karte verworfen ({{ ortungVerworfen.ungenau }} zu ungenau {{ ortungVerworfen.ungenau ? ', ' : '' }}{{ ortungVerworfen.veraltet }} veraltet {{ ortungVerworfen.ungenau || ortungVerworfen.veraltet ? ', ' : '' }}{{ ortungVerworfen.sprung }} unmögliche Sprünge). Ohne Satellitenempfang schätzt Android die Position aus Funkzellen – das ergibt Punkte hunderte Meter daneben, ohne dass es als Fehler ankäme. Die Messwerte selbst sind davon nicht betroffen und zählen vollständig; nur ihre Verortung auf dieser Karte fehlt.
Problemabschnitte sind dicker gezeichnet – sie sind meist kurz und gingen neben langen guten Strecken sonst unter. Beim Überfahren erscheinen Zeitpunkt, Dauer und vermutete Ursache. Abschnitte ohne Messdaten sind nicht verbunden. Das Kartenbild kommt von openstreetmap.org; dabei erfährt deren Server den betrachteten Ausschnitt. Mit dem Schalter oben bleibt nur die Route – dann wird nichts von dort geladen.
Bricht die Verfügbarkeit zu bestimmten Stunden ein, teilen sich zu viele Nutzer eine zu schmale Anbindung. Graue Balken heißen: keine Messungen in dieser Stunde.
Die Standzeiten liegen dicht beieinander. Das ist kein Zufall und keine wegbrechende Strecke – da räumt eine Zeitschaltung auf, mit hoher Wahrscheinlichkeit eine NAT-Tabelle. Auf einer Starlink-Strecke läuft der Verkehr durch ein Betreibernetz, dessen Einträge nach fester Frist verfallen. Abhilfe: die Anwendung soll häufiger als {{ dauer(linieGesamt.medianS * 1000) }} ein Lebenszeichen senden (TCP-Keepalive oder ein eigener Herzschlag im Protokoll).
Die Standzeiten streuen stark. Dann liegt es nicht an einer Frist, sondern die Strecke bricht selbst weg – etwa bei einem Satellitenwechsel. Ein Lebenszeichen hilft dagegen nicht; die Anwendung muss den Abbruch verkraften und die Sitzung selbsttätig neu aufbauen.
Noch zu wenige Abrisse für ein Urteil – drei Zahlen ergeben kein Muster. {{ linieGesamt.neuaufbauten === 0 ? 'Bisher hielt jede Verbindung durch.' : '' }}
Alle anderen Sonden bauen jedes Mal neu auf und können deshalb grundsätzlich nicht sehen, was einer bestehenden Verbindung zustößt. Diese hier hält eine offen und fragt sie alle 30 Sekunden an. Gemessen wird nicht die Antwortzeit, sondern die Standzeit: wie lange hält eine Verbindung, bevor sie ersetzt werden muss.
| Beginn | Dauer | Gerät | Art | Netz | Kanal | |
|---|---|---|---|---|---|---|
| {{ formatZeitGenau(a.von) }} | {{ (a.dauerMs / 1000).toFixed(1).replace('.', ',') }} s | {{ a.geraetName }} | {{ a.art }} | {{ a.ssid || a.transport || '—' }} | {{ a.kanalVor }} → {{ a.kanalNach }} DFS — | im Messtakt unsichtbar |
Diese Zeiten kommen nicht aus dem Messtakt: ohne Netz und ohne Internet meldet Android selbst, Router stumm der Herzschlag der App. Ein Abriss von zehn Sekunden fällt zwischen zwei Messungen hindurch, ohne eine Spur zu hinterlassen; auf einer Satellitenstrecke sind genau solche kurzen Aussetzer aber das typische Symptom. „Router stumm“ wiederum bemerkt Android grundsätzlich nicht – die WLAN-Anmeldung besteht ja weiter.
| Abschnitt | Adresse | Betreiber | Antwortzeit | davon neu | antwortet | bei Störung | |
|---|---|---|---|---|---|---|---|
| {{ st.nr }} | {{ st.art || '—' }} |
{{ st.ip || 'antwortet nicht' }}
{{ st.name }}
|
{{ st.betreiber || '—' }} (AS{{ st.asn }}) | {{ st.ms != null ? st.ms + ' ms' : '–' }} | +{{ st.zuwachs }} ms – | {{ prozent(verlaufZu(st.ip).antwortquote) }} – | {{ prozent(verlaufZu(st.ip).gestoertQuote) }} keine Störung |
Während der Störungen reißt es hinter Station {{ bruchstelleGesamt.letzteNr }} ab.
{{ bruchstelleGesamt.letzteAntwortende }} antwortet weiter,
{{ bruchstelleGesamt.ersteStumme }} nur noch in
{{ prozent(bruchstelleGesamt.stummQuote) }} der Fälle – im Normalbetrieb sind es
{{ prozent(bruchstelleGesamt.normalQuote) }}. Der Abschnitt dazwischen ist der Fundort.
Die Spalte davon neu ist die entscheidende: sie zeigt, wie viel Zeit dieser Abschnitt beisteuert. Die Werte enthalten alle denselben Messaufwand als Sockel – vergleichbar sind deshalb die Unterschiede, nicht die absoluten Zahlen. Springt sie beim Übergang in die Satellitenstrecke, liegt es an der Satellitenverbindung – Abschattung, Wetter oder Auslastung. Springt sie erst danach, ist die Satellitenstrecke in Ordnung und das Problem liegt an Land. Stationen, die nicht antworten, sind normal: manche Knoten schweigen grundsätzlich.
| Station | erreicht | ||
|---|---|---|---|
| {{ st.ttl }} | {{ st.ip }} |
{{ prozent(st.quote) }} ({{ st.erreicht }}/{{ st.sonden }}) | |
| Ziel | {{ zielsystem.name === 'FRS' ? 'Auswertungsserver' : 'Server' }} |
{{ prozent(spurGesamt.zielQuote) }} |
{{ spurGesamt.sonden.toLocaleString('de-DE') }} Sonden während der Störungen, alle paar Sekunden eine. Gefragt wird hier nicht, wie lange eine Station braucht, sondern nur, ob überhaupt noch ein Paket ankommt – diese Frage lässt sich auch dann beantworten, wenn nichts mehr geht, und sie lässt sich für alle Stationen gleichzeitig stellen. Gemessen wird über die Lebensdauer der Pakete: so antworten auch die Kernrouter, die einen direkten Anruf grundsätzlich ignorieren. In {{ spurGesamt.garNichts }} Fällen kam nicht einmal die erste Station zustande.
| Sonde | Art | Ziel | erreichbar | Antwortzeit | Messungen |
|---|---|---|---|---|---|
| {{ s.name }} (entfernt) | {{ s.art || '—' }} | {{ s.ziel || '—' }} |
{{ prozent(s.quote) }} | {{ s.msMittel != null ? s.msMittel + ' ms' : '–' }} | {{ s.messungen.toLocaleString('de-DE') }} |
Beantwortet die Frage, ob der Verkehr tatsächlich über Starlink lief – oder zeitweise über eine Mobilfunkleitung. Taucht hier mehr als ein Betreiber auf, ist die Verbindung zwischendurch umgesprungen.
Das ist die häufigste Erklärung für „gutes Signal und trotzdem lahm": Sender auf demselben Kanal teilen sich die Sendezeit, jeder wartet auf jeden. An der Signalstärke ist davon nichts zu sehen. Ein bis zwei Mitbewerber sind unauffällig, ab drei wird es spürbar.
.env fehlt der ANTHROPIC_API_KEY.
{{ deutung.modell }} · {{ formatZeit(deutung.erstelltAt) }}
Übergeben werden nur die verdichteten Kennzahlen dieses Zeitraums – keine Rohdaten, keine Positionen.
| Netz | Zugangspunkt | Band | Kanal | verbunden | Signal | Antwortzeit | gestört |
|---|---|---|---|---|---|---|---|
| {{ z.ssid || '—' }} | {{ z.bssid }} {{ z.geraetName }} |
{{ z.band ? z.band + ' GHz' : '—' }} | {{ z.kanal ?? '—' }} | {{ dauer(z.verbundenMs) }} | {{ z.rssiMittel != null ? z.rssiMittel + ' dBm' : '—' }} | {{ z.latenzMedianMs != null ? z.latenzMedianMs + ' ms' : '—' }} | {{ z.stoerungsanteil }} % |
Mehrere Zeilen mit demselben Netznamen bedeuten mehrere Sender an Bord. Fällt einer durch schwaches Signal oder hohen Störungsanteil auf, hängt genau dieser schlecht.
| Beginn | Dauer | Gerät | Zustand | Vermutete Ursache | Netz / Zugangspunkt |
|---|---|---|---|---|---|
| {{ formatZeit(s.von) }} | {{ dauer(s.dauerMs) }} | {{ s.geraetName }} | {{ texte.stufen[s.stufe] }} | {{ s.ursacheText }} | {{ s.ssid || '—' }} {{ s.bssid }} |
{{ stoerungenGesamt.length - 60 }} weitere Störungen – vollständig im CSV-Export.
Gib dem Gerät einen Namen, unter dem du es in der Auswertung wiedererkennst – zum Beispiel den Ort an Bord, an dem es liegt.
{{ g.messungen.toLocaleString('de-DE') }} Messungen · {{ formatZeit(g.datenVon) }} bis {{ formatZeit(g.datenBis) }} Noch keine Messungen eingegangen. · {{ g.modell }}, Android {{ g.android }} · zuletzt gemeldet {{ formatZeit(g.letzteMeldungAt) }}
{{ serverAdresse }} und den Code eintragen.Die App bringt die Fähigkeiten mit: einen HTTPS-Aufruf, ein Ping-Paket, eine TCP-Verbindung, eine Namensauflösung. Was damit geprüft wird, steht hier. Nach jeder Übertragung nennt der Server den Stand dieser Liste; weicht er vom gespeicherten ab, holt das Telefon sie sofort nach. Eine Änderung ist damit binnen eines Messtakts auf allen Geräten wirksam – während einer Störung an Bord ist genau das der Unterschied zwischen „jetzt nachsehen“ und „in zwei Tagen“.
Die fest eingebauten Sonden bleiben unberührt. Sie tragen die Bewertung und dürfen nicht davon abhängen, dass hier jemand etwas richtig ausfüllt.
| Schlüssel | Name | Art | Ziel | Takt | |
|---|---|---|---|---|---|
{{ s.schluessel }} |
{{ s.name }} | {{ s.art }} | {{ s.ziel }} |
{{ s.jederTakt ? 'jeder Takt' : 'alle 5 min' }} |
Abschalten hält die bisherigen Messwerte; Löschen entfernt nur die Sonde, nicht ihre Zeitreihe. Der Schlüssel lässt sich nicht ändern – unter ihm liegen die Messwerte.
{{ sondenFehler }}
{{ art }} | {{ text }} |
Der Messtakt liegt bei {{ schwellen.taktSekunden }} Sekunden, der Herzschlag zum Router bei fünf. Ein Abriss von drei Sekunden ist damit im besten Fall ein einzelnes verlorenes Paket – und ein einzelnes verlorenes Paket ist im WLAN Alltag, keine Störung. Genau diese Größenordnung bricht an Bord aber laufende Vorgänge ab.
Der Dauerping schließt die Lücke: ein Paket je Sekunde auf eine hier hinterlegte Adresse, lückenlos. Für jede einzelne Sekunde steht danach fest, ob etwas durchkam und wie lange es brauchte. Darübergelegt liegen die Wechsel des Zugangspunkts – denn die eigentliche Frage lautet nicht „gab es Aussetzer“, sondern ob sie mit dem Wechsel des Senders zusammenfallen.
Oben die Flottenvorgabe — sie gilt für jedes Gerät ohne eigene Adresse. Darunter lässt sich jedes Telefon einzeln abweichen. Der Zugangspunkt und das Gateway sind auf jeder Fähre andere, dafür taugt eine gemeinsame Adresse nicht.
| Gerät | Eigene Adresse | messen | |
|---|---|---|---|
| {{ g.name }} | folgt der Flotte |
{{ dauerpingFehler }}
Gespeichert. Die Telefone übernehmen die Änderung bei ihrer nächsten Übertragung – also binnen eines Messtakts. Niemand muss dafür an das Gerät an Bord.
Sinnvolle Ziele sind der Zugangspunkt selbst (trennt Funkstrecke von
allem dahinter), das Gateway oder eine feste Adresse im Internet wie
1.1.1.1. Wichtig: Nicht jedes Gerät beantwortet Pings. Antwortet die
Adresse gar nicht, wird das hier ausdrücklich als nicht prüfbar ausgewiesen –
und nicht als Totalausfall. Ein Messfühler, der schweigt, beweist nichts, solange nicht
feststeht, dass er überhaupt sprechen kann.
Wird geladen …
Für diesen Zeitraum liegt kein Sekundenraster vor. Entweder war der Dauerping aus, oder das Telefon hat noch nicht übertragen – der erste Block ist frühestens eine Minute nach dem Einschalten fertig.
{{ a.luecken.length }} Datenlücke{{ a.luecken.length > 1 ? 'n' : '' }} im Zeitraum – dort lief die Messung nicht. Sie zählen ausdrücklich nicht als Ausfall: sonst würde jede abgeschaltete Nacht zum stundenlangen Totalausfall, und die Auswertung behauptete das Gegenteil dessen, was gemessen wurde.
| Beginn | Dauer | davor | Zugangspunkt | Kanal | Fiel zusammen mit |
|---|---|---|---|---|---|
| {{ formatZeitGenau(x.von) }} | {{ x.sekunden }} s + | {{ x.msDavor != null ? x.msDavor + ' ms' : '—' }} | {{ x.bssid }} unbekannt → {{ x.bssidNach }} | {{ x.kanal }} — | {{ ereignisText(x.ereignis) }} {{ x.ereignis.abstandMs === 0 ? 'mittendrin' : x.ereignis.abstandMs + ' ms daneben' }} nichts in der Nähe |
Die Spalte davor ist der Wert der letzten beantworteten Sekunde. War die Strecke schon vorher zäh, kündigt sich der Abriss an; kommt er aus einem unauffälligen Wert heraus, ist es ein hartes Abreißen – zwei verschiedene Ursachen. Fiel zusammen mit nennt das nächstgelegene Netzereignis innerhalb von {{ naheMs / 1000 }} Sekunden. Steht dort nichts in der Nähe, scheidet der Zugangspunkt als Ursache aus – das ist der eigentliche Erkenntnisgewinn.
| Zugangspunkt | Kanal | Zeit | Aussetzer | Anteil | Faktor |
|---|---|---|---|---|---|
| {{ z.bssid }} · {{ z.ssid }} | {{ z.kanal != null ? z.kanal : '—' }} | {{ prozent(z.zeitProzent) }} | {{ z.ausfaelle }} | {{ prozent(z.ausfallProzent) }} | {{ z.ueberproportional }}× {{ z.ueberproportional }}× — |
Die reine Anzahl sagt nichts: Ein Sender, an dem das Telefon die halbe Zeit hängt, sammelt selbstverständlich die meisten Aussetzer ein. Erst der Faktor – Anteil an den Aussetzern geteilt durch Anteil an der Zeit – zeigt, ob einer aus der Reihe fällt. Ein Wert um 1 heißt: unauffällig. Deutlich darüber heißt: an diesem Sender passiert mehr, als seine Nutzungsdauer erklärt.
Jedes Telefon erfasst alle {{ schwellen.taktSekunden }} Sekunden einen Datensatz. Vier unabhängige Sonden laufen dabei nebeneinander – erst ihr Vergleich sagt, woran es liegt:
| Namensauflösung | Wird der Servername in eine Adresse übersetzt? Schlägt das allein fehl, ist der DNS-Server kaputt – nicht die Leitung. |
| Auswertungsserver | Vollständiger HTTPS-Aufruf. Klappt er, funktioniert die Kette von WLAN über DNS bis zur Gegenstelle. |
| Neutraler Test | Reine TCP-Verbindung zu 1.1.1.1, ohne Namensauflösung. Trennt „unser Server ist weg" von „das Internet ist weg". |
| {{ zielsystem.name }} | Das Fachsystem, mit dem an Bord gearbeitet wird ({{ zielsystem.url }}). Eigene Achse, weil es ausfallen kann, während das Internet läuft – und umgekehrt. |
| in Ordnung | Der Server antwortet in unter {{ schwellen.latenzLangsamMs }} ms. |
| langsam | Erreichbar, aber die Antwort dauert länger als {{ schwellen.latenzLangsamMs }} ms. Kein Ausfall, sondern Überlastung. |
| Anmeldeseite | Das WLAN fängt den Verkehr ab und verlangt eine Anmeldung im Browser. Typisch für Gast-Netze. |
| kein Internet | Das Telefon hängt im WLAN, aber nichts kommt durch. |
| kein Netz (schraffiert) | Weder WLAN noch Mobilfunk. Außer Reichweite. |
| keine Messdaten | Die App war aus oder das Telefon abgeschaltet. Kein Ausfall – deshalb zählt es auch nicht gegen die Verfügbarkeit. |
| Internet verfügbar | Anteil der Messungen, in denen die Verbindung nutzbar war (in Ordnung oder langsam). Bezugsgröße sind nur tatsächlich vorhandene Messungen – Zeiten ohne Daten verfälschen den Wert nicht. |
| {{ zielsystem.name }} erreichbar | Dasselbe für das Fachsystem. Weicht dieser Wert nach unten ab, während das Internet läuft, liegt das Problem nicht am Schiff, sondern beim Fachsystem oder dessen Anbindung. |
| Antwortzeit (Median) | Die mittlere Antwortzeit: die Hälfte der Messungen war schneller, die Hälfte langsamer. Robuster als ein Durchschnitt, den einzelne Ausreißer verzerren. |
| Langsamste 5 % | So schlecht war es in den schlechtesten 5 % der Fälle. Zeigt, wie zäh es sich anfühlt, wenn es zäh wird. |
| Längste Störung | Der längste zusammenhängende Zeitraum ohne nutzbare Verbindung. |
| Wechsel des Zugangspunkts | Wie oft das Telefon zwischen Sendern gesprungen ist. Jeder Wechsel unterbricht laufende Verbindungen kurz; häufige Wechsel deuten auf überlappende Funkzellen. |
| Paketverlust | Anteil der Pakete, die auf dem Weg zum Server verlorengingen. Über die Summen gerechnet, nicht je Takt gemittelt – sonst zählte ein Takt mit drei Paketen so viel wie einer mit dreißig. Über 2 % macht sich bemerkbar, über 5 % wird jede Anwendung zäh, obwohl „das Internet läuft“. |
| Router antwortet | Anteil der Herzschlag-Pakete, die das Gateway beantwortet hat. Rein örtlich: sagt nichts über das Internet, nur über die Strecke bis zum Sender an Bord. Fällt dieser Wert, während das Internet läuft, spinnt das WLAN selbst. Steht dort „nicht prüfbar“, hat der Router noch nie geantwortet – manche tun das grundsätzlich nicht. Dann taugt sein Schweigen auch nicht als Nachweis, und „Router stumm“ wird für dieses Gerät gar nicht erst ausgewiesen. |
| Heimlich über Mobilfunk | Anteil der Zeit, in der das Telefon zwar im WLAN hing, den Verkehr aber übers Mobilfunknetz leitete. Android macht das selbsttätig, wenn es dem WLAN misstraut. Auf See bedeutet das Roaming – also Kosten, die niemand bemerkt. |
Diese Werte erklären Störungen, die man an Signalstärke und Erreichbarkeit allein nie sieht.
| Erste Station | Antwortzeit des Zugangspunkts selbst (des Gateways). Der wichtigste Trennstrich: antwortet er, aber sonst nichts, ist die Anbindung nach draußen tot. Antwortet nicht einmal er, liegt es am Funk oder am Sender. Normal sind wenige Millisekunden – deutlich mehr heißt, der Sender selbst ist überlastet. |
| Privates DNS | Ist es eingeschaltet, scheitert hinter jeder Anmeldeseite die Namensauflösung. Ein häufiger und schwer zu findender Grund für „DNS defekt", der nichts mit dem Netz zu tun hat. |
| MTU | Größte übertragbare Paketgröße. Auf Satelliten- und VPN-Strecken oft zu klein eingestellt: die Verbindung kommt zustande, kleine Anfragen laufen, große bleiben hängen. Ohne diesen Wert sucht man den Fehler tagelang an der falschen Stelle. |
| Datenverbrauch | Tatsächlich übertragene Bytes seit der vorigen Messung, getrennt nach gesamt und Mobilfunk. Beantwortet die teure Frage in Megabyte statt in Prozent: wie viel lief wirklich über das Mobilnetz? |
| Verschlüsselung | WPA2, WPA3 oder offen. Ein offenes Netz erklärt eine Anmeldeseite; ein unerwarteter Wechsel verrät, dass sich das Telefon in ein fremdes Netz eingebucht hat. |
| Aushandlung | Die tatsächliche Verbindungsgeschwindigkeit im Vergleich zur größtmöglichen. Liegt sie dauerhaft weit darunter, wurde schlecht ausgehandelt – oft ein Zeichen für Störer auf demselben Kanal. |
| Funkzelle | Kennung des Mobilfunkmasts. Auf einem fahrenden Schiff macht sie die Wechsel zwischen Landmasten sichtbar – die Erklärung für kurze Aussetzer, die man sonst dem WLAN anlastet. |
| WLAN eingeschaltet | Trennt „jemand hat WLAN ausgeschaltet" von „außer Reichweite". In der Auswertung sähen beide sonst gleich aus und verlangen doch völlig verschiedene Maßnahmen. |
Der Messtakt von {{ schwellen.taktSekunden }} Sekunden hat eine eingebaute Blindheit: Was zwischen zwei Durchgängen kommt und geht, hinterlässt keine Spur. Zwei Verfahren schließen diese Lücke.
| Ereignisse von Android | Das System meldet jeden Wechsel von sich aus, auf die Millisekunde genau – Verbindung weg, Internet weg, Anmeldeseite erkannt, Sender gewechselt. Daraus entsteht die Aussetzerliste mit exakten Zeiten statt Schätzungen auf den halben Takt. |
| Herzschlag | Alle paar Sekunden ein einzelnes Paket an das Gateway. Er misst genau das, was Android nicht meldet: Bleibt das Telefon am Sender angemeldet, während der Router selbst nicht mehr antwortet, sieht das System keinen Fehler – die Anmeldung besteht ja weiter. Auf einem Schiff ist genau das der Normalfall. |
| ohne Netz | Die WLAN-Anmeldung ist abgerissen. Das Telefon hängt an gar nichts mehr. |
| ohne Internet | Das WLAN besteht, aber Android stellt fest, dass nichts mehr durchkommt. |
| Router stumm | Der Sender antwortet nicht mehr auf eigene Pakete, obwohl die Anmeldung besteht. Wird erst nach zwei ausgebliebenen Paketen gemeldet – ein einzelnes verlorenes Paket ist im WLAN Alltag, kein Ausfall. Der Beginn wird auf das erste ausgebliebene Paket zurückdatiert. |
| Kanal beim Abriss | Auf welchem Funkkanal die Verbindung abriss und auf welchem sie zurückkam. Sind es verschiedene, hat der Zugangspunkt den Kanal gewechselt. War der verlassene Kanal radarpflichtig (DFS: Kanäle 52–64 und 100–140), ist das die Signatur einer Räumung nach Radarerkennung — dort muss ein Zugangspunkt binnen zehn Sekunden weichen, und die Geräte fliegen mit raus. Der Messtakt allein kann das nicht zeigen: Er kennt den Kanal nur alle {{ schwellen.taktSekunden }} Sekunden, der Wechsel dauert aber nur Sekunden. |
| Im Messtakt unsichtbar | Aussetzer, die kürzer waren als ein Messtakt. Ohne diese beiden Verfahren stünden sie in keiner Auswertung – und es sind genau die, die eine Satellitenstrecke auszeichnen: Abschattung durch einen Mast, ein Satellitenwechsel, eine Böe. |
| Weg zum Server | Alle paar Minuten wird die Strecke Station für Station verfolgt – über Pakete mit begrenzter Lebensdauer, deren Ablauf jede Zwischenstation meldet. Die gewählten Eckpunkte werden danach in jedem Takt gemessen. |
| davon neu | Die wichtigste Spalte. Die Antwortzeit einer Station enthält alle vorherigen mit; erst der Zuwachs zeigt, wie viel dieser Abschnitt beisteuert. Der größte Sprung ist der Engpass. |
| Satellitenstrecke | Bei Starlink liegt zwischen Router und Internet ein Betreibernetz (Adressbereich 100.64.x.x). Ein Sprung dort heißt: Abschattung, Wetter oder Auslastung der Satellitenstrecke. Ein Sprung erst danach heißt: die Satellitenverbindung ist in Ordnung, es hakt an Land. |
| Betreiber | Aus der öffentlichen Adresse ermittelt. Beantwortet, ob der Verkehr tatsächlich über Starlink lief oder zeitweise über eine Mobilfunkleitung. Mehrere Betreiber im Zeitraum bedeuten, dass die Verbindung umgesprungen ist. |
| Standzeit der Verbindung | Wie lange eine bestehende Verbindung zum Server hält, bevor sie ersetzt werden muss. Alle anderen Sonden bauen jedes Mal neu auf – sie können nicht sehen, was einer laufenden Sitzung zustößt. Genau das ist aber gemeint, wenn ein Gerät „die Verbindung zum Server verliert“. Liegen die Standzeiten dicht beieinander, räumt eine Zeitschaltung auf (meist ein NAT); streuen sie, bricht die Strecke weg. Die beiden Fälle verlangen völlig verschiedene Gegenmaßnahmen. |
| Paketgröße, die durchkommt | Gemessen, nicht gemeldet: Android liefert für die MTU oft nur „unbekannt“. Ist der Pfad zu klein eingestellt und verschluckt die Rückmeldungen, gelingt der Verbindungsaufbau (kleine Pakete) und die Übertragung stirbt (große) – ohne jede Fehlermeldung. Für den Benutzer sieht das aus wie ein Verbindungsabbruch, während Latenz- und Erreichbarkeitsmessungen unauffällig bleiben. |
| Bereiche auf der Karte | Fasst benachbarte Messungen zu Feldern von 150 Metern zusammen und zeigt je Feld, welcher Anteil der Vorgänge durchgegangen wäre – also: Verbindung stand und {{ zielsystem.name }} war erreichbar. Beides zusammen braucht ein Kassiervorgang. Eine einzelne schlechte Messung an einem Ort sagt nichts; sie kann ein Funkschatten oder ein Schiff dazwischen gewesen sein. Erst wenn an derselben Stelle wiederholt dasselbe passiert, ist es eine Eigenschaft des Ortes. Felder mit weniger als acht Messungen bekommen deshalb gar kein Urteil – ihre Zahl steht unter der Karte. |
| Zeitregler auf der Karte | Fährt die Strecke nach. Der Ring um den Punkt trägt die Verbindungsqualität zum jeweiligen Zeitpunkt – so lässt sich Ort und Uhrzeit zusammen lesen. Das beantwortet die Frage, die keine der beiden Ansichten allein beantworten kann: Liegt eine schlechte Stelle an der Position oder an der Zeit? Auf einer Fähre, die dieselbe Strecke immer wieder fährt, ist das der Unterschied zwischen „dort ist ein Funkloch“ und „um die Zeit ist das Netz überlastet“. Kürzere Zeiträume ergeben eine feinere Spur – über 24 Stunden wird stärker zusammengefasst. |
| Positionen auf der Karte | Nicht jede gemeldete Position taugt. Ohne Satellitenempfang schätzt Android aus Funkzellen und WLANs – der Punkt liegt dann hunderte Meter daneben, und als Fehler kommt das nicht an; nur die mitgelieferte Genauigkeit verrät es. Dazu trägt jede Messung die zuletzt bekannte Position, auch wenn seit Minuten keine neue kam. Verworfen wird deshalb, was ungenauer als 100 m ist, älter als zwei Minuten, oder einen Sprung von über 30 m/s bedeuten würde. Nur die Verortung entfällt – die Messwerte selbst zählen vollständig. Wie viele Punkte betroffen sind, steht unter der Karte. |
| antwortet / bei Störung | Wie oft eine Station im Zeitraum überhaupt geantwortet hat – und wie oft während der Störungen. Der Vergleich der beiden Spalten ist die Aussage: Eine Station, die sonst zuverlässig antwortet und im Störungsfall schweigt, benennt den Abschnitt, hinter dem die Strecke tot ist. Eine Station, die immer schweigt, ist dagegen harmlos – manche Kernrouter beantworten grundsätzlich keinen direkten Anruf. |
| Wie weit kam noch etwas durch | Sobald weder der eigene Server noch die neutrale Gegenstelle erreichbar sind, springt in der App eine dichte Sonde an und fragt alle paar Sekunden alle Stationen gleichzeitig ab – nicht wie lange, sondern nur ob überhaupt. Diese Frage lässt sich auch beantworten, wenn nichts mehr geht. Sie läuft über die Lebensdauer der Pakete und erreicht damit auch die Kernrouter, die direkte Anrufe ignorieren. |
| Aufbau / Verschlüsselung / Antwort | Jeder Aufruf in seine Abschnitte zerlegt. Zieht sich der Aufbau, gehen Pakete verloren und werden nachgesendet. Zieht sich nur die Antwort, liegt es an der Gegenstelle – nicht am Netz. |
| Fremde Sender auf dem Kanal | Die häufigste Erklärung für „gutes Signal und trotzdem lahm". Funk ist ein geteiltes Medium: Sender auf demselben Kanal warten aufeinander. Ein bis zwei sind unauffällig, ab drei wird es spürbar – und an der Signalstärke sieht man davon nichts. |
| Überlappende Sender | Nur im 2,4-GHz-Band. Dort überlappen benachbarte Kanäle bis ±4, ein Sender auf Kanal 4 stört einen auf Kanal 1 fast so stark wie ein direkter Mitbewerber. Im 5-GHz-Band liegen die Kanäle sauber nebeneinander. |
| Sender mit unserem Netznamen | Wie viele Zugangspunkte an Bord dasselbe Netz aufspannen. Nützlich zum Abgleich: sind es weniger als erwartet, ist einer ausgefallen. |
| Pegelschwankung | Der Unterschied zwischen dem schwächsten und stärksten Messwert innerhalb eines Takts. Ein flatterndes Signal verbirgt sich hinter einem einzelnen Wert; viel Schwankung deutet auf Abschattung oder einen wandernden Störer. |
| Kanalbreite | Breite Kanäle sind schneller, solange sie frei sind – auf einem vollen Band fangen sie sich dafür mehr Störungen ein. Bei vielen Mitbewerbern ist schmal oft die bessere Wahl. |
| Bluetooth | Nur der Schalterzustand, bewusst kein Suchlauf. Bluetooth funkt ausschließlich im 2,4-GHz-Band und kann ein 5-GHz-Netz gar nicht stören – die Angabe ist nur dann von Belang, wenn an Bord auf 2,4 GHz gefunkt wird. |
| Signalstärke (dBm) | Negative Zahl, näher an null ist besser. Ab etwa −60 sehr gut, ab −70 brauchbar, unter {{ schwellen.rssiSchwachDbm }} dBm wird es unzuverlässig. |
| Zugangspunkt / BSSID | Die Hardware-Adresse des konkreten Senders. Mehrere Sender teilen sich meist denselben Netznamen – erst die BSSID verrät, an welchem man tatsächlich hängt. |
| Band und Kanal | 2,4 GHz reicht weiter, ist aber langsamer und überfüllter; 5 GHz ist schneller und reicht kürzer. Stehen mehrere Sender an Bord auf demselben Kanal, stören sie sich – bei gutem Signal und trotzdem lahmer Verbindung ist das ein häufiger Grund. |
| Mobilfunk (dBm) | Zum Vergleich mitgemessen. Zeigt, ob ein Ausweichen aufs Mobilnetz überhaupt eine Option wäre. |
{{ code }} | {{ text }} |
Die Zuordnung ist eine begründete Vermutung aus dem Zusammenspiel der vier Sonden, keine Diagnose. Sie schließt die häufigsten Verwechslungen aus – etwa schwaches Signal gegen tote Anbindung – kann aber seltene Fälle danebenliegen.