Hallo Martin,

Railcom verstanden


Hallo StahlblauBerlin,

meine 140 Loks haben zu 70% Pufferkondensatoren (ESU 4.0 mit ESU Powerpack). Dann dürfte ich ja eher auf der sicheren Seite sein, oder ?

Kann es jetzt sowieso nicht mehr ändern. Dadurch dass alle meine Magentdecoder, bzw Servos auf der anderen Stromversorgung liegen, werden die die Loks in ihrem Fahrbetrieb zumindest davon nicht beeinflussen. Den Rat hat mir damals ein WDP Beta User gegeben und dem Danke ich heute noch dafür .

MfG

Manfred

Mit den Powerpacks ist das eh langweilig. Zum einen ist der Ladestrom da begrenzt, zum anderen wird da während der Railcom-Lücke nur ein kaum erwähnenswerter Anteil der Ladung der Kondensatoren verbraucht. Nix verbraucht heißt halt auch nix zum Nachladen. Ein vergleichsweise winziger Elko mit 100µF ohne Mindest-Ladeschaltung (Diode/Widerstand) ist von den Stromspitzen ekliger, für ein paar µs mehr als ein A. Aber selbst der entlädt sich während der Railcomlücke nicht vollständig, die ist ja nur etwa 0,5 ms lang. Wenn ich nicht gerade einen Knoten im Hirn habe fällt bei einem 100µF-Elko und einem A Laststrom (Motor + Sound + Licht + X) die Spannung am Elko während der Railcom-Lücke um gerade mal 0,2 V...da ist also nicht wirklich was nachzuladen.
Die Stromversorgung zu trennen macht ja auch Sinn, wenn man 140 Loks auf dem Gleis stehen hat ist die Anlage ja auch etwas größer...und bei der ganzen Betrachtung ist ja nur relevant was auch gleichzeitig auf der Anlage steht und fährt.
Wenn aber alles an einer Zentrale hängt, in meinem Fall ein Z21-Nachbau, gibt es nur einen DCC-Ausgang und damit Datenquelle. Die Anzahl der Boosterkreise spielt da keine Rolle, die laufen alle synchron mit dem selben DCC-Signal am Eingang. Damit ist das Limit gesetzt, ca. 8000 Baud. Bei 10 gleichzeitig aktiven (fahrenden) Triebfahrzeugen, etwa 20 Funktionsdecodern in Waggons, drei Funktionsdecodern als stationäre Decoder für Beleuchtung sowie drei Weichendecodern a 8 Weichen (Servos) habe ich aber noch keine spürbare Verzögerung bei irgendwelchen Eingaben bemerkt. Bei Funktionsdecodern/Weichendecodern wird ja nur was gesendete wenn es auch was zu senden gibt. Die ganze Anlage hängt übrigens nur am Booster der Zentrale, mit 5A Belastbarkeit. Maximal hat die mir einen Stromaufnahme von 4,6 A in der Spitze protokolliert.

Zitat von Hobbyprog im Beitrag #22

---

Du fragst hier gezielt Sachen ab, wo du weißt das die mit DCC-Protokoll nicht funktionieren.

---

Hallo Eckhart,
falls man das Braucht oder haben möchte, ist das auch gut so.
Für mich persönlich wäre Railcom eine sinnvolle Option. So könnte man z. B. in Rocrail auch im manuellen Zugbetrieb eine Block - Verfolgung machen.
In diesem Fall wäre dann ein S88 überfordert.
Ich hatte auch schon mal überlegt RailCom in meinem Hobbyprojekt aufzunehmen. Idealerweise mit den Rückmeldemodulen zusammen.
Da ich beim Machen lerne, weiß ich nicht, ob ich sowas hinbekomme. Aber es gibt ja schon solche Projekte. Da wäre z. B. das Rocrail- WIO Projekt von Rob.

Viele Grüße Martin

Hallo Stahlblauberlin,

Heißt das mit den Akupacks habe ich dann deutlich weniger Probleme?

DIE 130 Züge sind immer auf der Anlage und auch unter Strom. Uhlenbrock hat mir allerdings erzählt, dass die IB2 nach 30 sec ohne Veränderung die die Lok aus dem zu übersendenden Protokoll nehmen. Die IB2 kann nur Max. Glaube 100 Loks, deswegen kommt bei mir auch beim Hochfahren der Anlage eine Fehlermeldung der IB2 (zu viele Loks im Control), aber ohne Auswirkung, da sich die Lokdecoder ja automatisch bei keiner Veränderung wieder abmelden. So hat es mir UB der Programmierer der IB2 erklärt. Fehlermeldung einfach ignorieren.

Ich habe insgesamt 6 Boosterkreise, die ich auch brauche, da sich die Akupacks bei Start vollsaugen. Selbstständig jeden einzelnen Kreis muss ich nochmal in 4 Kreise unterteilen und nacheinander hochfahren, sonst würden auf den ablotset 7-8 A kommen, Max 5 geht und macht Sinn.

8000 Baud, dachte die IB2 hat 50000 Baud ?

Hast du auch einen richtigen Namen ?

Mit freundlichen Grüßen Manfred

Manfred
eigentlich sollten doch die Akkus oder Kondensatoren über einen Ladewiderstand geladen werden.
Der verzögert bzw. Verlängert das Aufladen. Eine Diode überbrückt dann für ein vollen Entladestrom den Widerstand. Falls das nötig ist!

Der Widerstand verbraucht natürlich auch Leistung, daher??

Viele Grüße Martin

Zitat von Fisch65 im Beitrag #30

---

Heißt das mit den Akupacks habe ich dann deutlich weniger Probleme?

---

Zitat von Fisch65 im Beitrag #30

---

8000 Baud, dachte die IB2 hat 50000 Baud ?

---

Zitat von Hobbyprog im Beitrag #31

---

Der Widerstand verbraucht natürlich auch Leistung, daher??

---

Stahlblauberlin

meine Zentrale kann 64 Loks refreshen. Falls mehr nötig sind wird der älteste Eintrag gelöscht und durch die neue ersetzt.
Funktionbefehle refreshen habe ich nur für F0 bis F8 so programmiert. Und das geht mit einem NANO 328 - Die HEX zum Flashen hat 17 KB .

Viele Grüße Martin

Zitat von Hobbyprog im Beitrag #34

---

meine Zentrale kann 64 Loks refreshen. Falls mehr nötig sind wird der älteste Eintrag gelöscht und durch die neue ersetzt.
Funktionbefehle refreshen habe ich nur für F0 bis F8 so programmiert. Und das geht mit einem NANO 328

---

Stahlblauberlin
ist doch gut so. Ich wollte nur berichten was so ein antiker ATMega 328 8bit Mikrokontroller noch kann.
Viele Grüße nach Berlin Martin

Was habt ihr nur alle für riesige Anlagen...

Hallo Manfred,

Zitat von Fisch65 im Beitrag #23

---

Also sollte man Railcom zwingend ausschalten wenn man es nicht nutzt?

---

Die verwendeten steuerprotokolle hängen von den empfängern ab. Wer lokdecoder aus 20 jahren mit mm, mfx und dcc im einsatz hat, braucht auch eine zentrale die alle 3 protokolle gleichzeitig senden kann oder er rüstet für viel geld seine loks um. Das kann dann bei einzelnen modellen (nur mm + ursinus z.b mä 39161) bis zum motortausch führen.
Bei mir fahren mit den 3 aktiven protokollen 6 loks gleichzeitig im blockbetrieb und meine CS2 hat keine probleme, auch nicht mit der verarbeitung von 64 stück S88-rückmeldern.
Die weichen- signal- zubehör-steuerung ist ohnehin weder mit mm noch dcc oder beiden kein problem, da diese befehle ja seriell abgesetzt werden. Bei mir 200ms lang und 200ms pause dazwischen.

Es kommt also immer auf die ganz individuellen voraussetzungen - bereits vorhandene decoder - an.

Hubert

Zitat von hu.ms im Beitrag #39

---

Wer lokdecoder aus 20 jahren mit mm, mfx und dcc im einsatz hat, braucht auch eine zentrale die alle 3 protokolle gleichzeitig senden kann oder er rüstet für viel geld seine loks um. Das kann dann bei einzelnen modellen (nur mm + ursinus) bis zum motortausch führen.

---

Zitat von Stahlblauberlin im Beitrag #40

---

Da kann ich nur sagen: Schwein gehabt

---

Hallo,
ich bedanke mich für eure Berichte.
Mittlerweile habe das Gefühl, das artet hier immer mehr in Fachsimpeln aus. Ich habe mich da auch schon mitreißen lassen. Einige Sachen werden sogar wiederholt mit anderen Worten erklärt.
Es geht bei der Umfrage um Erfahrungsberichte, was bei Euch gut oder schlecht funktioniert. Oder was euch wichtig ist. Wenn ich die gemachten Berichte grob auswerte, zeigt sich, dass einige groß propagierte Probleme im Alltag nicht vorhanden sind. Ich bin ja der Meinung, eine Zentrale und S88 als Rückmeldesystem reicht völlig aus.

Die Umfrage macht nur Sinn, wenn jeder emotionslos, seine Erfahrungen mitteilt. Am Ende kann doch jeder selber entscheiden, was im wichtig ist. Besonders Einsteiger werden mit vielen gut gemeinten Ratschlägen über häuft.
Bei anderen Dingen ist es ja ähnlich. Der eine möchte das schnellste, das schönste Auto, das er sich gerade noch leisten kann. Ein anderer überlegt sich, ob das auch Sinn macht.

Viele Grüße Martin

Zitat von hu.ms im Beitrag #41

---

Warum "schwein gehabt"?
Wie beschrieben funktioniert bei mir doch alles bestens mit CS2 und 3 steuerprotokollen parallel.

---

Zitat von Hobbyprog im Beitrag #42

---

Es geht bei der Umfrage um Erfahrungsberichte, was bei Euch gut oder schlecht funktioniert.

---

Zitat von Stahlblauberlin im Beitrag #43

---

Zitat von hu.ms im Beitrag #41

---

Warum "schwein gehabt"?
Wie beschrieben funktioniert bei mir doch alles bestens mit CS2 und 3 steuerprotokollen parallel.

---

Ich halte nicht viel von Multiprotokollsystemen, einfach zu viele potentielle Störquellen. Das K.I.S.S.-Prinzip. Mal abgesehen davon nutze ich seit Ewigkeiten primär selbstgebaute Hardware. Da ist DCC weil sehr früh offengelegt und standardisiert einfach sehr viel besser unterstützt. Auch spielt der MM/MM2/MFX-Zoo nur im Märkliniversum eine ernste Rolle, bei allen Nichtnoppenbahnen hat sich DCC durchgesetzt, erst recht außerhalb Deutschlands.

---

Hallo,

mir scheint, die Frage sollte mehrstufig betrachtet werden.
Da ist einerseits die Kommunikation vom Booster zu den Zügen (und ggfs zurück - wenn's denn nötig ist) und meinethalben auch zu ortsfesten Einrichtungen wie Signalen, andererseits die Kommunikation der eventuell vorhandenen verschiedenen Komponenten der Steuerung: ortsfeste Rückmeldung, Kommunikation zwischen Steuerzentrale und Boostern, etc.

Beide funktionieren aber nach verschiedenen Maßgaben. Und brauchen darum auch verschiedene Protokolle. So wie mein Handy die Musik nicht über Bluetooth aus dem Internet holt, aber sehr wohl per Bluetooth an meine Ohrhörer weitergibt. Und wenn das Handy über Router und WLan mit dem Internet verbunden ist, kommen weitere Protokolle ins Spiel.

Für die Kommunikation am Gleis haben sich einige Protokolle bewährt, die auch schon seit langen Jahren "gemischt" im System existieren dürfen - die IB ist meines Wissens schon rund 30 Jahre alt. Für die Kommunikation der verschiedenen Komponenten, aber auch die Rückmeldung, gibt es verschiedene Protokolle, vom "quasi-analogen" S88 für die Rückmeldung über Loconet und CAN bis TCP/IP (was auch mein Router verwendet) - und sicherlich für jedes Protokoll auch seine guten Gründe.

Für meine kleine Anlage reicht es vollkommen aus, daß der PC mit den Zentralen (RedBox fürs Fahren, Sprog fürs Schalten) über seriell bzw. USB kommuniziert, s88 ist bisher (noch) als Rückmeldung direkt über Rocrail und die serielle Schnittstelle implementiert. Aber vielleicht lege ich das auf die RedBox, einfacher wäre es. Vom Sprog geht es per DCC zu den Weichen- und Signaldecodern; die RedBox sendet je nach Bedarf DCC, MM und m3 (mfx ohne Rückmeldung). Railcom habe ich nicht; dafür besteht kein Bedarf.

Und jetzt geb ich dem Drang nach und frage ganz offen: wo ist eigentlich das Problem für die Fragestellung?

Hallo

"Und jetzt geb ich dem Drang nach und frage ganz offen: wo ist eigentlich das Problem für die Fragestellung?"

Es gibt kein Problem. Ich möchte nur mal wissen, was so eine privater Modellbahner verwendet. Ich denke das ist für alle Modellbahner interessant.

Danke für Deinen Bericht.

Viele Grüße Martin

Hallo!

Für die Umfarge / Statistik / Neugier / Markt-Beobachtung / ... :

Auf meiner geplanten Anlage will ich als Zentrale die Märklin-Gleisbox einsetzen, zur Lok-Steuerung die MS 2 und (vermutlich) einige Mikrocontroller ("uC", Arduino oder ähnlich, Zweck siehe unten). Die kommunizieren also über den CAN-Bus (Märklin-Variante).
(Grund: Mir gefällt die MS 2. Hinreichend viel Anzeige, Drehknopf, Tasten, relativ preiswert zu besorgen, mehrere parallel einsetzbar.)

Als Gleis-Protokoll will ich nur DCC nehmen, für die Blockstrecken-Logik und den Schattenbahnhof mit Bremsen und Anhalten per Lenz ABC-Bremsen und entsprechende Bremsmoduln.

Belegt- und Rückmeldung über isolierte Schiene, per Optokoppler an uC. Im Schattenbahnhof sollen die auch die Weichen stellen, den Fahrstrom schalten ("normal" oder vom Bremsmodul) und im Kopfgleis die Fahrtrichtung umschalten.
Dafür an der Sbf-Einfahrt zusätzlich Railcom (ja, braucht Tams-Booster und Auswerte-Hardware) mit Übertragung (mindestens) der Loknummer zum uC.

Die Sbf-Weichen kommen (über passende Leistungs-Stufen) direkt an den uC.
Ob die Weichen im sichtbaren Bahnhof direkt analog gesteuert werden, über Decoder oder ganz anders, habe ich noch nicht entschieden. Dazu muss ich erst Erfahrungen mit der Kombination uC - Treiber - Weiche sammeln.

Ich will also auf dem Gleis DCC mit Railcom einsetzen und für die Steuergeräte den CAN-Bus. Ob und wie die uCs miteinander kommunizieren (müssen), werde ich erst bei genauerer Planung merken.

Disclaimer: Ich bin noch in der Planungsphase.

Viel Freude!
Jörg