8
Gigaset N870 Lan Sync
Hallo,
ich bräuchte Hilfe beim Troubleshooting für ein Gigaset DECT N870, denn ich vermute das ich irgendwas übersehe.
Kurz zur Historie: Vor mehr als 3 Jahren eingeführt, lief es Anfangs unauffällig. Keine Probleme, keine Asynchronität der DECT-Zellen. Letztes Jahr mit einem ersten Update seit Einführung, ging das Drama los. Ja ja, never change a Running System und so... ein Downgrade wäre möglich gewesen, war aber nicht drin, weil die neueren Telefone sonst nicht unterstützt wurden. Das Problem war das die Basisstationen täglich mehrmals Asynchron wurden. DIe Updates von Gigaset verschlimmerten das Problem sogar. Zu der Zeit gab es riesige Threads auch in anderen Foren mit massenhaft Problemen. Im Endeffekt konnte ich es nur eindämmen, in dem ich die Basisstationen statisch IP-Adressen vergeben habe. Danach wurden die Asyncs weniger. Es war dann in einem erträglichen Maß, das alle 14 Tage mal eine Basisstation Async ging. Ich habe das dann irgendwann auf Gigaset und der schlechten Firmware geschoben.
Jetzt werden die Asyncs und die Gesprächsabbrüche in den letzten Tagen immer mehr. Ich kann es mir einfach nicht erklären. Das letzte Update Release 2.54.0 ist eingespielt seit mehreren Wochen. Das es immer nur an der Firmware liegt, wäre einfach und würde auch den Bankrott von Gigaset erklären, aber es wäre auch irgendwo zu einfach.
Zum DECT-System:
Zur Switch-Infrastruktur:
Fehlersuche:
Als erstes fällt auf das manche DECT-Zellen öfters Async gehen als andere, was vermuten lässt das es eine Überlastung ist. Ist aber nicht der Fall, weil zu keinem Zeitpunkt überhaupt soviele Mobilteile da in der Nähe sind um die DECT-Zelle auch nur Ansatzweise auszulasten. Auch die 10 gleichzeitigen Gespräche pro Zelle sind nicht erreichbar, weil das nicht mal über der Telefonanlage insgesamt erreicht wird.
Ich habe mir dann entsprechende Zelle AP10 vorgenommen...
Das es immer da wieder Peaks gibt, halte ich für normal. Spricht halt dafür das es verwendet wird und das Gespräche drüber gehen. Das er da mal ein Paket eingehend gedroppt hat, finde ist jetzt noch kein Beinbruch. Zumal man auch nicht weiß warum.
Im Log steht immer wieder, soetwas z.B.:
Bei der Qualitäts-Statistik wird es dann richtig gruselig...
Abgesehen von den 11 Asyncs, "o-thr-exc" massiv erhöht innerhalb von wenigen Wochen. Der Counter sagt aus, wie of er über 500ns geschossen ist. Das ist die magische Grenze bei Gigaset bis zu der das System als funktional gilt. Allerdings trifft es nur zu, wenn es über einen längeren Zeitraum festgestellt wird. Das "ptp-d" als rms nur 192ns hat, ist davon auszugehen das immer nur einen kurzen Peak gibt. Das selbe Spiel bei "dls-d" wo die magische Grenze bei 1000ns liegt, aber eben auch nur über einen längeren Zeitraum.
https://teamwork.gigaset.com/gigawiki/pages/viewpage.action?pageId=10148 ...
Komischerweise habe ich durchweg ein Lan Sync Quality "q-id-lt" von weit über 90%. Dennoch kommt es immer wieder zu Asychronitäten.
Dann dachte ich das es an Kupfer-Kabeln zu dem DECT liegen kann: Weder am Switch noch am Gerät wurden Kabelfehler aufgezeichnet.
Warum er hier soviele Pakete droppt, ist mir schleierhaft. Ob das normal ist, weiß ich ebenfalls nicht. Ich kann hier nur vermuten: Doppelte übertragende PTP oder Sync-Pakete, solange bis er antwortet.
Am Switch sieht es so aus...
Der Switch-Port langweilt sich im Großen und Ganzen.
Eine Aufzeichnung des Traces über längeren Zeitraum habe ich gemacht, aber führt immer zu nichts, weil man nie genau sagen kann wann genau die DECT-Zelle async wird. Der Zeitraum kann mehrere Minuten andauern zwischen "es wurde erkannt das async ist" und "Neu synchronisieren" in der Zeit sind tausende Pakete eingegangen und man weiß nicht nach was man suchen soll.
Hat jemand eine Idee wonach man suchen könnte um dem Problem auf die Spur zu kommen? Wenn es ein Firmware-Problem ist, was ich nicht ausschließen kann, wie kann ich es dennoch optimieren damit es wieder in einem erträglicheren Rahmen läuft?
Gruß
ich bräuchte Hilfe beim Troubleshooting für ein Gigaset DECT N870, denn ich vermute das ich irgendwas übersehe.
Kurz zur Historie: Vor mehr als 3 Jahren eingeführt, lief es Anfangs unauffällig. Keine Probleme, keine Asynchronität der DECT-Zellen. Letztes Jahr mit einem ersten Update seit Einführung, ging das Drama los. Ja ja, never change a Running System und so... ein Downgrade wäre möglich gewesen, war aber nicht drin, weil die neueren Telefone sonst nicht unterstützt wurden. Das Problem war das die Basisstationen täglich mehrmals Asynchron wurden. DIe Updates von Gigaset verschlimmerten das Problem sogar. Zu der Zeit gab es riesige Threads auch in anderen Foren mit massenhaft Problemen. Im Endeffekt konnte ich es nur eindämmen, in dem ich die Basisstationen statisch IP-Adressen vergeben habe. Danach wurden die Asyncs weniger. Es war dann in einem erträglichen Maß, das alle 14 Tage mal eine Basisstation Async ging. Ich habe das dann irgendwann auf Gigaset und der schlechten Firmware geschoben.
Jetzt werden die Asyncs und die Gesprächsabbrüche in den letzten Tagen immer mehr. Ich kann es mir einfach nicht erklären. Das letzte Update Release 2.54.0 ist eingespielt seit mehreren Wochen. Das es immer nur an der Firmware liegt, wäre einfach und würde auch den Bankrott von Gigaset erklären, aber es wäre auch irgendwo zu einfach.
Zum DECT-System:
- 14x Basisstationen N870 (Lan Sync, 1x Master, 1x LAN Master)
- verschiendene originale Mobilteile (SL750H, S650H, S700H, SL800H Pro) ca. 38 Stück
- Die Basisstationen befinden sich alle im selben VLAN
Zur Switch-Infrastruktur:
- Core ist ein ICX7750 Layer3 (Commscope vormals Ruckus vormals Brocade)
- Access-Switches an denen DECT-Zellen (aber auch andere Endgeräte) hängen, ICX7250 und ICX7450
- untereinander mit 10Gbit LACP LAG verbunden
Fehlersuche:
Als erstes fällt auf das manche DECT-Zellen öfters Async gehen als andere, was vermuten lässt das es eine Überlastung ist. Ist aber nicht der Fall, weil zu keinem Zeitpunkt überhaupt soviele Mobilteile da in der Nähe sind um die DECT-Zelle auch nur Ansatzweise auszulasten. Auch die 10 gleichzeitigen Gespräche pro Zelle sind nicht erreichbar, weil das nicht mal über der Telefonanlage insgesamt erreicht wird.
Ich habe mir dann entsprechende Zelle AP10 vorgenommen...
Das es immer da wieder Peaks gibt, halte ich für normal. Spricht halt dafür das es verwendet wird und das Gespräche drüber gehen. Das er da mal ein Paket eingehend gedroppt hat, finde ist jetzt noch kein Beinbruch. Zumal man auch nicht weiß warum.
Im Log steht immer wieder, soetwas z.B.:
Oct 6 11:42:22.441 dlsd[30057]: >>> ptp-pd overshot/peak detected: obsrv-act[ns]: 41049 | obsrv-mean[ns]: 31239 | delta[ns]: 9810 | delta-rel[%]: 31Bei der Qualitäts-Statistik wird es dann richtig gruselig...
SYS ----- : dls-mode -, syn-mode -, lan-m ----, ptp-m ----, -- state ----
: client, LAN, OFF, OFF, SYNC (80)
DBC ----- : dm-id ----, cluster --, cl-mask --, level ----, -- Info -----
: 0x1035db44, 1, 0x000000ff, 2, 0xb081e000
PTP ----- : gm-id ----------------, domain ---, -------------------------
: 589ec6.fffe.2122c1, 21
DLS ----- : m-id -----------------, ----------, DS - : pari -----, rpn --
: 589ec6.fffe.2122c1, , 0x1035db44, 0x03
QUALITY - : ----------, ----------, ----------, ---------- --------------
qa cnts : async ----, tias -----, o-thr-exc , d-thr-exc , q-idx-st ----
: 11, 160, 3938, 14, 99.00
qa stats : ptp-pd ---, ptp-d ----, dls-d ----, tias-max -, q-idx-lt ----
stddev : 377, 241, 474, 2056, 96.57
TIMIMG -- : ----------, ----------, ----------, ---------- --------------
CURRENT - : ptp-pd ---, ptp-d ----, dls-d ----, osc-idx --, -------------
[ns] : 31058, 57, -180, 157
STATS --- : rms ------, min ------, max ------, mean ----- +/- stddev ---
p(av)[ns] : 160000931, 160000897, 160000962, 160000931 +/- 15
frq[MHz] : 13.823920, 13.823917, 13.823922, 13.823920 +/- 0.000001
osc-idx : 156, 156, 157, 156 +/- 0
ptp-pd[ns]: 31080, 30685, 31568, 31079 +/- 183
ptp-d[ns] : 192, -426, 406, 26 +/- 190
dls-d[ns] : 163, -439, 425, -0 +/- 163
eof dls-stats ===========================================================Abgesehen von den 11 Asyncs, "o-thr-exc" massiv erhöht innerhalb von wenigen Wochen. Der Counter sagt aus, wie of er über 500ns geschossen ist. Das ist die magische Grenze bei Gigaset bis zu der das System als funktional gilt. Allerdings trifft es nur zu, wenn es über einen längeren Zeitraum festgestellt wird. Das "ptp-d" als rms nur 192ns hat, ist davon auszugehen das immer nur einen kurzen Peak gibt. Das selbe Spiel bei "dls-d" wo die magische Grenze bei 1000ns liegt, aber eben auch nur über einen längeren Zeitraum.
https://teamwork.gigaset.com/gigawiki/pages/viewpage.action?pageId=10148 ...
Komischerweise habe ich durchweg ein Lan Sync Quality "q-id-lt" von weit über 90%. Dennoch kommt es immer wieder zu Asychronitäten.
Dann dachte ich das es an Kupfer-Kabeln zu dem DECT liegen kann: Weder am Switch noch am Gerät wurden Kabelfehler aufgezeichnet.
RX packets:87760063 errors:0 dropped:2346310 overruns:0 frame:0Warum er hier soviele Pakete droppt, ist mir schleierhaft. Ob das normal ist, weiß ich ebenfalls nicht. Ich kann hier nur vermuten: Doppelte übertragende PTP oder Sync-Pakete, solange bis er antwortet.
Am Switch sieht es so aus...
GigabitEthernet1/1/31 is up, line protocol is up
Port up for 51 day(s) 1 hour(s) 30 second(s)
Hardware is GigabitEthernet, address is
Configured speed auto, actual 100Mbit, configured duplex fdx, actual fdx
Configured mdi mode AUTO, actual MDI
EEE Feature Disabled
Untagged member of L2 VLAN 30, port state is FORWARDING
BPDU guard is Disabled, ROOT protect is Disabled, Designated protect is Disabled
Link Error Dampening is Disabled
STP configured to ON, priority is level0, mac-learning is enabled
MACsec is Disabled
Flow Control is config enabled, oper enabled, negotiation disabled
Mirror disabled, Monitor disabled
Mac-notification is disabled
VLAN-Mapping is disabled
Not member of any active trunks
Not member of any configured trunks
Port name is Gigaset DECT
IPG MII 96 bits-time, IPG GMII 96 bits-time
MTU 1500 bytes
MMU Mode is Store-and-forward
300 second input rate: 1904 bits/sec, 2 packets/sec, 0.00% utilization
300 second output rate: 8784 bits/sec, 6 packets/sec, 0.00% utilization
93485246 packets input, 13756771907 bytes, 0 no buffer
Received 2612 broadcasts, 11811 multicasts, 93470823 unicasts
0 input errors, 0 CRC, 0 frame, 0 ignored
0 runts, 0 giants
190245703 packets output, 32966867418 bytes, 0 underruns
Transmitted 597523 broadcasts, 95619127 multicasts, 94029053 unicasts
0 output errors, 0 collisions
Relay Agent Information option: Disabled
Protected: No
MAC Port Security: Disabled
UC Egress queues:
Queue counters Queued packets Dropped Packets
0 18668529 0
1 0 0
2 1551408 0
3 0 0
4 1693856 0
5 27656327 0
6 34023 0
7 56261478 0
MC Egress queues:
Queue counters Queued packets Dropped Packets
0 311769 0
1 675424 0
2 11109 0
3 83381781 0Der Switch-Port langweilt sich im Großen und Ganzen.
Eine Aufzeichnung des Traces über längeren Zeitraum habe ich gemacht, aber führt immer zu nichts, weil man nie genau sagen kann wann genau die DECT-Zelle async wird. Der Zeitraum kann mehrere Minuten andauern zwischen "es wurde erkannt das async ist" und "Neu synchronisieren" in der Zeit sind tausende Pakete eingegangen und man weiß nicht nach was man suchen soll.
Hat jemand eine Idee wonach man suchen könnte um dem Problem auf die Spur zu kommen? Wenn es ein Firmware-Problem ist, was ich nicht ausschließen kann, wie kann ich es dennoch optimieren damit es wieder in einem erträglicheren Rahmen läuft?
Gruß
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 61687433117
Url: https://administrator.de/contentid/61687433117
Ausgedruckt am: 21.11.2024 um 19:11 Uhr
8 Kommentare
Neuester Kommentar
Schau mal ob du die Empfangsstärke findest, also die dB Werte zwischen den Stationen. Wenn diese grenzwertig niedrig sind, reichen kleinste Änderungen, dass es zu einem Fehler kommt.
Die Sendeleistung würde ja nur Sinn machen, wenn sie sich darüber auch Synchronisieren. Was ja nicht der Fall ist, da explizit LAN Sync verwendet wird.
Einzige Einstellung die ich finden konnte, war die Reduzierung der Sendeleistung bei der Verwendung einer externen Antenne:
Es stellt sich natürlich die Frage wie die Mobilteile sich verhalten. Bleiben sie lange an einer DECT-Zelle angemeldet oder bleiben da kleben, auch wenn die Stärke des Signals schon eher schlecht ist, oder springen sie zeitig zur nächst besseren Signalquelle. Leider kann man das über die Werkzeuge die einem Gigaset mit gibt, nicht herausfinden. Zumindest habe ich bisher nichts gefunden.
Einzige Einstellung die ich finden konnte, war die Reduzierung der Sendeleistung bei der Verwendung einer externen Antenne:
Es stellt sich natürlich die Frage wie die Mobilteile sich verhalten. Bleiben sie lange an einer DECT-Zelle angemeldet oder bleiben da kleben, auch wenn die Stärke des Signals schon eher schlecht ist, oder springen sie zeitig zur nächst besseren Signalquelle. Leider kann man das über die Werkzeuge die einem Gigaset mit gibt, nicht herausfinden. Zumindest habe ich bisher nichts gefunden.
Ist dein komplettes Switch-Setup PTP-tauglich?
Wir setzen die großen Netgear-Switches ein und da gibt es bei manchen Switchtypen Einschränkungen für den PTP-Betrieb.
Da wir damals in einem unserer Objekte PTP nicht sauber laufen lassen konnten, sind wir auf die Syncronisation per Luftschnittstelle zurückgewechselt.
Das Problem zeigt sich beim Handover. Nur in diesem Fall müssen die Basen syncronisiert sein. Wenn du zwischen zwei Basen wechselst, die in dem Moment nicht synchronisiert sind, bricht die Verbindung mit hoher Wahrscheinlichkeit ab, sobald du den Bereich der abgebenden Zelle verlässt.
Wir setzen die großen Netgear-Switches ein und da gibt es bei manchen Switchtypen Einschränkungen für den PTP-Betrieb.
Da wir damals in einem unserer Objekte PTP nicht sauber laufen lassen konnten, sind wir auf die Syncronisation per Luftschnittstelle zurückgewechselt.
Das Problem zeigt sich beim Handover. Nur in diesem Fall müssen die Basen syncronisiert sein. Wenn du zwischen zwei Basen wechselst, die in dem Moment nicht synchronisiert sind, bricht die Verbindung mit hoher Wahrscheinlichkeit ab, sobald du den Bereich der abgebenden Zelle verlässt.
Das ist mir gegenwärtig nicht ganz klar muss ich gestehen. Laut diesem Eintrag im Configuration Guide:
https://docs.commscope.com/bundle/fastiron-08095-managementguide/page/GU ...
... soll es für alle Switches die ich hier im Einsatz habe und die Version 08095 haben, eine Option "ptp-clock" geben. Gefunden habe ich diese Option zum Aufrufen bisher nur beim ICX7750. Aber dort ist es nicht aktivierbar, weil es generell für einen Stack nicht supported wird. Bei den anderen, ICX7250 und ICX7450, ist es nicht auswählbar.
Sollte mich aber wundern, wenn solche Switches aus dem hohen Preissegment das nicht voll supporten.
Es ist ja auch nicht so das es dauerhaft nicht funktioniert. Ich kann mit dem Telefon durch das gesamte Haus spazieren und habe keine Probleme. Aber sporadisch, jetzt eben häufiger, verlieren die Basen ihren Sync.
Sync per Luftschnittstelle hatten wir ausgeschlossen, weil es sonst wegen der dicken Granitwände zu Problemen kommt, wenn man in ein anderes Stockwerk geht. Allerdings könnte man das dennoch, wenn man jetzt einmal dabei ist, testen.
https://docs.commscope.com/bundle/fastiron-08095-managementguide/page/GU ...
... soll es für alle Switches die ich hier im Einsatz habe und die Version 08095 haben, eine Option "ptp-clock" geben. Gefunden habe ich diese Option zum Aufrufen bisher nur beim ICX7750. Aber dort ist es nicht aktivierbar, weil es generell für einen Stack nicht supported wird. Bei den anderen, ICX7250 und ICX7450, ist es nicht auswählbar.
Sollte mich aber wundern, wenn solche Switches aus dem hohen Preissegment das nicht voll supporten.
Es ist ja auch nicht so das es dauerhaft nicht funktioniert. Ich kann mit dem Telefon durch das gesamte Haus spazieren und habe keine Probleme. Aber sporadisch, jetzt eben häufiger, verlieren die Basen ihren Sync.
Sync per Luftschnittstelle hatten wir ausgeschlossen, weil es sonst wegen der dicken Granitwände zu Problemen kommt, wenn man in ein anderes Stockwerk geht. Allerdings könnte man das dennoch, wenn man jetzt einmal dabei ist, testen.
Aber das scheint wirklich das Problem zu sein. LAN Sync ist nicht der Standard. Per Default ist es DECT, also Luftschnittstelle.
Es gibt nur ein Handvoll Switches, selbst bei den großen Herstellern die scheinbar PTP-tauglich sind. Bei Cisco sind es paar wenige Catalysten/Nexus, bei Brocade nur bei den Datacenter also ICX7750 aufwärts... aber nur dann wenn sie sich in keinem Stack befinden.
Hier eine scheinbar nicht ganz aktuelle Liste:
https://en.wikipedia.org/wiki/List_of_PTP_implementations
Behelfen kann man sich wohl, entweder mit dedizierter Hardware physisch getrennt, also auch kein VLAN oder eben DECT-Sync. Auch mit speziellen PTP-Switches, aber eben auch nur getrennt. Da gibt es paar Hersteller wie z.B. Perle oder FibroLAN.
Es ist bei mir scheinbar auch nur solange gut gegangen, weil meine Switches das Problem mir dem QoS sehr gut kaschieren konnten. Aber das geht natürlich nur solange wie die Bandbreite und Anzahl der Pakete überschaubar bleibt. Dadurch das Unternehmen auch gewachsen ist, wird es das Problem sein.
Das ist gerade eine echte Offenbarung. Mir war gar nicht bewusst das da so ein Zauber drum gemacht werden muss.
Es gibt nur ein Handvoll Switches, selbst bei den großen Herstellern die scheinbar PTP-tauglich sind. Bei Cisco sind es paar wenige Catalysten/Nexus, bei Brocade nur bei den Datacenter also ICX7750 aufwärts... aber nur dann wenn sie sich in keinem Stack befinden.
Hier eine scheinbar nicht ganz aktuelle Liste:
https://en.wikipedia.org/wiki/List_of_PTP_implementations
Behelfen kann man sich wohl, entweder mit dedizierter Hardware physisch getrennt, also auch kein VLAN oder eben DECT-Sync. Auch mit speziellen PTP-Switches, aber eben auch nur getrennt. Da gibt es paar Hersteller wie z.B. Perle oder FibroLAN.
Es ist bei mir scheinbar auch nur solange gut gegangen, weil meine Switches das Problem mir dem QoS sehr gut kaschieren konnten. Aber das geht natürlich nur solange wie die Bandbreite und Anzahl der Pakete überschaubar bleibt. Dadurch das Unternehmen auch gewachsen ist, wird es das Problem sein.
Das ist gerade eine echte Offenbarung. Mir war gar nicht bewusst das da so ein Zauber drum gemacht werden muss.
IP und Ethernet nicht echtzeitfähig und das ist schon lange bekannt.
Gab es früher Probleme mit der Sync. über die Luftschnittstelle oder wurde es einfach nur ausgeschlossen, weil man meinte, das es nicht funktioniert?
Wir haben mit fünf Basen 15000m2 Betonbau samt Außenbereich bespaßt, via Luftschnittstelle, weil die LAN-Sync. Probleme gemacht hat. Zu dem Zeitpunkt hatten wir noch Avayaswitches im Einsatz (sind in der gleichen Preisregion wie deine Switches unterwegs) und die kamen mit dem Synctraffic gar nicht klar.
Selbst die DECT-TDM-Systeme haben in der Regel die Basen untereinander via Luftschnittstelle syncronisiert, weils einfach besser funktionierte als über den Kabelweg.
Gab es früher Probleme mit der Sync. über die Luftschnittstelle oder wurde es einfach nur ausgeschlossen, weil man meinte, das es nicht funktioniert?
Wir haben mit fünf Basen 15000m2 Betonbau samt Außenbereich bespaßt, via Luftschnittstelle, weil die LAN-Sync. Probleme gemacht hat. Zu dem Zeitpunkt hatten wir noch Avayaswitches im Einsatz (sind in der gleichen Preisregion wie deine Switches unterwegs) und die kamen mit dem Synctraffic gar nicht klar.
Selbst die DECT-TDM-Systeme haben in der Regel die Basen untereinander via Luftschnittstelle syncronisiert, weils einfach besser funktionierte als über den Kabelweg.
Nochmal weiter recherchiert zu ICX Switches, falls einem das auch mal auf die Füße fällt:
Ab Version 10.0.00 unterstützen es nur noch ICX7550, ICX7650 und ICX7850. Mit hoher Wahrscheinlichkeit auch die neuen ICX8200er.
Bis Version 08.0.95: ICX7150 und ICX7850.
Das deckt sich mit anderen Herstellern, da sind immer nur eine sehr überschaubare Menge an Modellen wirklich tauglich für PTP.
Ansonsten kann man nur Switch Hops reduzieren oder eben DECT Sync verwenden. Ich habe letzteres gerade konfiguriert. Mal sehen wie es laufen wird.
Ab Version 10.0.00 unterstützen es nur noch ICX7550, ICX7650 und ICX7850. Mit hoher Wahrscheinlichkeit auch die neuen ICX8200er.
Bis Version 08.0.95: ICX7150 und ICX7850.
Das deckt sich mit anderen Herstellern, da sind immer nur eine sehr überschaubare Menge an Modellen wirklich tauglich für PTP.
Ansonsten kann man nur Switch Hops reduzieren oder eben DECT Sync verwenden. Ich habe letzteres gerade konfiguriert. Mal sehen wie es laufen wird.
Gab es früher Probleme mit der Sync. über die Luftschnittstelle oder wurde es einfach nur ausgeschlossen, weil man meinte, das es nicht funktioniert?
Ich kann mich leider nicht mehr genau erinnern. Ich habe mir sagen lassen das wir anfangs DECT Sync hatten und dann wegen Problemen auf LAN umgestiegen sind.
Wir haben hier 14 Stück für 5 Etagen. Grob 4500m² + 2000m² Außenbereich. Aber eben viele Mobilteile, in Kombination mit vielen Störquellen. Die Störquellen sind vielfältig: Angefangen von einem Grundstück mitten in der Stadt, zu medizinischen Geräten, hinzu Treppenaufgängen die sehr Massiv gebaut sind und so einige Signale wegschlucken. Selbst einige Zwischenwände sind aus 80er Ziegelwand. Dazu noch teilweise Feuerschutztüren. Da hatten wir in einem Raum auch explizit Probleme, weshalb uns auch da LAN Sync seitens Gigaset empfohlen wurde. Auch haben wir einen Fahrstuhl, da verliert man immer mal wieder das Signal.
Wir hatten vorher eine Elmeg Anlage die sogar von Gigaset mit projektiert wurde, die aber letztendlich überhaupt nicht lief. Wir haben dann alles original Gigaset Basen genommen und die an die projektierten Stellen angeschlossen. So wie es Gigaset ausgeleuchtet hatte.
Aber Ja, im Nachhinein haben wir es teilweise etwas zu gut gemeint mit der Anzahl der DECT-Zellen.
