… Ihr habt recht, Kollisionen sind ein Thema. Aber eher auf der Seite der FHTs. Die senden Ihren Kram unabgestimmt mit anderen FHTs und wenn Ihr das große Pech habt, dass welche immer gleichzeitig wollen, kommt es zu Problemen.
Insbesondere wächst die Wahrscheinlichkeit solcher Kollisionen recht schnell recht stark an, was die Probleme schon bei geringen Zahlen von Geräten erklärt. Mit der Teilung der verfügbaren Sendezeit durch Telegrammlänge ist es nicht getan, es können keinesfalls 90 FHTs unterstützt werden. Auch lässt sich Zahl der FHTs, die man parallel betreiben kann, nicht durch Erhöhung der Zahl der FHZs steigern. Hier muss mit Kollisionswahrscheinlichkeiten gerechnet werden, beim Betrieb von 90 FHTs ist die Kollisionswahrscheinlichkeit sehr hoch. Auch schon bei sehr viel kleineren Zahlen an FHTs. Und die erzeugen munter Ihre Kollisionen, egal wieviele FHZs zuhören.
Was aber mehrere FHZs an einem Standort betrifft, so ist kann die Software das Senden der Instanzen koordinieren. Hier kommt es dann definitiv nicht zu Kollisionen. So könnte man die FHZs 1 an FHTs binden und den FS20 Funkverkehr über eine zweite FHZ machen, wobei die FHZs kollisionsfrei senden. Wie gesagt, das koordiniert die Software.
Grundsätzlich liegt es nicht am Medium Luft und Funk, dass Kollisionen auftreten können. Das ist auch anderen Medien der Fall, etwa im Ethernet. Die Kollisionen werden auf der Protokollebene behandelt. Wenn Du etwa ein TCP/IP-Package bekommst, dann ist das verifiziert. Ob vorher andere Versuche, das gleiche Paket zu übertragen, gescheitert sind, erfährst Du gar nicht, weil das auf tieferen Protokollebenen behandelt wird.
Wer das mit den Kollisionen im Ethernet nicht glaubt, schicke mal in einem Ethernet im gleichen IP-Subnetz von Rechner A eine große Datei nach Rechner B und gleichzeitig eine von Rechner C nach Rechner D. Da wird sehr schön deutlich, dass die Summe der Datenübertragungsraten weit unter der Bandbreite des Netzes bleibt. Ausnahme: Ihr habt Gigabit-Ethernet. Da liegen die Limitierungen im Rechner selbst, d.h. der Rechner kriegt die Daten nicht mit der Geschwindigkeit aufs Netz, wie das Netz sie abtransportieren könnte.
Mehr als (sehr optimistische) 50 MB pro Sekunde leistet hier kein normaler PC. Häufig sogar nur 20-30 MB /Sek. Von solchen Übertragungen kann es mehrere parallel geben, und das Netz lacht sich immer noch schlapp und es treten nicht allzu viele Kollisionen auf.
In einem 100 MBit Ethernet beträgt die theoretische max. Übertragungsrate 12,5 MB pro Sekunde. Ein gewisser Teil geht für Protokoll-Overhead drauf, zusätzliche Daten die neben den Nutzdaten übertragen werden müssen. Ein weiterer Teil geht für Kollisionen drauf. Eine schlechte Ethernet-Installation kann man auch daran erkennen, dass die Nutzdatenrate häufig unter 60% der Bandbreite fällt. Das heißt, zuviele Geräte im gleichen Subnetz, zu viele Kollisionen. In einer vernünftigen Installation sind 60-70% Datenrate zu erwarten.
Grundsätzlich geht Kollisionsbehandlung auch bei Funk, aber nicht bei einem unidirektionalen System wie FS20. Es sind aber Systeme nicht nur denkbar, sondern auch im Handel, die bidirektional arbeiten, d.h. die Schalter bestätigen den Eingang des Schaltsignals und die ausgeführte Schaltaktion. Eine einfache Art der Kollisionsbehandlung bei so einem System kann so aussehen, dass der Sender im Falle, dass die Bestätigung ausbleibt, solange wiederholt, bis er Bestätigung bekommt.
Man könnte aber auch auf Protokollebene mit Bustokens arbeiten (Funk ist nichts anderes als ein Bus). Die Geräte erhalten nach irgendeinem Schema ein Sendeberechtigungstoken, und nur das Gerät, dass das Token besitzt, darf senden. So werden Kollisionen vermieden. Im Bereich kabelgebundener Netze arbeitet der Tokenring nach so einem Schema. Das Token wandert nach irgendwelchen Kriterien von einem Gerät zum anderen, zeitlich gesteuert, oder die Geräte beantragen das (mit Kollisionsrisiko) solange, bis sie es bekommen. Der Heuristiken sind da viele.
Ein Prozent Sendezeit ist nicht mehr so furchtbar viel, wenn man den Bandbreitenverbrauch, der durch eine Kollisionsbehandlung entstünde, in die Kalkulation einbezieht.
Was IPS angeht, konzeptionell werden mehrere FHZs unterstützt, soviel ist klar. Du kannst mehrere von diesen Instanzen definieren und geeignet verbinden. Die Frage ist halt, wo sind die dazu gehörenden Geräte denn? Alle am IPS PC, wenn IPS auch auf der Geräteebene mehrere FHZs unterstützen sollte. Ich habe das nicht verifiziert.
Und auch wenn IPS mit mehreren FHZs arbeiten kann (wie gesagt, ich weiß es nicht), weiß ich weiter nicht, ob IPS dann managed, dass die kollisionsfrei senden.
Trotzdem, ich stimme zu, dass der Einsatz meines Services mit FHZs überlegt werden muss. Ich denke, es gibt sinnvolle Einsatzmöglichkeiten, aber auch gewisse Beschränkungen, die in diesem System liegen. Die Software ist aber in Ihrem Einsatz nicht auf FHZs beschränkt, es gibt andere Systeme, die von der Architektur stärker profitieren könnten.
Vielen Dank nochmal für die USB-Kennungen. Ich habe inzwischen auch offiziell verifizieren können, dass dies die Produktkennung der FHZ 1000 und FHZ 1300 sind.
Cheers, starfarer