Verbindungsabbrüche OAP54 Bridge 5GHz durch Radarerkennung

[sTm]

Hallo,
ich habe hier eine Bridge über 3 OAPs im 5GHz Band am Laufen. Bis vor einigen Tagen war auch alles o.k. Seitdem die Sonne richtig herunter brennt kommt es häufig zu Radarmustererkennungen.
Meine Vermutung ist, dass durch die von den Dächern aufsteigende heisse Luft diese Fehlinterpretationen auslöst.
Vorher lief die Strecke mit 108Mbit/s klaglos.
AP1 --- ca. 2,5km --- AP2 ---- ca.1km --- AP3
alles über die Bridge, AP2 ist Master, AP1,3 sind die Slaves
Ich habe die Transferrate schon mal auf 72Mbit begrenzt, was eine leichte Verbesserung brachte. Das eigentliche Problem ist, dass der AP1 nach einem Kanalwechsel des Masters ca. 1-1,5 Stunden braucht, um sich wieder zu verbinden. AP3 hat keine Probleme, ca. 10-20s für ein Reconnect.
Ein trace dfs auf allen AP bringt einen Menge Radar zur Anzeige.

Was kann ich tun?
Wie kann ich die Radarempfindlichkeit zurücksetzen ?
Grüße
Stefan

[marc b]

Setzt doch mal den Schwellwert für die Erkennung etwas nach oben.


Marc

[sTm]

Das ist ja mein Problem
Wo mach ich das?
Stefan

[marc b]

Das ist ja mein Problem
Wo mach ich das?
Stefan

Welcher LCOS Version ?

[mistry7]

Hallo,

welche Firmware ist auf den AP´s????

grüße

mistry7

[sTm]

auf allen läuft die 6.12
Stefan

[LoUiS]

Hi,

das musst Du im Telnet/SSH oder im WEBconfig machen:

root@1x22:/Setup/WLAN/Radar-Pattern-Thresholds
> l

Pattern-pps Threshold
--------------------------
700 8
1800 6
330 15

Dort kannst Du die 3 verschiedenen Muster einzeln konfigurieren, aber frag mich nicht nach einem Wert, ich habs bei mir alles auf "Default" stehen.


Ciao
LoUiS

[sTm]

Danke, habe es geändert und warte mit Spannung auf den morgigen Mittag, wenn die Temperaturen steigen.

Ich habe nochmal die Fehlercounter unter dem WLAN Interface beobachtet. Sie zählen immer locker flockig hoch, 10-20/s sind derzeit normal. Wobei die Werte für RX und CRC Error korrespondieren. Ist das normal ? Die Verbindung steht trotzdem mit T-72Mbit. Derzeitige Temperatur des Gerätes um die 48°C.
Grüße
Stefan

[marc b]

Danke, habe es geändert und warte mit Spannung auf den morgigen Mittag, wenn die Temperaturen steigen.

Ich habe nochmal die Fehlercounter unter dem WLAN Interface beobachtet. Sie zählen immer locker flockig hoch, 10-20/s sind derzeit normal. Wobei die Werte für RX und CRC Error korrespondieren. Ist das normal ? Die Verbindung steht trotzdem mit T-72Mbit. Derzeitige Temperatur des Gerätes um die 48°C.
Grüße
Stefan

Schau doch mal was der Temperaturfühler des OAP sagt

Marc

[Panjan]

Pattern-pps Threshold
--------------------------
700 8
1800 6
330 15

Dort kannst Du die 3 verschiedenen Muster einzeln konfigurieren, aber frag mich nicht nach einem Wert, ich habs bei mir alles auf "Default" stehen.

Wundere mich, dass Alf sich nicht sofort gemeldet hat mit der Bemerkung: "Änderungen sind nicht konform mit der Netzagentur" bzw. "Dann kannst du DFS auch gleich abstellen".

Fakt ist: Bei mir läuft es erst stabil mit Einstellungen bis zu

700: 15
1800: 70
330: 17

(Alles ausgetestet unter Version 6.06, keine Ahnung, ob ich unter 6.12 wieder etwas nach unten gehen kann.)

Mich würde einmal interessieren, ob jemand Erfahrungen hat, ob starker Wind die Radarerkennung beeinflusst. Anders gesagt: Kann es sein, dass bei Antennen, die an einem Mast befestigt sind, der bei starkem Wind etwas wackelt, häufiger Radarsignale erkannt werden?

Viele Grüße
Panjan

[alf29]

Moin,

Wundere mich, dass Alf sich nicht sofort gemeldet hat mit der Bemerkung: "Änderungen sind nicht konform mit der Netzagentur" bzw. "Dann kannst du DFS auch gleich abstellen".

Das habe ich - denke ich - schon oft genug gesagt...

Fakt ist: Bei mir läuft es erst stabil mit Einstellungen bis zu

700: 15
1800: 70
330: 17

Das kommt einem Abstellen gleich, weil die ETSI-
Referenzmuster zum Teil gar nicht so lang sind.

Gruß Alfred

[marc b]

Moin,

also

700: 8 (10)
1800: 8 (10)
330: 15

reicht nach meiner Erfahrung auch aus.

[Casey]

Das kommt einem Abstellen gleich, weil die ETSI-
Referenzmuster zum Teil gar nicht so lang sind.

Werden denn die Radarerkennungen von der Firmware ignoriert wenn sie länger als die Referenzmuster sind und in der Form garnicht als echtes Radar auftreten können?

[alf29]

Moin,

nein. Die Mühe habe ich mir gar nicht erst gemacht weil die
Tabelle m.E. ohnehin überflüssig ist. Ein bißchen konform
zu sein ist witzlos, da kann man's auch gleich abschalten...

Gruß Alfred

[Casey]

Wenn die Burstlänge in der Firmware sowieso nach oben offen ist sehe ich kein Problem darin die Pulszahl soweit zu erhöhen das zumindest keine Phantomerkennungen mehr auftreten.
Warum vorher ein gemeinsamer Wert von 7 reichte wo mit neuen Firmwares 9 für das 1800er Muster notwendig ist weiss ich allerdings auch nicht.
Mi einer Erhöhung der Pulszahl dauert es eben ein klein wenig länger bis der Kanal freigemacht wird.
Daraus wird einem aber (ausser im Labor) keiner einen Strick drehen solange der Kanal überhaupt freigemacht wird.
Abgesehen davon steht im Standard eh nichts von 100 Prozentigen Erkennungsraten, sondern nur >60% bei 30% Channelload.
Deswegen macht es eben doch einen Unterschied ob man DFS ganz abschaltet oder etwas härtet.

Bei einem Maximum von 18 10 70 kann 8 9 15 kein großes Problem darstellen, insbesondere wenn man sowieso die Burstlänge ignoriert und sich allein auf die Pulsabstände stürzt.

"In general 5 sequential bursts are needed to achieve a real life detection rate of better that 99 % for any radar that falls within the scope of this table."

Diesem Satz entnehme ich das es selbst ETSI reicht wenn nach 5 Bursts von einem echten Radar eine Erkennung erfolgt solange sie dann wenigstens zuverlässig ist.

Schöner würde ich finden wenn man als Bedingung für einen Kanalwechsel zwei Erkennungen (mit Standardwerten) in kurzer Folge einstellen könnte, aber solange das nicht geht bleibt eben nur die Werte so hoch zu setzen das keine Phantomerkennungen mehr auftreten.

Oder habe ich irgendetwas übersehen?