THEMA: Lok läuft nicht richtig bei Railcom

Am Railcom Cutoff. Railcom ist sowieso hirnrissig, und das ist noch geschmeichelt.

Hallo Flo,
falls du mit "Cutoff" nichts anfangen kannst: Es funktioniert so, dass die Zentrale in bestimmten Intervallen eine kurze Pause beim Senden von Befehlen einlegt. Während dieser Sendepausen können Decoder Nachrichten an die Zentrale schicken. Einige (meist ältere) Decoder interpretieren das aber als kaputtes Digitalsignal und funktionieren nicht richtig. Da hilft nur RailCom aus oder Decoder tauschen.

Hallo Gerhard


Sicher wirst du diese Meinung mit Argumenten untermauern wollen. Schieß los!

Viele Grüße
Carsten von 1001-digital

das möchte ich auch gerne mal hören. Dass Railcom einen schweren Start hat, ist klar. Liegt aber nicht an Railcom ansich sondern an ganz anderen Dingen. Wer schon einmal ein paar Vorzüge von Railcom erleben durfte, wird solch einen Spruch wie in @1 nicht schreiben.
Wenn sich das "hirnrissig" auf die Komplikationen bei der Einführung des Systems bezieht, dann ist es wieder etwas anderes. Aber so wie es geschrieben wurde, bezieht sich das aufs System selbst.
Gerhard, hast du Railcom schon getestet oder ist das eine Aussage, die sich auf irgendwelche Kommentare bezieht?

Tomi

OK danke für eure Antworten. Anfangs hab ich erst gedacht die Lok wäre kaputt aber dann hab ich sie mit der Multimaus getestet und da lief sie perfekt. Jetzt lass ich Railcom einfach aus. Ich benötige das ja nicht. Das war bei meiner Zentrale von Anfang an eingestellt.

Ich nehme mal an da ist ein Fleischmanndecoder drin. Der verträgt wahrscheinlich RailCom nicht. Vielleicht geht es besser wenn du in CV29 die Analogerkennung ausschaltest. Wenn nicht, dann ist es eben so dass es nicht geht. Wird ja noch "lustig" mit Fleischmanndecodern und der Z21 Zentrale (die hat auch RailCom, weiss nicht ob per Default an oder aus).

Gruß,
Harald.

Folks!
Bereits vor etwa 10 Jahren als BiDi wie es damals noch hieß diskutiert wurde hat man diverse zu erwartende Probleme erörtert. Es ist natürlich immer unfair einem Produkt das vor der Einführung einer neuen Technik konstruiert wurde Probleme mit der Neuerung vorzuwerfen.

Im wesentlichen gibt es zwei Problemfelder:
1. die Austastlücke wo es keine Spannung am Gleis gibt lässt Decdoer abstürzen. Dieses Problem haben die Decoder aber auch auf Weichen und anderen stromlosen Stellen. Die Konstruktion dieser Decoder war schon damals ein Mist, so gesehen kei wirkliches RailCom Problem.
2. Verbraucher die den BiDi Strom der vom Decoder kommt wegfressen, das sind vor allem Lämpchen die ohne Gleichrichter am Gleis hängen.

Leider sind beide Fälle (RailCom stört bzw wird gestört) recht häufig. In beiden Fällen war bereits vor der Einführung von RailCom die Lösung technich nicht die Beste. Es rächt sich halt für Hersteller als auch für den Modellbahneranwender das leider übliche zwanghafte Sparen. Ein paar Eurocent pro Wagen oder Decoder hätten das vermieden. So gesehen sind die "Opfer" auf beiden oben beschriebenen Seiten selbst schuld, hier meine ich sowohl Hersteller als auch Modellbahner.

Die Änderung von CV29 Analogerkennung hilft hier meißt nicht viel, weil der Prozessor komplett abgestürzt ist. Schlimm betroffen sind da zB die älteren Lenz Decoder die keine Pufferelkos oder brown out Schaltung haben.

Hallo Arnold,
wenn es "nur" an der fehlenden Spannung liegt... Könnte man dann nicht den Decoder nachträglich noch puffern? Speziell bei den älteren Decodern sollten Plus und Masse doch noch recht einfach abzugreifen sein.

Viele Grüße
Carsten von 1001-digital

Aber bitte gerne doch!

Nachdem ich Railcom nicht nur als Gimmick sehe sondern was sinnvolles damit machen wollte, erlaube ich mir nämlich dieses Urteil.


- hirnrissig ist es, allen Deocodern für über 400µs einfach mal so den Saft abzudrehen. Lenz meint, dass die das schon können müssen. Tastache ist dass es nicht jeder Decoder kann.

- das Geschäftsgebahren von Lenz ist genug kommentiert worden. Patente, Geheimniskrämerei, unberechenbar.

- hirnrissig ist es, zwar die Übertragung genau zu spezifizieren, nicht jedoch was denn eigentlich. Da kann der Decoder irgendwas senden oder auch nicht, wie er halt grad lustig ist. Pflicht ist fast nur die Adresse. Na, eine tolle Information. Hier wurde eine historische Chance durch Dummheit vertan.

Ein Beispiel aus der Praxis gefällig?
Ich habe hier 3 Decoder liegen, ich hab den Dreck per Oszi und seriellem Adapter ausgewertet.
- Zimo schickt 2 Byte Adresse, 2 Byte "Speed". Fein.
- der  Lenz schickt 2 Byte Adresse, 2 Byte "Fuel 0", 4 Bytes "CV NACK NACK NACK". Aha.
- der ESU sagt mir 2 Byte Adresse, 6 Bytes ""NACK". Was soll man mit dem Mist anfangen? Der DCC Befehl wird verstanden, die Lok fährt normal, ALLE Funktionen hauen hin.

So, und jetzt verratet mir mal wie man da irgend eine vernünftige und sinnvolle Appliaktion damit machen kann?

- oberhirnrissig ist es, dass ein under derselbe Code 0x0F je nach Lenz-Geschreibsel, RP9.2.3 oder VHDM entweder ein "ACK" oder "NACK" bedeutet. Was soll der Sch..ss? Schmecks jetzt, was es der Deocder wirklich meint. Wurde er nach "Lenz" oder "RP 9.2.3" programmiert, wer weiss das schon?
Damit erübrigt sich jeder versuch, die Railcom-Daten auswerten und verwenden zu wollen.


Ich habe ziemlich viel Zeit in den Mist investiert, und habe es wegen der offensichtlichten Sinnlosigkeit ad acta gelegt. Vielleicht deswegen meine harsche Meinung zu Railcom, die ich aber genau so meine. Das braucht mir keiner mehr schönreden wollen.

Wers nicht glaubt und sich jenseits der bunten Prospekte informieren will:
http://www.opendcc.de/info/railcom/railcom.html
http://www.opendcc.de/info/railcom/railcom_lok.html  (ACK/NACK Problematik)

Nett formuliert. Es ist nämlich nicht "relativ schwierig, sondern praktisch unmöglich.


vg,
Gerhard



Die von GerhardT zu diesem Beitrag angefügten Bilder können nur von registrierten Usern gesehen werden - Login

Hallo Gerhard,
danke für die ausführliche Antwort.


Das ist dann aber allein Sache des Herstellers. Wenn ein Decoder für Railcom gebaut wird, muss eben eine entsprechend große Kapazität drauf sein. Und auf der anderen Seite: Wie willst du die Senderei ohne Cutout machen? Hast du ne alternative Idee?


Die Frage ist: Warum können es andere? Es gibt sowohl Decoder als auch Zentralen mit Railcom, also kann es so sinnlos nicht sein, wie du es hier beschreibst.


Das ist ein lokaler Link, du wirst deine HTML-Datei schon irgendwo hochladen müssen.


Da fällt mir gleich in der zweiten Zeile ins Auge:
"Achtung - diese Infos sind veraltet!"

Viele Grüße
Carsten von 1001-digital

Edit: Vielleicht noch ergänzend... Ich will nicht explizit Railcom hier hochhalten, ich bin einfach der Meinung, dass ein Rückkanal vom Decoder zur Zentrale längst überfällig ist. Ob der Railcom, BiDi oder Nachhaustelefonieren heißt ist mir relativ egal. Derzeit sieht es bei Railcom aber am ehesten so aus, als würde da mal was passieren.

Echt sorry für den falschen Link, peinlich, ich habs oben editiert.

Warums bei anderen "funktioniert"?
Wenn es mehr können soll als die Info "Decoder mit Adresse 34 ist da", dann funktioniert es mit anderen Zentralen auch nicht.
Ich wollte eigentlich die Geschwindigkeit und Temperatur auswerten. Von allen meinen Decodern kann das offensichtlich nur Zimo.



Ja und nein, denn der Cutout betrifft alle Decoder am Gleis. Und in der Praxis werden da immer ältere dabei sein, die aus dem letzten Loch pfeifen.



Vor ein paar Wochen hätte ich Dir das glatt unterschrieben. Railcom nicht optimal, aber wenigstens mal ein Standard. Im Detail betrachtet jedoch eine Katastrophe, und inzwischen verstehe ich auch warum das nicht so richtig in Fahrt kommt.



Gerhard

Veraltet aber leider trotzdem wahr.




ich nicht, abere andere: "ZACK"
http://atw.huebsch.at/dcc/BiDi.htm


vg,
Gerhard

Folks!

Die RailCom Lücke ist mMn für einen korrekt konstruierten Decoder kein Problem. Es darf da keinen Absturz geben, schon vor 30 Jahren nicht. Ja ich weiss selbst daß vor allem die Lenz, Arnold, LGB und alten Roco Decoder (und viele weitere die so wie die Lenz Decoder konstruiert sind) durch die Lücke abstürzen. Das ist aber auch damals ständig aufgetreten durch Kontaktschwierigkeiten am Gleis oder auf Weichenherzen. Dieses Verhalten hat oft zum schlechten Ruf der Digitalanlagen beigetragen. Die Decoder waren damals schon Mist und das hat sich nicht geändert. Durch einen Pufferkondensator kann man das Problem großteils ausbügeln. Eine technisch korrekte Decoderkonstruktion würde das aber im Ansatz vermeiden. Nämlich Prozessor getrennt von den Verbrauchern puffern und die Brownout Funktion des Prozessors nutzen. Das Können die Dinger seit den späten 1970'ern!!!!

Die NMRA Beschreibung ist veraltet, Lenz fand und findet es lustig selbst nach Belieben die Specs ändern zu können was er weidlich ausnützt. Klar mit gewissen Grenzen, aber diese Unberechenbarkjeit hat die großen Streitereien in der Branche verursacht. Einerseits will er damit Qualität sichern, das ist positiv. Andererseits geht es um Wettbewerbsvorteil, man betrachte die RailCom+ Geschichte, das ist zum Nachteil. Jedenfalls gibt es das NMRA Dokument das mit den aktuellen Specs kollidiert. Die Specs von RailCom sind nur zugänglich wenn man sich einem von Lenz aufgesetzten Vertrag unterwirft.

Es gibt 2 mögliche Antworten in der RC Lücke. Einerseits die Broadcasts für die Localdetectoren und andererseits die Antworten auf zuvor empfangene Fragen die dann an den Global Detector gesendet werden, der lokale liest es natürlich auch mit. Daher ist es auch korrekt wenn hier dann unterschiedliche Daten in der Lücke zu lesen sind. Der Decoder kann auch selbst entscheiden daß er was ad hoc melden will. Daher muß es unterschiedliches Verhaltren geben!
-AH-

Hallo Gerhard,
danke, das war sehr aufschlussreich!


Das liegt vielleicht daran, dass der Standard noch in Arbeit ist. Zumindest hab ich das so verstanden. Dieser Teil sollte sich also noch bessern.


Ja, im Extremfall müsste man diese Decoder tauschen oder mit einem Pufferkondensator nachrüsten. Speziell bei den etwas "gröber" aufgebauten älteren Decodern sollte das ja auch noch relativ einfach gehen.


Mit den Einblicken, die du hier lieferst, komm ich ehrlich gesagt auch ins Grübeln. Aber Railcom ist eben immernoch die derzeit beste Chance, dass wir eine Rückmeldung in die Decoder bekommen. Für mich persönlich ist das vor allem beim Programmieren interessant, dann wären wir endlich mal diesen leidigen Blödsinn mit dem "Morsen per Motor" los. Das Auslesen ohne eine Last am Ausgang ist ja leider immernoch eher die Ausnahme als die Regel. Naja, schauen wir mal, ob ZACK sich vielleicht zur Alternative entwickelt. Auch wenn ich den Namen blöd finde ;)

Viele Grüße
Carsten von 1001-digital

Danke Gerhard für die aufschlußreichen Bilder.


Es gehört schon einiges Zielwasser dazu, sich so ins eigene Nest zu pinkeln (da man ja schon Dekoder nach den alten Spezifikationen verkauft hat).

Gruß,
Harald.

Hallo,

wenn ich das hier so lese, muss ich mit dem Kopf schütteln. Bidirektionale Kommunikation mit den Decodern ist längst überfällig . Aber statt ein funktionierendes System wird da immer wieder daran herumgedocktert, bis die verschiedenen Hersteller die Nase voll haben und ihr eigenes Süppchen kochen. Der Dumme ist der kleine MoBahner, der dann übehöhte Preise zahlen darf, weil jeder Hersteller seine eigenen Entwicklungskosten abwälzen muss.
Wenn dann Märklin - unter solchen Umständen kann ich sogar verstehen, dass die ihr eigenes Protokoll machen - eine fertige, funktionierende aber nicht so leistungsfähige Alternative als das theoretisch existierende System anbietet, schreien alle auf.
Unter diesem Aspekt eröffnet dcc auch dem vielgescholtenen SX-Protokoll neue Chancen: Stellt euch vor, Rautenhaus und D&H bringen auf einen Schlag ein funktionierendes, leistungsfähiges Rückmeldesystem auf den Markt.... Ich bin mir absolut sicher, dass sich diese Firmen nicht die Butter vom Brot nehmen lassen und längst an soetwas tüfteln. Da haben sie dann schon fast den Vorteil, dass die Anzahl der Hersteller überschaubar ist und auch regional konzentriert. Die sind mit Sicherheit Dankbar für die Wartezeit, die sich aus den Differenzen zwischen NRMA und Lenz ergeben...

Wir dürfen gespannt sein.

Jens

Hallo Jens,
warum entwickeln ?
Mit SX 1 funktioniert das ganze schon 10 Jahre in Verbindung mit Belegtmelder 8i von MÜT , bzw.
Belegtmelder von MTTM.
Also das  ist bei SX ein alter Hut.
Viele Grüße Dirk

Hallo Dirk,
es geht darum, mehr als nur die Adresse zu übertragen. U.U. variable Informationen für die verschiedensten Anwendungen. Die genannte Rückmeldung hat nichts mit der Idee von RailCom gemeinsam. Das finden im Übrigen auch die SX-Hersteller und zumindest von D&H-Seite her hat man durchblicken lassen, dass man auch daran arbeitet. Was, wann, wie, wo ist dabei Spekulation. Fakt ist nur: Wenn im Rahmen des SX-Protokolls keine variable Rückmeldung möglich ist, wenn es für dcc ein solches System gibt, steht die SX-Entwicklung endgültig auf dem Abstellgleis.

Um Dir nur mal ein Beispiel zu nennen, was man sich bei Railcom so vorstellt: Nimm an, zwei Triebwagen werden gekuppelt. Die Kupplung ist dabei so konzipiert, dass die beteiligten Decoder das Kuppeln registrieren und sich abstimmen (sei es durch die Kupplung oder über die Schiene), dass einer z.B. der Master ist und der Andere der Slave und bis zur Trennung ab sofort beide auf die Adresse des Masters hören und so ohne händisches Zutun in Traktion fahren.

So gesehen eröffnet sich für SX quasi eine historische Chance: Wenn man in Zusammenarbeit ein ausgereiftes System kompatibel untereinander auf den Markt bringt, während man sich bei dcc weiterhin streitet...... Eine ausführlichere Rückmeldung könnte auch eine eventuelle Fehlersuche vereinfachen, indem man verschiedenen Werte abfragen kann.

Jens

Hallo Jens,
also bitte.. nur wegen Rückmeldung werden die Leute nicht scharenweise zu SX wechseln. Da stehen doch noch ein paar wichtigere Punkte dagegen, z.B. Anzahl der Funktionen oder Anzahl der Adressen. Eher wäre das eine Chance für SX2, dann allerdings müsste das System in allen Spurweiten massiv gepusht werden. Da wäre es aber nötig, das System offenzulegen, damit es a) mehr Decoderauswahl mit SX2 gibt und b) mehr Zentralen das System unterstützen.

Hallo Herr Röhrricht,
doch schon seit 10 Jahren? Da gab es die Zimo Zugnummernerkennung bereits seit ca. 5 Jahren, streng genommen ist der Hut bei DCC also schon deutlich älter :) Beide Systeme leisten aber nicht das, was mit Railcom mal möglich sein soll / möglich ist. Insofern ist das nur eingeschränkt vergleichbar.

Ich persönlich habe auch kein Problem damit, wenn es noch 1 oder 2 Jahre dauert, wenn ich dann ein vernünftig funktionierendes System habe. Aber langsam sollte man mal zu Potte kommen, sich gemeinsam an einen Tisch setzen und die Sache vorantreiben. Mit diesem Hickhack schaden sich gewisse Herren / Firmen nur selbst.

Viele Grüße
Carsten von 1001-digital

Anstatt dass man froh ist, dass sich etwas in Bezug auf BiDI tut (auch wenn es wahrlich schon lange überfällig ist und momentan nicht wirklich viele positive Infos nach außen dringen), wird nur wieder auf allem herum gehackt und teilweise mit Un- bzw. Halbwahrheiten aufgewartet.
Dass die PROBLEME, die bei Railcom momentan noch vorhanden sind, als hirnrissig bezeichnet werden, könnte ich vielleicht sogar noch nachvollziehen. Aber Railcom und dessen Möglichkeiten selbst als hirnrissig zu bezeichnen, ist schon etwas übertrieben.

Ich selbst bin sicher nicht glücklich über die nicht wirklich positiv verlaufende Entwicklung des Systems (mit allen Komplikationen auch in Bezug auf "Streitigkeiten" etc.), dennoch sehe ich viele positive Aspekte, die (wenn auch noch nicht heute) dem Modellbahner viele Vorteile bzw. Neuerungen bringen werden.
Sicher ist, dass auch hier nicht alle dieser Meinung sind, wie auch bei vielen anderen Dingen auch. Der eine hat nunmal gerne eine sich öffnende Tür am Güterwagen, der andere mag das überhaupt nicht. Aber der Großteil der Modellbahner wird in Zukunft Vorteile von Railcom bzw. BiDi haben.

Viele Grüße
Tomi

Carsten,

gerade du solltest wissen, dass es im Zusammenhang mit RailCom nicht allein m Rückmeldung geht - das ist erst der Anfang. Echte BiDi ist mehr als bloß Rückmelden. D.h. die Decoder qittiren nicht bloß Anweisungen, sondern sie generieren ggf. echte situatonsbezogene Meldungen. Aber wahrscheinlich weißt du das sogar sehr viel besser als ich.
Und wenn ich von SX rede, meine ich nicht zwangsläufig SX1. Wäre es nicht vorstellbar, dass man quasi ein SX3 konzipiert (meinetwegen ein völlig neues Gleisprotokoll, dass z.B. für jeden Dekoder einen mehrere Bytes großen Datenblock von vorne herein zur Meldung vorsieht)? Ich kenne längst nicht alle Ideen und Möglichkeiten, die es in der digitalen Kommnikation der Geräte untereinander gibt. Ein großer Vorzug von SX1 ist seine Einfachheit und sein fester Rahmen - der mit seiner Begrenzung auch gleichzeitig der größte Nachteil ist/scheint. Vieles, was heute im Allgemeinen möglich ist, war vor Jahren undenkbar. Somit könnte ich mir durchaus vorstellen, dass man heute feste Rahmen schafen kann, die trotzdem variabel sind.
Und die ewige Diskussion über das weltweite dcc und das zum Sterben verurteilte SX ist auch Schnee von gestern. Nichts ist statisch. Selbst Apple ist - trotz aller Windowsfanatiker mit ihrem Pseudokompatibilitätswahn - mittlerweile größer als MS (und das, obwohl sie mal kurz vor der Pleite waren und ohne Finanzspritze von einem gewissen Herrn Gates wären sie Geschichte). Nichts ist unmöglich.

Fakt ist: Es gibt das weltweite dcc, mit Märklin einen internationalen Konzern mit eigenem Protokoll und in Deutschland noch SXx. Alle wollen sie leben - die Frage ist nur: Wer findet den besten und schnellsten Weg. Zu glauben, dass dcc diesaufgrund seiner Marktverbreitung automatisch ist, ist schon mutig. Die Verbreitung von dcc und die unüberschaubare Anzahl an Herstellern ist hier der größte Bremsklotz von dcc. So gesehen hat Märklin als Monopolist mit seinem System rein theoretisch sogar die besten Karten, denn sie müssen auf keine anderen Rücksicht nehmen.
Überleben wollen alle und deshalb wird es mit Sicherheit auch Lösungen geben, an die wir momentan noch garnicht denken...

Jens

stimmt.
Vielleicht wird ja auch schon an einer Lösung gearbeitet, welche BiDi für beide Protokolle ermöglicht? Vielleicht gibt es schon Hersteller die (wie du es nennst, Jens), an SX3 arbeiten? Oder wird vielleicht tatsächlich schon an einem Protokoll gearbeitet, welches es ermöglicht, alle bisher auf dem Markt befindlichen Decoder "unter einen Hut" zu bringen OHNE auf die Vorteile beider (für uns N-Bahner wichtigen) Protokolle verzichten zu müssen? Quasi die Vorteile beider System in einen Topf werfen und daraus etwas machen, dass alle zufrieden sind??? Aber glaubt mir, selbst hier wird es immer noch Kollegen geben, die daran etwas auszusetzen hätten.
Jetzt warten wir doch einfach mal ab, ob bzw. was sich in Bezug auf BiDi in der nächsten Zeit tut. Die Grundsteine sind gelegt und man kann nur hoffen, dass aus den "Grundsteinen" keine Steine werden, die in den Weg gelegt werden. Es wäre schade um die Möglichkeiten, die einem hierdurch verbaut werden würden.

Viele Grüße
Tomi

Hallo Jens


Das war dann wohl etwas zu flapsig ausgedrückt. Rückkanal wäre treffender gewesen, die Begrifflichkeit spielt hier aber keine wirkliche Rolle.


Noch ein Protokoll? SX2 hat schon kaum eine Verbreitung erfahren, obwohl es technisch in vielen Punkten DCC überlegen ist. Ich bin leider nicht im Bilde, wie es mit der RückKANAL-Fähigkeit bei SX2 aussieht, aber ich bleibe dabei: Das wird kaum jemanden zum Wechsel bewegen. Und wechseln müsste man, denn wenn man BiDi effektiv nutzen will, muss es in allen Fahrzeugen vorhanden sein.


Feste Rahmen, die trotzdem variabel sind... Also quasi ein harter Ball, der weich ist? Der feste Rahmen ist für die meisten Anwender vollkommen irrelevant. Niemand braucht an der Modellbahn Echtzeitfähigkeit - vielleicht mal abgesehen von Spezialfällen wie dem Eisenbahnlabor der TU Dresden, wobei ich auch dort denke, dass es einfach ein "Nice to have" war. Der Nachteil eines festen Rahmens ist, dass der Platz in ihm begrenzt ist. Im Fall von SX kommt noch hinzu, dass jede Menge Datenmüll mitgesendet wird - immerhin werden auch Befehle an Loks verschickt, die überhaupt nicht auf dem Gleis stehen. Hat man dagegen ein variables Schema, kann man wichtige Befehle priorisieren. Ein "Stop" z.B. sollte im Idealfall immer sofort übers Gleis gehen und nicht erst dann, wenn die Lok grad mal an der Reihe ist. Glaub mir.. Der feste Rahmen bietet absolut keinen Vorteil. Er beschränkt nur.


Das finde ich nicht. Es ist eine Menge DCC-Hardware im Umlauf und es ist utopisch zu glauben, dass die Leute alles über Bord werfen, wenn ein anderes System nicht wirklich signifikante Vorteile bietet. Und selbst dann wird es laaaaange dauern. SX1 ist ja das beste Beispiel, technisch ist es lange überholt und andere Systeme bieten deutlich mehr. Trotzdem gibt es noch immer Leute, die daran festhalten und sogar Neueinsteiger. DCC wird sicher auch irgendwann den Weg allen Fleisches gehen, immerhin hat sich im Lauf der Jahrzehnte einiges an Schlacke angesammelt (z.B. kurze / lange Adresse, Fahrstufen), das wird allerdings sicher noch dauern.

Viele Grüße
Carsten von 1001-digital