THEMA: Railcom | Kompatibilität Detektoren/Rückmelder

Moin Jens,

Bidib geht mit Tams mc2 und Fichtelbahn Produkten (GBMboost, Bidib-IF und Bidib-IFnet)

Vg wassi

RC Modul(e) für LocoNet Bus gibt es auch noch.

Deine Schlussfolgerung ist leider richtig und Besserung ist nicht in Sicht. Wenn einem "ein bisserl CV Lesen" oder so ausreicht könnte ein RC Modul für LocoNet genügen, ansonsten bleiben nur die CAN Lösungen von ESU, ZIMO sowie der RS485 basierte BiDiB Bus.

Bei BiDiB gibt es wie bereits erwähnt 2 (voneinander unabhängige) Hersteller.
Für ZIMO CAN gibt es auch 2 Hersteller, die aber ein wenig miteinander verbandelt sind.

Alternative Entwicklungen kenne ich keine.
Die NMRA bastelt zwar munter an ihrem offenen LCC Ding, aber nachdem RailCom in den USA kein Thema ist erwarte ich hier keine Module.

Roco und Zimo haben hier und dort etwas gemeinsames....

Das LocoNet Modul aus den NL arbeitet mit der dazu gehörenden Zentrale und wohl auch mit Uhlenbrock IB zusammen.

Moin,

Danke allerseits.
Damit stimmt also mein Fazit.

Das bedeutet, dass ich, wenn ich später eine Zentrale wechseln möchte, ich auch die ganze Rückmelde-Hardware wechseln müsste, wenn ich auch den Anbieter der Zentrale wechseln will.

Das muss ich mir nochmal überlegen.

Ich denke, dann werde ich alleine auf die Zugverfolgung der Steuerungssoftware setzen.

Viele Grüße von Jens

Davon gehe ich aus, ist K.D. doch der Entwickler der Software der IB3 und lässt seine eigenen Komponenten bei Uhlenbrock fertigen:

https://www.facebook.com/story.php?story_fbid=1...p;id=100039297926182


(geht auch ohne anmelden, einfach auf das Kreuz rechts oben klicken)

Viele Grüße von Jens

So ein verfluchter Zufall...
Ich ziehe meine oben genannten Bedenken über LCC zurück...

_HEUTE_ hat TCS einen RailCom Melder für LCC angekündigt
https://www.tcsdcc.com/product-page/block-8-rcs

Servus

Habe mal die KI bemüht, um Hersteller zu finden, die Railcom-fähige Zentralen anbieten.
(mit Vorbehalt der Richtigkeit).

Aufgrund der Patentierung von Railcom durch Lenz / ESU ist Europa wesentlich stärker vertreten als der "Rest der Welt".

Angesichts des oben geschriebenen heißt das wohl, dass nur wenige Rückmelder mit mehreren Zentralen kompatibel sind?

- EUROPA -

Lenz
ESU
Roco / Fleischmann
Uhlenbrock
Tams
Viessmann
FichtelBahn
Zimo
Märklin / Trix
Piko
Rautenhaus
Littfinski
Stärz
DCC-EX  (LCC-Protokoll)

Digikeijs (RIP)
D&H (RIP, was die Zentrale betrifft)

JMRI via Computerinterface  (LCC-Protokoll)

- USA -

TCS (LCC-Protokoll)
Digitrax
NCE
RR-CirKits (LCC-Protokoll)


- UK -

Hornby
DCC Concepts
Gaugemaster
SPROG DCC

- JAPAN -

Desktop Station


Weiter meint die KI:

BiDiB will das Maximum aus RailCom herausholen (High-End-Rückmeldung).
LCC will einen universellen Welt-Standard für alle Komponenten (Interoperabilität)

stimmt das so?

VG Freetrack

Hallo,
es gibt eine Norm RCN-217 zu RailCom von der RailCommunity - ein Verband der Hersteller Digitaler Modellbahnprodukte e.V.

Norm RCN-217: https://normen.railcommunity.de/RCN-217.pdf
Mitwirkende bei RailCommunity:
https://www.railcommunity.org/index.php?option=...;id=38&Itemid=57

die mitwirkenden Firmen sollten doch untereinander kompatibel sein, oder ???

Gruß von einem der "nur" DCC fährt.
Rainer

Hi aufpassen!
Es gibt rund um das attraktive Thema RailCom einen Haufen Blender! Es kommen brutto bei jeder Aussendung eines DCC Pakets einiges an Daten zurück. Einfach überlegen etwa 80DCC Befehle pro Sekunde und Retour 2 bis 5 Bytes mit zusätzlichem Protokoll Overhead. Da muß der Bu schnell sein um das zu schaffen. Vieles ist redundant manchmal wird nix geschickt aber man muß vom Design her so im Design haben, daß man alle Daten die die Decoder absenden verarbeiten kann. Gut ist es wenn man bereits im Freimelder Intelligenz hat dei Redundante Nachrichten erlkennt und nicht aussendet das hilft dem Gesamtsystem.

Die meisten Bussysteme die im MobaBereich benutzt werden stammen technisch von der Architektur auch den 1960'er Jahren. S88, LocoNet, X-Pressnet udglm. sind in den Anfängen der Modem Geschwindikeiten. Wer kann sich noch an Akustikkoppler erinnern. Um die Datenmengen komplett zu transportieren sind sogar die schnellen Busse wie BiDiB, und CAN Busse gefordert, schaffen das aber locker.

Wenn man nun RailCom mit einem Großteil der Features benutzen möchte aber die modernen Busse aus "religiösen" Gründen ablehnt hat man kein RailCom sondern das was man auch bisher hatte nur bissl komplizierter gemacht.

Jene Zentralen die RailCom ernst nehmen haben ihre "Umgebung" 3rd Party Produkte gibt's selten, das ist derzeit so. Die Vorreiter beginnend mit Lenz über ESU und ZIMO haben, aus welchen Gründen auch immer, entschieden nichts bedeutendes mehr zu machen. LENZ hatte ohnehin nur den Zugnummernanzeiger. ESU hat bei dem Freimeldern nur teilweise RC drauf. ZIMO hat astronomische Preise, einzig Roco hat mit dem 8-fach melder der in Zusammenarbeit mit ZIMO entstand was preislich näherkommendes. Das geht weil hier auch der rasche, robuste und preislich besonders attraktive CAN Bus benutzt wird. Das ist das sonderbare, CAN Bus ist durch die Verwendung in Autos faktisch kostenlos geworden, steckt in vielen Prozessordesigns um wenige Eurocent mehr bereits drin. Die anderen Busse brauchen viel mehr HW Aufwand, was die Sache nicht günstig beeinflusst.
Die CAN Busse von ZIMO, ESU, Märklin sind elektrisch gleichwertig, verwenden die identen Chips, die Protokolle aber inkompatibel. Einzig Roco/Fleischman haben sich entschlossen die ZIMO Variante zu benutzen. CAN Busse und BiDiB eignen sich wenn man WIRKLICH RailCom benutzen will sonst ist das nur Kindergarten.
-AH-

Hallo

wegen Zukunftsfähigkeit bezüglich Datendurchsatz hier eine Übersicht

System Geschwindigkeit
Loconet 10k Baud ca. 100m Reichweite
CAN 250k Baud ca. 200m Reichweite
XpressNet 62,5k Baud ca. 400m Reichweite
BiDiBus 500k Baud ca. 400m Reichweite

Also wer Zukunftspläne mit Railcom hat, sollte nicht auf das tote Pferd Loconet setzen. Da bekommt man kaum noch Daten durch.

Man sollte auch nicht zuviel Hoffnung in Railcom setzen. Ich habe es gemacht und sehe, dass Railcom  seine Schwächen hat. Stichwort Geistermeldungen. Angeblich melden Loks zurück, die nichtmal auf der Anlage sind. Angeblich antworten Loks ausserhalb vom vorgesehenen Zeitfenster und das bringt die Steuerung durcheinander. Also bedingt brauchbar.

Dafür viel Geld investieren? Sollte man vielleicht überdenken.

Gruss

Stephan  

Dieses Problem taucht in den Foren immer wieder auf.

Die einen sagen, nur problematisch, wenn mehr als 10 Züge gleichzeitig fahren.
Die anderen, nur problematisch, wenn sie in den Lokdecodern Kanal 1 und 2 gleichzeitig eingeschaltet haben.
Und die anderen, dass sie gar keine Probleme mit Geistermeldungen etc. haben.

VG Freetrack

Edit: eine weitere, häufige Ursache von Problemen sind die Dekoder.
Hierbei sollen upgedatete D&H und Zimo nur selten Schwierigkeiten machen, bei den anderen Herstellern ist es sehr durchsetzt.

Jo mei, wenn man Produkte jenseits des Alpenhorizonts nie im Einsatz hatte, dann ist gut ratsch, Magister AH.

Wifi, $2 für die HW, mehrere Megabit, deckt alles im Raum.

Grüße
Harald.

Moin Allerseits,

Danke für viele neue Infos.
Ich bin nach weiteren Querrecherchen, insbesondere nach den Beiträgen von Arnold und Stephan erstmal ernüchtert.

Auf einen modernen Bus zu gehen, wäre nicht das Problem. Ich störe mich mehr daran, dass bezüglich Railcom jeder sein eigenens Süppchen kocht.

Nach dem Beitrag von Stephan, auch in einem anderen Forum, scheint Railcom jedoch selbst bei Bidib nicht zuverlässig zu funktionieren.

Schade.
Meine Ansprüche für Railcom wären übersichtlich:

- Lok- und Richtungserkennung (idealerweise mit automatischer Anmeldung)
- Weichenstellungsrückmeldung

Das wäre es auch schon.

Aber scheint nur unzuverlässig zu funktionieren.

Viele Grüße von Jens

Bei BiDiB funktioniert Railcom zuverlässig,
Geistermeldungen bei BiDiB sind Probleme der Decoder, auf die BiDiB keinen Einfluss hat.

Es gab in der Vergangenheit da ein paar Problem. Diese sollten aber mit Firmware-Updates behoben sein.
Wenn es weiterhin Probleme gibt, dann müsste das untersucht werden, Hilfe gibt es dafür im Normalfall im OpenDCC-Forum.

Grüße
Anderer Stephan

Mit dem DR5088LN-RC Modul kann man die Fahrzeugadresse (Decoderadresse), die fest implementierte Aufgleisrichtung, den Verschmutzungsgrad, die definierte Geschwindigkeit und eine Behälterfüllungen über RC auslesen. Außerdem wird die Blockbelegungsnummer und die Meldernummer übermittelt.

Desweiteren kann man auf dem Hauptgleis (POM plus RC) gezielt einen Lok- oder Funktionsdecoder sowohl auslesen(!) als auch programmieren. Das Programmiergleis entfällt damit fast vollständig. Ausnahme ist die eigene Ersteinrichtung des Lok- oder Funktionsdecoders, oder bei Umbauten und Wartungsarbeiten am Fahrzeug.

Vorraussetzung ist immer, dass Lok- und Funktionsdecoder RailCom implementiert haben.

Anschluß an jede Zentrale die mind. eine LocoNet T-Buchse hat und keine Einschränkungen für den LocoNet Bus hat bzw. einen anderen Bus für RC verlangt.
Ungeeignet trotz LocoNet Bus Anschluß sind z. B. die Z21/z21 von Roco/Fleischmann, siehe dazu deren CAN Bus Rückmeldersystem.

Die Nachfolgezentrale für die DR5000 ist die YD7001 / YD7010 Serie. Für den DR5088LN-RC Baustein gibt es ebenfalls einen Nachfolger YD6016LN-RC. Zu finden im örtlichen oder überörtlichen Fachhandel unter der Bezeichnung.

Hallo

Bei mir fahren keine 10 Loks auf der Anlage rum. Noch nicht zumindest. Im Vollausbau werden es an die 30 sein.

ich habe letztens überall Decoderupdates gefahren, wo es welche gab. Bugfixes bezüglich Railcom gab es bei D&H und sehr viele bei Zimo. Die Dekoder der MS/MN Serie sind eine einzige Baustelle. Da gab es mehrere Bugfixes. Wie Bananen, reifen die beim Kunden. Testläufe habe ich noch nicht gemacht. Da muss erstmal meine Landschaftsbaustelle geschlossen werden. Mal sehen, ob es besser wird.

Heutzutage ist es zwingend nötig, einen Programmer der jeweiligen Hersteller zu kaufen. Mit der heutigen Bananenware kommt man nicht drum rum, immer wieder Firmwareupdates fahren zu müssen, wenn man alle Funktionen richtig nutzen will. Nur Blöd, dass auf meiner Anlage Dekoder von 4 unterschiedlichen Herstellern fahren.

Gruss

Stephan

Ja, das ist alles etwas unbefriedigend. Wenn ich das heute neu designen würde, würde ich vielleicht normales Ethernet (für fest verdrahtete Sachen) benutzen. Dann kann man die Sachen direkt an den PC anschliessen. Das braucht zwar mehr Ressourcen, aber so viel dann auch nicht und Railcom Rückmelder sind ja eh komplizierter. (Oder man betrachtet die schwarzer Z21 einfach als CAN-LAN Adapter. Ist dafür allerdings recht teuer, wobei mit 40 Rückmeldern relativiert sich das dann wieder).
Zum Glück ist das bei den Schaltartikeln ja alles wesentlich kompatibler.

Gruss,
Steffen

Hello!
Zu den Geistermeldungen habe ich die Beobachtung, daß das häufiger auftritt wenn man die Daten über den GlobalDetector in der Zentrale und Booster unter Zuhilfenahme von Freimeldern benutzt. Das Problem dabei die RailCom Meldung hat relativ schwache Ströme, auf langen Leitungen kann da was passieren. Das war auch nur eine bedingt gute Idee wenn man eine größere Gleiskonfiguration hat.

Nutzt man örtlich lokal platzierte Leser fällt das Problem weniger stark aus ober gar nicht. Hauptproblem dabei dei Leser gehen halt gewaltig ins Geld.

Obiges natürlich abseits von Firmwareproblemen in den Decodern. Da gab's auch bei einigen Herstellern zu optimistische SW Releases.
-AH-

Moin AH.
Danke für den Verweis zum Globalen Detektor:
Wenn ein RC Baustein neben einer Anzahl X an Messanschlüssen auch einen "Global Detector" hat, dann dient der zum Anmelden in der MoBa Steuerungssoftware des Decoders. Dazu ein "getarntes" z.B. ein Stumpfgleis Gleis im BW einrichten. Dieses trenne ich ausnahmsweise vom Rest der Anlage. Und hier kann man dank RC auch die Einzelprogrammierung machen. Die hier Angemeldete Fahrzeuge werden dann in der Lokdatenbank gespeichert. Die Gleisblöcke werden über die separaten Messanschlüsse ausglesen. Damit ist das Problem aus der Welt.
Messfühlerleitungen zwischen Gleis und Anschlußpunkt am Baustein ist kurz zu halten. Gilt auch für normale Gleisbelegtmelder. Und ja, insbesonere RC Belegtmelder gehen ins Geld! Lange Strecken "überlebt" das RC Signal nicht, scheitert am Kabelwiderstand, weil es sich nur um einer sehr kleine Spannung und Stromfluß handelt. Insoweit ist RC so wie es entwickelt wurde - Entschuldigung - Grütze bzw. eine Gelddruckmaschine.
Soll man sich also auf RC mit diesem Messfühlersystem einlassen? NEIN! Kauft Euch normale Rückmelder und gut ists. Ich würde heute kein RC mehr anschaffen. Lieber lege ich einmalig meine Lokdatenbank an und lerne die Lok in der Modellbahnsoftware einmal an.

Fazit: AHs Kritik an dem unausgereiften System ist berechtigt. Alleine weil sich keiner wirklich an die Normen hält, sich beim Bussystem zur Datenrückmeldung vom Modulbaustein an die Zentrale nicht einigen kann. DCC-A hier, mfx dort und RailCom Plus obendrauf.

Grüße.

Frank

Ist ja so, dass bei den aktuellen Systemen die Rückmelder ja via Netzwerk verbunden sind.
Somit kann man die Kabellängen vom Gleis zum Rückmelder meist überschaubar gestalten.
Und dann wäre die Größe der gesamten "Gleiskonfiguration" ja nicht maßgeblich?

Ich gehe dabei davon aus, dass der Rückmelder das RC Signal dann problemlos zur Zentrale überträgt, oder ist hier die Kabellänge noch immer ein Thema?

VG Freetrack

Hallo,

now we have the salad.
Am Gescheitesten wäre es wenn alle Hersteller sich an einen Tisch setzen würden.

Schade eigentlich

Peter

Hallo RailCommer,

Lange Leitungen ?

hier ein Auszug aus RCN217:

...
Getestet wurden diese Schaltungen (Sender und Detector) auf großen Clubanlagen bis zu
einer Entfernung von 100m. Diese Entfernung wurde problemlos überbrückt. Zugelassen sind
dabei nicht vom Gleis durch Brückengleichrichter isolierte Verbraucher von 5 Ohm, die
parallel zum Messwiderstand des Detectors liegen.
...


Ciao
U

Hello!
Die klassischen Fehler an der Moba sind sinnbefreite falsche Verkabelungen. Im Wesentlichen sehr optimistische Annahmen die zu zu dünnen Kabeln führen. Man kann das kombinieren mit parallel Verlegung zu anderen Kabeln die dann mehr Möglichkeit haben durch Übersprechen die Signale zu stören.

RailCom sendet Strom in einer Schleife. Das ist eine durchaus sichere Übertragungsmethode die Störungen eher vermeidet. Ursprünglich war da 5V vorgesehen als treibende Spannung für die Stromquelle. Heutzutage senken die Hersteller die Spannung auf Prozessorniveau ~3V. Das macht die Sach' deutlich heikler.
Anwender schalten gerne Verbraucher parallel zum Gleis. In der N Welt häufig anzutreffen Lämpchen direkt im Rahmen. Allgemein kommuniziert das ist nicht sinnvoll die paar mA aus dem Decoder zurück zum Fühler mittels Lämpchen oder was auch immer abzuleiten.
Das Entkoppeln der Verbraucher über Si-Dioden wird großzügig ignoriert. Der Spannungsabfall von 0,5-0,8V würde Ausreichen in den RC-Sensoren genügend Signal ankommen zu lassen um das lesen zu können. Wird halt nicht gemacht sondern Verbraucher direkt an Gleissignal angeschlossen. Beleuchtete Wagen sind da häufig das Problem. Wird aber meist wegdiskutiert obwohl das sehr einfach nachzumessen geht.
In den Sensoren  gibt's die Herausforderung stärkere und schwächere Signale der Stromschleife zu lesen. Die einfachste Lösung im RC Signal Leser ist einen fixen Schwellwert zur Entscheidung 0/1 festzulegen. Wie in allen solchen Fällen weiß man, daß es billig ist sowas zu machen aber sicher schlecht funktioniert. Besser ist es den Sensor etwas an das Signalniveau anzupassen. Kostet nur sehr wenig, wird aber gerne eingespart weil so wie bei Anwendern auch bei den Herstellern viel Optimismus und großzügige Ignoranz der Physik gegenüber herrscht.

Die Unwissenheit local Detector zu global Detector macht die Dinge nicht leichter. Wenn die RC Antworten mehrerer Decoder gemeinsam ankommen am Lesegerät - was soll da rauskommen? Im Besten Fall Geistermeldungen oder völlige Fehlfunktion.

Ausreichend dicke Verkabelung, saubere Struktur und überlegen wo man RC Lesen will führen zu besseren Ergebnissen.
-AH-

Hallo Alle,



Ein RailCom Meldeabschnitt hat normalerweise ein Adresse. Zusammen mit der RailCom Nachricht ist das ein eindeutig.

z.B Loconet: INPUT_REP oder SENSOR Nachrichten enthalten eine Adresse.

Was soll da nicht richtig ankommen?

Ciao
U

Wird doch gemacht:
https://railcommunity.de/

Hallo,



Die Stromschleife wird vom Booster geschaltet (Railcom Cutout). Das bedeutet. das Railcom Signal vom Decoder muss zum Booster und wieder zurück. Wo der Detektor sitzt, ist egal.

VG,
Frank

Und welches Protokoll auf welchem Bus sollen wir der RC nach dann für Rückmelder und Steuerung wählen? Die NMRA hat ja LCC der nicht so richtig abheben will. Bei der RC gibt's ja weder layer2 noch layer3 als Ansatz zu einer Norm, oder?

Grüße,
Harald.

Ein Bus wird von der Railcommunity nicht favorisiert, nur S88 definiert.

Grüße
Stephan

@28 Da reden wir aneinander vorbei.

Es gibt Konzepte wo man versucht auf Local Dectectoren zu verzichten und versucht alles über einen Global Detector (hockt in der Zentrale oder Booster) gekoppelt mit Freimeldern abzuwickeln. Kann man machen, aber das ist nicht RailCom sondern man nutzt Railcom Teile möglichst schlecht. Die Diskussion in diesem Thread zeit was dabei rauskommt. Viele glauben wenn irgendwo an der Anlage abseits der Decoder ein RC Leser versteckt ist daß das zu sinnvollen Ergebnissen führt.

Die Klage wegen Busverwirrung ist berechtigt, aber was die NMRA aufführt wird nix. In Europa gints zumundest 3 CAN Busse und BiDib. Ob sich da einer etablieren kann hängt von den handelnden Personen ab. Die Entscheider sind alle in gewisser weise "auffällig"...
-AH-

Korrektur zu AH Ausführung bezgl. Bussystem i.V.m. RailCom.

Neben 3 CAN Bussystemen bietet ein bekannter Hersteller auch einen RailCom Detektor über LocoNet an. Der funktioniert vorzüglich. Man kann den Detektor lt. Hersteller auch an einer Uhlenbrock IntelliBox oder auch an der ESU Ecos betreiben sofern die Ecos sich mit dem LAN Bus auf den Baustein zwecks Datenverkehr einstellen lässt. Daneben auch mit Digitrax US Zentralen und KATO Zentralen, sofern LocoNet Bus vorhanden ist. Näheres weiter unten im Text.

Und was man auch kann: wer die passende Zentrale DR5000, YD7001, YD7010 zum RailCom Detektorbaustein DR5088LN-RC / YD 6016LN-RC hat, kann in der Wartungssoftware der Zentrale mittels einer individuell gestalteten CV Liste alle Decoder diesre Welt über RailCom auslesen, sofern der Decoder RailCom hat. Das geht ratzfatz, an jeder beliebigen Stelle der Anlage wo ein Detektorausgang mit einem entsprechenden Gleisabschnitt (idealerweise im BW) verbunden ist und hat kein nerviges Tickern und gefühlt stundenlanges Warten am Programmiergleis bis das Alles eingelesen ist. Umgekehrt kannst dann auh präparierte CV Listen in den Decoder schicken. Das geht auch wesentlich flotter als am Programmiergleis wo Du mühsam jede CV extra bearbeitest. Fern vom Programmer kannst Du dagegn in aller Ruhe die CV Liste mit Excell bearbeiten. Habs heuer getestet, das geht pima einfach. Man braucht also nie mehr sein Fahrzeug von der anlage nehmen. Ja man kann sie sogar gleich aufgleisen und programmieren ohne den separaten PROG Ausgang zu benutzen. Benutzt wird nämlich der POM Ausgang dafür!
Ich hoffe ich konnte es verkürzt rüber bringen.

Also man sieht RailCom ist, richtig umgesetzt, schon ein kleiner Fortschritt ggü. dem normalen DCC Betrieb.

Schade nur, dass man DCC-A nun erfunden hat, weil man sich mit ESU und seinem RailCom Plus in der Railcom Community (Lizenz) damals wohl nicht einig wurde. Das macht dann wieder Zentralensoftware komplexer bzw. freie Hersteller implementieren DCC-A oder RailCom Plus erst gar nicht, weil man den Markt nicht abschätzen kann. Dem Kunden ist damit wieder einmal ein Bärendienst erwiesen worden. Auch bei den Decodern trennt es sich zwischen den Beiden auf.

Nunja, in Amerika drüben siehts net besser aus. TCS wählt für seinen neuen Detektor den LCC Bus. Inkompatibel geht's munter weiter.

Immerhin kannst an einer US Digitrax Zentrale und KATO Zephyr Zentrale mit LocoNet Bus auch den Niederländerländischen Detektorbaustein anschliessen und mit JMRI MoBa Steuerung dann RailCom laufen lassen.

Angenehmen Sonntag. Und a bisserl was geht immer!

Frank

@31:

Die Trennung in lokale und globale Detektoren ist doch nur Augenwischerei. Fakt ist: Ein lokaler Detektor ist nur so gut wie die Annahme, dass nur maximal ein Decoder im Abschnitt steht. Wer aber mit Doppeltraktionen oder RailCom-fähigen Wagen fährt, hebelt dieses Prinzip sofort aus. Die lokalen Detektoren mutieren zu global Detektoren. Für eine wirklich verlässliche Modellbahn ist das zu wenig. Man verlagert das Kanal-1-Kollisionsproblem nur, statt es zu lösen.

Da die gängigen Bussysteme hier konzeptionell an ihre Grenzen stoßen, bin ich einen eigenen Weg gegangen. Ich habe ein Bus-System entwickelt, das speziell auf maximale RailCom-Ausbeute getrimmt ist. Mit Verlaub: In Sachen RailCom-Tiefe spielt das in einer eigenen Liga. Ich sehe momentan kein anderes System, das diese Informationsdichte und Zuverlässigkeit in naher Zukunft erreichen wird. Viele sagen es sei Liebhaberei - mag sein. Da mein System nicht-kommerziell ist ( https://github.com/git4dcc ), taucht es in keiner Vergleichsliste auf.

VG,
Frank

@32 ein RailCom Detector der über LocoNet irgendwas meldet schmeißt den Großteil der empfangenen Daten weg. Das hat nichts mit RailCom zu tun. Genau das ist das Verständnisproblem. Also sorry über LocoNet bekommst Du nur das was das "transponding" Verfahren an Funktionalität bereitstellt. Decoder Adressen aber nicht mehr.

@33 Jein, die Zentrale kann den ersten in den Abschnitt eingefahrenen Decoder auffordern eine gewisse Zeit keinen Kanal1 broadcast zu machen. Das würde das Problem zumindest entschärfen. Das ist aber nicht der Kern, in Kanal 2 darf nur der angesprochene Decoder antworten, daher gibt es dort keine Kollisionen und das ist der Sinn des lokalen Detektors.
-AH-

LocoNet is sowieso ein Problem weil das offizielle Dokument nur eine Teilmenge beschreibt und sobald du mit Digitrax ins Boot gehüpft bist wohl kaum LocoNet Mitteilungen implementieren darfst die dir gefallen würden sondern nur auf "Digitrax öffentlich" + "Digitrax geheim" beschränkt wirst. Wenn man allerdings nicht irgendwelche Papiere unterschreibt könnte man alle möglichen Datenpakete senden. Die dann allerdings vielleicht mit irgendwelche zukünftigen Paketen von Digitrax im Konflikt stehen könnten.

Wie Arnold sagt: Um die Kollisionen zu lösen stellt man Kanal1 ab. Reicht Kanal2 nicht aus um alle Daten zu übertragen die man übertragen will sobald man weiss welche Adressen auf der Anlage zu finden sind?

Grüße,
Harald.