Hallo, widme mich jetzt mal verstärkt meinem Hobby, Modelleisenbahn. Soll natürlich Digital sein und "von mir..." Frage ist, wie man/ich eine möglichst Zeitnahe Verbindung zwischen den verschiedenen Funktionsgruppen realisiert. Funktionsgruppen sind einmal die Zentrale, die diversen Aktoren und die Rückmelder. Habe für mich erst mal ausgeschlossen WLan, Bluetooth oder andere Funknetze...bleibt eigentlich nur IR. Was meint ihr...oder was würdet ihr machen? Danke und Gruß Rainer
Rainer V. schrieb: > Was meint ihr...oder was würdet ihr machen? Den guten alten Draht schlägt nix, also sollte man den auch nehmen, wann immer möglich. Einfach, billig, zuverlässig.
c-hater schrieb: > Den guten alten Draht schlägt nix, also sollte man den auch nehmen, wann > immer möglich. Einfach, billig, zuverlässig. Lieber Freund, wenn du mit dem guten alten Draht ein komplexes System vernetzen willst, dann wirds einfach kompliziert! Unnötig kompliziert...
Rainer V. schrieb: > weil nicht schnell genug??? Was, bitteschön, muß bei einer Modelleisenbahn wirklich schnell gehen? Es handelt sich dabei um Mechanik, die mit maximal ein paar cm/s unterwegs ist.
Rainer V. schrieb: > c-hater schrieb: >> Den guten alten Draht schlägt nix, also sollte man den auch nehmen, wann >> immer möglich. Einfach, billig, zuverlässig. > > Lieber Freund, wenn du mit dem guten alten Draht ein komplexes System > vernetzen willst, dann wirds einfach kompliziert! Unnötig kompliziert... Aber Du musst doch sowieso Strom überall hinführen. Wo ist denn da das Problem 1 (oder 2) weitere Adern für Daten mitzuziehen? Es gibt doch sicherlich haufenweise Lösungen wo Leute genau das realisiert haben, also ein Bussystem.
Rainer V. schrieb: > Lieber Freund, wenn du mit dem guten alten Draht ein komplexes System > vernetzen willst, dann wirds einfach kompliziert! Unnötig kompliziert... Hmm. Genau deshalb sind wohl die CPUs intern mit WLAN o.ä. vernetzt...
Mit 400GBASE-ZR ist der Flaschenhals jedenfalls nicht in der Kommunikation!
c-hater schrieb: > Was, bitteschön, muß bei einer Modelleisenbahn wirklich schnell gehen? Es muß schnell gehen, wenn ein Ereignis erkannt wird! Die Züge mögen natürlich dahin dümpeln (aus Sicht des Contollers) wenn aber der "langsame" Zug sein Gleis erreicht/verlassen hat, dann braucht die Zentrale diese Info "sofort"! Ich schreibe das bewußt in Anführungszeichen, weil ich bisher nicht weiß, wie die Zeiten wirklich sein werden. Und als "Assembler" weiß ich genau, dass auch bei 16MHz manchmal kaum Luft bleibt! Ich gebe zu, dass ich nicht weiß, wie die Profisysteme da was machen, aber darüber kriegt man natürlich auch keine Infos! Also, ich fang' mal an... Gruß Rainer
Markus M. schrieb: > Aber Du musst doch sowieso Strom überall hinführen. Wo ist denn da das > Problem 1 (oder 2) weitere Adern für Daten mitzuziehen? Hi, habe dich jetzt nur aus der überraschenden Menge der Antworten herausgenommen. Strom und damit Info ist überall, wo eine Schiene liegt...ist bei Modellbahn so...man möchte aber auch mit sogenannten "Handheld-Geräten" arbeiten. Das sind (im besten Fall "stand-alone" Geräte) mit denen man irgendetwas auf der Anlage manuell und "sofort" steuern kann!! Gruß Rainer
Und du schließt WLAN aus weil es langsam ist? ? Ich mein du kannst 4K Netflix damit streamen und hast vielleicht 20ms Ping (intern eher weniger) aber die Eisenbahn muss das mindesten innerhalb 20us wissen ?
Rainer V. schrieb: > Ich schreibe das bewußt in Anführungszeichen, weil ich bisher nicht > weiß, wie die Zeiten wirklich sein werden. Dann fängst du falsch herum an. Du musst dein System skizzieren und dir dann überlegen in welcher Zeit eine Aktion passiert sein muss. Und was passiert, wenn es länger dauert. Z.B. könnte es auch reichen wenn die Nachricht einen Timestamp enthält damit die Zentrale weiß wann etwas passiert ist, wie schnell die Nachricht ankommt ist aber völlig egal. Alles sowas musst du dir überlegen und festmachen. Wenn du soweit bist, dann ist erst der Zeitpunkt um das Übertragungssystem festzulegen. Dann kannst du entscheiden, ob es ein Echtzeit tauglicher Assembler Verhau werden muss, oder ob es reicht die Nachricht irgendwo in ein WLAN Mesh rein zu kippen. Oder ob du vielleicht sogar dezentral gehst, z.B. Weichen und Haltepunkte werden "intelligent" gebaut. Der Haltepunkt kümmert sich um das zeitkritische Anhalten des Zuges und meldet dann gemütlich an die Zentrale.
Rainer V. schrieb: > Es muß schnell gehen, wenn ein Ereignis erkannt wird! Die Züge mögen > natürlich dahin dümpeln (aus Sicht des Contollers) wenn aber der > "langsame" Zug sein Gleis erreicht/verlassen hat, dann braucht die > Zentrale diese Info "sofort"! Definiere "sofort". > Ich schreibe das bewußt in > Anführungszeichen, weil ich bisher nicht weiß, wie die Zeiten wirklich > sein werden. Sowas kann man tatsächlich AUSRECHNEN. Mag dir unwirklich vorkommen, aber so beginnt Systemdesign nunmal. Man ermittelt die Anforderungen, die die Funktion sicherstellen. > Und als "Assembler" weiß ich genau, dass auch bei 16MHz > manchmal kaum Luft bleibt! Also ich wüßte nicht, wo es da bei einer Modellbahn eng werden könnte. Nunja, jedenfalls für eine übliche private Anlage. Sachen wie das Hamburger Miniatur-Wunderland sind natürlich eine Dimension, die einen einzelnen µC mit 16MHz schon gehörig in's Schwitzen bringen könnten. Aber sowas hast du zu Hause sicher nicht. Diese großen Anlagen arbeiten PC-basiert. Aber es sind sicher auch hunderte µC dezentral beteiligt, die sich jeweils nur um kleine Teilaufgaben kümmern. Der Punkt ist: auch die ganz großen Anlagen arbeiten fast vollständig drahtgebunden. Nur für bestimmte Teile (nämlich das, was ohne drahtgebundene Versorgung auskommen muss) wird auch zur Signalisierung notgedrungen eine drahtlose Technologie eingesetzt.
Guest schrieb: > Und du schließt WLAN aus weil es langsam ist? ? > > Ich mein du kannst 4K Netflix damit streamen und hast vielleicht 20ms > Ping (intern eher weniger) aber die Eisenbahn muss das mindesten > innerhalb 20us wissen ? Sorry, wenn ich mich als totalen Depp outen muß, aber ich habe keine Vorstellung von Netflix...aber du kannst dir vielleicht vorstellen, dass auf meiner angedachten Anlage ca. 100 Melder/Aktoren mit Rückmeldung miteinander reden müssen. Ich rede nicht nur von einer Zentrale, die mit einem Steuer-PC verbunden ist. Das natürlich gerne per High-Speed-Usb. Gruß Rainer
Rainer V. schrieb: > ca. 100 Melder/Aktoren Wow. Hundert. So eine unglaublich große Zahl. Das ist mit hundert Megabit pro Sekunde, a.k.a. hundert millionen Bit pro Sekunde, die WLAN bietet, kaum lösbar. Da bleiben ja kaum eine Million Bit pro Sekunde pro Sensor. Das ist bestimmt zu wenig. Im Ernst: Ja, Funk ist nicht die Lösung für dein Problem. Weil es einfach viel zu komplex ist. Aber dein Problem ist trivial mit jeden beliebigen drahtgebundenen Bus lösbar.
Digitale Modellbahn hat etwa 22kBaud am Gleis. Das ist noch viel Luft selbst zum grottigsten WLan. Da kann man fast noch trommeln.
Rainer V. schrieb: > gerne per High-Speed-Usb Und gerade das laesst sich gern mal einige Zeitm bevor irgendwas losgeht. wendelsberg
warum schrieb: > Aber dein Problem ist trivial mit jeden beliebigen drahtgebundenen Bus > lösbar. Naja, vielleicht nicht mit jedem beliebigen, aber es gibt sicher genug geeignete Kandidaten.
c-hater schrieb: > Hamburger Miniatur-Wunderland Ja Mann, ich will mich natürlich nicht auch nur angedacht mit MiWu vergleichen, aber auch da weiß ich nicht, wie die das wirklich machen! Natürlich haben die hömmelene PC's im Einsatz! Und wie es mit persönlicher Aktion über eben diese Handgeräte aussieht, weiß ich auch nicht! Aber ich wiederhole, 16MHz sind oft weg, wie nix!! Ich dachte, wenn ich über WLan auch nur 50 Sender auswerten muß, um eine Aktion zu bestätigen (z.B. Signal.XY auf rot) dann dauert das. Meine Alternative ist jetzt halt per IR pollen und die INfo kriegen. Weiß wirklich nicht, ob das in einem Funknetz schneller geht! Gruß Rainer
wendelsberg schrieb: > Und gerade das laesst sich gern mal einige Zeitm bevor irgendwas > losgeh Du hast ja so recht...
Wieso hast du dich so auf die 16MHz eingeschossen und wo hin verschwinden die? Polling über Infrarot klingt nach totaler Systemdesign Katastrophe. Schau dir am besten erstmal an wie die reale Bahn ihre Leittechnik macht. Wenn du da eine ähnliche Trennung Stellwerk - Leittechnik einziehst, ist es am Ende egal ob dein Bedienpult per USB oder WLAN da dran hängt. Ich persönlich würde entweder CAN Bus zu jedem Aktor legen, oder Ethernet zu größeren Knoten die dann eine Handvoll Aktoren bedienen. Ethernet hätte den Vorteil, dass man die ganze Anlage "by Design" entweder per Bedienpult oder per App/Laptop und WLAN steuern kann, ohne dass die einzelnen Knoten davon irgendwas mitbekommen
warum schrieb: > Ja, Funk ist nicht die Lösung für dein Problem. Ist es wirklich nicht, aber... > Weil es einfach viel zu > komplex ist. ...nicht deshalb. Das Problem bei Funk ist: das ist ein shared medium. Man kann hier keine Latenzen garantieren. Jeder Arsch im selben Band kann die schöne theoretische Betrachtung zum Einsturz bringen. Jeder WLAN-Nutzer in der Großstadt kennt dieses Problem mittlerweile. Selbst wenn es im Durchschnitt für einen Netflix-Stream reicht (was oft nicht mal mehr der Fall ist), kommt es immer mal wieder "Hängern" bis in den Sekundenbereich (wenn ein Reconnect nötig wird). Wer Funk kennt, nimmt Draht, wann immer möglich. So einfach ist das.
Rainer V. schrieb: > Ich dachte, > wenn ich über WLan auch nur 50 Sender auswerten muß, um eine Aktion zu > bestätigen (z.B. Signal.XY auf rot) dann dauert das. Meine Alternative > ist jetzt halt per IR pollen und die INfo kriegen. WLAN ist alleine schon vom physikalischen Prinzip her schneller als IR durch die viel kürzeren Wellenlängen. Du machst sehr viele Annahmen ("dauert das", "16MHz sind oft weg, wie nix!!"), die alle falsch sind. wendelsberg schrieb: > Und gerade das laesst sich gern mal einige Zeitm bevor irgendwas > losgeht. Hast du eine USB-Maus?
Hallo Rainer V. - du hast ja schon die "Elite" des Forums und den "mitfühlenden" Umgangston der hier leider viel zu oft herrscht mitbekommen: Daher, wenn auch im "harten und umfassenden" Technikbereich sich dort nur wenige Leute mit wirklich tief gehenden E-Technikwissen herumtreiben, aber es gibt einige und vor allem sind dort "alle" und insbesondere die "richtigen" E-Techniker freundlich: https://www.stummiforum.de/ und besonders dort https://www.stummiforum.de/viewforum.php?f=21&sid=3d1f28ef1854025ceb12fe5ad66679c4 weniger da es mehr um die Nutzung von fertigen Produkten geht und nur ganz wenig wirklich tiefgreifendes wissen bezüglich Datenfunknetzen haben- aber sicherlich auch immer noch besser als was hier so menschlich (fachlich stimmt es hier schon - nur "musst" du vorher dich natürlich in die gleiche Liga hoch studiert haben - sonst bist du es nicht wert unterstützt zu werden...) abgeht. https://www.stummiforum.de/viewforum.php?f=7&sid=3d1f28ef1854025ceb12fe5ad66679c4 Tja "ihr" könnt stolz auf eure Leistung sein - eine echte Bereicherung für das Forum - bleibt schön unter euch, bildet eure Nerdgruppen sucht euch eurer Speichel lecker... Mensch
Mensch schrieb: > Rainer V. - du hast ja schon die "Elite" des Forums und den > "mitfühlenden" Umgangston der hier leider viel zu oft herrscht > mitbekommen: Da kann wohl einer mit Kritik nicht umgehen.
warum schrieb: > WLAN ist alleine schon vom physikalischen Prinzip her schneller als IR > durch die viel kürzeren Wellenlängen. Schlimmer geht es nimmer - du willst uns doch verar...en?! Oder meinst du das wirklich ernst?
Mensch schrieb: > Schlimmer geht es nimmer - du willst uns doch verar...en?! Oder meinst > du das wirklich ernst? ja. Datendurchsatz korreliert direkt mit der Frequenz (und Parallelität (MIMO)).
Guest schrieb: > Ich mein du kannst 4K Netflix damit streamen und hast vielleicht 20ms > Ping (intern eher weniger) Und wenns dumm läuft, dauert der Ping auch mal 2 Sekunden. Dann nämlich wenn man die schöne Eisenbahn den Kumpels oder der angeheirateten Verwandtschaft zeigen will und alle ein Handy in der Hosentasche haben. warum schrieb: > WLAN ist alleine schon vom physikalischen Prinzip her schneller als IR > durch die viel kürzeren Wellenlängen. Ja, das hört sich schlüssig an. Ist aber natürlich trotzdem Käse. Denn IR hat die kürzere Wellenlänge... ? c-hater schrieb: > Wer Funk kennt, nimmt Draht, wann immer möglich. So einfach ist das. Das stimmt allerdings.
warum schrieb: > WLAN ist alleine schon vom physikalischen Prinzip her schneller als IR > durch die viel kürzeren Wellenlängen. OMG Von Physik hast du wohl echt keine Ahnung. WLAN sind 2,4 bzw. 5GHz, das entspricht einer Wellenlänge im Bereich von Zentimetern. IR fängt (bei großzügiger Auslegung) so ca. bei einem Millimeter Wellenlänge an. Das was normalerweise mit IR gemeint ist, hat aber nur so 10..1 µm Wellenlänge. Bitte lies' vor weiteren peinlichen Äußerungen unbedingt: https://de.wikipedia.org/wiki/Elektromagnetische_Strahlung
c-hater schrieb: > Von Physik hast du wohl echt keine Ahnung. > > WLAN sind 2,4 bzw. 5GHz, das entspricht einer Wellenlänge im Bereich von > Zentimetern. IR fängt (bei großzügiger Auslegung) so ca. bei einem > Millimeter Wellenlänge an. Das was normalerweise mit IR gemeint ist, hat > aber nur so 10..1 µm Wellenlänge. Das Nutzsignal wird bei IR nicht direkt auf die Frequenz des Lichtes moduliert.
warum schrieb: > Das Nutzsignal wird bei IR nicht direkt auf die Frequenz des Lichtes > moduliert. Das ist wahr. Vielleicht benutzt du dieses Wissen zukünftig für korrekte Formulierungen? Und wenn du schonmal dabei bist, kannst du auch gleich darüber nachdenken, mit welcher Frequenz man IR modulieren könnte. Zumindest rein theoretisch... Du brauchst das aber nicht in diesem Thread auszubreiten. Das sind Spiele, bei denen der TO sowieso nicht mitspielen könnte...
Mega Thread hier ? @TO Am einfachsten und sichersten wird im Endeffekt wohl eine Lösung per Draht (BUS) sein. Deine Sorgen gehen jedenfalls in die falsche Richtung. WLAN IR Bluetooth oder was auch immer. Für ein paar hundert Teilnehmer die nicht alle immer auf die ms exakt sein müssen kannst du da prinzipiell nehmen was du willst. Funk ist eben einfach prinzipiell komplizierter.
warum schrieb: > WLAN ist alleine schon vom physikalischen Prinzip her schneller als IR > durch die viel kürzeren Wellenlängen. Beides sind elektromagnetische Wellen, die eine mit 2.4GHz bzw. 5.5GHz, die andere mit 360THz. Wer hat da jetzt die kürzere Wellenlänge? Das Thema ist nicht die Wellenlänge, sondern das Modulationsverfahren. Bei den billigen IR-Fernbedienungen macht dir der 38/56kHz Unterträger die Übertragungsgeschwindigkeit kaputt.
warum schrieb: > Das Nutzsignal wird bei IR nicht direkt auf die Frequenz des Lichtes > moduliert. Für Low-Speed Anwendungen. Wenn man höhere Geschwindigkeiten haben will, dann moduliert man das Licht natürlich direkt mit dem (aufbereiteten) Signal. Oder was glaubst du, wie LWL-Transceiver in der Datentechnik funktionieren, die über IR Datenraten bis 100Gbps erreichen? Und über so etwas werden auch problemlos harte Echtzeitanwendungen gefahren, es gibt sogar Standards für die dazu benutzten Kommunikationsprotokolle ...
Ralf D. schrieb: > Wenn man höhere Geschwindigkeiten haben will, > dann moduliert man das Licht natürlich direkt mit dem (aufbereiteten) > Signal. Oder was glaubst du, wie LWL-Transceiver in der Datentechnik > funktionieren, die über IR Datenraten bis 100Gbps erreichen? Das meinte der Threadersteller bestimmt, wenn er IR sagte.
Rainer V. schrieb: > Ich dachte, > wenn ich über WLan auch nur 50 Sender auswerten muß, um eine Aktion zu > bestätigen (z.B. Signal.XY auf rot) dann dauert das. Meine Alternative > ist jetzt halt per IR pollen und die INfo kriegen. Ich denke nicht, dass diese Vorstellung zu den Fakten passt. Was WLAN hat ist einge gewisse Latenz, weil der Bus halt ziemlich high-level ist. Das bewegt sich aber im Bereich weniger Millisekunden. Was für deine Anwendung egal ist. In einer hundertstel Sekunde passiert da gar nichts. Was WLAN hingegen auch hat, ist eine nahezu unendliche Bandbreite, die du mit keinem anderen gängigen Funk-Protokoll, sei es IR oder sonstwas, auch nur näherungsweise erreichen wirst. Was aber auch egal ist, weil deine 100 Sensoren quasi 0 Bandbreite benötigen.
Die Übertragungsrate ist bei allen gängigen Schnittstellen nicht das Problem. Die Latenz ist viel spannender! Bei WLAN dauert die Übertragung eines Steuerbefehls typischerweise 1-9ms. Aber auch Zeiten von bis zu 200ms sind völlig normal, kommen jede Stunde mehrmals vor. Zeitweise fallen Funkverbindungen auf den freien Frequenzen aber auch komplett aus. Leute, die nicht in Hochhäusern leben, kennen das Problem vielleicht nicht. Aber bei mir zu Hause fallen WLAN und Bluetooth mehrmals am Tag für kurze Zeit (meist 1-5 Minuten) komplett aus. Deswegen wäre für mich klar, dass ich meine Modelleisenbahn (wenn ich sie noch hätte) nicht mit WLAN/Bluetooth ansteuern würde. Ich würde hier eher RS-485 verwenden, dann hat man zugleich Probleme mit Spannungsabfall an GND Leitungen umschifft. Bei chip45.com bekommst du Arduino kompatible Mikrocontroller-Module mit RS-485 Anschluss. Für die PC Seite gibt es entsprechende USB Adapter.
Rainer V. schrieb: > Es muß schnell gehen, wenn ein Ereignis erkannt wird! Die Züge mögen > natürlich dahin dümpeln (aus Sicht des Contollers) wenn aber der > "langsame" Zug sein Gleis erreicht/verlassen hat, dann braucht die > Zentrale diese Info "sofort"! Ich schreibe das bewußt in > Anführungszeichen, weil ich bisher nicht weiß, wie die Zeiten wirklich > sein werden. Bei 1:87 entsprechen 250 km/h etwa 80 cm pro Sekunde (wenn ich mich nicht verrechnet habe). Wenn du z.B. von 100ms (eine Ewigkeit also) vom Ereignis bis zur Verarbeitung der Meldung ausgehst, legt die Huschebahn 8cm zurück. Grüße M.
Stefan ⛄ F. schrieb: > Die Latenz ist viel spannender! Weitgehend vernachlässigbar in diesem Anwendungsfall, solange sie sich im 10er Millisekundenbereich befindet. > Bei WLAN dauert die Übertragung eines Steuerbefehls typischerweise > 1-9ms. Wo hast du die Zahl her? > Aber auch Zeiten von bis zu 200ms sind völlig normal, kommen jede > Stunde mehrmals vor. Nur, wenn das Medium völlig überlastet ist oder die Signalstärke nicht ausreicht. >Ich würde hier eher RS-485 verwenden, Ja, das wäre eine gute Möglichkeit.
warum schrieb: >> Bei WLAN dauert die Übertragung eines Steuerbefehls typischerweise >> 1-9ms. > Wo hast du die Zahl her? Eigene Erfahrung auf umfangreichen Messreihen. >> Aber auch Zeiten von bis zu 200ms sind völlig normal, kommen jede >> Stunde mehrmals vor. > Nur, wenn das Medium völlig überlastet ist oder die Signalstärke nicht > ausreicht. Ja. Ich habe immer mehr als 60 WLAN Netze in Reichweite, reicht das als Erklärung?
Stefan ⛄ F. schrieb: > Eigene Erfahrung auf umfangreichen Messreihen. aha. Also nix wirklich belastbares. Ja, einige Steuerbefehle laufen mit niedrigerer Geschwindigkeit, damit alle im Netz sie verstehen können. Insbesondere, wenn man antikes 802.11b im Netz unterstützt. Aber selbst dann laufen alle management frames sehr sehr viel schneller durch als deine Untergrenze von 1ms.
warum schrieb: > Nur, wenn das Medium völlig überlastet ist oder die Signalstärke nicht > ausreicht. Was meinst du wohl, was auf dem Medium los wäre, wenn 100 Gleisbesetztmelder alle einzeln per WLAN angekoppelt sind und der TO sie darüber im 10ms pollen wollte ;-)
Wolfgang schrieb: > Was meinst du wohl, was auf dem Medium los wäre, wenn 100 > Gleisbesetztmelder alle einzeln per WLAN angekoppelt sind und der TO sie > darüber im 10ms pollen wollte ;-) Nicht viel, wenn die nur passiv auf Befehle warten. Aber ja. Ich stimme ja zu, dass WLAN für diese Anwendung völlig ungeeignet ist.
warum schrieb: >> Eigene Erfahrung auf umfangreichen Messreihen. > Also nix wirklich belastbares. Kannst ja mal zu Besuch kommen, dann führe ich es dir vor. Für mich ist diese Erkenntnis bereits 100% belastet, denn ich habe damit täglich zu tun. > Ja, einige Steuerbefehle laufen mit niedrigerer Geschwindigkeit, damit > alle im Netz sie verstehen können. Ich rede nicht von WLAN internen Kram sondern von Paketen via TCP oder UDP, womit er seine Sensoren und Aktuatoren steuert.
Stefan ⛄ F. schrieb: > Ich rede nicht von WLAN internen Kram sondern von Paketen via TCP oder > UDP, womit er seine Sensoren und Aktuatoren steuert. Also keine Steuerbefehle, sondern Nutzdaten. Ja. Da kann es durch diverse Effekte zu Latenzspitzen im Millisekundenbereich kommen.
warum schrieb: > Also keine Steuerbefehle, sondern Nutzdaten. Du bist echt ein Erbsenzähler. Der TO will seine Modelleisenbahn steuern, also überträgt er Steuer-Befehle. Mein Chef überträgt seine Steuerbefehle per Email.
Stefan ⛄ F. schrieb: > Du bist echt ein Erbsenzähler. Nein. Du hast dich ungenau ausgedrückt. Genau wie ich weiter oben bei dem IR-Thema. Das führt halt zu Missverständnissen.
Lange Rede kurzer Sinn, WLAN ist als Technologie für dein Vorhaben eher nicht geeignet, aber nicht weil die Latenz hoch oder die Bandbreite zu klein wäre, sondern weil es nicht darauf ausgelegt ist, winzige Datenmengen von hunderten Teilnehmern zu übertragen. Das Funkprotokoll, das du suchst, braucht aber weder weniger Latenz noch mehr Bandbreite als WLAN, im Gegenteil, wenn es ein Tausendstel der Bandbreite und die zehnfache Latenz hat, ist das völlig ok. Ich würde mal abschätzen, wie das für deinen Fall z.B. mit den gut verfügbaren nRF24L-Modulen aussieht. Muss aber zugeben, dass ich nicht so den Überblick über den Funkprotokoll-Markt habe. Soviel aber kann ich dir sagen: fang am ganz untersten Ende an. Deine Anwendung ist sehr anspruchslos, außer dass sie viele Teilnehmer unterstützen muss.
Rainer V. schrieb: > Die Züge mögen > natürlich dahin dümpeln (aus Sicht des Contollers) wenn aber der > "langsame" Zug sein Gleis erreicht/verlassen hat, dann braucht die > Zentrale diese Info "sofort"! Nein, braucht sie nicht. Denn solange ein Block belegt ist, darf kein anderer Zug einfahren. Wenn ein Rot-Signal überfahren wird, muss das anders gelöst werden. Soforthalt auf dem Streckenabschnitt.
Hallo Rainer, so ein ähnliches Ziel wie du hatte ich mir auch einmal gesteckt. Nach einiger Recherche und Überlegungen bin ich jedoch zu dem Schluss gekommen, dass ich mich sehr verzettelt hätte, ein komplettes Steuersystem für eine Modellbahn von null an zu entwickeln. Daher möchte ich dir als Tipp den Weg erläutern, den ich bei meiner künftigen Modellbahn gehen werde. Und zwar bekannte offene Standards zu benutzen: - Für die Übertragung der Befehle an Loks gibt es das DCC Protokoll, dessen Spezifikation du u.a. hier https://www.nmra.org/index-nmra-standards-and-recommended-practices unter Punkt 9.2 und Punkt 9.3 findest - Für die Vernetzung zwischen Zentrale, Rückmeldemodule usw. werde ich den BiDiB verwenden, dessen Spezifikation hier http://bidib.org/index.html und hier https://www.opendcc.de/ zu finden ist Der Vorteil ist, dass ich auf bewährte Technik zurückgreife. Bei Bedarf kann ich mir aber einzelne Komponenten selber entwicklen. Ich bleibe aber kompatibel zu existierenden Standards. Daraus ergibt sich, dass ich weniger Overhead in Basisentwicklung stecken muss und mehr Zeit für die eigentliche Modellbahn habe. Gruß Alexander
Hallo Rainer, ich würde auch Leitungen zur Datenübertragung einsetzen. Wer Funk kennt nimmt Kabel! Wenn es denn unbedingt schnell, zukunftssicher und Funk sein soll würde ich auf Industrial 5G setzen. SCNR Selbsternannter Weltverbesserer
Markus M. schrieb: >> Lieber Freund, wenn du mit dem guten alten Draht ein komplexes System >> vernetzen willst, dann wirds einfach kompliziert! Unnötig kompliziert... > > Aber Du musst doch sowieso Strom überall hinführen. Wo ist denn da das > Problem 1 (oder 2) weitere Adern für Daten mitzuziehen? Was man nicht mal braucht. Wenn man das passend aufbaut, kann man auch gleich die Stromleitung für die Datenübertragung mit benutzen. Und zu den üblichen Verdächtigen (Loks, Signale und Weichen) laufen sowieso schon die Schienen hin. Man kann sowohl die Versorgung, als auch sämtliche Daten direkt da drüber schicken. Dann braucht man gar keine zusätzliche Verdrahtung und auch keinen WLAN oder Infrarot oder Lichtwellenleiter. Für Komponenten, die nicht sowieso schon mit den Schienen verbunden sind, muss man dann eben einen Abgriff an geeigneter Stelle machen und Leitungen dorthin ziehen. So wäre zumindest mein Ansatz für sowas. Minimaler Verdrahtungsaufwand, und ich muss auch nicht 100 WLAN-Module in der Anlage verstreuen. Und ich muss mir auch nicht bei jeder Komponente Gedanken machen, wie ich den IR-Empfänger anbringe, damit der auch immer und aus jeder Richtung die Signale sauber empfängt und die Lok auch im Tunnel drauf reagieren kann. Rainer V. schrieb: > c-hater schrieb: >> Was, bitteschön, muß bei einer Modelleisenbahn wirklich schnell gehen? > > Es muß schnell gehen, wenn ein Ereignis erkannt wird! Was heißt "schnell"? Und wie hast du ermittelt, dass WLAN dafür nicht reicht? Um solche Anforderungen bewerten zu können, muss man sie mit Zahlen hinterlegen. Also überlege dir: Wie schnell fährt dein Zug? Wie lang ist die Roundtrip-Time der Verbindung? Damit ergibt sich, wie weit der Zug in dieser Zeit überhaupt kommt. Meine Vermutung: Wenige Millimeter. > Die Züge mögen natürlich dahin dümpeln (aus Sicht des Contollers) wenn aber > der "langsame" Zug sein Gleis erreicht/verlassen hat, dann braucht die > Zentrale diese Info "sofort"! Auch hier gilt wieder: "sofort!" ist keine messbare Größe. Sofort geht nicht, also muss man immer mit einer gewissen Latenz leben. Auch deine Zentrale kann die Informationen nicht beliebig schnell verarbeiten, braucht also Zeit. Daher: Quantifiziere die erforderlichen Reaktionszeiten. Dann, und nur dann kannst du eine Aussage darüber treffen, ob eine bestimmte Technologie dafür geeignet ist oder nicht. > Ich gebe zu, dass ich nicht weiß, wie die Profisysteme da was machen, aber > darüber kriegt man natürlich auch keine Infos! Auch die machen sich Gedanken über die erforderlichen Reaktionszeiten und bauen ihr System darauf basierend auf. Sie sagen nicht einfach, es muss "schnell" gehen, und da wir mal gehört haben, X sei nicht "schnell", nehmen wir es gar nicht erst in die Auswahl mit auf. Rainer V. schrieb: > Hi, habe dich jetzt nur aus der überraschenden Menge der Antworten > herausgenommen. Strom und damit Info ist überall, wo eine Schiene > liegt...ist bei Modellbahn so... Eben, genau das wäre für mich der zentrale Ansatzpunkt. > man möchte aber auch mit sogenannten "Handheld-Geräten" arbeiten. Das sind > (im besten Fall "stand-alone" Geräte) mit denen man irgendetwas auf der > Anlage manuell und "sofort" steuern kann!! Kannst du ja machen. Dazu muss dieses Handheld-Gerät aber nicht mit jedem Signal einzeln direkt kommunizieren, sondern nur mit der Zentrale, die dann das Signal ansteuert. Und nein, das führt nicht dazu, dass es nicht "schnell" ist. Es ist sowieso viel besser, wenn eine Zentrale alles verwaltet, als wenn alle munter kreuz und quer direkt miteinander reden und es keine Instanz im System gibt, die darüber noch den Überblick hat. warum schrieb: > Rainer V. schrieb: >> dass auch bei 16MHz >> manchmal kaum Luft bleibt! > > So ein Unsinn Allerdings. Selbst wenn man in der Reaktion hochkomplexe Dinge berechnet und sich dafür 16.000 Taktzyklen Zeit lässt, dauert es gerade mal eine Millisekunde. In der Zeit ist die Lok vermutlich weniger als einen Millimeter weit gekommen, denn mehr als 1 m/s wird sie wohl eher nicht fahren. Rainer V. schrieb: > Sorry, wenn ich mich als totalen Depp outen muß, aber ich habe keine > Vorstellung von Netflix...aber du kannst dir vielleicht vorstellen, dass > auf meiner angedachten Anlage ca. 100 Melder/Aktoren mit Rückmeldung > miteinander reden müssen. Ok. Das, was von Netflix kommt, entspricht von der Datenmenge her etlichen Millionen von Melder-Ereignissen pro Sekunde. Allerdings halt aus einer einzelnen Quelle, nicht aus 100 Stück parallel. Und WLAN ist eher auf Durchsatz ausgelegt als auf kurze Reaktionszeiten und viele kleine Datenpakete. > Ich rede nicht nur von einer Zentrale, die mit einem Steuer-PC verbunden > ist. Das natürlich gerne per High-Speed-Usb. Da reicht USB1 low-speed auch locker aus. Das sind schon 1,5 MBit/s. Um das auszureizen, muss deine Anlage schon ziemlich groß sein. Die 480 MBit/s von High-Speed-USB kriegst du nur ausgereizt, wenn deine Loks nebenher noch ein Live-Video mitschicken. Das ist das Problem: Du rechnest nicht mit Zahlen, sondern siehst nur Begriffe, und da es "schnell" sein muss, muss es "high-speed" sein. wendelsberg schrieb: > Rainer V. schrieb: >> gerne per High-Speed-Usb > > Und gerade das laesst sich gern mal einige Zeitm bevor irgendwas > losgeht. Wobei "einige Zeit" hier immer noch viel geringer ist als das, was für die Bahn irgendwie relevant wäre. Andre schrieb: > Wieso hast du dich so auf die 16MHz eingeschossen und wo hin > verschwinden die? Naja, wenn er da im Hintergrund noch nen IP-Stack für sein WLAN betreibt, sind die natürlich schnell weg. warum schrieb: > Du machst sehr viele Annahmen ("dauert das", "16MHz sind oft weg, wie > nix!!"), die alle falsch sind. Ja, das ist das Problem. Außer den 16 MHz und den 100 Meldern und Aktoren habe ich bisher keine einzige konkrete Zahl gesehen. Die sind aber - ich kann es nur nochmal wiederholen - absolute Grundvoraussetzung für die Auswahl einer geeigneten Architektur. warum schrieb: >> Aber auch Zeiten von bis zu 200ms sind völlig normal, kommen jede >> Stunde mehrmals vor. > > Nur, wenn das Medium völlig überlastet ist oder die Signalstärke nicht > ausreicht. Also der Normalfall in halbwegs dicht besiedelten Wohngebieten.
:
Bearbeitet durch User
Hallo und danke für die rege Beteiligung! Ich nehme jetzt für mich mit, dass ich Funknetz "vergesse". Auch die Anbindung von Handsteuergeräten werde ich erst mal per Kabel machen. Und den Ansatz, die Schiene zu nutzen, da sie ja sowieso schon da ist, werde ich also erst mal grundsätzlich zur Basis machen. Wenn's irgendwo nicht reichen sollte, kann ich immer noch Draht ziehen... DCC und Drumherum habe ich schon auf dem Schirm...auch Stummis Forum...dauert halt seine Zeit, bis man sowohl die richtigen Fragen als auch die richtigen Antworten sortiert hat. Gruß Rainer
Also IR ist mit Sicherheit die schlimmste aller Lösungen. Ich arbeite gerade an einen Projekt wo ich IR-Fernbedienungen auslese, damit ich die Daten hinterher senden kann. Das mache ich mit ein Arduino. In ca. 5-10 % aller Fälle kommen da "komische" Daten an. Drücke ich die Taste der Fernbedienung nochmal sind die Daten O.K. Was ich damit sagen will ist, du brauchst ein sehr großes Sicherheitsprotokoll und Rückkanal. Dafür ist IR einfach gesagt Mist. Es gibt in meinen Augen nur 2 Möglichkeiten. 1.) Man nimmt das System der Hersteller. DCC z.B. Ich habe ein Buch von Arnold hier wo das System bis auf das letzte Bit dokumentiert ist. Das ganze über Kabel. Man kann es sogar mischen, und über einen PC steuern. Hab ich schon vor ca. 15 Jahren in Köln auf der Messe gesehen. Ich würde da keine großen Experimente machen. Allerdings um Kosten zu sparen, ein Teil des Systems selbst bauen. Ein paar Platinchen mit einen Chip drauf löten ist Arbeit aber spart ca. 60 % der Kosten. Die Schaltpläne für z.b. den S-88 findest du doch im Netz. Gruß Pucki
Der aktuell günstigste Einstieg dürfte wohl eine bei Ebay gekaufte "Paket"-Z21 (weiß) mit zusätzlich gekauftem WLAN-Code sein. Dann kannst Du über die Z21-Apps Deine digitale Bahn steuern. Rückmelder werden z.B. bei Märklin mit CAN gemacht, sonst ist es meist der S88-Bus, erfunden von Märklin. Es gibt auch Railcom für Lok-Rückmeldungen. Dafür gibt es genügend Literatur und Beispiele im Netz. Nur beispielhaft, keine Empfehlung und bei weitem nicht erschöpfend: https://www.opendcc.de/ https://www.bidib.org/ https://www.fichtelbahn.de/ https://tams-online.de/Produkte/s88 https://www.bmbtechnik.de/s88-decoder/ ... und natürlich stummi. :-) "Paket" meint, dass viele die Einsteigerpakete von ROCO oder Pico aufkaufen und dann die Einzelteile einzeln weiterverkaufen. Hab ich auch schon gemacht, um günstig an bestimmte Loks bzw. Waggons zu kommen.
Hier noch ein Link den ich "mal eben" gefunden habe. http://www.7fun.de/jofri/Eisenbahn/S88/ Mit Idee und Schaltplan im sub-Links. RJ-45 Kabel wird übrigens im Modelleisenbahnbau gerne eingesetzt weil es viele Vorteile hat(Abgeschirmt, Rutscht wegen der Nase nicht raus, etc) . Allerdings nur sehr selten als Netzwerk selbst. Gruß Pucki
Alexander K. schrieb: > Also IR ist mit Sicherheit die schlimmste aller Lösungen. Das ist so allgemein formuliert großer Quatsch. IR wird im Modellbahnbereich durchaus häufig verwendet, z.B. Pico hatte damit eine digitale Steuerung und auch CAR-Systeme nutzen IR. IR != Fernbedienung
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.