[Michael.Frey]

Hallo,

die ECoS unterstützt seit der Version 1.1.0 ebenfalls RC, seit 1.1.1 auch ohne Bugs.

Als RC-fähige Decoder wurden ja schon der Lopi 3.0 genannt (ältere Lopi 3.0 werden per Update RC-fähig).

Zumindest laut Anleitung sind alle Lokpiloten (außer mfx) für Railcom vorbereitet. Besonders interessant dürfte in diesem Zusammenhang der zum Lopi 3.0 registerkompatible Funktionsdecoder sein. Sechs Ausgänge und Railcom für knapp 13 Euronen sind ein Wort.

Der Switchpilot ist ebenfalls RC-fähig. Er löst, entsprechend angeschlossen, an der ECoS ein Warndreieick aus wenn eine Weiche von Hand verstellt wurde.

Es kommt halt darauf an was die Zentralen oder Steuerungsprogramme mit den angebotenen Informationen anfangen werden.

Alleine die Möglichkeit CVs auf dem Hauptgleis im Betrieb auszulesen ist schon eine schöne Sache. Da kann man mal eben schnell einen Wert ermitteln ohne die Doku rauszuholen. Programmieren geht natürlich auch, aber das ist ja kein Fortschritt gegenüber der DCC-Hauptgleisprogrammierung.

Grüße

Michael

[Werdenfels]

Zitat von Michael.Frey

---

Zumindest laut Anleitung sind alle Lokpiloten (außer mfx) für Railcom vorbereitet.

---

Hallo Michael!

Auch der Lokpilot MFX (ebenso der Loksound MFX) sind für Railcom vorbereitet. Infos siehe hier. Bitte noch das Pluszeichen unter Details klicken.

Ein Stammtischkollege hat schon erfolgreich auf Railcom geflasht. Allerdings stehen Tests in Ermangelung einer geeigneten Zentrale noch aus.

[Bodo Müller]

Hallo Michael,

Zitat von Werdenfels

---

Hallo Michael!

Auch der Lokpilot MFX (ebenso der Loksound MFX) sind für Railcom vorbereitet. Infos siehe hier. Bitte noch das Pluszeichen unter Details klicken.

Ein Stammtischkollege hat schon erfolgreich auf Railcom geflasht. Allerdings stehen Tests in Ermangelung einer geeigneten Zentrale noch aus.

---

es ist gut zu wissen, dass nachgerüstete Lokpiloten sowie Loksound 3.5 mit RailCom-fähiger Firmware aktualisiert werden können. Die Frage ist nur, was macht man mit den ganzen mfx-Loks von Mä*, insbesondere mit den Neuheiten, die jetzt mit SDS/mfx ausgeliefert werden? Theoretisch, streng genommen, kann man diese Loks ja gar nicht kaufen, weil spätere Kompatibilitätsmöglichkeiten bis dato nicht geklärt sind. In alle Loks später einen zusätzlichen FD-R einzubauen, kann ja auch nicht die Patentlösung sein.

Ich bin mal gespannt, ob Mä* in irgendeiner Form auf das RailCom-Thema eingeht, und ebenfalls Firmware Updates der Decoder bereit stellt...

[ktams]

Zitat von Bodo Müller

---

Ich bin mal gespannt, ob Mä* in irgendeiner Form auf das RailCom-Thema eingeht, und ebenfalls Firmware Updates der Decoder bereit stellt...

---

hi,
wenn, dann allerhöchstens TRIX. Tante M wird das wohl nie machen, da für RailCom zwingend DCC benötigt wird. Man sagt zwar: sag niemals nie, aber ich hege doch erhebliche Zweifel, ob Tante M jemals DCC einsetzen wird.
Gruß Kersten Tams

[Michael.Frey]

Hallo Namensvetter,

Zitat von Werdenfels

---

Auch der Lokpilot MFX (ebenso der Loksound MFX) sind für Railcom vorbereitet. Infos siehe hier. Bitte noch das Pluszeichen unter Details klicken.

Ein Stammtischkollege hat schon erfolgreich auf Railcom geflasht. Allerdings stehen Tests in Ermangelung einer geeigneten Zentrale noch aus.

---

Das Dein Kollege erfolgreich geflasht hat glaube ich gerne. Beim Lokpilot mfx wird aber kein Railcom nachgerüstet, sondern es werden folgende Features aktiviert:

1. LokPilot V3.0 Decoder ab Produktion 2007 (Hardware Type V3.3) können auf dem AUX1 und AUX2 Ausgang ein spezielles Signal für ROCO-Digitalkupplungen erzeugen.

2. Mit der 6021 können nun auch CVs und CV-Werte größer als 80 eingegeben werden (siehe Handbuch!)

3. Verbesserte Unterstützung von langen Motorola-Adressen bis 255 (wo vorgesehen).

Der Lokpilot mfx verwendet zwar die gleiche Hardware wie der Lopi 3.0, die Firmware ist aber in Teilen eine andere - und er spricht natürlich mfx statt Railcom.

Ich bin überzeugt das man mit geeigneter Ausrüstung aus den mfx-Lopis normale Lopi 3.0 machen könnte. Dem hat ESU aber auf Ebene der Bordmittel (Lokprogrammer) einen Riegel vorgeschoben. Das ganze ist mir zwar unverständlich, denn so wandern z.B. meine mfx-Lopis CO2-belastend per ebay zu einem neuen Besitzer, um in der Lok einem DCC-Decoder Platz zu machen.

Ich würde ein Geschäftsmodell daraus machen. Ein kostenpflichtiges Update (so um die 5 Euro), eine schlaue Software um das Provisioning und die Verrechnung zu automatisieren. Die mfx-Decoder haben doch eine eindeutige Kennung, die könnte man zur Steuerung des Prozesses verwenden. Update per ECoS oder Lokprogrammer.

Das damit wohl ein Garantieverlust verbunden wäre ist klar. Aber auch heute muss ich einen Reserve-mfx-Lopi für Rücksendungen zu Märklin bereit halten.

Grüsse

Michael

[Bodo Müller]

Hallo,

Zitat von Michael.Frey

---

Das ganze ist mir zwar unverständlich, denn so wandern z.B. meine mfx-Lopis CO2-belastend per ebay zu einem neuen Besitzer, um in der Lok einem DCC-Decoder Platz zu machen.

Grüsse

Michael

---

aha, was machst du denn mit den Mä* Loks, die mit einen C-Sinus oder SDS ausgestattet sind und dazu noch einen lokspezifischen Sound haben?

Wenn man komplett auf DCC bzw. Railcom setzen will, dürfte man eigentlich keine Mä* Lok mehr kaufen. Selbst bei den Trix Loks, die derzeit DCC benutzen (mit und ohne SOund) ist nicht gesagt, dass deren Decoder irgendwann einmal mit einem Firmware-Update geflashed werden können. Dazu muss Trix es erst einmal liefern.

Also, wenn auf Nummer Sicher gehen will, dürfte man derzeit gar nichts mehr kaufen....

[SAH]

Guten Tag Michael,

Zitat von Michael.Frey

---

2. Mit der 6021 können nun auch CVs und CV-Werte größer als 80 eingegeben werden (siehe Handbuch!)

---

welches Handbuch? bzw. wie?
mfG.
SAH

[Udo Nitzsche]

Zitat von SAH

---

welches Handbuch? bzw. wie?

---

Guckst Du hier: http://www.esu.eu/index.php?id=293

Das benötigte Handbuch ist das erste in der Liste.
Ab Seite 25 findest Du das Programmieren mit der 6021.

[Michael.E]

Zitat von Michael.Frey

---

Das Dein Kollege erfolgreich geflasht hat glaube ich gerne. Beim Lokpilot mfx wird aber kein Railcom nachgerüstet, sondern es werden folgende Features aktiviert:

1. LokPilot V3.0 Decoder ab Produktion 2007 (Hardware Type V3.3) können auf dem AUX1 und AUX2 Ausgang ein spezielles Signal für ROCO-Digitalkupplungen erzeugen.

2. Mit der 6021 können nun auch CVs und CV-Werte größer als 80 eingegeben werden (siehe Handbuch!)

3. Verbesserte Unterstützung von langen Motorola-Adressen bis 255 (wo vorgesehen).

---

Hallo Michael ( langsam werden das hier zuviel )

Michael W. meinte mich damit. Das die von dir aufgezählten Features von 1-3 alle durch das Flash implementiert wurden mag ja noch sein.

Allerdings, was macht dich da so sicher, dass der Lokpilot mfx jetzt nicht doch RC kann?
Ich habe leider keine passende Zentrale um das auszuprobieren.
So wie ich das auf die schnelle Überblicke, sind die Handbücher älter als das jetzt angebotene Flashtool.
Mit dem Loksound mfx ging es übringens nicht.

[Bodo Müller]

Hallo Oliver,

Zitat von ozoffi

---

Hallo!

Mit entsprechenden RailCom-Dedektoren, es geistert da der Name "Kilometerstein" herum, ist dies nicht mehr nötig. Mit RailCom erfolgt die Rückmeldung über die Schiene - womit dann eine digital gesteuerte Anlage wirklich nur noch 2 Leitungen von der Zentrale zum Gleis benötigt und der gesamte Datenverkehr eben über diese 2 Leitungen abgewicklet wird.

---

das interessiert mich jetzt genauer. Wie ist das jetzt genau bei einer RailCom-Steuerung im Gegensatz zur üblichen GBM mittels Kontaktgleis zu einem S88-Modul? Wie werden denn dann bei RailCom Gleisabschnitte definiert, die dann als besetzt gemeldet werden? Wie genau handhabt man die sogenannten Kilometersteine, also Detektoren? Wird ein solcher an eine bestimmte Stelle des Gleises platziert, z.B. einer am Anfang und einer am Ende des Streckenabschnitts und somit gilt dieser als überwachter Gleisabschnitt, oder wie funktioniert das?

Kersten sagte ja weiter oben, dass man die Technik der GBM nachwievor noch benötigt, jedoch anstelle des S88-Moduls - so habe ich das verstanden - dann den Detektor (LRC120) anschliesst, und somit nicht nur ja/nein, sondern auch wer, gemeldet wird. Ist das korrekt?

Ich frage deswegen, weil ich meine zukünftige Anlage gerne mit dem PC steuern möchte, dabei soll auch eine Zugerkennung realisiert werden, damit das Steuerungsprogramm nicht nur weiss wo ein Zug ist, sondern auch welche Lok/Zug. Dies scheint ja mit RailCom ein Kinderspiel zu sein.

[ozoffi]

Servus Bodo!

Grundsätzlich muss auch bei Railcom ein Gleisabschnitt (also das Gleis getrennt vom Rest) vorhanden sein, um inerhalb dieses Abschnittes Abfragen - bezogen auf diesen Abschnitt - durchzuführen.
So ein "Kilometerstein" würde (noch gibt es ihn nicht) mit 2 Leitungen am Gleis *ausserhalb* des abzufragenden Abschnittes angeschlossen - oder eben an einer parallel zum Gleis verlaufenden 2poligen Ringleitung, mit der man eh alle x Meter den Strom einspeist. Darüber wird der Baustein mit Spannung und Signalen versorgt. Ein Kabel vom Baustien führt zum getrennten Abschnitt - bis jetzt also im Grunde nicht anders als bestehende Module. Nun kann aben inerhalb dieses Abschnittes, "abschnittsbezogen" abgefragt und gleichzeitig gesteuert werden. ZIMO plant da zb. das HLU Signal zu übertragen ... (noch ist es nur ein Plan ...).
Solange sich also ein Fahrzeug, dass mindestens Strom braucht, im Abschnitt befindet, gilt dieser als besetzt. Hat dieses Fahrzeug einen Decoder, kann man zusätlich noch die Adresse u.ä. auslesen.
So ein Kilometerstein hat vielleicht auch noch zusätzliche Schalteingänge, mit denen man punktgenaue Abfragen stellen kann.

Der Witz daran ist, dass man keinen gesonderten Rückmeldebus (bei ZIMO zb. der CAN-BUS) benötigt. Weil eben die Signale *bidirektional* sowohl von der Zentrale zum Dedocer, als auch vom Decoder zur Zentrale gesendet werden. Eventuelle Booster müssen natürlich BiDi fähig sein. Was nun die Zentral, oder der Handregeler wie mit der Information anfängt, wird von System zu System unterschiedlich sein. Manche werden viele Features gleich in der Zentrale implementiert haben. Manche werden dafür Zusatzmodule anbieten.
Das es keine extra Leitung für die Rückmeldung mehr geben muss, wird für Indoorbahner vermutlich nicht ganz so prikelnd sein - wieviele Strippen da unter der Anlage gezogen werden, ist vermutlich nicht sehr relevant. Für Gartenbahner ist dies jedoch ein nicht zu unterschätzender Faktor!
Denn wenn die Gleise einmal liegen, kann hinterher nur mit viel Aufwand noch eine Leitung zusätzlich vergraben (im Wörtlichen Sinn!) werden.
Ebenso ist es für Indoorbahner vermutlich unerheblich, ob ich nun ein Gleisabschnittsmodul mit mehreren Ein-/Ausgängen mögliuchst zentral verbaue und dann halt mit mehr oder wenige rlangen Leitungen zu den einzelnen Abschnitten gehe. Wenn sich ein abzufragender Abschnitt 50meter weit weg befindet und da ist wirklich nur *ein* Abschnitt, wird mir so ein "Kilometerstein", der ersten klein ist, zweitens wetterfest und eben wesentlich günstiger, als ein großes Abschnittsmodul sehr entgegen kommen
So ein "Kilometerstein" (auch da geistern derzeit viele Ideen herum), könnte nicht nur einfach einen Abschnitt abfragen (welche Lok mit welcher Adresse steht in dem Abschnitt) und u.U. noch Fahrbefehle (Halt/Fahrt etc.) absetzen, sondern zusätzlich Schaltbefehle entweder gleich über das Gleis, oder über IR nur an eine bestimmte Lok geben (nur der 5-Kuppler soll vor einer Kurve in genau einer Fahrtrichtung das Geräusch "Kurvenquitschen" so lange abspielen, bis das Fahrzeug eben die Kurve verlassen hat).

Bei ZIMO denkt man z.b. daran einen Weichendecoder als "Kilometersein" aufzurüsten. Damit wäre alle oben genannten Szenarien dann möglich.
Man könnte damit nicht nur Signale, oder Weichen schalten, sondern auch in diesem Abschnitt befindliche Fahrzeuge melden und punktgenaue Schaltvorgänge autark realisieren .. uvm.

Es erschließen sich hier schon einiges an Möglichkeiten, die bisher nur mit entsprechenden Aufwand (oder gar nicht) möglich waren. Natürlich ist es auch eine Frage der Kosten und des Umsetzungswillen div. Hersteller.

[SAH]

Guten Morgen Udo,

Zitat von Udo Nitzsche

---

Zitat von SAH

---

welches Handbuch? bzw. wie?

---

Guckst Du hier: http://www.esu.eu/index.php?id=293
Das benötigte Handbuch ist das erste in der Liste.
Ab Seite 25 findest Du das Programmieren mit der 6021.

---

das Handbuch des ESU-Lopi3 habe ich bereits.
Mir ging es um die Programmierung der CV's > 80 mit Werten >80 mit Hilfe der 6021. *Das* habe ich nicht gefunden, oder ich habe da eine ältere Version :

mfG.
SAH

[Michael.Frey]

Hallo Stefan,

Zitat von SAH

---

das Handbuch des ESU-Lopi3 habe ich bereits.
Mir ging es um die Programmierung der CV's > 80 mit Werten >80 mit Hilfe der 6021. *Das* habe ich nicht gefunden, oder ich habe da eine ältere Version :

mfG.
SAH

---

es gibt ein neues Handbuch. Zitat aus dem Handbuch:

Die Märklin®-Zentralen 6021 hat eine Sonderstellung: Da sie
nicht der NMRA-DCC Norm entspricht, implementieren die
LokPilot Decoder eine spezielle Programmier-Prozedur, die genau
eingehalten werden muss. Ein Auslesen der Werte ist nicht möglich.
Es stehen zwei Modi zur Verfügung:
Im Kurzmodus können nur Einstellparameter mit einer Nummer
< 80 verändert werden, sofern der gewünschte Wert ebenfalls
< 80 sein soll.
Im Langmodus können alle Einstellparameter mit Werten von 0
bis 255 verändert werden. Da das Display der 6020/6021 nur
zweistellige Werte zulässt, müssen die einzugebenden Werte
aufgeteilt und in zwei Schritten eingegeben werden.
Der LokPilot XL V3.0 beherrscht stets sowohl den Kurz- als auch
den Langmodus. LokPilot V3.0 Decoder unterstützen den Langmodus
ab Softwareversion 0.0.6560. Der LokPilot micro V3.0
und LokPilot Fx V3.0 kann nur im Kurzmodus programmiert werden.

Grüße

Michael

[ktams]

hi,
wen es interessiert: Ich habe mal unsere Pressetexte zu RailCom auf meine Webseite gestellt.
Hier der Link:
http://www.tams-online.de/htmls/RailCom/RC_Infos.html
Gruß Kersten Tams

[digilox1]

Hallo Kersten Tams,

Seit neuestem soll RailCom einzig per CV29/3 aktiviert oder deaktiviert werden.

Eine Verständnisfrage: Wie muss ich mir die Funktionsweise vorstellen, wenn mehrere Decoder auf einem Stromkreis *nur* den Globaldetektor ansprechen aber mit aktivem Adress-Broadcast unterwegs sind und, sagen wir, Stromaufnahme, Motorspannung, Geschwindigkeit, usw., usw. adressindividuell übermitteln sollen ?

Wie wird ein für den Globaldetektor unverständliches Geschnatter vermieden?

Danke und Gruss,
Manfred

P.S.: Habe die Frage schon im MOBAZI gestellt, aber wahrscheinlich wurde Herr A. Hübsch im Messesturm verhagelt.

[ktams]

hi,
der Rückkanal besteht aus zwei Teilen. Zum einen den Broadcast-Kanal, in dem alle Decoder ihre Adresse schnattern und einem drei mal so großem zweiten Teil, in dem ein Decoder nur dann etwas sagen darf, wenn er vorher auf seiner Adresse angesprochen wurde.
Ich denke, damit ist klar, wo ein lokaler und wo ein globaler Detektor horcht
Gruß Kertsn Tams

[digilox1]

Hi,

das ging ja geradezu RailCom-mässig schnell.

Aber: Dann muss ja der Lokaldetektor auf beide Kanäle hören können, damit all die schönen Dinger auch auf der Handregler-Anzeige erscheinen, wenn per GBM/Lokaldetektor eine Positionsbestimmung durchgeführt werden soll?

Danke und Gruss,
Manfred

[ktams]

Zitat von digilox1

---

Hi,

das ging ja geradezu RailCom-mässig schnell.

---

hi,
hatte noch vor dem Ausmachen des PC mal kurz vorbei geschaut...

Zitat

---

Aber: Dann muss ja der Lokaldetektor auf beide Kanäle hören können, damit all die schönen Dinger auch auf der Handregler-Anzeige erscheinen, wenn per GBM/Lokaldetektor eine Positionsbestimmung durchgeführt werden soll?

Danke und Gruss,
Manfred

---

Das geht ein wenig anders. Natürlich kann (muss nicht) der lokale Detektor auch auf den zweiten Teil hören. Das kann sinnvoll sein, wenn er für seinen Gleisabschnitt z.B. die aktuelle Geschwindigkeit des Zuges, der gerade hier fährt, lokal anzeigen soll. Ein Handregler muss dagegen immer von der Zentrale bedient werden. Das heißt, die Zentrale muss die Position vom lokalen Detektor gesagt bekommen (wie auch immer). Das ist die einzige Anwendung, wo ein lokaler Detektor der Zentrale (oder PC) etwas sagen muss. Alles andere kann die Zentrale direkt aus dem Decoder über den globalen Detektor erfahren.
Die Art der Rückmeldung der Position vom lokalen Detektor zur Zentrale ist noch offen. Hier kann ich mir z.B. vorstellen, dass ein lokaler Detektor eine Adresse bekommt und das per RailCom an den globalen Detektor und damit der Zentrale meldet. Das würde externe Kabalage überflüssig machen. Ob das schnell genug ist, muss ich noch berechnen. Einer Schätzung nach wird es aber auf jeden Fall für kleine und mittlere Anlagen (also etwa 99%) völlig ausreichen.
Gruß Kersten Tams

[Lichtleiter]

Hallo,

ich bin etwas irritiert! Ich öffne einen Beitrag mit dem Titel "zukuftssichere Modellbahn" ...und finde nur Beiträge zum Thema "zukuftssichere Informationstechnologie (für Modellbahnen)", was absurder Schwachsinn an sich ist, denn genausogut könnte man fragen, ob die Windows Vista Nachfolgeversion wohl besser auf AMD, oder Intel Prozessoren laufen wird...

Liebe Leute, Modellbahnbau ist so ein schönes Hobby und hat sicherlich etwas "Ewiges", aber lasst uns doch die IT als das nehmen, was sie ist, nämlich unberechenbar ...wenn ihr beim M***Markt mit einem Notebook vorne zur Kasse rausgeht, dann wird hinten schon die nächste Generation reingeschoben und nächsten Samstag 100,- Euro günstiger angeboten....

...und das müssen wir auch für den Teil der Modellbahnerei akzeptieren, der der IT näher ist, als der Feinmechanik! (oder einfach immer weiter analog fahren und die IT ignorieren)

Gruß, Jörn

[GDL]

Hi,

war längere Zeit ausser Gefecht gesetzt.Zu den Fragen von weiter vorne.
Nein ich fahre nicht mit Transpondern.
Ich fahre mit IR Eigenentwicklungen.Preis pro Fahrzeug ca. 3 Euro.
Ausserdem fahre ich meine Eigenentwicklung(ein aufgebohrtes DCC).

Dadurch kann ich meine eigene Software und eigenen Platinenlayouts immer an die neue PC Technik anpassen.

Mein selbstentwickeltes bidirektionales Steuerungssystem hat mich Bauteilmäßig ca. 200 Euro gekostet.

Natürlich kann nicht jeder sein eigenes System entwickeln, aber es gibt ja mittlerweile eine grosse open Source Gemeinde.Und Anleitungen für Selbstbaudecoder gibt es ja auch.Und diese "Seiten" bleiben bestimmt auch Zukunftssicher.

Servus
Georg

[Michael.Frey]

Hallo Bodo,

Zitat von Bodo Müller

---

aha, was machst du denn mit den Mä* Loks, die mit einen C-Sinus oder SDS ausgestattet sind und dazu noch einen lokspezifischen Sound haben?

---

ich setze die richtigen CVs, dann klappt es auch mit C-Sinus.

CV 129 auf 32
CV 132 auf 32
CV 135 auf 32
CV 138 auf 32

Außerdem verwende ich die neueste Firmware. Im Lokprogrammer sieht das dann so aus:



Grüße

Michael