Hallo zusammen,

Ich hab im 'offenen RailCom Brief' auf O.Zoffis Idee für DCC (oder wie auch immer genannt) NEU
geantwortet.

Ich stell mir nun die Frage, ob es dafür überhaupt interesse gibt.
Oder ob O.Zoffi sich da nur mal über irgendein ärgerliches Detail Luft gemacht hat.
Ich selber denke mir durchaus, das DCC nun mal 20 ... 30 Jahre alt ist, und alleine
deswegen schon durch einen 'Nachfolger' abgelöst gehört.
In dieser langen Zeit sind die Prozessoren nun mal um vieles leistungsfähiger geworden,
haben einen massiven Preisverfall durchlaufen und es sind eben auch Techniken
'aufgetaucht', welche z.B.: über eine simple Telefonleitung gut 30MBit (ADSL) an Daten
schaufeln können.

Nimmt man das alles zusammen, dann sollte es, ohne enorme Mehrkosten, durchaus
möglich sein, eine deutlich bessere Digital Steuerung hinzubekommen.

Ich denke auch, das z.B.: mfx in Senderichtung mit den dynamisch langen Feldern für
Adresse, Befehl und Paramter da schon mal einen Anfang gemacht hat.
Nur mehr als ein Anfang ist das auch nicht, da könnte man noch einiges mehr herausholen.

Meine Frage ist nun, gibt es dafür Interesse, wollen 'wir' (MoBahner) so etwas, oder ist das
sowieso eine Nebensache, die gerade mal für einige wenige Freaks in Frage kommt.

Ach ja, an all die 'ist doch wieder nur teuer' Lamentierer:
Klar die erste System Generation, von wem auch immer wird was kosten, nur wenn das
System was bringt, werden früher oder später auch Billighersteller mitmachen.
Darauf müßt Ihr dann eben warten.

mfg
Mike

Antworte mal so: ist denn DCC schon auf jeder Anlage und jeder Lok implementiert! Reizt den wer DCC wirklich aus?

Hi,

Zitat von macbee

---

Antworte mal so: ist denn DCC schon auf jeder Anlage und jeder Lok implementiert!

---

Wahrscheinlich nicht. Darum geht es mir aber auch nicht.
Es gibt sicher noch Analog Fahrer, MM2, mfx, SX und was sonst auch immer.
Ich will jene auch gar nicht nun mit Gewalt was neues aufdrücken. Ich denke jeder
MoBahner betreibt sein Hobby unter anderem ja auch deswegen, damit er eben
sein höchst privates Königreich haben kann.
Damit hab ich kein Problem.

Zitat von macbee

---

Reizt den wer DCC wirklich aus?

---

Tja, siehe oben, mache fahren 'immer noch' Analog und sind damit zu frieden.
Meine Frage zielt aber auf jene, für die die DCC Fähigkeiten aus welchem Grund
einfach nicht mehr reichen.
Die Gründe hierfür können aber vielfältig sein. Das kann z.B.: ein komplett
vermurkstes Funktion Mapping sein (Ich denke das kommt von O.Zoffi) und
damit aufhören, das der Befehlsdurchsatz zwischen PC und Schiene einfach zu
lahm geworden ist.

Genau um das rauszufinden hab ich dieses Thema aufgemacht.
Eher aber nicht um rauszufinden, das es eine Menge gibt, welche sowieso zufrieden sind.
Das die Mehrheit offenbar mit allen DCC Unzulänglichkeiten zumindet leben gelernt hat,
ist mir schon klar, sonst hätte schon lange vor mir irgendwer die Idee gehabt so einen
Thread anzufangen.

mfg
Mike

Brauchen wir unbedingt ein neues DCC?
Doch muß eine Trennung zwischen FAHREN und PROGRAMMIEREN gemacht werden.
Im Fahrbetrieb ist, wenn ich mir das Protokoll anschaue, es doch mit den kurzen Informationen (3 oder 4 Byte) umfangreich. Was wird zu über 90% benötigt? Lokadresse mit Geschwindigkeitsangabe und/oder Funktionsinformation, sowie Stellbefehle für Decoder.
Doch bevor ich fahre muß ich den Decoder programmieren, zumindest die Lokadresse wenn mehr als eine Lok vorhanden ist. Die meisten Voreinstellungen reichen erst einmal aus, die Lok fährt (mehr oder weniger gut). Nun beginnt doch erst das Spiel mit der Programmierung. Ideal ist eine Zusammenfassung der CV's in einer Gruppe.
Eine Gruppe wären die Funktionen und Funktionsausgänge für Licht etc. Sinnvoll wäre ein Zusammenhang aller CV's hierfür.
Eine andere Gruppe ist für das Fahrverhalten der Loks zu nennen. Hier ist schon ein großer Umfang an CV's nötig, um optimale Eigenschaften einstellen zu können.
Eine dritte Gruppe wäre für den Sound etc zuständig. Hier tritt eine Überschneidung mit der ersten Gruppe auf, da ich den Sound etc auch teilweise über Funktionstasten steuern möchte. Doch eigentlich ist es keine Überschneidung, da ich eine Zuordnung bereits getroffen habe. Also wäre nur eine Programmierung der Eigenschaften notwendig.
Nun zu RailCom. Hier wäre eine eigene Gruppe sinnvoll. Da nun aber DCC vor Jahrzehnten entwickelt und genormt wurde, hat warscheinlich niemand an eine solche Möglichkeit gedacht. Aber wann wird RailCom übertragen? In den DCC-Pausen, die von der Zentrale gesteuert werden. Hier wäre der richtige Ansatz zur Änderung. Nach jeder Information eine Pause zum Empfang von RailCom. Die Begrenzung auf 2 Byte wäre sinnvoll, größere Informationen könnten dann in 2 Informationsblöcken gesendet werden. Zur Auswertung würde ein Bit reichen (weitere Info / keine weitere Info).

Bei einem Betrieb mit etwa 20 Loks gleichzeitig (ohne abgestellte Loks), die ständig Geschwindigkeits- oder Funktionsänderungen erhalten, gibt es keine Probleme. Demnach kann mit dem bisherigem DCC-Protokoll weiter gesteuert werden.
Was soll ein neues DCC bringen? RailCom-Auswertung wird nicht im DCC-Protokoll gemacht. Oder soll es nur wegen dem Alter des DCC sein?

Das waren nur mal meine Gedanken dazu.

Didi

Hi,

Zitat von mb-didi

---

Doch muß eine Trennung zwischen FAHREN und PROGRAMMIEREN gemacht werden.
Im Fahrbetrieb ist, wenn ich mir das Protokoll anschaue, es doch mit den kurzen Informationen (3 oder 4 Byte) umfangreich. Was wird zu über 90% benötigt? Lokadresse mit Geschwindigkeitsangabe und/oder Funktionsinformation, sowie Stellbefehle für Decoder.

---

Nun hier würde ich mal als erstes einhacken.
Fahrzeuge mit langen Adressen und 128FS brauchen schon 4Byte Befehle, nur damit ist es ja noch nicht
getan, für die Funktionen kommen dann nochmal bis zu 4 Befehle zu je 3/4 Byte hinzu, nicht zu vergessen,
das jeder dieser Befehle auch noch seine eigenen PreÄmbel Bits 'verbratet'.

Sofern ich da nun keinen echten Rechenfehler mache, dann kostet das ganze 18 Datenbytes und 5x12=60
PreÄmbel Bits. Aus meiner Sicht echt eine Menge, um gerade mal ein Fahrzeug zu steuern.

Zitat von mb-didi

---

Doch bevor ich fahre muß ich den Decoder programmieren, zumindest die Lokadresse wenn mehr als eine Lok vorhanden ist. Die meisten Voreinstellungen reichen erst einmal aus, die Lok fährt (mehr oder weniger gut). Nun beginnt doch erst das Spiel mit der Programmierung. Ideal ist eine Zusammenfassung der CV's in einer Gruppe.
Eine Gruppe wären die Funktionen und Funktionsausgänge für Licht etc. Sinnvoll wäre ein Zusammenhang aller CV's hierfür.
Eine andere Gruppe ist für das Fahrverhalten der Loks zu nennen. Hier ist schon ein großer Umfang an CV's nötig, um optimale Eigenschaften einstellen zu können.
Eine dritte Gruppe wäre für den Sound etc zuständig. Hier tritt eine Überschneidung mit der ersten Gruppe auf, da ich den Sound etc auch teilweise über Funktionstasten steuern möchte. Doch eigentlich ist es keine Überschneidung, da ich eine Zuordnung bereits getroffen habe. Also wäre nur eine Programmierung der Eigenschaften notwendig.

---

Richtig, auch hier ist einfach mal 'aufräumen' angesagt, und eine sinnvolle Gruppeneinteilung ist da
schon mal der erste Schritt.

Zitat von mb-didi

---

Nun zu RailCom. Hier wäre eine eigene Gruppe sinnvoll. Da nun aber DCC vor Jahrzehnten entwickelt und genormt wurde, hat warscheinlich niemand an eine solche Möglichkeit gedacht. Aber wann wird RailCom übertragen? In den DCC-Pausen, die von der Zentrale gesteuert werden. Hier wäre der richtige Ansatz zur Änderung. Nach jeder Information eine Pause zum Empfang von RailCom. Die Begrenzung auf 2 Byte wäre sinnvoll, größere Informationen könnten dann in 2 Informationsblöcken gesendet werden. Zur Auswertung würde ein Bit reichen (weitere Info / keine weitere Info).

---

Nun ich denke da hat RailCom einen ähnlichen Ansatz, die 'Lücke' gibt es nach jedem Befehl.
Diese Lücke ist in zwei Bereiche unterteilt:
A) Broadcast
B) Data Channel.
Der Data Channel kann statt 2 Byte 36Bits übertragen, der Unterschied ist aber eher eine rein technische Sache,
und hat mit den 'High-Level' Anwendungen nicht viel zu tun.
'Verlängerungen' sind hingegen derzeit nicht bekannt, wohl aber sinnvoll, auch mit 36Bit kann ein Dekoder
nicht 'alles' am Stück senden.

Ein weitere Ansatz ist ganz sicher, diese RailCom Lücke auch gleich als PreÄmbel zu nutzen.
Die trennt ja sowieso schon vollkommen klar einen Befehl von einem weiteren, einfach weil sie
nun mal genau 'dazwischen' vorhanden ist.
Alleine dadurch würden im obigen Beispiel schon mal 5x12=60 PreÄmbel Bits wegfallen, das würde
zusätzliche 60/9 DCC Befehlsbytes ergeben, oder mehr als ein normales Kommando braucht.

Zitat von mb-didi

---

Bei einem Betrieb mit etwa 20 Loks gleichzeitig (ohne abgestellte Loks), die ständig Geschwindigkeits- oder Funktionsänderungen erhalten, gibt es keine Probleme. Demnach kann mit dem bisherigem DCC-Protokoll weiter gesteuert werden.
Was soll ein neues DCC bringen? RailCom-Auswertung wird nicht im DCC-Protokoll gemacht. Oder soll es nur wegen dem Alter des DCC sein?

---

Nun ich denke da an:
- Anlagen mit doch deutlich mahr als 20 Fahrzeugen
- An eine Absicherungen (Keine Rückmeldung ==> Befehl nicht angekommen)
- An ein schnelleres Protokoll
- An eine bessere Konfig Logik.

Tja und natürlich auch an Dinge, die mir alleine eben nicht einfallen.

mfg
Mike

Zitat von MikeF

---

Nun ich denke da an:
- Anlagen mit doch deutlich mahr als 20 Fahrzeugen
- An eine Absicherungen (Keine Rückmeldung ==> Befehl nicht angekommen)
- An ein schnelleres Protokoll
- An eine bessere Konfig Logik.

---

Und wieviel % der "normalen" Modellbahner brauchen das? Vernachlässigbar wenige, mutmaße ich. Man kauft ja auch keinen 7,5-Tonner, wenn man nur ein paar Maggiwürfel transportieren will.

Hi,

Zitat von HaJoWolf

---

Und wieviel % der "normalen" Modellbahner brauchen das? Vernachlässigbar wenige, mutmaße ich. Man kauft ja auch keinen 7,5-Tonner, wenn man nur ein paar Maggiwürfel transportieren will.

---

Nun unter anderem ja dieser Thread.
Wenn sich da nur 'Brauch ich nicht' Freunde melden, ... dann scheint es tatsächlich keiner zu brauchen.
Oder ich hab die Frage im falschen Forum gestellt.

Ich kann nur von mir sprechen, ich gehör zumindest zu jenen, die einen 7,5Tonner haben, aber
eigentlich Bedarf für einen 100Tonner haben.

mfg
Mike

Hallo Mike,

ich antworte mal von der technischen Seite, zuerst mal prinzipiell (und frei von 'wer braucht das'-Überlegungen): Zur Lok muß Energie und Daten, zurück nur Daten. Es steht eine unsichere Zweidrahtverbindung zur Verfügung.
Energie: hier muß ich leider auf die Kosten (und auf die Energieeffizienz) schielen und da ist durchgeschalteten FETs klar der Vorzug zu geben vor irgendwelchen pegelmäßig codierten Signalen zu geben.
Daten: downstream (man verzeihe mir hier Anglizismen) haben wir broadcast, es kommt also auf Reaktionszeit und Datendurchsatz an. Neben der bisher bekannten Zeitkodierung des Energiesignals fällt mir da auch ein Zeitmultiplex zwischen Energie und eingestreuten Datenpaketen ein. Die Datenpakete müssten relativ lange Symboldauern und hohe Redundanzen haben, wie z.B. eine OFDM mit vorgeschaltetem Interleaver. Sowas kann man mit aktuellen Prozessoren erzeugen und auch auswerten - wobei man sich nach der Decke der verfügbaren, integrierten A/D- und D/A-Wandler strecken muß.
Daten: upstream ist es Punkt-zu-Punkt, man muß also eine Art Multiplex (egal in welcher Domain: Zeit, Frequenz, Code) einführen, um individuelle Nachrichten zu haben.

Soweit theoretische Überlegungen - jetzt kommen die 'aber':
Das macht nur Sinn, wenn es mit vorhandenem Material zusammenspielt. Also bleibt da DCC (quasi als Energieträger) und da werden die neuen Pakete eingestreut.
Ein solcher Entwurf macht nur Sinn, wenn das gut verbreitet verfügbar ist, also die 'Großen' einsteigen. Und die werden schon genau fragen 'wer braucht das?' und 'wieviel Umsatz bringt mir das pro eingesetzte Entwicklerstunde?', also die oben angeschnittene 7,5to Frage.

Da sollten wir uns lieber zuerst mal Gedanken machen, was man aus DCC (also der bisherigen Physik) rausholen kann. Sowas kann man nämlich dann mit geringerem Aufwand und ev. updatefähig hinbringen.

Einen seriellen Datenstrom muß man im Empfänger partionieren - dazu wird i.d.R. eine Verletzung der Kodierregel als Framekennung verwendet - im Falle DCC sind das 10 aufeinanderfolgende 1-Bits, also die Framekennung erfolgt hier erst auf Layer 1. Wenn man da in der Layer 0 geht (also die Bitkodierung), wäre schon viel gewonnen. Wie Du schon geschrieben hast: Cutout bietet sich an (und das macht auch SX so). Des weiteren wird ja DCC i.d.R. mit einem Prozessor dekodiert, die an RS232 angelehnte Kodierung mit Trennbyte und folgendem XOR ist (etwas überspitzt forumliert) Bandbreitenverschwendung. Hier eine aktuelle Fehlerkorrekturtechnik eingesetzt ... würde zum einen die Gefahr falschen Empfanges verringern und auch den Durchsatz verbessern.
mfg W.K.

Es ist jedem bewusst, das wenn man heute ein Protokoll entwickeln würde vieles anders gemacht werden würde! Aber die Masse ist noch nicht mal soweit, das die moderne DCC zentralen einsetzt und gerade bei DCC sind die analogies sehr zahlreich!

Daher sollte man zwar nachdenken und planen aber zuerst zusehen, dass das was am Markt ist gekauft wird! Diese Erlöse finanzieren dann DCC 2!

Anders sieht es bei MFX aus! Hier müsste maerklin gleich zwei Dinge endlich machen!!!! Alle FX Decoder aus allen Loks verbannen und nur noch MFX Decoder verbauen und zweitens das Protokoll weiterentwickeln! Die installierte Basis ist hier ja wirklich da!!!

Cheers

Eine Modelleisenbahn ist ein langfristiges Projekt und reicht bis zu 50 Jahre in die Vergangenheit. Heute muss sie bis 1960 kompatibel sein, im Jahre 2020 bis 1970. DCC, Mfx und MM wird also noch dreißig Jahre lang aktuell sein. Ein neues Protokoll ist immer zusätzlich, niemals Ersatz.

Ich plane, als DCC-Mfx-MM-Ersatz oder -Zusatz etwas nach Industrie-Standard (WLAN, Bluetooth, ...), nichts Moba-spezifisches, einzusetzen. Wer damit auf den Markt kommt, hat mich als Kunden. Moba-spezifische Lösungen werde ich wohl auslassen.

Anreize schafft man, in dem man seine Produkte effizienter macht (der Motor, der weniger verbraucht; der Computer, der weniger kostet; das Kraftwerk, das weniger Emissionen ausbringt). Viele Moba-Hersteller gründen ihr Dasein aber auf der Sucht ihrer zahlenmäßig weniger werdenden Konsumenten und machen das Gegenteil von Kostenreduzierung: sie erhöhen scheinbar den Wert ihrer Produkte, um höhere Stückpreise verlangen zu können. So lange ich den Verdacht habe, dass ein weiteres Protokoll entsprechend dienen soll, versuche ich, es zu meiden.

Ich schätze Innovation - aber nicht, um gemolken zu werden.


Sollte ich da alleine mit meiner Meinung sein, ist es für DCC 2 nicht schlimm.

Moin Mike,

Zitat von MikeF

---

Nun ich denke da an:
- Anlagen mit doch deutlich mahr als 20 Fahrzeugen
- An eine Absicherungen (Keine Rückmeldung ==> Befehl nicht angekommen)
- An ein schnelleres Protokoll
- An eine bessere Konfig Logik.

---

Die Auflistung enthält keine Funktion für den normalen MoBa-Kunden (ein paar Technik-Freaks ausgenommen), also für den Kunden der das Zeug kaufen soll. Man kann die Kunden nur mit konkreten praktisch nutzbaren Features locken. Weil mit (leider) auch nichts gescheites für die MoBa einfällt, gebe ich ein Beispiel aus einem anderen Bereich. Ein neues PKW-Modell wird dem Kunden auch nicht dadurch angeprießen, indem man beschreibt, das eine neue Generation von Einspritzpumpe zum Einsatz kommt, welche den Treibstoff um xx% feiner vernebelt als das Vorgängermodell. Nein man wirbt damit, das der Wagen einen halben Liter weniger Treibstoff verbraucht.

Hi,

Zitat von Andi

---

Die Auflistung enthält keine Funktion für den normalen MoBa-Kunden (ein paar Technik-Freaks ausgenommen), also für den Kunden der das Zeug kaufen soll. Man kann die Kunden nur mit konkreten praktisch nutzbaren Features locken. Weil mit (leider) auch nichts gescheites für die MoBa einfällt, gebe ich ein Beispiel aus einem anderen Bereich. Ein neues PKW-Modell wird dem Kunden auch nicht dadurch angeprießen, indem man beschreibt, das eine neue Generation von Einspritzpumpe zum Einsatz kommt, welche den Treibstoff um xx% feiner vernebelt als das Vorgängermodell. Nein man wirbt damit, das der Wagen einen halben Liter weniger Treibstoff verbraucht.

---

Absolut richtig.
Als Webeaussage bringt es kaum was zu sagen, das das neue Protokoll nun 5fach schneller
ist als DCC (Noch schlimmer wenn man da die Symbolzeitreduktion angeben würde).
Als Werbespruch würde sich da eher eignen, das man nun 50 Züge viel zuverlässiger als
10 DCC Züge steuern kann.
Auch da werden sich zwar einige denken: 'Was soll ich mit 50 Zügen', nur eine Menge werden
sich dann denken, das sie mit Ihren 5 Zügen schon genug ärger haben, und wenn das Ding
nun 50 schafft, dann sollten die 5 Züge in jedem Fall keinen Ärger mehr machen.

Andere werden das Ding nehmen, weil sie ganz grundsätzlich 'überdimensionieren', ...

Ich wollte aber mit Absicht keine Werbesprüche ablassen, ich wollte eher rausfinden, was
den nun die Schwachstellen sind, und ob es für die überhaupt eine Lösung geben kann.

Nur irgendwie scheint das nicht so recht zu klappen. Es wird hier (Stummi Forum allgemein)
über alle möglichen und unmöglichen Ärgernissen mit DCC lamentiert, aber so recht auf
den Punkt will das wohl keiner bringen.

mfg
Mike

Hallo Mike und die anderen Vorausdenker,

klar, ich bin mir bewusst, dass ein bidirektionaler schneller Funkverkehr das Optimum wäre. Aber sinnieren wir doch einfach mal, ob wir mit dem bereits vorhandenen die Situation wesentlich verbessern könnten.

Eigentlich haben wir schon fast alles, was wir benötigen. Man muss es nur sinnvoll kombinieren.

Was stört uns am derzeitigen DCC?
- Viel Schienenbandbreite für wenig Information (Viele Präambelbits, 4-Byte-Befehle, XOR als Checksumme).
- Die CV-Struktur ist suboptimal.

Was stört uns am derzeitigen RailCom?
- Der Rückmeldung mangelt es an Energie. Die Speed wäre aber da.

Wenn wir jetzt die Vorteile von mfx mit der RDS-Strom-Rückmeldung und DCC (RailCom-Rückmeldung) + Protokollerweiterungen sinnvoll kombinieren würden, hätten wir doch schon fast alles was wir benötigen.

- Als schnelles Protokoll von der Zentrale zur Schiene bietet ein erweitertes mfx mit ständiger Rückmeldung gem. RailCom, aber nicht in spannungslosen Datenpausen, sondern unter Dampf wie beim mfx-RDS, nur eben mit der Speed von RailCom, eigentlich alles bisher Benötigte.

Das mfx-Protokoll ist, vereinfacht betrachtet, ein sinnvoll abgespecktes DCC. Dagegen ist nichts einzuwenden. Framegrenzen werden, wie weiter oben schon gefordert, durch eine gezielte Protokollverletzung angezeigt. Weiterhin gibt es eine richtige CRC-Checksumme. Es sind sinnvolle Befehle für eine objektorientierte CV-Struktur vorhanden. Was fehlt ist eine kontinuierliche Befehlsquittierung/Rückmeldung wie bei RailCom. Das könnte man aber problemlos einbauen.

Was bei mfx aber nicht so ideal ist, das ist die langsame RDS-Rückmeldung. Dafür liegt bei der Rückmeldung aber Versorgungsspannung am Gleis. Und genau da würde ich ansetzen. Statt nun mit der langsamen RDS-Speed rückzumelden, würde ich jetzt die Spannung eingeschaltet lassen und mit 200mA oder sogar noch größeren 250kBit RS232-Strom-Pulsen (gem. RailCom-Spec) bei eingeschalteter Versorgungsspannung zurücksenden, und da auch wieder mind. 2 Kanäle und ein/mehrere Strom-Status-Bit(s). Das bringt eine wesentlich bessere Rückmeldesicherheit.

RailCom krankt ein wenig an der Empfindlichkeit. Mit 45mA bei einer größeren Anlage vom hintersten Winkel aus senden, ist einfach fast nicht mehr machbar, besonders bei der elektrischen Verschmutzung durch die PWM der Lokmotoren. Und dafür kurzzeitig alles Abschalten ist ein Aufwand, der vermeidbar wäre.

Zusätzlich wird vereinbart, dass jeder Schienenbefehl direkt per RailCom, oder sogar noch einfacher, nur durch ein (Strom-)Bit quittiert wird. Man kann daher die Bandbreite fressenden sinnlosen Befehls-Wiederholungen drastisch zurückfahren und dadurch richtig viel Schienenbandbreite sparen.

Als weitere Massnahme würde ich Befehle einführen wie z. B. mit der im Decoder eingestellten ABV und/oder eingestelltem konstantem Bremsweg abbremsen. Auch dieser Befehl wird quittiert. Damit versende ich von der Zentrale aus nur einen einzigen kurzen Schienen-Befehl und kann mich dann darauf verlassen, dass der Decoder das verstanden hat und das auch tut, was er soll, sofern er ordentlich versorgt wird. Ebenso für das Anfahren. Ein Befehl genügt und nicht für die ansteigenden Fahrstufen einen ganzen Blumenstrauss von Fahrbefehlen. Das ist unnötig, auch heute schon.

Weiterhin würde ich noch so was wie diese assymetrische Betriebsspannung für Bremsstrecken einbauen, damit man Blockbetrieb auch ohne Zentralen-Befehle dezentral nur vom Signal ausgelöst, steuern kann.

Wie die Rückmeldung einer Weichenlage oder Belegtmeldung über das Gleis ohne viel Latenz (= Verzögerung) gemacht werden kann, da habe ich momentan noch keine brauchbare Idee. Das gebe ich ganz offen zu.

Was man mit den o. g. Kombinationen aber schon erschlagen kann ist folgendes:
- Schnelles Gleisprotokoll
- Lokpositionsrückmeldung (zumindest Abschnittsweise) durch in die Zuleitung eingeschleifte Stromsensoren möglich (weil jeder Fahrbefehl durch einen Hochstrom-Impuls von dem angesprochenen Decoder quittiert wird).
- Halbwegs sicheres schnelles Rückmelden über Hochstrom-RailCom-Datenpakete zwischen den Datenframes, wobei ein CutOut nicht nötig ist, weil in der Zeit, wie bei RDS, Spannung anliegt.

Alle diese bisher angeführten Verbesserungen beruhen nur auf einer Kombination von den guten Eigenschaften von den bisher auch schon vorhandenen Protokollen und HW und sind zu dem bisherigen DCC/MM/mfx vollkommen kompatibel.

Gruss

est2fe

Hallo Mike,

Zitat

---

Ich wollte aber mit Absicht keine Werbesprüche ablassen, ich wollte eher rausfinden, was
den nun die Schwachstellen sind, und ob es für die überhaupt eine Lösung geben kann.

Nur irgendwie scheint das nicht so recht zu klappen. Es wird hier (Stummi Forum allgemein)
über alle möglichen und unmöglichen Ärgernissen mit DCC lamentiert, aber so recht auf
den Punkt will das wohl keiner bringen.

---

Genau an den "Werbesprüchen" wird es aber scheitern. Andi hat es auf den Punkt genau getroffen, ein neues Protokoll in einem stagnierendem Markt braucht ganz viele "Willhaben-Funktionen", um überhaupt eine Chance zu haben.
Ein Protokoll, welches einfach nur besser, schneller ist wird kaum jemanden interessieren, wenn das alles ist. Mit den bereits vorhandenen Technologien wird bereits vieles abgedeckt oder könnte abgedeckt werden. Sicher gibt es noch ein paar Wünsche vom mfx-Lager, sicher ist in RailCom-City noch einiges offen aber so lange da kein wirklicher Mehrwert drin ist wird da keiner gross investieren.

Als nächstes frage ich nach den "möglichen und unmöglichen Ärgernissen mit DCC", welche im Stummiforum diskutiert werden. Hast Du dazu ein Beispiel? Mir fällt da jetzt kein Ärgernis ein, über welches da so lamentiert worden ist.

Zitat

---

Als Werbespruch würde sich da eher eignen, das man nun 50 Züge viel zuverlässiger als
10 DCC Züge steuern kann.
Auch da werden sich zwar einige denken: 'Was soll ich mit 50 Zügen', nur eine Menge werden
sich dann denken, das sie mit Ihren 5 Zügen schon genug ärger haben, und wenn das Ding
nun 50 schafft, dann sollten die 5 Züge in jedem Fall keinen Ärger mehr machen.

---

Auch hier weis ich weder was von unzuverlässigen 10 Zügen, noch von 50, erst Recht nicht von 5, die Ärger machen. Und selbst wenn es bei 50 Zügen ständig und nachvollziehbar Ärger gäbe würde ich mir das schon sehr gut überlegen, ob ich meine zuverlässige 5-Züge-Anlage auf das neue System (zumindest um den Austausch der Decoder wird man nicht herumkommen) umrüste, weil es dann mit 50 Zügen genauso zuverlässig funktioniert.

Das hat alles nichts mit "brauch ich nicht" zu tun, etwas Neues muss auch greifbar neues bieten, nur besser sein reicht nicht.

Hallo,

Zitat von est2fe

---

...Wie die Rückmeldung einer Weichenlage oder Belegtmeldung über das Gleis ohne viel Latenz (= Verzögerung) gemacht werden kann, da habe ich momentan noch keine brauchbare Idee...

---

Alles was nicht aufs Gleis muss, hat nichts auf dem Gleis verloren.
Wer sich das Gleissignal mit Weichen- u. Signalbefehlen zudröhnt, ist selbst Schuld, wenn die Latenz der Lok-Befehle leidet.
Die Lösungen dafür sind aber auch schon lange bekannt und werden praktiziert.
LocoNet, CBus usw. lassen grüßen, Rückmeldung inklusive.

Es grüßt RainerK

Zitat von MikeF

---

..... Es wird hier (Stummi Forum allgemein)
über alle möglichen und unmöglichen Ärgernissen mit DCC lamentiert, aber so recht auf
den Punkt will das wohl keiner bringen....

mfg
Mike

---

Moin Mike,



Du hast Dich sicher verschrieben und meinst mfx.

Von diesen Problemen kann man fast täglich in "Digital" lesen.

MFX Loks melden sich zum verrecken nicht an und sind auch nach Stunden von Tests nicht zum Laufen zu bringen.

Ist mir bei DCC in 5 Jahren noch nie passiert.

DCC alt ist fürnmich vollkommen ausreichend und absolut stabil. Was "Neues" will ich mir nicht antun.


Gruß Markus

Zitat von Marky

---

DCC alt ist fürnmich vollkommen ausreichend und absolut stabil. Was "Neues" will ich mir nicht antun.

---

Sehe ich auch so. Mfx und MM gönne ich mir zusätzlich für die Altlasten.

Es sei denn, es gibt ein System, welches günstiger ist. Dann würde ich es zu den drei bestehenden Systemen hinzufügen. Bis auf wenige Technik-verliebte und experimentierfreudige Ausnahmen erwarte ich nur von Neueinsteigern, dass sie sich ausschließlich für ein viertes neues System entscheiden würden.

Hallo Rainer,

Zitat

---

Wer sich das Gleissignal mit Weichen- u. Signalbefehlen zudröhnt, ist selbst Schuld, wenn die Latenz der Lok-Befehle leidet.

---

Diese Aussage kenne ich sehr gut. Sie war in den Anfängen bei der MoBaSbS sehr oft benutzt worden und wird dort auch konsequent gelebt.

Da würde mich wirklich einmal interessieren, ob das so ist. Da habe ich Bedenken. Wenn es jemand gibt, der bei einer mittleren Anlage (sagen wir mal 10 gleichzeitig fahrende Loks und 50 - 100 Weichen/Signale, wo ein Teil davon auch im Betrieb geschaltet werden müssen) mir dazu mal statistische Daten liefern könnte, dann wäre das einfacher, solche Aussagen zu bewerten.

Dazu habe ich folgende Fragen:
- Wie viele wirklich benötigte Lokbefehle / Sekunde werden im Normalfall über das Gleis gesendet?
- Wie viele Weichen/Signalbefehle werden in 10 Sekunden im allgemeinen benötigt?

Dann bilden wir da mal vom zeitlichen Aufwand her einen Quotienten und überlegen uns dann, ob wir weiter darüber diskutieren müssen.

Bisher war keiner der Gefragten in der Lage, mir da wirklich verlässliche Daten herbeizuschaffen.

Gruss

est2fe

Zitat von est2fe

---

Wenn es jemand gibt, der [...] mir dazu mal statistische Daten liefern könnte, dann wäre das einfacher, solche Aussagen zu bewerten.

---

Bei Teppichbahn-Treffen, wenn mit dem Ein-Zentralen-Prinzip an fünf oder mehr Stellen gleichzeitig Aktivitäten sind und sieben oder acht "Bahnfahrer" und "Fahrdienstleiter" tätig werden, kollabiert so ein System auch schon mal. Liegt aber oft an den Zentralen oder irgendwelchen anderen der mannigfachen Möglichkeiten einer Fehlfunktion und alle unterschiedlichen Kanäle sind gleichermaßen betroffen, auch der parallel aufgebaute Bus (Loconet, Easynet etc.).

Eine qualitative Aussage, wie belastet ein einzelner Kanal ist, ist das allerdings nicht.

Hallo Markus,

Zitat

---

MFX Loks melden sich zum verrecken nicht an und sind auch nach Stunden von Tests nicht zum Laufen zu bringen.

---

das ist ein anderes Problem und tritt nur mit den neueren Zentralen auf. Bei der MS1 habe ich das bisher noch nicht erlebt, sofern da technisch alles in Ordnung war. Bei der MS1 gibt es den mfx-Verify-Befehl, der für jede Lok zyklisch immer wieder gesendet wird. Dieser wurde bei neueren Zentralen z. T. weggelassen (Schienenbandbreite?). Offensichtlich sorgt der aber dafür, dass dieses Verhalten des nicht Anmelden wollens da wohl nicht auftritt.

Fazit: Wenn man das, was es derzeit schon gibt, richtig einsetzten würde, hätte man weniger Probleme.

Gruss

est2fe

Zitat von Marky

---

MFX Loks melden sich zum verrecken nicht an und sind auch nach Stunden von Tests nicht zum Laufen zu bringen.

---

Das kenne ich als reproduzierbares Verhalten auch bei ECoS I bzw. CentralStation I, wenn eine Mfx-Lok mit fliegendem Wechsel von einer Mfx-Zentrale zur anderen Mfx-Zentrale geschickt wird (also ohne kurze Pause in der Stromversorgung; wenn man nicht vergisst, sie für eine Sekunde stromlos zu schalten, passiert das nicht).

Hallo est2fe,

die Frage zur realen Belastung und Latenz ist natürlich berechtigt.
Das es dazu nur wenige qualifizierte Antworten gibt, liegt wohl im wesentlichen daran, dass jede Zentrale - insbesondere bei Multi-Protokollbetrieb -
eine andere Anzahl von Befehlswiederholungen, Algorythmen der Slots u. Wiederholungen und Dauer von Umschaltzyklen verwendet.
Verlässliche Analysen verschiedener Zentralen bei unterschiedlichen Slotbelegungen sind da wohl mehr als wünschenswert.

Unabhängig von der Auslagerung der Zubehörsteuerungen (Weichen, Signale usw.) in separate Bussysteme,
ist anstelle von Einzel-Fahrstufen nur ein Befehl mit der gewünschten Ziel-Geschwindigkeit und Nutzung der Dekoder-Anfahr-/Brems-Verzögerung,
die vielversprechenste Möglichkeit zur Reduzierung der Gleis-Daten-Last, selbst wenn der Befehl zur Sicherheit noch zweimal wiederholt wird.

Bei den bekannten Steuerprogrammen ist das - soweit mir bekannt - im Automatikbetrieb ohnehin die einzige Möglichkeit wie Lokbefehle gesendet werden.

Es grüßt RainerK

Zitat von Muenchner Kindl

---

einem stagnierendem Markt

---

Dürfte das Hauptproblem sein.

Hätte die Modellbahnbranche ein Wachstum wie div. andere boomende Branchen, gäbe es auch Innovationen en masse.


Ärgernisse mit DCC hatte ich auch noch nie. Meine Zentrale ist zwar auch schon 13 Jahre alt, stellt aber so manche aktuelle Zentrale noch in den Schatten.
Robust, zuverlässig, langlebig - mit der Lenz LZ100 hab ich glaub das Optimum erwischt..

Grüße
Torsten

Hallo!
Da ich ja erwähnt wurde und nun lese, dass es offenbar gar keine "Ärgernsise mit DCC" gibt ... nun ja, wer eine digitale Steuerung nur als Mehrzugsteuerung benutzt, wird kaum Ärgernisse finden - bis auf die Üblichen, begründet durch zu wenig Leistung, oder unzureichender Kurzschlußerkennung etc. (DAS hat aber mit dem Protokoll an sich nichts zu tun).

Auch die Aussage "alles was nicht zur Steuerung von Loks dient, gehört nicht ans Gleis", kann ich SO nichts abgewinnen! Imho ist das mehr als kurzsichtig! Eine vernünftige digitalte Steuerung MUSS mit den sprichwörtlichen zwei Kabel auskommen!
Schlimm genug, dass bisher für Rückmeldungen u.ä. diverse "Busse" gezogen werden mussten, oder dass vielfach unter digital ein Halteabschnitt noch immer nur stromlos geschalten wird!

Das die Rückmeldung welche Lok(s) in welchen Abschnitt(en) wo stehen, entweder gar nicht, oder mit RailCom nicht ganz so wie erwünscht realisiert sind - na ja, wenn das für Euch kein Thema ist, gibt es einen Ärgernispunkt weniger ...

Das wir bei DCC inzwischen zwar bis zu 28 Funktionen übermitteln, das NMRA-Funktionmapping, welches ja angebliche DER Standard ist, nicht einmal die bisherigen 14 Funktionen barierefrei berücksichtigt, oder dass wir mit 5stelligen Adressen zurecht kommen müssen (für die USA, deren Loks all nur maximal 4 Stellen haben, reicht das alles aus - bei europäischen Loks müssen wir uns was einfallen lassen ... tun auch offenbar alle, sonst gäbe es da weit mehr Geschrei)

Die ganze Diskussion über die Fahreigenschaften wegen bremsen oder variabler Zugmasse und passenden Sound - derzeit SO nicht wirklich realisierbar - scheint eh dem Großteil wurscht zu sein.

Weiter zu den Consistadressen, die ja nur bis maximal Adresse 127 möglich sind ... und wenn ich mich noch anstregen, finde ich ganz sicher noch weitere Kritikpunkte, die *heute* einfach nicht mehr zeitgemäß sind und sich dank neuer Technik sicher großteils beheben lassen.

Vielleicht brauch man dazu ja gar kein neues *Protokoll*, sondern nur eine neue "CV-Verwaltung", sowohl im Fahrpult/Zentrale, als auch im Decoder.
Nur gehört DAS auch zu DCC! Und wenn man das alles ändert, wäre es ja bereits "DCC2" ...

Derzeit wird aber lediglich um ein bestehendes altes Protokoll / CV-Verwaltung Anbauten erstellt, die eigentlich mehr Löcher aufreißen, als sie schließen.

Hi,

Danke est2fe, auf so einem Beitrag habe ich gehofft.

Zitat von est2fe

---

Was stört uns am derzeitigen DCC?
- Viel Schienenbandbreite für wenig Information (Viele Präambelbits, 4-Byte-Befehle, XOR als Checksumme).
- Die CV-Struktur ist suboptimal.

Was stört uns am derzeitigen RailCom?
- Der Rückmeldung mangelt es an Energie. Die Speed wäre aber da.

---

Zusätzlich würde ich noch meinen, das die möglichen/definierten RailCom Meldungen noch
SEHR beschränkt sind. Gerade mal CV lesen und Speed Meldung ist nicht gerade umfangreich.

Zitat von est2fe

---

- Als schnelles Protokoll von der Zentrale zur Schiene bietet ein erweitertes mfx mit ständiger Rückmeldung gem. RailCom, aber nicht in spannungslosen Datenpausen, sondern unter Dampf wie beim mfx-RDS, nur eben mit der Speed von RailCom, eigentlich alles bisher Benötigte.

---

Nun eine Befehlsquittierung ist bei mfx vorhanden, jeder mfx Dekoder sollte eine 2Bit Meldung abgeben
(Befehl erhalten, Ausführung, ...)
Allerdings wird dies mal so mal so gehandhabt, wieso ist mir allerdings unklar.

Zitat von est2fe

---

Was bei mfx aber nicht so ideal ist, das ist die langsame RDS-Rückmeldung. Dafür liegt bei der Rückmeldung aber Versorgungsspannung am Gleis. Und genau da würde ich ansetzen. Statt nun mit der langsamen RDS-Speed rückzumelden, würde ich jetzt die Spannung eingeschaltet lassen und mit 200mA oder sogar noch größeren 250kBit RS232-Strom-Pulsen (gem. RailCom-Spec) bei eingeschalteter Versorgungsspannung zurücksenden, und da auch wieder mind. 2 Kanäle und ein/mehrere Strom-Status-Bit(s). Das bringt eine wesentlich bessere Rückmeldesicherheit.

---

Richtig, eine Rückmeldung bei voller Versorgung wäre deutlich besser.
Allerdings ist dies auch eine technische Herausforderung. Bei voller Spannung arbeitet ja alles
einfach mal weiter, das ist ja genau der Vorteil. Nur dadurch hat man am Gleis auch alle
Störungen (besonders die Motor PWM's). Die aber aus einem in jedem Falle sehr geringen
'Datenstrom' rauszufiltern ist keine simple Sache.
Märklin hat es sich da einfach (aber eben auch lahm) gemacht, die verwenden RDS Chips
und die sind duch jahrelangen Entwicklungsaufwand eben genau auf diese Probleme
hingetrimmt worden.
Eine RDS Artige Lösung, welche statt 57kHz z.B.: 570kHz verwendet, würde etwa 10fach
schneller sein. Das ist mit modernen DSP's noch kein Problem, aber immer noch um einiges
langsamer als RailCom. Viel weiter hinauf darf man sich aber nicht wagen, sonst braucht
jeder zumindest eine Amateufunklizenz, ...

Zitat von est2fe

---

Zusätzlich wird vereinbart, dass jeder Schienenbefehl direkt per RailCom, oder sogar noch einfacher, nur durch ein (Strom-)Bit quittiert wird. Man kann daher die Bandbreite fressenden sinnlosen Befehls-Wiederholungen drastisch zurückfahren und dadurch richtig viel Schienenbandbreite sparen.

---

Das denke ist eine echt einfache Sache.

Zitat von est2fe

---

Als weitere Massnahme würde ich Befehle einführen wie z. B. mit der im Decoder eingestellten ABV und/oder eingestelltem konstantem Bremsweg abbremsen. Auch dieser Befehl wird quittiert.

---

Auch richtig, generell könnte man durch eine Befehlssatz Optimierung eine Menge erreichen.
Wenn diese mit einer Art Acknowledge kombiniert ist, schafft man recht bequem den Mehrfachen
Durchsatz.

Danke, genau an solche Beiträge habe ich beim Start des Themas im Sinn gehabt.

mfg
Mike