Eddys Meldung: bei zu vielen Netzen überschreiben sich die Namen; die Netze
müssten "von der Signalstärke nach oben weiter auseinander gezogen werden".
Mit 15 Netzen (Mehrfamilienhaus) nachgestellt und bestätigt.
Ursache: die Wunschhöhe eines Labels hängt am Messwert, und reale Nachbarnetze
liegen fast alle zwischen -65 und -85 dBm — in einem Band von nur ~40 Einheiten
drängten sich zehn und mehr Namen.
Die BLÖCKE lassen sich dafür aber nicht verschieben: ihre Höhe IST der
Messwert. Ein Netz mit -70 dBm auf Höhe -50 zu zeichnen hätte die dBm-Achse
zur Falschaussage gemacht — genau der Fehler, der beim Umbau von Parabel auf
Trapez behoben wurde. Verschoben wird deshalb nur der NAME:
- Vom Wunschplatz aus wird abwechselnd nach oben und unten die nächste freie
Zeile gesucht (bis 12 Stufen). Zwei Namen stören sich nur, wenn sie sich
auch waagerecht überlappen — nebeneinanderliegende Netze behalten ihre Höhe.
Vorher: nur 4 Versuche nach oben, danach fiel das Label ersatzlos weg.
- Eine dünne Linie in der Netzfarbe führt vom versetzten Namen zum Scheitel
seines Blocks, damit die Zuordnung eindeutig bleibt.
- Findet ein Name gar keinen Platz, wird das ausgewiesen ("15 Netze · 3 ohne
Namen") statt stillschweigend wegzufallen.
Netzauswahl (Eddys Vorschlag): Kästchen je Netz in der Liste, dazu die
Schnellwahl "nur starke" (eigenes Netz + alles über -70 dBm) und "alle".
Ein Hinweisband nennt die Zahl der ausgeblendeten Netze und bietet
"Alle zeigen" an.
WICHTIG dabei: Das Ausblenden betrifft ausschließlich die Zeichnung.
Kanalempfehlung und Warnregeln rechnen weiter mit ALLEN sichtbaren Netzen —
sonst würde das Ausblenden eines starken Störers dessen Kanal plötzlich als
"frei" empfehlen. Im Emulator gegengeprüft: nach "nur starke" (11 von 18
ausgeblendet) blieben die Empfehlungswerte 0,83 / 1,33 / 1,38 unverändert.
Demodaten auf 18 Netze erweitert und ein Render-Szenario "dicht24" (15 Netze)
ergänzt, damit sich diese Dichte auch ohne echten Empfang prüfen lässt.
Gerendert, angesehen und zusätzlich im Emulator auf dem Gerät geprüft.
Zwei Widersprüche, die beim Durchsehen der offenen Punkte auffielen. Beide
entstanden erst dadurch, dass der Kanalgraph seit dem letzten Commit die
Wahrheit zeigt — Empfehlung und Kennzeichnung waren noch auf dem alten Stand.
1. Kanalempfehlung ignorierte die Kanalbreite.
interferenceWeight() rechnete nur mit dem Abstand der Kanalnummern. Ein
40-MHz-Netz auf Kanal 1 belegt real 2402-2442 MHz und damit auch Kanal 6
(2437), wurde wegen |1-6| = 5 aber als "stört nicht" gewertet. Gerechnet
wird jetzt in MHz, mit derselben occupiedRange(), die auch das Diagramm
zeichnet.
Belegt mit tools/test-recommend.mjs: in zwei von drei realistischen Lagen
nennt die alte Formel einen ANDEREN Kanal als den tatsächlich besten —
z.B. bei einem starken 40-MHz-Netz auf Kanal 1 empfahl sie Kanal 6, obwohl
dieses Netz genau dorthin reicht (richtig ist Kanal 11). In der Demo-Lage
ändert sich die Spitzenempfehlung nicht, nur die Bewertung der übrigen
Kanäle (K6 von 0,62 auf 0,80).
2. DFS-Kanäle 52-64 waren im Diagramm nicht als solche erkennbar.
Der Block hieß "UNII-1/2A" und trug keine DFS-Kennzeichnung, während
channelWarnings() Kanal 52-144 als DFS behandelt. Ein im Diagramm "frei"
wirkender Kanal 56 hätte den Kunden ungewollt auf DFS gesetzt (möglicher
Radar-Zwangswechsel), obwohl die Warnung darunter das Gegenteil sagte.
UNII-1 (36-48) und UNII-2A (52-64) sind jetzt getrennte Blöcke mit
korrekter Kennzeichnung.
Damit die zusätzliche Aufteilung nicht zu mehr Scrollen führt: ein Block ohne
Netze wird kompakt gezeichnet (ohne dBm-Skala, ~1/4 der Höhe) statt in voller
Größe. Er bleibt sichtbar — er ist die Antwort auf "wo ist noch Platz".
Nebenbei im Render-Werkzeug behoben: es stapelte alle Segmente mit gleicher
Höhe und erzeugte dadurch künstliche Lücken im Testbild, die es in der App
nicht gibt.
Eddys Rückmeldung nach dem ersten Einsatz auf dem Handy: das zweite Diagramm
ergibt keinen Sinn, Zahlen überlappen, und die Signalstärke ist in den
Diagrammen nirgends ablesbar. Alle drei Punkte bestätigt und behoben.
Ursache (nachgerechnet, nicht geraten): die 745 MHz des 5-GHz-Bandes wurden
in dieselbe Breite gequetscht wie die 80 MHz des 2,4-GHz-Bandes — 9,3-fach
schlechtere Auflösung, 8,6 statt 80 Einheiten je 20-MHz-Kanal. Bei 8,6
Einheiten Tick-Abstand und 12,6 Einheiten Breite einer dreistelligen Zahl ist
Überlappung unvermeidbar ("3640444852566064"). Der vorhandene Tick-Filter
filterte nachweislich 0 von 25 Ticks weg, weil er nur gegen den
Frequenzbereich prüfte, in dem ohnehin alle Kanäle liegen.
Kanalgraph:
- 5 GHz in die regulatorischen Blöcke geteilt (UNII-1/2A, UNII-2C, UNII-3),
ein gemeinsamer Maßstab je Band -> 20-MHz-Kanal jetzt ~24 statt 8,6
Einheiten breit, alle Kanalzahlen einzeln lesbar.
- Leere Blöcke werden gezeichnet ("frei — keine Netze") statt weggelassen.
Weglassen ließe das Band voller aussehen als es ist und versteckt genau
die gesuchte Antwort: wo ist noch Platz.
- Trapez statt Parabel — die Fläche zeigt den tatsächlich belegten
Frequenzbereich. Bei der Parabel lag nur die Spitze auf dem Messwert; mit
dBm-Achse wäre alles außer der Bogenmitte falsch abgelesen worden.
- Kanalbreite über centerFreq0 statt Primärfrequenz: ein 80-MHz-Netz auf
Kanal 36 wurde sonst um 5180 statt 5210 gezeichnet, Nachbarkanäle sahen
fälschlich frei aus.
- Farbe je Netz (stabil über BSSID-Hash), gleiche Farbe in Graph, Zeitverlauf
und Netzliste. Vorher verschmolzen überlappende graue Blöcke zu einer Fläche.
- Belegte Kanalnummern hell, freie gedämpft; SSID von hinten gekürzt (sonst
heißen alle FRITZ!Box-Netze gleich); gekappte Blöcke werden markiert.
dBm-Achse (neue gemeinsame Komponente RssiAxis, für Kanalgraph UND
Zeitverlauf — damit sie konstruktiv nicht auseinanderlaufen können):
- feste Skala -95..-30 dBm, 2,0 Einheiten je dB (glatte Rasterlinien),
beschriftet -30/-50/-70/-90, Einheit "dBm", Praxiszonen grün/rot.
- Bewusst "Empfangspegel", nicht "Sendestärke": die Achse zeigt den Pegel am
Standort des Handys, nicht die Leistung des Routers.
- Schrift 7 -> 9/10 (war ~7,6 CSS-px, unter der Lesegrenze), Kontrast der
Achsenbeschriftung von zinc-600 (2,29:1, unter WCAG-Minimum) auf zinc-200/300.
Momentaufnahme wird jetzt synchronisiert: sie lag bisher nur lokal und kam nie
im Protokoll auf dem Server an, obwohl sie genau dafür gemacht wird. Landet
jetzt zusätzlich als Messung (tool='wifikanal') in Sync und PDF.
Klartext-Fazit über dem Diagramm ("Dein Netz: Kanal 6 · -48 dBm (sehr gut) ·
2,4 GHz freister Kanal: 1") — unter Zeitdruck schneller als jedes Diagramm.
Neu: tools/render-chart.mjs rendert die echten Svelte-Komponenten
serverseitig zu SVG/PNG, inklusive Randfällen (1 Netz, 25 Netze, 5 Netze auf
einem Kanal, Bandränder, leeres Band, Zeitverlauf mit Aussetzer). Das ist die
Lehre aus dem Fehler: in Phase 4 wurde die Chart-Mathematik nur durchgerechnet
(keine NaN, nichts außerhalb des Zeichenbereichs) und daraus geschlossen, das
genüge. Rechnerisch korrekt heißt nicht lesbar — ein Diagramm muss man ansehen.
Weiterhin offen: der Emulator hat keine WLAN-Hardware und liefert immer 0
Netze. Alle Diagramme sind mit realistischen Testdaten gerendert und geprüft,
aber nicht mit echtem Empfang auf dem Handy.
Details: ROADMAP_UMSETZUNG.md Phase 4 / Nachbesserung
