[Muenchner Kindl]

Lutz (Mulliba),

Zitat

---

Sagen wir's mal so - Leute die meinen dass mfx entbehrlich sei schreiben das nur weil sie es halt zufällig nicht nutzen

---

Ich nutze mfx nicht zufällig nicht sondern ganz bewusst nicht. 2004 war ich noch davon begeistert, bis ich die CS1 live gesehen habe und was alles damit (nicht) möglich ist. Bis auf das Anmelden von Loks mit Namen und Funktionstastensymbolik, sowie einem erweiterten Adressraum bringt mfx dem Anwender aus meiner Sicht nicht viel. Meiner Meinung nach zu wenig, ich hatte damals u.a. erwartet, dass z.B. eine Ortsbestimmung möglich ist. Auch die Anzeige von Ist-Daten (aktuelle Stromaufnahme, Ist-Geschwindigkeit) stelle ich mir sinnvoll vor, bei mfx technisch sicher möglich aber halt bis heute nicht ausgeführt (und auch nicht angekündigt).

RailCom kann das alles, mittlerweile auch das Anmelden an der Zentrale. Warum es sich nicht durchsetzt liegt nicht daran, dass Trix nicht im Boot sitzt, sondern daran, weil es von den führenden Beteiligten schleifen gelassen wurde.
Dieses Schleifenlassen kann sich Märklin mit seiner grossen und treuen Stammkundschaft leisten aber nicht so eine kleine Arbeitsgruppe.

Allerdings, auch wenn die Mitglieder der Arbeitsgruppe nur ein paar Namen in einer langen Liste sind, dank der Unterstützung von RailCom durch ESU dürften die meisten Modellbahner RailCom-fähige Decoder in ihren Loks haben. Ich bin bekanntlich kein Fan von ESU aber ich fest überzeugt, dass es gut ist, dass die jetzt fest im Boot sind. Da dürfte die Abkehr von Zimo nichts machen und wer bisher, wie ich, sabbernd auf die tollen Innovationen aus Wien bezüglich RailCom gewartet hat, wird sich halt dafür von Zimo abkehren.

Zitat

---

Vom U.S. Markt wollen wir hier gar nicht erst reden (Bsp. Digitrax).

---

Was interessiert mich der US-Markt? Müssen wir den US-Markt fragen, ob wir innovativ sein dürfen? Hat Märklin zur Einführung von mfx den US-Markt befragt?

[RainerK]

Hallo zusammen,

weil es schon so lange her ist, wird oft vergessen, dass die sogenannte Norm des NMRA für DCC
aus dem damals noch proprietären System eines Herstellers (Lenz) erstellt wurde.
In Gießen gibt es auch aktuell Leute, die an RailCom etwas mehr tun, als Wunschvorstellungen zu formulieren.

Es grüßt RainerK

[Martin Lutz]

Hallo,

Märklin hat das mfx Sytsem einfach nie fertig entwickelt. Das nach so langer Zeit. Aber wenn man das sol liest, glaube ich mit Railcom und RailcomPlus wird es nicht anders gehen. Ich behaupte jetzt mal, dass das Railcom System in die Hose geht.

Bedenkt man, dass man heute schon eine Anlagensteuerung hinkriegt, mit derer man eine Funktionalität erreicht, die bei Railcom heute noch erst in Träumen existieren, dann erst Recht.

Solange Roco seine Decoderhersteller wechselt wie andere ihre Unterhosen, dann ist eine ganzheitliche RailCom Nutzung der ganzen Anlage sowieso unmöglich, wenn die Decoderhersteller nicht alle eine RailCom Lizenz tragen. Wenn sich Roco darüber nicht schert, wie es der Anschein hat, dann wird sowieso nichts daraus. (Gilt auch für andere Rollmaterialhersteller). Wie steht es eigentlich bei der Rsailcom Arbeitsgruppe um das Thema "Bindung von Rollmaterialhersteller an das RailCom System"? Hat man sich da mal Gedanken gemacht?

Wenn ich schon eine ganze Anlage mit Railcom steuern möchte (intelligente Positionsrückmeldung, Tachwelle usw), dann sollte ich doch mein ganzes Rollmaterial RailCom fähig haben.

[Muenchner Kindl]

Hallo Martin,

Zitat

---

Märklin hat das mfx Sytsem einfach nie fertig entwickelt. Das nach so langer Zeit. Aber wenn man das sol liest, glaube ich mit Railcom und RailcomPlus wird es nicht anders gehen.

---

Der entscheidende Unterschied ist, dass RailCom ein offener Standard ist. Das Potential, was der eine nicht nutzt kann der andere implementieren. Im Idealfall kann ich dann die Gerätschaften mischen und mir damit das zusammenstellen was ich brauche. Beim mfx-System bin auch darauf angewiesen was Märklin liefert. Wenn da keine Positionsmeldung möglich ist ist keine Positionsmeldung möglich.

Zitat

---

Bedenkt man, dass man heute schon eine Anlagensteuerung hinkriegt, mit derer man eine Funktionalität erreicht, die bei Railcom heute noch erst in Träumen existieren, dann erst Recht

---

Das liegt sicher darin begründet, dass hier ein immenser Vorlauf an Entwicklung und Erfahrung vorliegt. Seit wann gibt es TC, WDP und Co? Eine Anforderung an eine Software ist schneller umgesetzt als eine Hardwareentwicklung. Wer heute eine perfekt eingerichtete und parametrisierte Clubanlage betreibt wird kaum auf RailCom umstellen. Wer aber von vorne anfängt sollte sich zumindest mit der Thematik befassen.

Zitat

---

Wenn ich schon eine ganze Anlage mit Railcom steuern möchte (intelligente Positionsrückmeldung, Tachwelle usw), dann sollte ich doch mein ganzes Rollmaterial RailCom fähig haben.

---

Wer sein Rollmaterial ausschliesslich mit ESU (ausser Loksound), Lenz, Tams, Kühn (?) oder Zimo (naja, letzterer jetzt nicht mehr) ausgerüstet hat, hat eigentlich hier schon alle Voraussetzungen geschaffen.
Die Verbreitung von RailCom-fähigen Decodern dürfte nicht zu unterschätzen sein.

[kaeselok]

Hallo Kollegen,

welches Protokoll benutzt wird ist mir eigentlich wurscht solange die "oben drauf" laufenden Anwendungen und Funktionalitäten STABIL und PERFORMANT laufen!

Ich erinnere an MFX und die CS1 und die Dauer der Anmeldung. Insbesondere hinweisen möchte ich auf die seit Jahren grasierenden Anmeldeprobleme mit MFX mit Märklin und ESU Zentralen. Insbesondere möchte ich außerdem auf diverse Decoder-Instabilitäten hinweisen (alle Hersteller) die aufgrund Protokollsalat, Sapnnungshöhen und Voodoo einfach Loks "drauf los fahren" lässt. Von fehlenden MFX-Weichen/Signal/Rückmeldedecodern spreche ich gar nicht. Da hat der sehr verehrte Kollege Mumm gezeigt, was EIN Mensch im stillen Kämmerchen stabil entwickeln kann und die großen Hersteller nicht hinbekommen.

Mit der CS2 kam die schnelle Anmeldung von Loks. Nett.
Mit Railcom Plus kam die super-schnelle Anmeldung von Loks. Auch nett.

Mir ist's wie gesagt wurscht, solange bei mir keine Loks wild losfahren, solange ich MÄRKLIN Produkte auch auf NICHT-MÄRKLIN Zentralen vernünftig fahren kann!


Viele Grüße,

Kalle

[digilox1]

Nun, ich plazierte den Link zum "Offenen Brief" auf der Lenz-Seite bei der englischsprachigen ZIMO-Yahoo-Group.

Ein Kommentar ist eingetrudelt bislang; jene die ein Lizenzproblem im Zusammenhang mit der OEM-Praxis von Lenz, ESU und ZIMO vermuteten, werden wohl Recht behalten:

http://groups.yahoo.com/group/Zimo-DCC/message/2890

Gruss,
Manfred

[nobby]

Hy,

der Link funktioniert leider nicht, wenn man keinen Yahoo-Account hat

[Gast]

Hallo zsuammen,

Zitat von nobby

---

Hy,
der Link funktioniert leider nicht, wenn man keinen Yahoo-Account hat

---

Und selbst wenn, brauch man noch eine Zugrif auf den Zimo-DCC Account.

Um die Bedeutung von Lenz und ESU für RailCom und RailComPLus Erweiterung zu bewerten, sollte man sich ein wenig in der Entwicklungsgeschichte von DCC und mfx auskennen:

DCC wurde von Lenz als Auftragsarbeit für Märklin in den 80ern entwickelt, und als Märklin-Digital auf allem Märklin Spuren inklusive H0 in Nürnberg vorgeführt . Das war meineswissens die "Erfindung" der Mikroprozessozer (also per Software) gesteuerten Modellbahn (alledings weiss ich nicht genau, ab wann Zimo den Mikroprozessor verwendete), die Eigenschaft, die DCC von auch damals schon exisitierenden Mitbewerbern unterschied. Das Ur-DCC verblieb bei Märklin in Spur 1 und in Arnold (damals Märklin). Für Märklin-H0 schien die damals schon auf zu dieser Zeit relativ teuren Mikrokontrollern (Interview Video waren im alten Stummi verlinkt) implementierte DCC zu teuer. So wurde MM (customized Motorola Logik ) als Budget-Lösung verwendet, bei deren Einführung auch Lenz beteiligt war.

"DCC" wurde danach von Lenz in der NMRA als Standard genormt. Jeder kann sich dort für eine Handvoll
Dollar eine NMRA Nummer kommen lassen. Weswegen es zur Konformitäts-Sicherung später ein NMRA DCC Konformitäts-Logo (Pflaume) gab, das aber nur sehr wenige europäische Hersteller u.A. Lenz, Zimo, ESU für sich beanspruchen konnten.

RailCom war ein weitere Entwicklung von Lenz im Anfang des aktuellen Jahrtausends. Erst mal ging es nur um die DCC konformer Übertragung von Daten in Gegenrichtung, nicht um Feature-Zusagen an Endkunden. Patente sind auf Patentstorm.US öffentlicht einsehbar. Es konkurrierte wohl bei der NMRA mit Digitrax-Transponding, ein Lösung die Belegtmeldung und Fahrzeugkennung (Richtung bin ich nicht sicher) in einem Rückmelder vereinte.

Ca 20 Jahre nachdem dem Märklin DCC von der H0-Bettkante gestossen hatte, gingen sie dann doch auch zu Mikrokontroller gesteuerten Digital-Bahn über. Diesmal beuaftragten sie wohl ESU.

Auch diese Zusammenarbeit währte nicht allzu lange, die CS2 war die Ablösung der bis dahin wohl auf ESU-Entwicklungen basierenden Geräten, allerdings immer noch mit dem mfx-Protokoll. mfx und Anmeldung tragen typische Merkmale eher neuzeitlicher Informatik (ESU Patentantrag wahr zeitweise öffentlich einsehbar).

So hat Märklin es geschickt verstanden, diverse Techniken unter und im Sinne seinen eigenen Kunden und Systeme zu nutzen.

Zimo hatte ursprünglich ein eigenes sogar bidirektional erweitertes Digital-Format, hat aber zunehmend DCC wie RailCom verwendet und DCC/RailCom-Geräte auch vorbildlich weiterentwickelt.

Was bei RailComPLus IMHO gerade passiert, ist das Lenz und ESU ihre Technologien zusammenwerfen, úm ein mehrwertiges leichteres DCC zu schaffen, um erstmal die meineserachtens zumindest für zukünftige Mobahner wichtigste bidirektionale Errungenschaft , die Anmeldung , bei DCC nachzurüsten. Unter der Decke wird dabei gleichzeitig die Sicherung der Hinrichtung betrieben, ein Massnahme die im Gleis die nahezu endlose redundanten Wiederholungen von bereits verstandene Befehlen erübrigt (NMRA konformes DCC muss Befehle mit 95% Wahrscheinlichkeit beim erstenmal verstehen, Wiederholungen sind datentechnisch vorwiegend "Füllsel", dienen nur dem Energietranssport), und so neue DCC-Bandbreite freisetzt.

Das aktuelle Statement auf der Lenz-Seite ist deswegen sehr wichtig für Tams und Kühn. Bisher war die Existenz der Arbeitsgruppe RailCom für mich zwar in Foren erwähnt, aber die Ergebnisse oder öffentlcihe Auftritte waren für mich nicht auszumachen. Im Gegenteil, die Ankündigung von RailCom-Abschnittsmeldern mit und ohne Belegtmeldung, von RailCom(Plus)-Decodern mit und ohne Anmeldung erweckte doch eher den Eindruck, als ginge es nur darum , das Papperl RailCom für sich zu vereinnahmen, ohne das wirkliche Mehrwerte für den Mobahner dabei entstehen.

Ich glaube erst die Anmeldung UND entsprechende Steuergeräte wird den normalen Anwender von RailCom überzeugen, und auch erst dann, wenn bereits mit dem Startset zu erleben. Hat er sofort die Lok und Funktionen im Display und kann vor allem auch sofort losfahren ohne sich um Adressen und Funktionmapping etc zu kümmern, erst dann wird er einen überzeugenden Mehrwert durch RailCom verspüren. Nicht auszudeneken, wie er an die Decke hüpft, wenn auch noch die bereits beim Anschieben die Tachonadel sich erhöbe .

Der offenen Brief der Arbeitsgruppe RailCom war also längst überfällig, den Durchbruch kann RailCom aber erst mit entsrechenden Produkten erzielen, die vor allem auch die Handhabung der digitalen MoBa vereinfachen. Loyalitätskäufe sind bei RailCom eher weniger zu erwarten.

Grüsse Frank

[Rainer48]

Zitat von Muenchner Kindl

---

Der entscheidende Unterschied ist, dass RailCom ein offener Standard ist.

---

Hallo,

ist RailCom das wirklich noch, ich lese da in dem offenen Brief etwas ganz anderes. Dort steht z.B.

Bei ihrem letzten Treffen am 31. Mai in Gießen hat die Arbeitsgruppe RailCom die Spezifikation für den Rückmeldestandard RailCom® verabschiedet.
Heisst für mich, dass die bisherigen Standards demnächst ungültig werden.

Interessierte Firmen können sich ab Ende Juni an den Lizenzinhaber (Lenz Elektronik GmbH) wenden, um die Spezifikation zu erhalten
Sollte ein offener Standard nicht für jedermann frei zugänglich veröffentlicht werden?

Die Lizenz wird kostenfrei vergeben und setzt die vollständige Einhaltung der Spezifikation voraus.
Wer überprüft und überwacht die Einhaltung der Spezifikation, wieviel kostet diese Überprüfung und wie lange dauert sie? Welche Forderungen muss der Lizenznehmer sonst noch erfüllen, z.B. Dritten Einsicht in die eigenen Entwicklungs- oder Fertigungsunterlagen gewähren?

Aus meiner Sicht ist da überhaupt noch kein offener Standard erkennbar, eher das Gegenteil.

[Muenchner Kindl]

Hallo,

Zitat

---

Aus meiner Sicht ist da überhaupt noch kein offener Standard erkennbar, eher das Gegenteil.

---

Mit "Offen" meinte ich, dass man unter Einhaltung der Spezifikationen bauen und anbieten kann was man will. Der eine baut einen Weichendecoder mit Lagerückmeldung, der andere eine Tachowelle. Alles unter der Einhaltung der Standards, die man ja bekommt.
Bau doch mal einen mfx-Weichendecoder und frage Märklin nach den Spezifikationen...

[RainerK]

Hallo Frank,

Zitat von Gast_001

---

...Nicht auszudeneken, wie er an die Decke hüpft, wenn auch noch die bereits beim Anschieben die Tachonadel sich erhöbe ...

---

Was wohl nie passieren wird, denn wieviel % der Lokantriebe drehen sich, wenn man die Lok schiebt?
Wer dann glaubt, dass nur deswegen die Hersteller auch noch die Antriebsmechanik ändern, darf sich zu Recht als Traumtänzer bezeichnen lassen.

Oder habe ich die Ironie-Tags übersehen, Frank?

Es grüßt RainerK

[BBII]

Zitat von Muenchner Kindl

---

Bau doch mal einen mfx-Weichendecoder und frage Märklin nach den Spezifikationen...

---

Hallo, dann würde ich doch mal vorschlagen, einen BiDi-Dekoder oder BiDi-Rückmelder zu bauen und Lenz/ESU nach den Specs zu fragen ...

Auch ich sehe bis dato keinen offenen Standard und kann mich den Bedenken von Rainer nur anschließen. Darüber hinaus steht m.E. auch das railcom-Patent auf recht wackeligen Füßen, es gibt nachweisbare 'Prior Art', also entsprechende ältere Vorveröffentlichungen, wo genau das Prinzip Halbduplex (Abschalten des Boosters und Rückübertragung mittels Stromschleife in der Abschaltzeit) beschrieben ist.

Hoffen wir also alle darauf, dass sich die Leute auf eine Technik einigen und dass diese vom Protokoll her offen ist und (ganz wichtig) einheitlich implementiert wird! Ein Wildwuchs nutzt keinem, im Gegenteil: nur wenn die Lok von Roco/Piko/wem-auch-immer auf meiner mit railcom ausgerüsteten Anlage nutzen kann, dann kaufe ich sowohl Lok als auch entsprechende Anlagenausrüstung. Wenn das aber nur geht, wenn der Donnerstag auf den 13. des Monats fällt, dann kauft das keiner.

Servus Wolfgang
http://www.opendcc.de, http://www.bidib.org

[Heinzi]

Hallo Thomas

Zitat

---

Warum es sich nicht durchsetzt liegt nicht daran, dass Trix nicht im Boot sitzt, sondern daran, weil es von den führenden Beteiligten schleifen gelassen wurde.

---

Das ist ein bischen salop gesagt.
Für das Schleifenlassen sehe ich hauptsächlich einen Grund:
- Die Wirtschaftlichkeit. Wäre damit Geld zu verdienen, würden die Hersteller mehr daran setzen Railcom auf die Geleise zu bringen.

Dass mit ESU an Bord nun plötzlich so schnell die Anmeldung einer Lok daher kommt (notabene etwas was ja hier vielfach verschriehen wird) sollte nach dem Bruch zwischen Märklin und ESU zu denken geben.
Für die DCCler bleibt zu hoffen, dass es nicht dabei bleibt. (Wir werden sehen)

Hallo .... weisichweralles
Zum Thema mfx Weichendecoder.
Im Ernst, was soll das ganze Theater?
An den aktuellen mfx (M4) Zentralen muss ich auch einem mfx Weichdendecoder mitteilen, ob er eine normale Weiche oder eine Bogenweiche ist. Ich muss ihm mitteilen ob er eine Links- oder Rechtsweiche, oder gar eine Doppelkreuzweiche ist. Ich muss ihn ebenfalls einem Register zuordnen und muss ihn ebenfalls im Gleisbild manuel einarbeiten. Da kann ich ihm dann wirklich auch noch gleich eine vom System (Dipschalter) vorgegebene Adresse zuteilen. Eine Rückmeldung, vor allem wenn es dann noch eine Pseuderückmeldung ist) benötige ich nicht.......meine C-Gleis-Weichenantriebe schalten absolut zuverlässig.
Also dafür mehr Geld auszugeben, bin ich wirklich nicht bereit.

[Peter Müller]

Zitat von Gast_001

---

... den Durchbruch kann RailCom aber erst mit entsrechenden Produkten erzielen, die vor allem auch die Handhabung der digitalen MoBa vereinfachen.

---

Und nicht vergessen, das Hobby darf nicht (noch) teurer werden. Bei RailCom bin ich mir nicht so sicher, ob es nicht manchmal dazu dienen soll, höhere Preise nehmen zu können. Ich möchte gerne demnächst RailCom testen, aber das wäre ein Hinderungsgrund.

[digilox1]

Zitat

---

Dass mit ESU an Bord nun plötzlich so schnell die Anmeldung einer Lok daher kommt (notabene etwas was ja hier vielfach verschriehen wird) sollte nach dem Bruch zwischen Märklin und ESU zu denken geben.

---

Wieso? Meinst Du, Märklin habe ESU dafür bezahlt, dass die Lok-Anmeldung in DCC *nicht* kommt?

Zitat

---

Zum Thema mfx Weichendecoder.
Im Ernst, was soll das ganze Theater?
An den aktuellen mfx (M4) Zentralen muss ich auch einem mfx Weichdendecoder mitteilen, ob er eine normale Weiche oder eine Bogenweiche ist. Ich muss ihm mitteilen ob er eine Links- oder Rechtsweiche, oder gar eine Doppelkreuzweiche ist. Ich muss ihn ebenfalls einem Register zuordnen und muss ihn ebenfalls im Gleisbild manuel einarbeiten. Da kann ich ihm dann wirklich auch noch gleich eine vom System (Dipschalter) vorgegebene Adresse zuteilen.

---

Dein mfx-Weichendecoder ist der Lokdecoder des DCC-lers: Er ist nicht in der Lok eingebaut, sondern ein Aftermarket-Teil - so will es der DCC-ler haben, von wegen freier Wahl und so! Er muss ihn also selber konfigurieren, d.h. die Funktionen mappen und die Icons (so vorhanden) dazu auswählen und setzen, da kann er auch die Adresse selber zuteilen.

Enter ESU and Lenz mit der Selbstanmeldung bei DCC, wonach keiner gefragt hat.
Jetzt ist die vermeintliche "Killerapplikation" da, aber mindestens der grösste bisherige OEM-Kunde (Roco) und einige kleine sind weg. Denn die ganze Erleichterung der Selbstanmeldung - wenn es denn eine ist - kommt eigentlich nur bei werksseitig mit Decodern ausgerüsteten Loks zur Geltung, sonst ist es eine zusätzliche Belastung - siehe Weiche.

Der DCC-ler will die freie Wahl der Decoder, nicht nur der Icons in den bereits ab Werk mit Decodern ausgerüsteten Loks.

Nun, sowohl ESU als auch Lenz sind als Lokimporteure aufgetreten mit ihrer jeweils eigenen Elektronik in den Kisten. Aber sich den OEM-Markt durch Zimo vom Tisch ziehen zu lassen, weil man glaubt, mit der Selbstanmeldung endlich die Applikation gefunden zu haben, mittels der man die eigenen OEM-Produkte den DCC-lern auf die Augen drücken kann?

Wenn RailCom patentrechtlich auf wackligen Füssen steht, wie BB II/Wolfgang schreibt, kann man eigentlich
zuversichtlich sein, dass aus dem Kind doch noch was wird.

Gruss,
Manfred

[digilox1]

Zitat

---

Und nicht vergessen, das Hobby darf nicht (noch) teurer werden. Bei RailCom bin ich mir nicht so sicher, ob es nicht manchmal dazu dienen soll, höhere Preise nehmen zu können. Ich möchte gerne demnächst RailCom testen, aber das wäre ein Hinderungsgrund.

---

Bei mfx dagegen bist Du Dir gaaanz sicher, dass es nicht dazu dienen kann, höhere Preise nehmen zu können!?

Manfred

[Rainer Lüssi]

Hallo zusammen

Mfx ist ganz offensichtlich zu teuer in der Herstellung.
Wie sonst lässt sich erklären, dass M* die Einsteiger-Loks und Startpackungen ohne mfx ausrüstet (lange Zeit ausgerüstet hat).
Obwohl genau für diese Zielgruppe (Kinder, Einsteiger) mfx als Plug-and-Play Lösung gedacht war.

M* hätte gut daran getan, einen Schnitt zu machen und ab einem gewissen Zeitpunkt alle Loks nur noch mit mfx auszurüsten.
Aber dieser Mischmasch bringts wohl nicht wirklich.

Gruss
Rainer

[digilox1]

Zitat

---

Mfx ist ganz offensichtlich zu teuer in der Herstellung.
Wie sonst lässt sich erklären, dass M* die Einsteiger-Loks und Startpackungen ohne mfx ausrüstet (lange Zeit ausgerüstet hat).
Obwohl genau für diese Zielgruppe (Kinder, Einsteiger) mfx als Plug-and-Play Lösung gedacht war.

---

In Märklins neuer Produktlinie "my world" habe ich keine einzige Lok mit mfx gefunden, in den anderen Starterpackungen haben nur die beiden "Megapackungen" Loks mit mfx-Decoder sowie die Lok der Spur 1-Starterpackung. Vielleicht ist neben den Kosten auch die Zuverlässigkeit ein Knackpunkt?

Gruss,
Manfred

[Rainer48]

Hallo,

Zitat von Gast_001

---

Was bei RailComPLus IMHO gerade passiert, ist das Lenz und ESU ihre Technologien zusammenwerfen, úm ein mehrwertiges leichteres DCC zu schaffen

---

Elegant formuliert. Ich vermute allerdings, dass hier gerade die Einführung eines eigenen, von der NMRA weitgehend unabhängigen Standards für den deutschsprachigen Raum betrieben wird. Sucht man auf den Webseiten der NMRA nach dem Begriff „Railcom“, so findet man dort nur Protokolle aus dem letzten Jahrzehnt. Auch die technische Beschreibung des Rückmeldekanals in der NMRA RP 9.2.3 ist vom April 2005 und hat den Status eines Entwurfs nie verlassen.

Und was die bisherige Lizenzierungspraxis für DCC durch die NMRA betrifft, ich sehe da auf der offiziellen Liste der Konformitätsbestätigungen über all die Jahre hinweg als deutsche Hersteller nur die Firma Lenz Elektronik GmbH und in 2003 ESU mit dem Lokpilot. Im Umkehrschluss heißt das für mich, daß die Fa. Lenz auch schon bisher die Lizenzen an die deutschen Lizenznehmer direkt vergeben hat.

Daher eine vielleicht provozierende Frage: Ist es vielleicht so, dass alte DCC-Patente am Auslaufen sind und man jetzt dringend ein neues Alleinstellungsmerkmal benötigt, um Wettbewerber auf Distanz zu halten? Alles natürlich nur wegen des „Zusatznutzen für den Kunden“.

Und warum finde ich den gestrigen Beitrag von D zum Thema Lizenzierungspraxis heute plötzlich nicht mehr?

[Gast]

Zitat von Rainer48

---

Hallo,

Zitat von Gast_001

---

Was bei RailComPLus IMHO gerade passiert, ist das Lenz und ESU ihre Technologien zusammenwerfen, úm ein mehrwertiges leichteres DCC zu schaffen

---

Elegant formuliert. Ich vermute allerdings, dass hier gerade die Einführung eines eigenen, von der NMRA weitgehend unabhängigen Standards für den deutschsprachigen Raum betrieben wird. Sucht man auf den Webseiten der NMRA nach dem Begriff „Railcom“, so findet man dort nur Protokolle aus dem letzten Jahrzehnt.

---

Wenn Du genau wisen möchtest, was der in Amerika geschützte Teil von RailCom ist, musst Du bei patentstorm.us nach Lenz + Giessen suchen.

Zitat

---

Auch die technische Beschreibung des Rückmeldekanals in der NMRA RP 9.2.3 ist vom April 2005 und hat den Status eines Entwurfs nie verlassen.

---

Sehe ich auch so., bei den Nutzungsüberlegungen fing der Knatsch an. Jeder hatte wohl ne eigen Vorstellung welches Feature das wichtigste sei. Jedenfalls im ersten Nutzungs-Entwurf war gesicherte Hinübertragung und Geschwindigkeitsrückmeldung (kein Tachowelle )schon drin. Ich nehme an, der stammte auch von Lenz.

Zitat

---

Und was die bisherige Lizenzierungspraxis für DCC durch die NMRA betrifft, ich sehe da auf der offiziellen Liste der Konformitätsbestätigungen über all die Jahre hinweg als deutsche Hersteller nur die Firma Lenz Elektronik GmbH und in 2003 ESU mit dem Lokpilot. Im Umkehrschluss heißt das für mich, daß die Fa. Lenz auch schon bisher die Lizenzen an die deutschen Lizenznehmer direkt vergeben hat.

---

Tja, Multi-Kulties und einige gewagte sonstige Schaltkreise hätten den Konformitäts-Test sicher nicht bestanden, also sind die DCC-Panscher erst gar nicht angetreten. Für DCC konforme reichte es wohl aus, bestimmte Decoder-Generationen , auch als OEM-Decoder-Lok testen zu lassen. Und auch die Testkapazitäten waren wohl Mangelware. Das Zertifizierungsverfahren war immer ein heiss diskutierte Punkt in den NMRA-Protokollen, man kann sich leicht vorstellen, das das viel Aufwand machte. "NMRA-Konform" ist mittlerweile anscheindend auch zum Werbe-Spruch verkommen . Seit ers praktisch keine Konformitätsprüfung mehr gibt, taucht er immer öfter auf. Die NMRA hat für uns praktisch ihre informative wie DCC schützende Rolle leider verloren.

Zitat

---

Daher eine vielleicht provozierende Frage: Ist es vielleicht so, dass alte DCC-Patente am Auslaufen sind und man jetzt dringend ein neues Alleinstellungsmerkmal benötigt, um Wettbewerber auf Distanz zu halten? Alles natürlich nur wegen des „Zusatznutzen für den Kunden“.

---

Also, DCC wurde von Lenz an die ganze Welt kostenlos verteilt, da wurde meineswissens nie über Lizensen oder Patente diskutiert. Nachdem es sich so entwicklete, das RailCom mit dem NMRA-Instrument nicht mehr zu schützen war, weil man sich wohl innerhalb der NMRA auch nciht mehr grün war, beschloss Lenz wohl RailCom selbst zu schützen. So wie Märklin sich wenigstens den Namen "mfx" sicherte, sicherte Lenz sich wohl die Namen "RailCom". "RailComPlus" scheint ein von ESU und Lenz geschützer Name zu sein. Diese sind wohl auch juristisch lernfähig.

Auch laut "offener Brief" geht es aber nicht ums Lizenzeintreiberei, sondern um die Erhaltung eines Standards, bitte bei Interesse genau lesen. Der geschützte Name ist dazu imho ein wichtiges Instrument.

Zitat

---

Und warum finde ich den gestrigen Beitrag von D zum Thema Lizenzierungspraxis heute plötzlich nicht mehr?

---

Sorry, war zu vorlaut. Habe ich selbst gelöscht, weil ich hier kein Tachowelle Diskussion führen wollte, und mir meine Spekulationen zu "Roco+Zimo vermarkten RailCom oder auch nicht" im nachhinein zu spekulativ erschienen.

Grüsse Frank

[digilox1]

Zitat

---

Ich vermute allerdings, dass hier gerade die Einführung eines eigenen, von der NMRA weitgehend unabhängigen Standards für den deutschsprachigen Raum betrieben wird.

---

Schon möglich, aber TCS, ein amerikanischer Decoder-Hersteller, wirbt bei seinen neuesten Produktlinien auch mit RailCom:

[url]http://www.tcsdcc.com/public_html/Customer_Content/Customer_Info/Whats_New/What's_New.htm[/url]

Bei den Konformitätsbestätigungen ist ein Zimo aus dem letzten Jahrtausend aufgeführt.

Gruss,
Manfred

[huebsch]

Nachdem ich einige PMs zu diesem Thread bekommen habe will ich die Antwort hier gleich an alle geben. Für jene die mich noch nicht kennen ich bin Modellbahner mit Begeisterung und betreibe in Wien einen Elektronikwerkstatt. Es besteht ein Naheverhältnis zu ZIMO, ich bin aber kein ZIMO Angestellter.

Ob die Vertragskündigung von Lenz an ZIMO so wie es dargestellt wird überhaupt möglich ist, darum muß sich Dr. Ziegler kümmern. Jetzt im Juni 2011 hängt das einmal in der Luft. Es wird dazu sicher bald einen Newsletter von ZIMO geben.

Ich persönlich habe die Streiterei nämlich ganz anders in Erinnerung als es in der Stellungnahme auf der Lenz-Seite dargestellt wird. Dr. Ziegler hat nicht die existierenden RailCom Drafts in Frage gestellt. Viel mehr geht es darum. daß er sich nicht einem Diktat von ESU unterwerfen will. Weiters meint er, daß die esxistierenden Mängel in RailCom behoben werden müssen. Es hat abgelehnt sich an die in Zukunft erscheinenden Specs zu halten auf deren Entwicklung er keinen Einfluß haben soll. Das neue Konzept soll so aussehen: ESU entwicklet unter Duldung von Lenz neue Prozederes. Wenn's fertig ist müssen es alle anderen RailCom Firmen so fressen oder eben sein lassen. ESU hat damit 1-2 Jahre Entwicklungsvorsprung. Wie das läuft hat man bei der Vorstellung von RailCom Plus gesehen. Soweit ich weiß hat da immer noch niemand in der RailCom Gruppe die Specs erhalten, oder eben erst vor kurzem. Tams und Kühn ist für ESU keine Konkurrenz, ich glaube auch nicht daß die viel von RailCom Plus implementieren werden (können). Lenz selbst hat auch kein Interesse mehr, es gibt seit 10 Jahren nix wirklich Neues im Digitalbereich, sondern konzentriert sich auf Spur 0

Ohne Zweifel gibt es wirtschaftliche Konflikte. ESU war bis 2009 unumschränkter Dominator im Decoderbereich. Nachdem ESU Märklin, Roco, Fleischmann, Haag und einige weitere OEM Kunden verloren hat, vor allem an ZIMO, hat sich in der Branche viel bewegt. Das sollte man wissen wenn man die Reaktionen von ZIMO, ESU und Lenz in der gegenständlichen Streiterei liest.

Für den Modellbahner ist eine Dominanz eines Unternehmens gut und schlecht gleichzeitig. Wenns nur einen gibt, entstehen kaum Kompatibilitätsprobleme. Das Preisniveau wird sich vermutlich nicht gerade erfreulich entwickeln. Ich erinnere nur an die Situation bei H0 Soundkombidecodern. Wo waren dei Preise vor dem Eintritt von ZIMO und Tran in den Markt? Oder Features: 22kHz Sampling Rate hätten wir vermutlich noch lange nicht gäbe es nicht den Konkurrenzdruck. ZIMO widerum hätt' wohl kaum das Funktionmapping verbessert wenn es nicht ESU gäbe wo es äußerst kompliziert aber wesentlich flexibler geht. Man sieht ein Monopol ist üblicherweise eher schlecht für den Endkudnen.
Ja ich weiß es gibt auch weitere Decoderhersteller, diese schaffen aber kein Produktionsvolumen um die Fahrzeughersteller beliefern zu können (Ausnahme Uhlenbrock). Weiters sind Soundkombidekoder wohl keine einfache Sache, da sind die Namen auch dünn gesät. Die Sounddecoder werden aber immer stärker von den Modellbahnern gefordert.

Zu den technischen Basics: es fällt auf daß die RailCom Lücke bereits früher mit gleicher Funktion im Selektrix benutzt wurde. Die Rückmelderei bei Digitrax (Transponding) und ZIMOs Zugnummernimpulse wurden beim RailCom Patent nicht genannt, obwohl sogar in der selben Branche. Das ABC (asymmetrisches DCC) war anfang der 90'er von Urs Mayer vorgestellt worden und wurde bewußt nicht patentgeschützt worden, das ABC Patent von Urs Mayer erwähnt Lenz nicht einmal. Ebenso hat Dr. Ziegler keinen Schutz beim HLU Verfahren gemacht. Was mich wundert, ist weshalb niemand diese Umstände die meiner Meinung das RailCom Patent wohl nicht zulassen, bei der Anmeldung des Patents gemeldet hat. Ob der von Lenz beanspruchte Patentschutz überhaupt hält, sollte es zu einer weiteren Eskalation kommen, ist fraglich. Meiner Meinung nach wurde bei der Erteilung sehr oberflächlich geprüft und prior Art, die immer anzugeben ist bei einer Anmeldung, einfach verschwiegen.
Interessant ist auch daß ZIMO seit 2002 in allen Decodern RailCom drauf hat und auch mit dem MX31ZL das erste Produkt am Markt hatte das RailCom nutzte. Es gab da auch Erweiterungen wie km/h Meldung, Weg, Motorstrom, RoutingCodes, virtuelle Kraftstoffreserven und vieles mehr. Experimentell war auch schon die Lokanmeldung implementiert die aber von der RailCom Gruppe nicht aufgenommen wurde. Lenz hat außer der roten 7-Segmet Anzeige nicht viel mehr geschafft. Leider hat sich ZIMO dann etwas zu viel vorgenommen die neuen Zentralen und ähnliches lassen immer noch auf sich warten. Einzig ESU hat es geschafft RailCom auch nutzbar zu machen. Obwohl ESU lange Zeit aus der 4'er Gruppe ausgeschlossen war. Interessanterweise hat Lenz das bei ESU nicht beanstandet aber allen anderen wehement die Nutzung von RailCom untersagt! Inzwischen weiß man warum das so war. Weshalb sich das die anderen RailCom Mitglieder gefallen lassen wundert mich sehr.
Rückblickend interessant ist jetzt auch die Entwicklung um die Märklin/ESU MTX Schnittstelle heutzutage MTC. Auf Verbesserungsvorschläge gleich bei der Vorstellung beim DCC Working Group Meeting bei Märklin wurde damals beleidigt reagiert. Dadurch wurde eine zweite Norm PluX nötig. Das hätte man sich ersparen können. Es ging im Wesentlichen um eine geschiktere Anordnung der Signale um schmälere Stecker für kleine H0, TT und N Modelle zu ermöglichen. Ich erkenne hier einige Parallelen zur jetzigen RailCom Situation.

Weiter oben habe ich Probleme mit RailCom erwähnt. Konkret versickert das Signal auf jeder mäßig großen H0 Modellbahnanlage die Fahrzeuge am Gleis hat. Viele Wagen sind mit Glühlämpchen beleuchtet. Gibts davon viele wird der Rückmeldestrom weggefressen. Auch RC Entstörglider in Loks dämpfen das Signal. Auf Gartenbahnen ist auch schnell nach 20-30 Metern Schiene aus mit dem Lesen. Dieses Problem in RailCom zu beheben wurde aber verweigert. Es ist einer der Gründe die zur Eskalation und dem Bruch geführt haben.

Wie kann es weiter gehen? Ich befürchte daß die nötigen Ergänzungen in RailCom wegen Sturheit der Beteiligten nicht implementiert werden. Daher wird es wohl ein weiteres Verfahren zur Rückmeldung geben das dann allen Gerüchten nach PublicDomain sein wird. Sollte es sich so entwickeln wird es zwei parallel existierende Verfahren die hoffentlich gleichzeitig am Gleis sein können geben. Das ist möglicherweise etwas unpraktisch nur bisher war das ja auch schon öfters der Fall siehe MTC/PluX. Aus Erfahrung weiß man daß nicht immer das bessere der billigere solche "Wettkämpfe" gewinnt - die Entscheidungen werden ganz woanders getroffen. Es liegt wohl in der Hand der großen Fahrzeughersteller bzw Kunden. Für die Großen Hersteller ist eine Betriebssicherheit und "Idiotensichereiht" wichtig und muß existierende Produkte möglichst weiterverwendbar machen. Mit RailCom in seiner jetzigen Form wird's da schwer reine Spielbahner oder Kinder damit zu versorgen.

Im nächsten halben Jahr bis zur Nürnbergmesse wird's sicher noch einige Überraschungen geben. ZIMO wird wohl RailCom in seiner jetzigen Form weiter unterstützen und ein weiteres neues Verfahren anbieten.
(edit: ein Satzfragment saniert)

[Peter Müller]

Danke, dass Du uns an Deinen Einblick hast teilhaben lassen. Ich habe mir Deinen Beitrag mal vorsichtshalber kopiert. Wer weiß, wer da noch alles interveniert.

Zitat von huebsch

---

Daher wird es wohl ein weiteres Verfahren zur Rückmeldung geben das dann allen Gerüchten nach PublicDomain sein wird.

---

Das hört sich doch gut an. Dann warte ich lieber noch ein Weilchen.

[digilox1]

Hier noch die vorläufige Stellungnahme von ZIMO:

http://www.zimo.at/web2010/

Gruss,
Manfred

[Andi]

Moin Peter,

Zitat von Peter Müller

---

Zitat von huebsch

---

Daher wird es wohl ein weiteres Verfahren zur Rückmeldung geben das dann allen Gerüchten nach PublicDomain sein wird.

---

Das hört sich doch gut an. Dann warte ich lieber noch ein Weilchen.

---

hört sich das wirklich gut an? Der Moba-Markt ist ein bestenfalls leicht stagnierender Markt. Somit ist gar kein Platz (und vor allem auch kein Budget) vorhanden, um sich Mehrfachentwicklungen leisten zu können. Es ist doch schon schlimm genug, das Märklin seine eigene Suppe kocht.

Schon heute wird von vielen Fachleuten beklagt, das die Protokollvielfalt die Ursache für viele Probleme (z. B. unkontrolliert losfahrende Loks) darstellt. Mit einer Zentrale die 3 oder noch mehr verschiedene Anmeldeprozeduren unterstützt, wird die Sache bestimmt nicht besser.