Hallo Zusammen,

Im DCC Bereich gibt es ja seit einiger Zeit RailCom, die Bi Direktionale Kommunikation zwischen Zentrale und Dekoder. Was bietet RailCom zur Zeit für Vorteile?
Ok das Auslesen von CV's auf der Anlage ist eine Sache. Aber viel Wichtiger ist die Frage, ob ich mit RailCom auch Rückmeldung der Position der Lock habe. Damit könnte man sich dann Gleisbelegtmeldung sparen.
Grüße

Jan

Hallo Jan

Wenn du Dir diese Diskussion anschaust und auch mal die Links durchklickst, wirst Du auf alle Fragen erschöpfende Auskunft bekommen.

Guten Morgen Jan,

Zitat

---

Was bietet RailCom zur Zeit für Vorteile?

---

Vorteile gegenueber was?
Aktuell gibt es zwei Protokolle, die bidirektionale Kommunikation bieten. Das ist Maerklins mfx und RailCom als Erweiterung des DCC-Protokolls.

mfx beschraenkt sich zunaechst auf das automatische Anmelden von Fahrzeugen an der Zentrale (incl. Funktionstastenbelegung und Klartextname) und bietet im Prinzip so eine Art Ueberwachung: Wenn eine Lok nicht mehr erreichbar ist blinkt deren mfx-Symbol. Ausserdem koennen Loks im Betrieb konfiguriert werden.
Weitere Eigenschaften oder Applikationen (Weichendecoder ect.) gibt es nicht, eine Positionsrueckmeldung ueber diesen Kanal ist derzeit laut Maerklin FAQ nicht vorgesehen.

Bei RailCom ist es ein wenig anders, die Technologie ist offener und durchschaubarer. Vieles darueber steht in dem Link, den Michael bereits veroeffentlicht hat.
Aktuell moeglich ist eine Positionsrueckmeldung auf einer dem zu ueberwachenden Gleisabschnitt zugeordneten Anzeige, das Auslesen von Decodern und das Auslesen und stetige Anzeigen bestimmter CVs, z.B. die aktuelle Ist-Geschwindigkeit oder die momentane Stromaufnahme (wird nicht von allen Zentralen angeboten). Demnaechst wird es bei einigen Zentralen (z.B. Zimo) auch moeglich sein, die aktuelle Position auf der Zentrale selbst anzuzeigen, die zukuenftigen Applilkationen sind noch weitgehend offen.
Ausserdem gibt es seit kurzer Zeit Weichen- Servo- und Schaltdecoder (Tams), die die Lage der Weichen an die Zentrale via RailCom zurueckmelden koennen.

Zukuenftig geplant sind z.B. Weichendecoder, die abhaengig von einem herannahenden Zug eine Weiche/Signal stellen (der Schienenbus wird auf das Nebengleis geleitet, der IC fahert auf dem Hauptgleis weiter) und diverse Spielwerterweiterungen wie z.B. die Funktion, dass eine Lok mit Betriebsstoffen versorgt werden muss oder dass ein Wagen mit virtuellen Guetern oder auch Personen be- und entladen werden kann. Auch wird es demnaechst moeglich sein, RailCom-Daten an den PC weiterzugeben, so dass z.B. die ermittelte Adresse in einem Gleisbereich auch im PC-Gleisbild angezeigt wird. Ferner sollen sich auch RailCom-Loks kuenftig an der Zentrale anmelden koennen.

Vorteile:
- Offener Standard mit Beteiligung mehrerer Hersteller, daher groesserer Funktionsumfang und hoehere Chancen zur Weiterentwicklung, ausserdem grosse Auswahl z.B. an Decodern.
- Sehr schnelle Datenuebertragung
- keine Betriebsbeeintraechtigung bei Stoerung (ist bei einem mfx-Decoder der mfx-Teil defekt kann die Lok mit einer mfx-Zentrale nicht mehr gefahren werden, bei einem defekten RailCom-Sender funktioniert die Lok weiterhin unter DCC)

Nachteile: ist nicht so einfach und selbstlaufend wie mfx

Zitat

---

Aktuell moeglich ist eine Positionsrueckmeldung auf einer dem zu ueberwachenden Gleisabschnitt zugeordneten Anzeige,

---

wobei man klar wissen muss dass es "nur mit dem lokdecoder" nicht getan ist .

Zitat

---

- Lokdecoder mit RailCom - Funktionalitaet
- Digitalzentrale mit DCC und RailCom
- RailCom - Detektoren (lokal und/oder global)

---

dass muss man sich bewust sein.

aber das ganze machen pc steuerungsprogramme doch schon "längst" (wenn ich nicht irre) . aber eben ohne spezielle decoder.
will man auch "etwas haben" von solchen rückmeldungen, benötigt man doch weiterhin genau solche programme immer noch. (ausser man hat eine zentrale mit integriertem gleisbild und integrierter steuerungssoftware z.b: à la commander ) sicherlich werden solche programme eventuell einfacher, ob sie dann aber auch günstiger werden?

der wirkliche vorteil erkenne ich also nicht wirklich. (nutzen den ich anderswie nicht auch schon habe.)
die frage sei also durchaus erlaubt, ob da nicht etwas entwickelt wird, von dem nur ganz wenige finanzstarke "grossbahner" auch einen wirklichen nutzen haben?
was bringt es z.b dem "durchschnistbahner" wenn er anstelle einer "soll"geschwindigkeitsanzeige eine "ist"geschwindigkleitsanzeige geliefert kriegt, wenn er doch beides selber "kalibrieren muss.


einen wirklichen vorteil erkenne ich ev darin (so denn die anlage mit den speziellen rückmeldedecodern ausgestattet ist), dass eine lok eventuell jederzeit überall aufgegleist werden kann.

ebenfalls nicht unerwähnt bleiben sollten auch eventuelle nachteile:
lässt sich mit den neuen railcom rückmeldedecoder auch ein liegengebliebener Wagen detektieren?
wie vehällt es sich mit reaktionszeiten bei kleinen anlagen mit vielen kleinen abschnitten und eventuell "schlechten" geleisen?
steigen die reinheitsanforderungen an die Stromübergänge nochmals?

Moin,

Zitat

---

wobei man klar wissen muss dass es "nur mit dem lokdecoder" nicht getan ist .

---

das versteht sich eigentlich von selbst, dass man ausser Lokdecoder noch weiteres Equipment benoetigt, das war aber auch gar nicht die Frage.

Zitat

---

aber das ganze machen pc steuerungsprogramme doch schon "längst" (wenn ich nicht irre)

---

Jein. Steuerungsprogramme werten aus, dass ein Gleisabschnitt belegt ist, mehr nicht. Dass dies die Lok X oder der Zug Y ist muss man dem Programm sagen. Das Programm "verfolgt" dann Lok X oder Zug Y und wenn man mit dem Spielen fertig ist wird der Zustand gespeichert. Wenn Du waehrend dem Betrieb Lok X gegen Lok Z tauschst bekommt das Programm davon nichts mit.
Mit RailCom erhaelt das Programm nicht nur die Information "Gleis 1 ist besetzt" sondern "Auf Gleis 1 steht Lok X".

Zitat

---

die frage sei also durchaus erlaubt, ob da nicht etwas entwickelt wird, von dem nur ganz wenige finanzstarke "grossbahner" auch einen wirklichen nutzen haben?

---

die Frage ist durchaus erlaubt und wurde schon oft genug beantwortet. Nimm einen Schattenbahnhof mit meinetwegen 5 Gleisen, den Du ohne weiteres nicht einsehen kannst. Mit RailCom weist Du sicher, welche Lok auf welchem Gleis steht. Das hat nichts mit finanzstarke Grossbahner zu tun, die Umruestung auf mfx ist teuerer.

Zitat

---

lässt sich mit den neuen railcom rückmeldedecoder auch ein liegengebliebener Wagen detektieren?

---

Nein, aktuell nicht. Wo soll das ein Nachteil sein und mit welchem System soll das gehen? Lediglich mit einer zusaetzlichen Kontaktstrecke und S88 haette man die absolute Sicherheit, entgleist der Wagen unguenstig hast Du auch da Pech gehabt. Ganz sicher faehrtst Du hier nur mit Achszaehlern.
Allerdings sind auch RailCom-Komponenten fuer Wagen in Planung, evtl. lassen sich kuenftig sehr wohl liegengebliebene Wagen detektieren.

Zitat

---

wie vehällt es sich mit reaktionszeiten bei kleinen anlagen mit vielen kleinen abschnitten und eventuell "schlechten" geleisen?

---

Zwischen dem Befahren eines lokalen RailCom-Abschnitts und der Anzeige vergeht etwa eine halbe Sekunde (Bauchgefuehl, ich habe es nicht nachgemessen). Was meinst Du mit schlechten Gleisen? Sind die Gleise dreckig gibt es keinen Kontakt und natuerlich auch keine Rueckmeldung, das gilt fuer alle Systeme.

Zitat

---

steigen die reinheitsanforderungen an die Stromübergänge nochmals?

---

Was bitte sind Reinheitsanforderungen? Wenn Du damit das Trennen von Boosterkreise meinst, diese haengen vom Boostertyp ab, nicht davon ob Du RailCom verwendest. Der B3 von Tams z.B. muss beidpolig getrennt werden, ob mit oder ohne RailCom.

hallo thommas

Zitat

---

versteht sich eigentlich von selbst, dass man ausser Lokdecoder noch weiteres Equipment benoetigt

---

ist mir klar, habs nur der vollständigkeitshalber geschrieben.

Zitat

---

Jein. Steuerungsprogramme werten.......

---

ist mir auch klar. und hier bietet die rückmeldung Railcom und hoffentlich auch mal mfx) den vorteil dass ich nur teilabschnitte (z.b. einen nichteinsehbaren sbh damit ausrüsten kann.) bei den "verfolgersoftware" braucht es schon etwas mehr um eine lok nicht aus den "augen zu verlieren"
diese mögliche teilbestückung ist echt vorteil. (den ich momentan auch nutzen könnte)

Zitat

---

Was meinst Du mit schlechten Gleisen?.................Was bitte sind Reinheitsanforderungen?

---

sory, war schlecht formuliert. ich meinte "veschmutzte" geleise.

Hallo nochmal,

Zitat

---

war schlecht formuliert. ich meinte "veschmutzte" geleise.

---

Hier gelten die selben "Reinheitsgebote" wie fuer Digital ueberhaupt, wobei es hier auf die Anzeige bzw. Detektor ankommt.
Beispiel dazu: Lok bleibt bei mir auf Schmutzfleck stehen, die Adresse wird noch eine Zeitlang (halbe Sekunde) angezeigt. Wenn also die Lok auf einer verschmutzten Stelle einen kleinen Flackerer macht, dann hat das auf RailCom keine Auswirkungen.

Zitat von Muenchner Kindl

---

Nachteile: ist nicht so einfach und selbstlaufend wie mfx

---

...und es fehlt eine Fahrzeug- und Funktionssymbolik wie bei mfx (die zwar im Ansatz gut, aber nicht konsequent umgesetzt worden ist, wie leider soviel bei Märklin...)

Peter

Hallo Zusammen,

erst mal entsculdigung, dass ich mich erst heute wieder melde. Hatte leider viel zu tun .
@ Michale: Danke für den Link, das hat mir weitergeholfen.
@ Münchner Kindel: Ich denke sowohl Railkom als auch MFX stecken beide noch in den Kinderschuhen. In der Zukunft bieten beide Systeme jedoch die Möglichkeit, dank echter Rückmeldung auch eine große Anlage ohne PC zu steuern. Die Verkabelung wird dann noch einfacher. Mann braucht dann auch keine S88 mehr. Nur noch Lokdecoder, Weichendekoder und Signaldekoder. Über einfache Kontaktpunkte auf der Stercke kann dann die Positionsbestimmung erfolgen. Somit können Bremsstrecken, Haltepunkte oder Blockabschnitte über die Zentrale eingerichtet und gesteuert werden.
Insgesammt dürfte damit eine Digitalanlage billiger werden. aber wie gesagt das ist noch Zukunftsmusik und dürfte wohl noch drei bis vier Jahre Dauern, bis all das möglich wird.
Gruß

Jan

Hallo Jan,

ich möchte Dich ja Deiner Illusion nicht berauben, aber ohne eine Mindestanzahl von Rückmeldern wird es auch in Zukunft nicht gehen.
Ob die jetzt S88-, RS-, Railcom- oder Sonstwie-Rückmelder heißen ist dabei egal.
Und eine begrenzte Anzahl virtueller Rückmelder als Ergänzung sind bei guten Softwarelösungen auch heute schon Stand der Technik.

Im Übrigen wird es wohl eher so sein, dass die mfx-Rückmeldung schon in Erwachsenenschuhen steckt. Jedenfalls wenn man den Aussagen von Märklin glauben schenken darf.
Mir erscheint es sogar so, dass das ortopädische Schuhe sind. Die Rückmeldung von mfx macht nicht gerade den zuverlässigsten Eindruck.
Ich würde mich nicht darauf verlassen, dass da noch was kommt.
Railcom muß dies auch erst noch beweisen, erscheint mir aber zur Zeit eher für die Zukunft gerüstet und ausbaubar.

Gruß
Knut

Hallo,

als es die Systems-Seite von Maerklin noch gab stand da in der FAQ drin, dass eine Positionsrueckmeldung mit mfx nicht vorgesehen ist und waehrend es auf der RailCom-Seite neben Positionsrueckmeldung auch bereits rueckmeldefaehige Weichen- und Schaltdecoder gibt (fuer mfx nicht mal angekuendigt) stellt sich schon die Frage, welche Technik da weiter ist.

Preislich kann man da kaum vergleichen. Da die Auswahl an Komponenten bei RailCom groesser ist kann man mehr kaufen und was man an der Anschaffung fuer den Booster spart gibt man fuer lokale Detektoren, die es ja in der mfx-Welt nicht gibt, aus.

Hallo münchner kindl

ich habe gerade etwas nach railcom weichenpositionsrückmeldern gegoogelt....

kannsd du mir etwas auf die sprünge helfen wo es so was gibt?

hallo jan:
ich möchte dir deine ilusionen auch nicht zerstören. aber bei lenz steht z.b geschrieben (sinngemäss) "diese Rückmeldungen sind vor allem bei pc-steuerungen sehr hilfreich. "

hallo m...k..

wo finde ich lokal und globaldetektoren?


entweder "verkmarkten" die ihre produkte wirklich schlecht. oder ?

Hi,

Zitat

---

kannsd du mir etwas auf die sprünge helfen wo es so was gibt?

---

lokale Detektoren: Lenz, Tams
globale Detektoren (in Booster integriert): Zimo, Lenz(?), ESU
Weichendecoder: Tams, ESU (ob die ESUs dem RailCom-Standard entsprechen weis ich nicht, die kamen bevor die Normen fuer Weichendecoder verabschiedet waren)

Hi,

hift das ?


Gruß Markus


Edith: da war der "Onkel" schneller und detaillierter...logisch..sein Steckenpferd

Hallo zusammen,

Zitat

---

globale Detektoren (in Booster integriert): Zimo, Lenz(?), ESU
Weichendecoder: Tams, ESU (ob die ESUs dem RailCom-Standard entsprechen weis ich nicht, die kamen bevor die Normen fuer Weichendecoder verabschiedet waren)

---

Bei Lenz steckt der RailCom bereits im Booster (und somit in auch in der Zentrale), seine gelesenen Daten - soweit der sie den überhaupt bereits liest - rückt er aber noch nicht raus (ans XPressNet).

Die "echte" Weichenrückmeldung gibt es bei Lenz schon seit den frühen 90ern, bereits integriert in den Weichendecoder allerdings über den RS (Rückmelde-) Bus (nicht RailCom) und weiter ins XpressNet an Handregler oder PC.

Ich sehe eine Entscheidung für RailCom (wie auch immer es sich entwickelt) derzeit eher noch als Investition in die Zukunft, als als sofort nutzbarer Vorteil. Dazu gehören dann RailCom-fähige Booster/Zentralen und zumindest RailCom-fähige Lokdecoder, möglichst mit updatebarer Software.

Am heissesten wird derzeit eine rückgemldete ID spekuliert, die einem entsprechenden Steuergerät die Zuordnung externer daten (Daten, Bilder, Internet, Betriebsanleitungen, ...) zur Loko ermöglichen würde. So ähnlich wie es die CS jetzt bereits macht.

Das meiste Konkrete gibt es wohl bei Zimo, wen wunderts .

Viele Grüße
Frank

Hallo Heinzi,

Zitat

---

ich möchte dir deine ilusionen auch nicht zerstören. aber bei lenz steht z.b geschrieben (sinngemäss) "diese Rückmeldungen sind vor allem bei pc-steuerungen sehr hilfreich. "

---

Mag sein, dass das bei Lenz so steht, aktuell gibt es noch keinen Weg in den PC fuer RailCom-Daten.

Auch ohne PC laesst sich das gut nutzen, so koennen die Anzeigemodule von Tams in ein analoges GBS integriert werden. Auch zum Auslesen von CVs waehrend des Betriebs benoetigt man keinen PC. Das Anmelden von Loks halte ich dagegen fuer Kaese, dass die neue DCC-Lok erstmal auf Adresse 3 hoert steht in deren Anleitung (irgenwann weis man das auch so) und das Aendern der Adresse ist keine Herausforderung (da ist die Suchfunktion dieses Forums komplizierter).

Ich habe es irgendwo schonmal angedeutet, im Raum stehen auch gewisse Spielerweiterungen. Stellt Euch mal vor, am Verladegleis ist eine "Datentankstelle" angeschlossen. Euere neue Leig-Einheit habt Ihr mit einem speziellen Decoder ausgestattet und wird auf das Ladegleis rangiert. Dort wird er virtuell mit Stueckgut beladen. Der Inhalt kann jederzeit abgefragt werden und so wird die Einheit zur naechsten Stueckgut-Verladestelle (ebenfalls mit Datentankstelle) gezogen. Ein bisschen entladen, ein wenig zuladen usw.
Gleiches auch mit Betriebsmitteln von Loks und Zuegen, bei Maerklin-mfx war das mal so angedacht, bei RailCom ist es ohne grossen Aufwand moeglich.

Vergleicht auch mal den technischen Aufwand, der bei mfx betrieben wird, nur um Loks anzumelden und als aktiv anzuzeigen mit dem, was bei RailCom notwendig ist.

Insgesamt sind die Moeglichkeiten von RailCom sehr offen und weitreichend und jeder teilnehmende Hersteller wird etwas zur Vielseitigkeit beitragen. Das ist fuer mich der groesste Vorteil

Zitat von Muenchner Kindl

---

Mag sein, dass das bei Lenz so steht, aktuell gibt es noch keinen Weg in den PC fuer RailCom-Daten.

---

Auch ESU ist da nicht wirklich besser. Die ECoS kann im Rahmen von Weichendekodern Railcom auswerten und zeigt dann manuelle Weichenveränderungen, aber was Loks angeht ist da momentan Ruhe im Karton. Die Weichenrückmeldung erfolgt unteranderem auch so, dass man das mit einem TAMs Baustein auswerten kann.

Zitat von Muenchner Kindl

---

Ich habe es irgendwo schonmal angedeutet, im Raum stehen auch gewisse Spielerweiterungen....

---

Neben diesen Ideen gibt es noch etwas anderes: Was hier der eine oder andere ja auch schon leidvoll erfahren hat, ist die Tatsache dass Befehle verzögert bei den Empfängern ankamen. Neben echten Software-Fehlern in den entsprechenden Hardwaren (IB läßt grüßen) gibt es auch irgendwann einfach Engpässe auf der Schiene. Zum Glück ist die Alzheimer-Phase bei vielen Dekodern überwunden, aber so schnell wie ein LAN ist die Schienenübertragung nicht. Hier bietet Railcom den Vorteil, dass Dekoder empfangene Kommandos bestätigen könnten - laut NMRA Definition. Wenn dieses Verhalten in der Zentrale berücksichtigt würde, reicht das einmalige Senden eines Kommandos an eine Lok man erhält die Bestätigung, dass der Dekoder es verstanden hat und gut - freie Bandbreite für das nächste Kommando. Dank der "Geheimhaltung" von mfx ist nicht bekannt ob dort so etwas geplant ist oder nicht.
Beim mfx wird zyklisch von der Zentrale nachgefragt, ob eine Lok noch auf der Anlage ist. Das passiert nicht all zu häufig (im Bereich von Sekunden bezogen auf eine Lokadresse). Langsam fahrende Rangierloks bzw. Epoche 1 / 2 kann man damit zur Not erfassen, beim ICE geht das schief. mfx ist mit dem bisher bekannten Protokoll nicht in der Lage Positionsbestimmung zu machen.
Knut

Hallo zusammen,

Zitat

---

Neben diesen Ideen gibt es noch etwas anderes: Was hier der eine oder andere ja auch schon leidvoll erfahren hat, ist die Tatsache dass Befehle verzögert bei den Empfängern ankamen. Neben echten Software-Fehlern in den entsprechenden Hardwaren (IB läßt grüßen) gibt es auch irgendwann einfach Engpässe auf der Schiene. Zum Glück ist die Alzheimer-Phase bei vielen Dekodern überwunden, aber so schnell wie ein LAN ist die Schienenübertragung nicht. Hier bietet Railcom den Vorteil, dass Dekoder empfangene Kommandos bestätigen könnten - laut NMRA Definition. Wenn dieses Verhalten in der Zentrale berücksichtigt würde, reicht das einmalige Senden eines Kommandos an eine Lok man erhält die Bestätigung, dass der Dekoder es verstanden hat und gut - freie Bandbreite für das nächste Kommando. Dank der "Geheimhaltung" von mfx ist nicht bekannt ob dort so etwas geplant ist oder nicht.

---

Das Versenden über DCC ist ziemlich sicher: Aus berufenem Mund dürfte die Empfangswahrscheinlichkeit im Betrieb bei korrektem DCC 90% (8ms Übetragungszeit) liegen. Bei geeingneter Versendestrategie bei 99% innerhalb von 50 ms. Entscheidend dabei sind aus eigener Erfahrung Qualität von DCC-Sendern (Zentralen) und Decodern. Zumindest bei unsere Vereinananlge sind bei Verwendung entsprechender Produkte keine DCC-bedingten relevante Verzögerungen festzustellen. Multi-Kulti
hat sich aber bereits genau in diesem Punkt eher negativ erwiesen. Spätestens wenn Loks unaufgefordert fahren, dann ist das Kind schon ziemlich tief in den Brunnen gefallen.

Was in der NMRA zur Nutzung des Rückkanals steht, ist nicht zwangsweise RailCom, sondern nur ein nicht verabschiededer "Entwurf". Ein Teil der erhofften RailCom-Funktionen benötigt weiterhin das periodische Senden der DCC-Befehlen, um die RailCom-Nachrichten in einen lokbezogenen Kontext zu senden. Von daher würde ich nicht grundsätzlich davon ausgehen, das die Übertragung zukünftig durch eine mögliche Quittierung gestoppt werden kann, so das obigen Qualitäten weiterhin die eigentliche Gewährleitungs der Übertragungsqualität bleiben dürfte.

Es ist leider so, das man den User in solche Überlegungen nicht wirklich mir einbezieht. Wenn die Hersteller wüssten ,was sie das verpassen .

Viele Grüße
Frank

HI,

auf die Gefahr hin das ich als miessmacher von DCC hingestellt werden.. Es sind derzeit nur 4 von unzähligen hersteller die railcom unterstützen und daher ist das system im gegensatz zu DCC weder offen noch transpartent noch genormt... die NMRA ist sich hier noch gar nicht sicher in welcher richtung es weitergeht weil der vorstoß nur von diesen firmen kommt...

daher ist derzeit die gefahr bei railcom, dass die NORM wenn sie denn jemals kommen wird ganz anders aussieht und die decoder die sich an die dann gültige norm halten werden nicht mit den geräten dieser 4 hersteller funktionieren werden und umgekehrt.

diese 4 hersteller forcieren im deutschen markt railcom weil hier märklin/ESU mit MFX etwas vorgelegt hat was in den anderen märkkten wo es DCC gibt nicht existiert.. einen innovativen ansatz... egal wie der nun funktioniert oder nicht...deshalb mussten diese firmen reagieren während die digitraxx und co kg hier noch keinen handlungsbedarf sehen.

niemand kann genau sagen was die NMRA als regulating body mit dem thema rückmeldung machen wird. hornby, digitraxx, Athearn, walthers und alle anderen hersteller von decodern werden diesen nicht existierenden standard nicht unterstützen und deren stückzahlen stellen die von den hiesigen firmen weit in den schatten...

DAHER kann man hier nicht von offen oder genormt oder gar von DCC sprechen.. man kann sehr wohl von einem guten ansatz einiger zusammenarbeitenden deutschen firmen sprechen und wenn man NUR deren geräte kauft derzeit hoffen, dass diese technik auch in zukunft funktionieren wird.

hoffen tun wir alle das die NMRA sowie damals wieder den deutschen vorstoss annimmt und railcom normt..ABER ....

Hallo macbee,

Zitat

---

diese 4 hersteller forcieren im deutschen markt railcom weil hier märklin/ESU mit MFX etwas vorgelegt hat was in den anderen märkkten wo es DCC gibt nicht existiert..

---

hier irrst Du: RailCom wird nicht "nachgelegt". Es existierte schon als mfx noch nicht erfunden war.

Gruß
Hans

Zitat

---

Es sind derzeit nur 4 von unzähligen hersteller die railcom unterstützen

---

das sind doppelt so viele wie die, die mfx unterstuetzen

Achja, wie war das?

Tams + Kuehn + Lenz + Zimo + ESU = 5 Hersteller

Zitat von macbee

---

HI,

auf die Gefahr hin das ich als miessmacher von DCC hingestellt werden.. Es sind derzeit nur 4 von unzähligen hersteller die railcom unterstützen und daher ist das system im gegensatz zu DCC weder offen noch transpartent noch genormt... die NMRA ist sich hier noch gar nicht sicher in welcher richtung es weitergeht weil der vorstoß nur von diesen firmen kommt...

---

hi,
ja genau 4 Firmen :
1. Lenz
2. Kühn
3. Zimo
4. Tams
5. ESU
6. Viessmann
und es haben weitere Firmen angekündigt, das zu unterstützen...

Zitat von macbee

---

daher ist derzeit die gefahr bei railcom, dass die NORM wenn sie denn jemals kommen wird ganz anders aussieht und die decoder die sich an die dann gültige norm halten werden nicht mit den geräten dieser 4 hersteller funktionieren werden und umgekehrt.

---

die Gefahr besteht allein deshalb nicht, weil Lenz das Patent hält. Etwas von Lenz nicht autorisiertes wird es deshalb NICHT geben.

Zitat von macbee

---

diese 4 hersteller forcieren im deutschen markt railcom weil hier märklin/ESU mit MFX etwas vorgelegt hat was in den anderen märkkten wo es DCC gibt nicht existiert.. einen innovativen ansatz... egal wie der nun funktioniert oder nicht...deshalb mussten diese firmen reagieren während die digitraxx und co kg hier noch keinen handlungsbedarf sehen.

---

RailCom ist lange vor mfx als Vorschlag der NMRA vorgelegt worden und in RP9.3.1 und 9.3.2 als Vorschlag niedergelegt worden. Wer nun von wem abgeschrieben hat und wer hier etwas vorgelegt hat, dürfte dann wohl nicht wirklich die Frage sein. Märklin-Gläubigkeit in allen Ehren, aber bei der Wahrheit muss man schon bleiben.

Zitat von macbee

---

niemand kann genau sagen was die NMRA als regulating body mit dem thema rückmeldung machen wird. hornby, digitraxx, Athearn, walthers und alle anderen hersteller von decodern werden diesen nicht existierenden standard nicht unterstützen und deren stückzahlen stellen die von den hiesigen firmen weit in den schatten...

---

Es ist die Frage, wie lange sich die Firmen einem Fortschritt entziehen können. Derzeit blockieren amerikanische Firmen aus finanzpolitischen Gründen die Weiterentwicklung. Das sehen wir hier in Europa dann etwas anders. Ein kluger Mann hat mal gesagt: Wer zu spät kommt, den bestraft das Leben....

Zitat von macbee

---

DAHER kann man hier nicht von offen oder genormt oder gar von DCC sprechen.. man kann sehr wohl von einem guten ansatz einiger zusammenarbeitenden deutschen firmen sprechen und wenn man NUR deren geräte kauft derzeit hoffen, dass diese technik auch in zukunft funktionieren wird.

---

das ist jetzt nicht ernst gemeint, oder?
RailCom ist und war eine Erweiterung des DCC-Standards und wurde so entworfen, dass alle bisherigen und zukünftigen DCC-Produkte damit problemlos laufen. Wer kein RailCom in seine Produkte implementiert, kann es halt nicht nutzen. Das ist alles.

Zitat von macbee

---

hoffen tun wir alle das die NMRA sowie damals wieder den deutschen vorstoss annimmt und railcom normt..ABER ....

---

... wenn nicht, ist es auch kein "Beinbruch", da alles auch ohne RailCom weiterhin problemlos funktioniert. Und wer mehr will, muss halt die richtigen Produkte kaufen. Alternativen zu den Amis gibt es hier in Europa genug.

Sorry für die etwas deutlichen Worte, aber so einen Unsinn kann ich nicht stehen lassen.
Gruß Kersten Tams
P.S. da ich nicht weiß, ob ich noch mal Zeit finde, ins Forum zu schauen, wünsche ich schon mal ein frohes Fest und guten Rutsch

@ macbee:

...Siehst Du, hab' ich Dir doch auch schon Mal geschrieben dass die Amis uns nicht mehr besonders jucken. Die fahren ja auch ohne Lastregelung - Tun wir das auch?!?!?!

Ich freue mich schon auf alles was kommt bezüglich RailCom. Erste (Tams-) Komponenten laufen bereits im Probebetrieb.

Achtung, auch hier bei der Wahrheit bleiben!
SoundTraxx, QSI und TCS haben laengst auf Regelung via BEMF umgestellt, und was DigiTrax bringt kann man IMHO immerhin als Versuch werten