Hallo User,
plage mich weiter mit dem Thema Railcom obwohl ich dieses Thema erst einmal beiseite schieben wollte.
Hardware DCC Fahrsignale von der FCC über drei Booster (D&H), alle Rückmelder von Fichtelbahn GBM16TS.
Alle Loks von der Moba genommen und um nach Testung und erneutem Einfahren der Loks diese wieder aufzugleisen. Habe dabei trotz aller eingetretenen Stabilität hinsichtlich der Railcom-Infos folgendes beobachtet: Lok fährt per Fahrstrasse vom Startpunkt zum Zielpunkt über mehrere Faz und keiner Kehrschleife, alles Korrekt, erst bei der zweiten Fahrt passiert am Ziel folgendes: bei Ankunft Richtungswechsel im FAZ, obwohl bei Ankunft am Ziel Fahrtrichtung korrekt angezeigt wird, und erst mit Halt die Fahrtrichtung wechselt.
Bei allem was ich inzwischen zum Thema Railcom gelernt habe, so finde ich hier keinen Erklärungsansatz. Kann mir hier im Forum jemand auf die "Spur" helfen?
Vorab Dank vom Niederrhein, Achim
Hallo Achim, ist bei mir auch so! Habe Railcom abgeschaltet und nun bleibt die Fahrtrichtung so wie es soll! Kann am Booster liegen oder am Lokdecoder. Grüße Ingo
Hallo Achim,
Entweder ist für den Zielanschnitt die Richtungsanzeige bei Fahrzeugerkennung via Railcom verkehrt herum konfiguriert oder grundsätzlich für die Lok halt. Muss du experimentell ggf im Vergleich mit weiteren Fahrzeugen ermitteln
Grüße
Markus
Hallo Ingo,
Hallo Markus,
ja Ingo war auch mein kürzlicher Gedanke, jedoch wollte und will ich noch nicht einsehen das Railcom bei mir nicht funktionieren will. Gebe noch nicht auf, am Ende kann es auf das Abschalten hinauslaufen.
Das beschriebene Zielfaz kann seit Jahren nur in einer Richtung ausgefahren werden, denn dahinter lauert schon der nächste Erzzug. Die derzeitigen decoder der Firmen D&H, ESU und Zimo sind vor dem erneuten Aufgleisen der leergefahrenen Moba mit neuer Firmware aktualisiert worden.
Auch habe ich bei drei wieder in Betrieb genommenen Lok folgendes beobachtet: beim hochfahren von Windigipet werden drei Loks zwar auf den Faz gemeldet jedoch wird das Feld nicht mit der entsprechenden Lok ausgefüllt. Erst nach dembetätigen einer Funktion der entsprechenden Lok wird diese dann korrekt mittels Railcomsignal angezeigt !?
Auch die Signalauswertung unter dem Punkt Überwachung in Windigipet gibt keine Hinweise, hier liegt beinah alles im grünen Bereich, eine Zone zeigt nur mildes Grün.
Ich weiss das hier kein speziefisches Problem vorliegt, dachte das die User möglicherweise ähnliche Erfahrungen mit Railcom haben u. am Ende dann Railcom einzustampfen. Selbst das , Ingo wäre am Ende auch eine Lösung.
Guten Abend, achim
Hallo Achim
Zitat von: achim schuetzendorf in 24. April 2025, 20:40:56beim hochfahren von Windigipet werden drei Loks zwar auf den Faz gemeldet jedoch wird das Feld nicht mit der entsprechenden Lok ausgefüllt.
welche Decoder haben diese Loks eingebaut?
MfG
vik
Hallo Vik,
kann ich jetzt nicht mehr nachvollziehen ausser das die grössten Ärgenisse bereiten bei mir die aktuellen MS Zimos trotz aktuellster Firmware.
grüsse, Achim
Zitat von: achim schuetzendorf in 24. April 2025, 20:40:56Ich weiss das hier kein speziefisches Problem vorliegt, dachte das die User möglicherweise ähnliche Erfahrungen mit Railcom haben u. am Ende dann Railcom einzustampfen. Selbst das , Ingo wäre am Ende auch eine Lösung.
Guten Abend, achim
Ich kann mich damit gut identifizieren.
Railcom ist für mich nur noch für POM geeignet.
Für den Rest ist es ausgeschaltet.
Ich verwende nur Zimo-Decoder, daher dachte ich zunächst an ein isoliertes Problem.
Aber es ist viel umfassender, als ich dachte.
Auch Esu- und Imperium-Decoder weisen ähnliche Probleme auf.
Bei Spurweite 0 und größer ist die Störungswahrscheinlichkeit deutlich höher.
Dies liegt an der Signalübertragung und dem Datenempfang eines lokalen Railcom-Empfängers.
Das ist im Datenprotokoll von Windigipet sehr gut zu sehen.
Die Stromerkennung eines Standorts ist ausgeschaltet, es gibt jedoch eine Railcom-Meldung an diesem Standort. Ist es Teil der Strecke, stoppt alles.
DCC arbeitet im Hochfrequenzbereich von durchschnittlich 6,8 kHz.
Auf einem Digiscoop mit einem DCC-Datenanalysator kann ein vollständiger DCC-Befehlssatz von einem parallel liegenden Messingstab in 7 cm Entfernung von einem an ein DCC-System angeschlossenen Schienenstück (40 cm) gelesen werden.
Da es sich hier um HF handelt, ist dies technisch nicht mehr zu lösen.
Feldstärkemessungen zeigen, dass die Übertragung bis zu 40 cm von der Quelle entfernt messbar ist.
Vermutlich ist dies der Grund, warum RFID-Techniken in Großbritannien wieder aus der Versenkung geholt werden.
Dabei liegt der Tag zwischen den Schienen und die Leseeinheit befindet sich in der fahrenden Lok neben dem DCC-Decoder.
Der fahrende RFID-Sender kommuniziert entweder über Bluetooth oder WLAN mit der Schnittstelle.
Problem gelöst. Railcom ist ebenfalls noch verfügbar, jedoch nur für POM.
Kind regards
Rupert
Hallo Foristen,
Bin mit meinen zuvorgenannten Problemen etwas weiter nachdem ich die Hardware komplett auf Readybooster und GBM, also mit reinen Fichtelbahn Bausteinen, umgerüstet habe. Die "alte" Selektrix Hardware ist zunächst beiseite geräumt und ich habe bessere und sinnvollere Ergebnisse erhalten.
Nun habe ich aber ein Phänomen das ich nicht genau zuordnen kann: Im Lokcontroll gibt es links neben dem Windigipet-Quadrat ein i im Kreis das bei Railcomverbindung aktiv ist.
Jetzt ist es so das bei Mobastart alle ! Loks ohne aktivem Symbol starten, erst mit dem programmieren z.B. mit CV29, ist das Symbol wieder aktiv, auch während der ganzen Mobasitzung.
Die Frage die sich mir stellt, was zeigt das Symbol an und woraum wird hier von seiten der Elektronik, bzw. des Windigipet Programmes reagiert. ?.
Dumme Frage? keine Ahnung...................
Grüsse vom Niederrhein, Achim
Hallo Achim,
das "i"-Symbol enthält Informationen zum Fahrzeug, wenn es aktiv ist. Das muß nichts mit Railcom zu tun haben. Bewege die Maus auf das "i" und im Tooltip werden die Infos angezeigt.
Hallo Sven,
Okay, komme nur deswegen auf Railcom, wenn aktives "i", wird diverses wie Spannung, Geschwindigkeit etc angezeigt und ich hatte dies Infos Railcom zugeordnet.
Aber warum ist das "i" nicht schon beim Start der Moba aktiv? Also sobald das Gesamtsystem Windigipet und die kompletten Hardware hochgefahren ist?
Grüsse,Achim
Hallo Achim,
Weil die Decoder diese Infos per Railcom nur von Zeit zu Zeit übertragen und solange die nichts gesendet haben, gibt es da noch keine Infos.
Grüße
Markus
Hallo Markus,
danke für die Erläuterung. Habe anhand Deiner Erklärung in einem anderen Forumsbeitrag ein Macro und per Stellwerkfunktion alle Loks beim Start von Windigipet einmal alke Spitzenlichter aus- und einschalten lassen. Problem gelöst.
Danke und ein schönes Wochende, Achim
Hallo Markus,
Zitat von: Markus Herzog in 04. Juni 2025, 22:09:52Weil die Decoder diese Infos per Railcom nur von Zeit zu Zeit übertragen und solange die nichts gesendet haben, gibt es da noch keine Infos.
ist das Detektieren der Aufgleisrichtung (vorausgesetzt das Fahrzeug mit dem Railcom Decoder ist korrekt nach Norm verdrahtet) nicht eine Funktion des lokalen Detektors (unter Berücksichtigung der aktuellen DCC-Polarisierung im Rückmeldeabschnitt)? Wenn Kanal 1 permanent eingeschaltet ist, erhält der Detektor sehr engmaschig die Adresse und stellt die Information auch laufend zur Verfügung. Spannend ist das allerdings, wenn sich der Railcom-Detektor in einen Kehrschleifenabschnitt befindet und dort die Polarisierung umgeschaltet werden muss. Falls das Programm die Kehrschleifenumschaltung nicht zeitnah mitbekommt, werden die Daten dort falsch interpretiert und kollidieren mit den im Programm gespeicherten Informationen.
Wie können (auch im Automatikbetrieb) die Daten synchronisiert werden, bzw. wie sollte man vorgehen um die unterschiedliche Informationslage aufzulösen (ohne explizit manuell einzugreifen)?
MfG
vik
Hallo vikr,
in der Userfrage auf die sich mein Zitat bezog, ging es nicht um die Aufgleisrichtung, sondern um Dinge die QoS-Meldung und weitere Meldungen, die der Dekoder von Zeit zu Zeit absondert. Also Kanal 2 Daten.
Mit Glück gelingt es wie Achim schon schrieb über Licht aus/an den Dekoder dazu zu bringen die Infos nochmal zu senden. Ich habe aber auch schon Dekoder gesehen, die solange keine Wertänderung eintrat zig Minuten brauchten ehe sie sich (wenn überhaupt) nochmal geäußert haben.
Zu der Thematik Kehrschleife und Aufgleisrichtung: WDP hat hier keinerlei Verfahren implementiert für "Oh da ist eine Kehrschleife" umgeschaltet und interpretiere die gemeldete Aufgleisrichtung umgekehrt. Zumal wie schon von dir korrekt bemerkt man jetzt auch noch wissen müsste bei jeder Richtungsmeldung "War schon umgeschaltet oder nicht". Hier wäre mein Erwartungshaltung an die Hardware-Hersteller, dass man dem Kunden ein Kehrschleifenmodul anbietet mit Railcom-Detektor, der egal wie rum die Kehrschleife "steht" das korrekt an den PC oder andere Mithörer meldet. Meiner Meinung nach ist das in Hardware zu lösen, denn selbst wenn das ein PC kann... Sollen das dann lokale Railcom-Displays oder Handregler auch alle auflösen können?
Und ehe die Frage kommt: Keine Ahnung ob es so eine Hardware schon gibt, damit habe ich mich noch nie befasst.
Beim schnellen Googeln habe ich Hinweise gefunden nach dem Motto: "Schalte einen Einzel-Railcom-Detektor zwischen Kehrschleifenausgang und Gleis", klingt auch noch einer Idee, ohne das jetzt komplett durchdacht zu haben...
Grüße
Markus
Hallo Rupert,
Zitat von: Rupert van Swol in 02. Mai 2025, 08:34:48Railcom ist für mich nur noch für POM geeignet.
Für den Rest ist es ausgeschaltet.
Ich verwende nur Zimo-Decoder, daher dachte ich zunächst an ein isoliertes Problem.
Aber es ist viel umfassender, als ich dachte.
Auch Esu- und Imperium-Decoder weisen ähnliche Probleme auf.
...
Problem gelöst. Railcom ist ebenfalls noch verfügbar, jedoch nur für POM.
Kind regards
Rupert
vor gerade mal zwei Jahren warst Du sehr enthusiastisch vom Gegenteil überzeugt...
Zitat von: Rupert van Swol in 25. Mai 2023, 09:45:15Ich habe mich 2022 von der Lenz Spur 0 und dem System verabschiedet, da ich nach 40 Jahren bereit für etwas anderes war.
Ich bin dann bei Lokstore digital gelandet, von denen ich alles habe.
Spur-0-Lokomotiven aus Großbritannien sind defacto mit Zimo ausgestattet.
Warum Zimo und nicht Lenz
ZIMO Decoder aller Typen (sowie Digitalzentralen und Gleis-Rückmelder als Empfangsgeräte) waren schon seit den 1990er Jahren (lange vor RailCom) mit einer proprietären Form der ,,bi-directional communication" ausgestattet - der ,,ZIMO Zugnummernerkennung". Dies war damals ein wesentlicher Unterschied zu Produkten des Mitbewerbs.
In Anlagen mit den bis 2010 gebauten MX9 Gleisabschnitts-Modulen wird weiterhin die ZIMO Zugnummernerkennung verwendet, da MX9-Module NICHT mit ,,RailCom" arbeiten (die nachfolgenden ,,StEin"-Module hingegen schon).
Seit dem Jahr 2005 (kurz nach der Einführung durch die Fa. Lenz) sind alle ZIMO Decoder ausgestattet
für das in der Zwischenzeit genormte Rückmeldeprotokoll ,,RailCom" (RCN-217 bei RailCommunity -
VHDM - und S-9.3.2 bei NMRA).
RailCom ersetzt auch die oben erwähnte ZIMO Zugnummernkennung.
Die grundsätzliche Funktionsweise von RailCom beruht darauf, dass der ansonsten kontinuierliche Energie- und Datenstrom, also das DCC - Schienensignal, welches von der Digitalzentrale auf die Schiene gelegt wird, von kurzen potenzial-freien Lücken (die "RailCom-Cutouts", max. 500 microsec) unterbrochen wird; in diesen Lücken können die Decoder weitgehend ungestört Rückmelde-Informationen (als ,,RailCom-Nachrichten", insgesamt - beide Channels
zusammen - bis zu 48 bit lang) aussenden, welche von ,,lokalen Detektoren" (einzelnen isolierten Gleisabschnitten zugeordnet) oder vom globalen Detektor in der Digitalzentrale selbst empfangen und ausgewertet werden.
n ZIMO Decodern (mittlerweile auch in den meisten Fremdprodukten) sind die RailCom-Funktionen
standardmäßig eingeschaltet; wenn dies nicht der Fall sein sollte, werden sie aktiviert durch:
CV #29, Bit 3 = 1 UND CV #28 = 3 (oder = 67, wenn Großbahn-Decoder),
falls die Geschwindigkeits-Rückmeldung (Tacho) nicht funktionieren sollte: CV #158, Bit 2 = 1 oder ausnahmsweise (falls MX31ZL als Zentrale): = 0
In den ersten Jahren nach Einführung von RailCom wurde dessen Potenzial nur für zwei Möglichkeiten
intensiv genutzt: zur Adress-Meldung für isolierte Gleisabschnitte (das, was zuvor die ZIMO Zugnummernerkennung geleistet hat), sowie zum CV-Programmieren und -Lesen im Operational Mode (auch
,,Programming-on-the-Main" oder ,,PoM" genannt). Dies hat sich - etwa seit dem Jahr 2015 - geändert:
Kurz zusammengefasst können die RailCom-Aufgaben so gegliedert werden:
Durch sämtliche RailCom-Antworten (zunächst unabhängig vom Inhalt der Nachricht selbst) wird
der Empfang der jeweils vorangehenden DCC-Befehle bestätigt, was die Betriebssicherheit und
die Bandbreite der gesamten DCC-Steuerung erhöht. Letzteres ist der Fall, weil quittierte DCCBefehle nicht wiederholt werden müssen.
,,RailCom Channel 2" (der jeweils zweite - mit 36 Bit größere Teil - jeder RailComGesamtnachricht): Darüber werden, jeweils als Antwort auf einen DCC-Befehl an die eigene Decoder-Adresse, aktuelle Daten aus dem Fahrzeug zum globalen Detektor der Digitalzentrale gemeldet; dazu gehören beispielsweise (je nach Auslegung) die "echte" (gemessene) Geschwindigkeit,
Routing- und Positions-Codes, simulierte "Treibstoffvorräte", aktuelle Werte der CVs auf Anfrage
(CV-Programmieren und -Lesen im Operational Mode, PoM)
,,RailCom Channel 1" (der jeweils erste - kleinere Teil mit 12 Bit): Darüber wird (mit Ausnahmen,
z. B. in Anmeldeverfahren) ausschließlich die eigene Decoder-Adresse gemeldet, und zwar als
Antwort auf sämtliche DCC-Befehle (also vor allem auf diejenigen, die NICHT das eigene Fahrzeug
adressieren, daher bis zu 100 Mal/sec). Da somit alle Decoder gleichzeitig Channel 1-Daten aussenden, sind diese nur auf isolierten Gleisabschnitten durch lokale Detektoren lesbar, wenn sich
dort gerade nur ein einziges Fahrzeug mit RailCom-aktiviertem Decoder befindet.
Im globalen Detektor des Basisgerätes überlagern sich hingegen die gleichzeitigen Channel 1-Daten der verschiedenen Decoder und sind daher nicht lesbar, was aber sowieso keinen Sinn hätte, da die Adressen nur lokal
(auf den einzelnen isolierten Gleisabschnitten) von Interesse sind.
Die obige ,,Kurzbeschreibung" der RailCom-Technik bezieht sich nur auf die ,,normalen" Vorgänge; es gibt in der
Praxis (auch in den Normen selbst) zahlreiche Abweichungen und Ausnahmen in den Channel-Zuteilungen, u.a.
Weiterentwicklung der RailCom-Nutzung:
Da laufend neue RailCom-Anwendungen geschaffen und in Decodern und Digitalgeräten implementiert werden, wobei ZIMO häufig eine Vorreiter-Rolle einnimmt, können Betriebsanleitungen diesbezüglich nicht immer aktuell gehalten werden.
Daher gibt es hier nur eine kurze Auflistung von Anwendungen und ins Auge gefassten Anwendungen,
die entweder schon realisiert wurden (je nachdem, wann dieser Text gelesen wird), gerade in Arbeit
sind, oder vielleicht in näherer Zukunft realisiert werden (in ZIMO Decodern und Systemen):
Klassische Anwendungen
Diese werden von vielen modernen Digitalzentralen verwendet (Geschwindigkeitsanzeige noch selten).
- Adress-Meldung (zur Anzeige auf Ziffernanzeigen oder Computer-Stellwerk),
- CV-Programmieren und -Lesen, Geschwindigkeits-Meldung (zur Tacho-Anzeige am Bediengerät),.
Erweitere Meldungen aus den Fahrzeugen
Diese werden derzeit hauptsächlich von ZIMO Digitalzentralen und Bediengeräten ausgewertet.
Stand SW-Version 4.210:
- Richtungszustands-Meldung (zur Anzeige Vor-/Rückwärts sowie Ost-West-Richtung am Bediengerät
und automatische Steuerungseingriffe); gemäß RailCommunity-Norm: ID7, Sub-ID 27,
- ZIMO Aufgleissuche; gemäß RailCommunity-Norm: ID1, ID2, ID14 (nach Aufforderung auf Adresse 0),
- Quality-of-Service-Meldung, gemäß RailCommunity-Norm: ID7, Sub-ID 7,
- Gleisspannung am Ort des Decoders; gemäß RailCommunity-Norm: ID7, Sub-ID 46.
Geplant:
HLU&ABC-Meldungen (zur Anzeige am Bediengerät und automatische Steuerungseingriffe), Zielentfernung und Zielgeschwindigkeit (zur Anzeige auf ,,Echt"-Führerständen), zurückgelegte Wegstrecken,
Steigungen, Gefälle, Kurven (Decoder mit Sensoren), Höhendifferenzen, Drehwinkel, Streckenprofile,
aktuelle Position, Decoder-bezogene Daten (Motorstrom, Temperatur, ...).
Geplante betriebliche Anwendungen
Diese sind bis auf weiteres nur innerhalb von ZIMO Systemen verfügbar.
Übermittlung größerer Datenmengen aus den Fahrzeugen und Zügen, beispielsweise GUI (GraphicalUser-Interface) aus dem Fahrzeug zu den Bediengeräten), Streckenprofil oder Vorbild-Gewichte und -
Masse der Wagen eines Zuges, Textnachrichten aus dem Zug zur Anzeige am Bediengerät.
die Railcom-Kommunikation schien für Dich komplett beherrschbar zu sein...
Jede Technik hat ihre Grenzen, aber wenn man die kennt, kann man sie sehr gut nutzen.
MfG
vik
Hallo Markus,
Zitat von: Markus Herzog in 11. Juni 2025, 13:19:11Zu der Thematik Kehrschleife und Aufgleisrichtung: WDP hat hier keinerlei Verfahren implementiert für "Oh da ist eine Kehrschleife" umgeschaltet und interpretiere die gemeldete Aufgleisrichtung umgekehrt. Zumal wie schon von dir korrekt bemerkt man jetzt auch noch wissen müsste bei jeder Richtungsmeldung "War schon umgeschaltet oder nicht". Hier wäre mein Erwartungshaltung an die Hardware-Hersteller, dass man dem Kunden ein Kehrschleifenmodul anbietet mit Railcom-Detektor, der egal wie rum die Kehrschleife "steht" das korrekt an den PC oder andere Mithörer meldet. Meiner Meinung nach ist das in Hardware zu lösen, denn selbst wenn das ein PC kann...
OK, das wurde die dezidierte Hardware (RailCom-Detektor) natürlich nochmals teurer machen. Im PC wäre es dagegen eine Softwarelösung.
Zitat von: Markus Herzog in 11. Juni 2025, 13:19:11Sollen das dann lokale Railcom-Displays oder Handregler auch alle auflösen können?
Es handelt sich in erster Linie um ein organistorisches Problem, man muss eine Grundstellung für jeden Eingebauten Dezektorabschnitt vereinbaren und natürlich, im Moment der Kehrschleifenumschaltung, das Steuerungssystem über die Umkehrung der Bedeutung für die betroffenen Abschnitte und RailCom-Detektoren informieren. Falls sich dort schon Fahrzeuge befanden muss die Logik für die Interpretation der Railcom-Nachrichten aller dieser Fahrzeuge angepasst werden.
Falls das nicht, oder nicht rechtzeitig passiert, wird das Steuerprogramm falsch informiert und trifft u.U. falsche Entscheidungen, z.B. in welche Richtung der Fahrzeugmotor vom Decoder gedreht werden muss, damit das Fahrzeug das Gleis in der gewünschten Verkehrsrichtung verlässt.
WDP beherrscht das auch ohne die Nutzung von Railcom, d.h. man kann - insbesondere im Automatikbetrieb - auch einfach auf Railcom verzichten.
Eine inkorrekte Interpretation der eigentlich richtigen (Railcom)-Messdaten, einfach nur der Hardware anzulasten, obwohl man bei der Messung gar nicht alle Rahmenbedingungen erfasst, darf man aber vielleicht doch kritisieren. Wobei ich keineswegs behaupte, dass es einfach sei, das alles beim Programmieren umfassend zu berücksichtigen.
MfG
vik
Hallo vikr,
wie so oft im Leben: man kann es so oder so sehen. Und wir bügeln schon ständig Unzulänglichkeiten der Hardware aus und man immer mal wieder entscheiden wie weit man dabei geht. Das möchte ich jetzt aus Zeitgründen aber auch nicht weiter diskutieren, denn die WDP-Programmarbeit ruft.
Grüße
Markus
Hallo Markus,
Zitat von: Markus Herzog in 13. Juni 2025, 01:20:42wie so oft im Leben: man kann es so oder so sehen.
ja, das ist häufig Geschmackssache...
Zitat von: Markus Herzog in 13. Juni 2025, 01:20:42wir bügeln schon ständig Unzulänglichkeiten der Hardware aus und man immer mal wieder entscheiden wie weit man dabei geht.
aber physikalische Gesetzmäßigkeiten in Raum und Zeit als Unzulänglichkeiten der aktuell eingesetzten Hardware einzuordnen, führt letzlich nicht wirklich zur Lösung solcher Probleme. Das hat - nicht zuletzt - die Geschichte Gallileis gezeigt. ;-)
MfG
vik
Hallo Markus,
Zitat von: Markus Herzog in 13. Juni 2025, 01:20:42wie so oft im Leben: man kann es so oder so sehen.
ja, das ist häufig Geschmackssache...
Zitat von: Markus Herzog in 13. Juni 2025, 01:20:42wir bügeln schon ständig Unzulänglichkeiten der Hardware aus und man immer mal wieder entscheiden wie weit man dabei geht.
aber physikalische Gesetzmäßigkeiten in Raum und Zeit als Unzulänglichkeiten der aktuell eingesetzten Hardware einzuordnen, führt nicht wirklich zur Auflösung solcher Probleme. Das hat - nicht zuletzt - die Geschichte Gallileis gezeigt. ;-)
MfG
vik
Hallo Vik,
So wie ich das sehe, wird die Railcom-Funktionalität zunehmend zu einer markenabhängigen Angelegenheit.
Wenn Sie nur Zimo-Decoder haben, werden Sie mit einem vollständigen Zimo-System kaum Probleme haben.
Wenn Sie zu einem ,,freien System" wie BidiB oder LoDi wechseln, kann es bei einer hohen Melderdichte zu Nebenwirkungen in diesem System kommen, die sich negativ auf die Zugüberwachung auswirken.
Als Nutzer bin ich damit nicht allein, und ich beschränke mich hier auf die Niederlande.
Aber wir werden sehen, wie sich die RFID-Technik über Wifi und einen MQTT-Broker in Windigipet 2025 bewährt. :)
Viel Spaß mit Railcom, wie ich bereits geschrieben habe: POM Only :)
https://www.youtube.com/shorts/DD0P9evUxHU?feature=share
https://www.youtube.com/shorts/yWMozA1jOe8?feature=share
https://www.youtube.com/shorts/FVqqeegwd1g?feature=share
Rupert