Hallo
ich möchte mal eure Meinung dazu hören.

Ich finde das man eine kleine bis mittlere MOBA Anlage sehr gut, nur mit dem DCC Protokoll betreiben kann.
Als zusätzliches Protokoll kann dann noch das altbewährte S88 für die R Melder Verwendung finden.

Bitte schreibt wirklich eure eigen Erfahrungen auf. Daher nicht von hör und sagen berichten.

Meine Meinung ist hier völlig unbedeutend:

Ich finde alle die neuen zusätzlichen Protokolle. CAN-Bus. BIDI, WIO, LokNet und was weiß ich, nicht schlecht und die werden auch Vorteile haben.
Braucht ein normaler Modellbahner das, oder ist das nur ein Kostentreiber.

Das DCC Protokoll ist fast über die gesamte Modellbahn abgreifbar.
Es werden fast alle Zubehör -- Artikel unterstützt.
Die Decoder kosten weniger, und sind auch oft als Eigenbau erhältlich.

Das DCC Protokoll, soll Probleme mit der Datenrate haben. Sind mehr als 100 Behelfe pro Sekunde wirklich zu wenig. Oder ist das nur ein Mythos von Großanlagenbetreiber.
Man kann auch für weniger als 25€ eine zweite Zentrale nur für die Zubehörartikel parallel betreiben.

Ich beziehe mich hier auf kleine private MOBA_Anlagen. Größe Anlagen haben ganz andere Ressourcen.
Natürlich gibt es auch Modellbahner die sich vornehmlich für die Technik interessieren. Ich zähle mich auch dazu.

Ich habe fast alles für das DCC Protokoll als Hobby entwickelt, daher wahrscheinlich meine verlieben für das DCC Protokoll und die Fragestellungen.

Ich denke das ist auch sehr kontrovers. Weil die Kluft zwischen den Analog Digital -Betrieb sehr weit gefächert ist.

Bitte nur sachlich berichten, jeder hat doch das beste System wenn er damit zufrieden ist.


Viele Grüße Martin

Ich zeige einfach meinen Entscheidungsweg. Um überhaupt Loks bewegen zu können, ist DCC faktisch Standard. Also ist es nicht das Dümmste, darauf zu setzen. Kleiner Nebeneffekt: damit fahren nicht nur Loks, sondern es lassen sich auch Steuerbefehle an Funktionsdecoder senden. Auch da gibt es ein umfangreiches Angebot. Wenn man seine Anlage nicht automatisieren will, ist man an der Stelle eigentlich schon durch.

Zum Automatisieren braucht es zusätzlich die Möglichkeit, Sensoren auszuwerten und die Daten an die Zentrale zu senden. Das geht in der Theorie zwar mit DCC (siehe Railcom), aber es nicht für diesen Fall gemacht. Man braucht also ein paralleles Bussystem. Es sollte ohne Zusatzaufwand elektisch stabil laufen, herstellerunabhängig und bidirektional sein. Wenn sich dann noch Handregler oder Booster integrieren lassen sollen, landet man eigentlich automatisch bei Loconet. Wenn man bis auf das Fahren alle Aufgaben per Loconet erledigt, reicht die Bandbreite von DCC auch für überdurchschnittliche Modellbahnanlagen.

Will sagen: DCC + Loconet reicht letztlich für alles.

Gruss, iwii

Guten Abend Martin

Zitat von Hobbyprog im Beitrag #1

---

Bitte nur sachlich berichten,

---

Zitat von Hobbyprog im Beitrag #1

---

Ich finde das man eine kleine bis mittlere MOBA Anlage sehr gut, nur mit dem DCC Protokoll betreiben kann.
Als zusätzliches Protokoll kann dann noch das altbewährte S88 für die R Melder Verwendung finden.

---

Zitat von Hobbyprog im Beitrag #1

---

Das DCC Protokoll, soll Probleme mit der Datenrate haben. Sind mehr als 100 Behelfe pro Sekunde wirklich zu wenig. Oder ist das nur ein Mythos von Großanlagenbetreiber.
Man kann auch für weniger als 25€ eine zweite Zentrale nur für die Zubehörartikel parallel betreiben.

---

Zitat von Hobbyprog im Beitrag #1

---

Ich denke das ist auch sehr kontrovers. Weil die Kluft zwischen den Analog Digital -Betrieb sehr weit gefächert ist.

---

Hallo iwii,

Zitat von iwii im Beitrag #2

---

DCC + Loconet reicht letztlich für alles.

---

Zitat von Hobbyprog im Beitrag #1

---

Das DCC Protokoll, soll Probleme mit der Datenrate haben. Sind mehr als 100 Behelfe pro Sekunde wirklich zu wenig. Oder ist das nur ein Mythos von Großanlagenbetreiber.



Viele Grüße Martin

---

Ich verwende für meine kleine Anlage eine IB2 mit DCC und LocoNet. Da hängt alles entweder am Gleis oder am LocoNet. Das ist sehr einfach und übersichtlich.

Moin Kollegen,

Ich verwende DCC nur zum Fahren, das Schalten wird bei mir analog elektromechanisch oder rein mechanisch mit Stellhebeln und Verschlußregistern unterschiedlicher Systeme ausgeführt.

Für meine relativ kleine Anlage bin ich mit aber zufrieden obgleich ich auch lange Lokadressen und diverse Mehrfachtraktionen nutze.

Zitat von Hobbyprog im Beitrag #1

---

ich möchte mal eure Meinung dazu hören

---

Abend...

Zitat von Ludwig47 im Beitrag #8

---

.......mfx. Das ist bis dato zumindest im Mittelleiterbetrieb offensichtlich unverzichtbar,

---

@iwii: Auch DCC bietet Belegt- und Rückmeldung (ohne Railcom), dafür gibt es genug Bausteine am Markt.

Probleme mit der Datenrate kann ich nicht bestätigen; was meinst Du mit "Behelfe"? Ich vermute, das ist nur ein Tippfähler und soll Befehle heißen? Ich habe ganz sicher auf meiner Anlage niemals 100 Befehle/Sekunde, due Beschleunigung/Verzögerung wird ja nicht von der Zentrale, sondern vom Lokdecoder vollzogen, hierfür braucht es ja dann keinen Zentrale-Befehl aufs Gleis. Auf meiner Anlage können maximal vier Züge gleichzeitig fahren, zusätzlich sind dann noch maximal 4 in Halteblöcken. Auch bei dann noch zusätzlicher Ausfahrt plus vorrücken im Schattenbahnhof hab ich keine Probleme; im SB rücken max. 6 Züge gleichzeitig vor, wobei "gleichzeitig" Theorie ist, denn nicht auf allen Abschnitten wird zeitgleich anzufahren sein.

Ich könnte also die komplette Anlage mit DCC-Komponenten und Software (oder Handsteuerung) fahren. Warum habe ich dann Littfinski Belegtmelrder und S88 Bus dafür? Weil es zur Zeit des Anlagenbaus die preisgünstigere Variante war. Heute würde ich komplett DCC bauen.

Zitat von HaJo Wolf im Beitrag #10

---

Auch DCC bietet Belegt- und Rückmeldung (ohne Railcom), dafür gibt es genug Bausteine am Markt.

---

Zitat von Hobbyprog im Beitrag #1

---

Bitte schreibt wirklich eure eigen Erfahrungen auf

---

Zitat von Hobbyprog im Beitrag #1

---

Daher nicht von hör und sagen berichten.

---

Hallo Eckhard,

Zitat von Eckhart im Beitrag #12

---

Und das billigste Interface ist das, dass alles in einem kann, Steuerbefehle, Rückmeldungen (beides bidirektional), Firmwareupdates, Konfigurationsoberfläche ohne zusätzliche externe Software, Debugging, mehrfache galvanische Trennung, hohe Geschwindigkeiten, billige und überall zu habende Verkabelung und Verbindungskomponenten.

---

Hallo HaJo,

Zitat von HaJo Wolf im Beitrag #10

---

Auch DCC bietet Belegt- und Rückmeldung (ohne Railcom), dafür gibt es genug Bausteine am Markt.

---

Hallo vik!

Zitat von vikr im Beitrag #13

---

Du plädiert damit für eine SX-Zentrale?

---

Hallo Eckhart und Mitleser.
einen Booster braucht man nur, falls die Leistung der Zentrale für den Fahrbetrieb nicht ausreicht. Hat nichts mit dem DCC-Protokoll zu tun.
Ein stationärer Decoder braucht max. 20mA Digitalstrom, wenn der nicht aus der Digitalspannung versorgt werden.

Ich vermute Du meist mein Vorschlagt mit der zusätzlichen einfachen Zentrale, um mobile und stationäre DCC-Befehle auf zwei Datenleitungen aufzuteilen.
Das hat dann zwei Vorteile. Der Datenbus für den Fahrbetrieb wird entlastet. Die zweite Zentrale für die stationären Decoder kann auch gleich die Stromversorgung
für die Decoder übernehmen. Daher sind nur 2 Kabel z. B. als Ringleitung nötig. Das beschreibt nur eine Möglichkeit. Ob das dann wirklich nötig ist, kann man bezweifeln.
Die wenigen kurze 3 Bytes Befehle (max. 7ms) an die Zubehördecoder spiele im Normalbetrieb keine Rolle. Und natürlich muss auch die MOBA-Software das Aufteilen möglich machen,

Ich denke das wird nicht von jedem, so gesehen, und das ist auch gut so. Ich hatte auch berichtet, dass ich mich überwiegen mit dem DCC-Protokoll beschäftige.
Eventuell bin ich daher zu stark auf DCC fixiert.

DCC kann nur Rückmeldungen über RailCom, oder auf dem Programmiergleis abgefragt CV-Werte bestätigen.
S88 ist richtig! streng genommen kein Protokoll, sondern ein Schieberegister. Das aber auch nach einem Protokoll, Takt abgefragt werden muss,

Ich baue und programmiere alles von Grund auf als Hobby selber.
https://bluethners.de/DCCProjekt/Zentrale/index.html

Ich werde mir eure Erfahrungsberichte aufmerksam durchlesen, und entscheiden, ob mein DCC-Projekt noch Sinn macht.
Ich habe keine MOBA-Anlage, mur eine HO-Teststrecke!

Die Umfrage hat keinen kommerziellen Zweck. Ich denke das die Erfahrungsberichte auch den eine oder anderen interessieren

Viele Grüße Martin

Hallo Martin!

Zitat von Hobbyprog im Beitrag #16

---

Ich vermute Du meist mein Vorschlagt mit der zusätzlichen einfachen Zentrale, um mobile und stationäre DCC-Befehle auf zwei Datenleitungen aufzuteilen.
Das hat dann zwei Vorteile. Der Datenbus für den Fahrbetrieb wird entlastet. Die zweite Zentrale für die stationären Decoder kann auch gleich die Stromversorgung
für die Decoder übernehmen. Daher sind nur 2 Kabel z. B. als Ringleitung nötig. Das beschreibt nur eine Möglichkeit. Ob das dann wirklich nötig ist, kann man bezweifeln.
Die wenigen kurze 3 Bytes Befehle (max. 7ms) an die Zubehördecoder spiele im Normalbetrieb keine Rolle. Und natürlich muss auch die MOBA-Software das Aufteilen möglich machen,

---

Hallo,

Das mit der DCC Limitierung höre ich zum ersten Mal, kann das jemand mal genauer erklären?

Für mich könnte das ein Thema werden, da:

* meine Loks maßgeblich DCC fahren

* 24 Loks gleichzeitig ich nenne das „unter DCC in Betrieb“, vielleicht nur 15-20 in Bewegung, Rest in Warteposition von WDP gesteuert

* Bremsen und Beschleunigung über Uhlenbrock IB 2 und WDP, allerdings habe ich die Loks auf einer IB2 und alle Schaltmagnetartikel (Motorolla und DCC) auf einer zweiten IB2

Wann passiert sowas? Wie macht sich das Bemerkbar? und was kann man dagegen tun?

Mit freundlichen Grüßen Manfred

Hallo Manfred!

Zitat von Fisch65 im Beitrag #18

---

Das mit der DCC Limitierung höre ich zum ersten Mal, kann das jemand mal genauer erklären?

---

Zitat von Fisch65 im Beitrag #18

---

Wann passiert sowas? Wie macht sich das Bemerkbar? und was kann man dagegen tun?

---

Zitat von Fisch65 im Beitrag #18

---

Das mit der DCC Limitierung höre ich zum ersten Mal, kann das jemand mal genauer erklären

---

Hallo Iwii, Eckhart,

Erstmal Danke für eure schnelle Antwort

Na ja, die zweite IB2 hilft schon, da die erste IB2 nur mit den Lokadressen belegt ist, keine der weiteren Dekoderansteuerungen, MLL Ansteuerungen, etc geht über die erste, sondern immer und ausschließlich über die zweite (komplett separater Stromkreis).

Wer kann ungefähr sagen, ab welcher Anzahl es Probleme mit DCC gibt? Kann man die DCC Belastung irgendwie auslesen?

Wenn parallel noch Motorola Decoder angeschlossen sind, macht das zusätzlich Probleme? Gibt es da auch ein Limit? Frage, weil ich die Lichter in den Waggons über separate Decoder schalten will, ca 50 Züge, die aber nicht alle direkt schalten müssen (heißt Zeitverzug ok) bzw. dauernd verändert werden. Das läuft aber auch über die Schienenspannung, also gleicher Stromkreis wie die DCC Loks.

Erhöht das noch die DCC Probleme?
Mit freundlichen Grüßen Manfred

Hallo Eckhart

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

Meine eigenen Decoder kann man nur über USB neu flashen. Daher nur ein Kabel anschließen.
Man kann auch gleich den ganzen NANO austauschen. Einfach ab an -- stecken.

Die CV-Konfiguration kopieren und als Datei Speichern geht. Die kann dann auch über DCC im POM Modus übertragen werden.
Mit entsprechenden Programmierkenntnissen ist auch ein Update über DCC möglich. Ich glaube das geht bei manchen Lokdecodern. ????

Frage was machst Du wenn der Decoder kaputt ist. Einen neuen mit WLAN an der Stelle neu hin beamen. Man findet immer ein wenn und aber.

Ich behaupte ja nicht das die neuen Bussysteme keine Voreile haben. Braucht man das aber wirklich und wird das auch wirklich von jedem Decoder unterstützt.
Die kommerziellen DCC-Zubehördecoder sind doch ausgereift und günstig. Die brauchen kein Update. Da Zicken schon er die neuen Systeme.

Die WS2811 bzw. 2812 werden über einen eigenen Datenbus gesteuert. Genauso wie du auch keine Servos direkt mit DCC oder sonst was ansteuerst. Du sendest nur welche Parameter aus der Tabelle/ Speicher verwendet werden sollen. Das PWM wird vom Decoder erzeugt, Der WS2811 Datensatz aktualisiert und als WS2811 Datensatz gesendet.

Du kannst aber über DCC oder was auch immer Befehle senden. Bei meinem DCC WS2811 Decoder für LED-Signale. Die Adresse sagt dann, was der WS2811 Bus ändern soll.
Ich habe dazu ein DCC WS2811 Decoder programmiert. Der 126 DCC-Adressen dafür bereit hält. Die MoBALedLib macht das nicht anders. Die Abläufe werden vorab in einer Tabelle konfiguriert.

Es kann sein das in der neuen ESP-Version noch mehr möglich ist. Für spezielle Anwendungen kann man ja ein ESP32 direkt dafür verwenden. Das mach ich auch mit meinem WiFi Handregler oder Z21 App so.

Das ein WLAN hier Vorteile hat, wenn in schneller Folge Befehle nötig sind, ist sicher richtig. Ich habe jetzt den WLAN als Alias für Bussysteme genannt!
Letztlich ist es auch egal, es muss jeder selber wissen, was er haben möchte bzw. auch wirklich gebrauchen kann.

Daher die Umfrage, was braucht Ihr wirklich. Ihr sollt hier keine Überzeugungsarbeit leisten. Ich bin nicht beleidigt, wenn ihr anderer Meinung seid.


Mit der DCC-Datenrate können die meisten nichts anfangen, und die ist auch nicht fix.
Es ist richtig das alle gemachten Lokbefehle + Funktionen reihum wiederholt werden. Aber nur dann wen gerade keine neuen Befehle anliegen.
Daher schätze ich das 80 bis 125 DCC-Befehle pro Sekunde auf den Gleis gesendet werden können. Die Spannweite entsteht einmal dadurch das ein 0 Bit 226 Mikrosekunden und 1 116 Mikrosekunden dauert. Die Präambel aus 10 oder 15 1 Bit sein kann. Der Datensatz mit Checksumme 3 Byte Zubehör, kurze Lokadr. mit 28 Fahrstufen, oder auch 5 Bytes lange Lokadresse 128 Fahrstufen bestehen kann. Die 15 Bit Präambel ist bei Railcom zwingen nötig. Wobei tatsächlich, ich glaube 4 Bits zeitlich übersprungen werden. Sendepause für Railcom!


Viele Grüße Martin

Hallo Martin,

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

Mit freundlichen Grüßen Manfred

Hallo Manfred,

das kann man nicht generell so sagen. Einmal kann das im Lokdecoder deaktiviert werden. Das bringt dann nichts für die Datenrate.
Kann aber für die Stromversorgung Vorteile bringen. Die Decoder verbrauchen Strom zum Senden, der nur aus den Kondensatoren kommen kann.
Die Gleisspannung ist ja für 4 Bits aus. Danach müssen die wieder geladen werden, bei viele Decoder gleichzeitig werden für sehr kurze Zeit hohe Ströme verbraucht.
Daher abschalten kann nicht schaden.
Bei der Datenrate sieht es anders aus. Falls die Zentrale die Präambel nicht auf 10 wechselt, bleibt alles beim Alten. Daher kommt auf die Zentrale an.
Ich würde mir aber wegen die max. 500 Mikrosekunden 0,5 Millisekunden kein Kopf machen. Ich denke neuere Zentralen senden 15 Bits, weil 10 Bits bits mit Railcom AN eventuell nicht funktionieren, Dann werden die Hersteller mit Reklamationen oder Fragen überschüttet.

Ich werde das demnächst mal testen.

Viele Grüße Martin

Zum Kondensatornachladen bei Railcom: Bei meinen Bastelleien rund um die Z21PG/Treiber IBT2 hab ich mich ausführlich mit der Erfassung des Stromes des Gleissignales beschäftigt, mit bis zu 10 Railcom-fähigen Decodern auf dem Gleis. Teilweise waren die Loks mit zusätzlichen Puffer-Elkos mit bis zu 1000µF ausgestattet, teilweise nackig. Die Stromspitzen nach der Railcom-Lücke waren vernachlässigbar, auf den Decodern vorhandene Kondensatoren dürfen beim Übertragen ja nicht vollständig entladen werden, der Controller der Decoder braucht ja mindestens seine 3,3V. Zuzüglich der Mindestspannung für den Spannungsregler muss der Kondensator also noch mindestens 4-5V haben. Bei einem einzelnen Railcom-Decoder kann man mit normaler Hobby-Messtechnik noch gar nichts messen, das geht im normalen Gezappel unter. Bei zehn Decodern war eine leichte Spitze von ca. 100 mA auf dem Oszi zu erkennen, währen der ersten Halbwelle des DCC-Signals.
Was die Protokollflut angeht: Ich für meinen Teil nutze ausschließlich DCC und S88 für die Rückmeldung, dabei erfolgt die auch Versorgung aller stationären Decoder (Weichen, Signale, Beleuchtung) via DCC. Allerdings seit Jahren ohne stromfressende Magnetartikel, grundsätzlich nur Servos. Für stationäre Decoder ggf. mit eigenem Booster. Hält die Verkabelung übersichtlich und die Fehlersuche einfach. Da ich meine stationäre Elektronik auch zum größten Teil selbst baue ist für diese Kombination auch die Auswahl an Projekten am üppigsten.