Mfx und DCC

#101 von aftpriv , 08.04.2018 12:29

Hallo Foianer

warum versteift Ihr Euch immer auf einen PC um eine komplexere Anlage zu steuern und sicher am Laufen zu halten. Es bedard (kann aber natürlich ein PC odr Laptop sein, finde ich aber eine Verschwendung von teuerer Hardware) lediglich eines Einplatinencomputers (z.B. Rasperry-, (ich verwende den) BananaPi oder BeagleBoneBlack um eine mächtige Steuerung laufen zu lassen, bei mir ist es Rocrail (€ 12,Jahr als Unterstützung) das via CAN-Bus eine Gleisbox steuert, später kommen noch Booster hinzu, da ganze läuft 7/24, da der Stromverbrauch nur ca. 5W/Stunde ist. Für Rückmeldungen, Anzeigen Ansteuerungen (von z.B. Weichen) ist RocnetNode per I2C auf einem oder mehreren RaspberryPi´s implementiert. Zur Anzeige des Gleisbildstellwerkes und der Lokregler ist jedes Gerät mit HID geeignet. Dieses System habe ich ausgewählt, weil es mächtig und sehr kostengünstig ist.

Wenn ein Mobahner aber das obige Setup nicht benötigt ist eine handelsübliche Zentrale (und er damit auskommt) die richtige Option. Wenn es aber damit nicht ausreicht: sieh oben, dann ist eine handelsübliche Zentrale aber reine Geldverschwendung

Gruß
Alf

PS: Railcom und mfx verwende ich auf meiner Anlage nicht

#102 von MariusS ( gelöscht ) , 08.04.2018 12:55

Hallo,

Zitat

Weil das Abschneiden alter Zöpfe zwangsläufig zu Inkompatibilitäten führt. Mich stört am meisten das Heckmeck um die langen und kurzen Adressen bei DCC. Prinzipiell würden die langen Adressen ausreichen, denn auch die können Adressen ab 1 abbilden. Man wird das aber nicht los, weil per Default alle Decoder mit kurzer Adresse 3 ausgeliefert werden. Ändert man das auf lange Adresse 3, haben Kunden mit Bestandssystemen das Nachsehen, weil die die lange Adresse 3 nicht aufrufen können. So eine eigentlich simple Änderung zieht also einen Rattenschwanz an Konsequenzen nach sich, den Aufwand scheut man schlicht und einfach.

Okay. Dieses "Problem" kenne ich auch von früher. Wenn man die alten C-Digitalhandregler benutzt, dann kann man nur Adressen von 1 bis 99 einstellen. Das heißt dann, dass bei einem der neuen Dekoder der Großteil des Adressraums nicht genutzt werden kann, einfach weil die alte Hardware hier Einschränkungen aufweist. Im Betrieb macht das trotzdem nichts aus. Man kann halt nur dieses Feature der neuen Dekoder nicht nutzen. Ebenso verhällt es sich bei der Rückmeldung.
Aber dass man im Dekoder zwischen langer und kurzer Adresse hin und herschaltet kann ich, wie du, auch nicht nachvollziehen. Auch ein Adressraum von 60000 Adressen begint bei 1.

Zitat

Ich bin bin ehrlich gesagt kein Freund von Multiprotokoll. Das Vermischen zweier unterschiedlicher Systeme fügt immer potentielle Problemstellen hinzu. Obs nun blinkende Lampen sind, oder losrasende Loks, weil sie in den Analogmodus fallen - Dann lieber nur ein System verwenden.

Ok. Ich dachte gerade das wäre eines DER großen Aushängeschilder der bekannten Systeme.

Zitat

Zitat
Es liegt doch im Konzept ein Fehler vor, wenn die Systeme, egal welche, auf analoge Technik angewiesen sind, um entsprechende Halte-Funktionalität zu liefern.
Dann kommt noch hinzu, dass diese analoge Technik, im Fall von ABC, nicht besonders Betriebssicher zu sein scheint.
Des Weiteren bringt der Einsatz der Analogtechnik hier und da immer noch funktionelle Einschränkungen mit sich.
Außerdem muss der Dekoder diese analoge Technik "verstehen", was nicht grundsätzlich gegeben ist.
Das habt ihr hier doch geschrieben, oder verstehe ich das alles falsch?

Warum soll das ein Fehler sein? Wie funktioniert das denn bei C-Digital? Dort muss doch auch eine Meldung zur Zentrale, damit die einen Befehl zur Lok schicken kann, oder? Wenn dort sonst auch einfach nur an einem Gleis eine Halt-Info ausgegeben wird, obwohl für die Lok im Regler eigentlich eine Fahrstufe eingestellt ist, haben wir dort sonst den gleichen Bruch. Ich hab aber von C-Digital keinerlei Ahnung, viel mehr als den Namen kenn ich nicht. Daher wär ich über eine grobe Zusammenfassung dankbar, wie das dort gehandhabt wird.

Also, so wie ich das sehe und ihr ein digitales System definiert habt, gibt es im Fall des neuen C-Digital (mit Rückmeldung) keine analoge Technik, die für einen automatischen Halt sorgt, weil die Halteinformation im Datenprotokoll enthalten ist und nicht lokal irgendwo erzeugt wird.

Dann muss man hier aber unbedingt noch das alte C-Digital mit der Technik aus den 90ern vom neueren unterscheiden.
Im alten System war es so, dass jeder Dekoder auf die im Datensignal enthaltene Halte-Info reagiert hat, weil es auch noch keine Rückmeldung gab und man also nicht gezielt einer Lok ein Halt zuordnen konnte. Hier war es dann so wie du das beschreibst, eine Lok fährt ins Halt und bleibt stehen, obwohl am Handregler eine gewisse Soll-Fahrstufe angezeigt wird.
Kurzschlussgefahr beim Überfahren und Brücken von Halte- und Streckenabschnitten gab es nicht und die Lok war natürlich immer voll ansprechbar, ohne Einschränkungen. Rangierfahrten waren möglich.
Im neuen System ist das ganz anders. Da geht funktional alles genauso wie früher, nur dass ein Halt lokspezifisch, genauso wie Fahrrichtung, Funktionen usw, von der Zentrale über das Gleis gesendet wird bzw. werden kann, wenn man es möchte und die Zentrale den Fahrdienstleiter mimt. Alles eine Frage der Konfiguration. Es braucht also keinen "Halteabschnitt" mehr. Am Display des Handreglers wird einem Signalhalt angezeigt und die tatsächliche Fahrstufe der Lok. Der Fahrstufenregler ist allerdings unverändert. Wird durch eine angeschlossene Taste oder ein BSW oder einen PC oder irgendeine bedingte Abfolge oder oder oder der Befehl für Weiterfahrt verlangt, geht diese Information an die Zentrale. Die nimmt bei dieser Lok dann die Halte-Info weg und die Lok beginnt wieder zu beschleunigen. Am Handregler ist das Signalhalt-Symbol verschwunden und die Angezeigte Soll-Fahrstufe entspricht wieder der des Drehreglers.

Noch ein wichtiger Zusatz ist, dass hier, sowohl beim alten also auch beim neuen System nicht über die ABV angehalten wird. Ganz einfach, weil die ABV keinen konstanten Anhalteweg erzeugen kann. Das war und ist hier schon immer strickt getrennt. Nur für das Anfahren nach dem Wechsel von Halt auf Fahrt wirkt die ABV-Einstellung.

Zitat

Zitat
Abhilfe schafft dann erst die PC-Steuerung + Rückmelder, egal ob DCC, Märklin oder SX Systeme. Diese sollte aber nicht zwingend für ein Digitalsystem von Nöten sein, sondern mehr als "Bereicherung" dienen, damit komplexere Zusammenhänge geschaltet werden können. Außerdem scheint sie auch nicht wenig zu kosten.
Die Grundfunktionalität eines Digitalsystems und dazu gehört auf jeden Fall auch das automatische Halten, das muss man glaube ich nicht diskutieren, sollte sich dadurch nicht erst überhaupt ergeben.
Es muss also ein deutlich größerer Aufwand getrieben werden, damit die Systeme eine vollständig digitale Steuerung darstellen. Eine Zugverfolgung geht ohne PC überhaupt nicht.

Es geht schon ohne PC, du kannst sowas auch mit kleinerer Hardware bzw. Microcontrollern machen. Ich benutze z.B. einen Raspberry Pi, weiter gibt es Zentralen mit integrierter Steuerungssoftware. Ein PC ist aber leistungsmäßig und von der Flexibilität her der beste Weg.

Ah, ok.

Zitat

Ich persönlich sehe den automatischen Halt nicht als Grundfunktionalität. Digital heißt, dass in jeder Lok ein Lokführer sitzt, über den Decoder bin ich das. Damit liegt auch das Halten in meiner Verantwortung. Jeglicher Automatismus sitzt "on top" auf dem Digitalsystem, nutzt also nur dessen Funktionen um ins Geschehen einzugreifen. Anders gesagt ist die Automatik ein weiterer Mitspieler, der mir Aufgaben abnimmt.

Ich eben schon. Das tolle an Digital war und ist doch, dass mehrere Loks gleichzeitig, unabhängig von einander, verschiedene Dinge machen können. Wenn man aber immer nur eine oder zwei Loks in einem Moment steuern kann, ist es doch naheliegent und notwendig eine Automatikfahrt zu integrieren. Daraus folgt aber, dass auch ein automatischer Halt integriert sein muss/sollte. Das nicht zu machen wäre in meinen Augen so, als würde man sagen:
- zu Digital gehört keine ABV, weil ich das als Fahrer selber übernehmen muss (-> Automation simulierter Masse)
- zu Digital gehört kein automatischer Lichtwechsel bei Fahrrichtungswechsel, weil auch das der Fahrer selbst übernehmen muss

Ich sehe das desshalb eben anders als du. Für mich gehört all das mit zum Grundprinzip von Digital, wie auch ein möglicher automatischer Halt.

Zitat

Zitat
Hier lag ich mit der Problematik, die die Art der physikalischen Übertragung der Digitalsysteme mitsichbringt wohl doch nicht so falsch, oder? Denn diese ist doch die Ursache, wesshalb die Systeme erst mit zuhilfenahme eines PCs + Rückmeldemodulen zu Systemen werden, die die volle Funktionalität eines Digitalsystems liefern, ohne dass es in irgend einer Form zu einem Bruch mit dem "digitalen Grundgedanken" kommt.

Ich weiß nicht, was das eine mit dem anderen zu tun hat. Es wäre jetzt nicht das Problem es anders zu machen. Man könnte z.B. eine Hardware entwickeln, die sich als Handregler am System anmeldet und auf der anderen Seite Railcom-Meldungen von einem Gleisabschnitt entgegennimmt. Als Handregler kann das Ding eine Lok übernehmen, wenn sie in den Abschnitt einfährt, und der Zentrale sagen, dass sie an diese Adresse jetzt bitteschön Fahrstufe 0 senden soll. Das würde mit jedem Railcom-fähigen Decoder funktionieren, keine unüberfahrbaren Trennstellen produzieren und auch keinen Bruch mit dem Digitalgedanken bedeuten.

Ja, das ähnelt dann von der Idee schon etwas auffällig dem C-Digital, findest du nicht? Und geben tut es sowas weder bei DCC noch Märklin, was ich dem: "man könnte eine Hardware entwickel" entnehme. Es wäre dann halt nur etwas abgekupfert ...
Allerdings wäre hier das Bremsen dann von einer zuvor eingestellten ABV abhängig. Denn der Dekoder kann so nicht unterscheiden, ob nun der Mensch am Handregler die FS 0 eingestellt hat oder es sich um einen autom. Signalhalt handeln soll. Die Bremsweglänge ist dann eben nicht fahrstufenunabhägig konstant und die Loks halten immer anders wenn sich die Fahrstufe im Moment des Eintritts in den Abschnitt mit diesem "Handregeler-Konzept" einfährt.

Zitat

Wie ich dir oben schon schrieb: Konzeptionelle Fehler hängen sehr davon ab, was das Ziel des Konzepts sein sollte. Ein Geländewagen hat doch keinen konzeptionellen Fehler, nur weil du damit kein Formel 1-Rennen gewinnen kannst.
Wie ich oben schon schrieb ist das nicht der Fall. Es wäre durchaus möglich Lösungen zu bauen, aber es gibt wohl keinen Markt dafür.

Alles klar. Das siehst du einfach etwas anders als ich. Aber ich respektiere und akzepeptiere deine Meinung.
Beim C-Digital stand, laut Martins Aussage, der automatische Signalhalt mit im Lastenheft.
Schade, dass es keinen Markt gibt.

Zitat

Zitat
Ich hatte doch schon einmal geschrieben, dass diese Übertragung ein potentielles Kurzschlussproblem in sich trägt, welches dann hier und da zu Tage tritt (treten kann).
Da liege ich doch dann auch nicht falsch, oder?

Wenn du damit das Überfahren von Trennstellen meinst, bei denen unterschiedliche Gleissignale anliegen, dann ja. Es tritt aber eben nur bei falscher Handhabung der Technik auf.

Ja, für mich steigt hier subjektiv die Anzahl der Risikofaktoren um mehr als nur eine an.

Zitat

Bei C-Digital kannst du das auch haben, wenn du auf einer Seite die Kabel verkehrt anschließt.

Wohingegen eine falsche Verdrahtung ein Risiko ist welches sich in allen Systemen zeigt, kommen hier noch ein paar hinzu. Klar hast du sonst recht und es ist vielleicht nicht ganz richtig von einem Fehler des Konzepts zu sprechen.
Wenn man allerdings etwas baut, so habe ich das zumindes einmal gelernt, versucht man so gut es geht Risikofaktoren auszuschalten. Auch bei offenliegenden Starkstromleitungen kann ich ein Warn-Schild anbringen und mich nach einem Unfall hinstellen und sage: "Da steht die Warnung. Es handelt sich hier um eine falsche Handhabung!" Anstatt von vornherein bei der Konstruktion, hier z.B. durch Isolation, gewisse Vorkehrungen zu treffen, um das Risikopotential so weit wie nur möglich herunterzufahren.
Das wäre meine Meinung dazu... ich hoffe wir sind noch gut miteinander

#103 von MariusS ( gelöscht ) , 08.04.2018 13:01

Hallo Markus,

Danke für deine ehrlichen worte.

Zitat

so langsam hast Du es ja erkannt. Ich fasse mal aus meiner Sicht und auch für meine Anlage knallhart zusammen.

Ohne PC-Steuerungssoftware mit stinknormaler S 88 Rückmeldung kann meine Anlage unmöglich laufen bzw. man müßte sich so verbiegen und tausende Sachen zusammenstricken, daß man mit z.B einer ECos oder CS evtl. einen Bruchteil von dem erreichen kann was mit einer Steuerungssoftware möglich ist. Die Kisten (ECos und CS) sind im Vergelich zur Steuerungssoftware einfach nur saudumme Kisten. Mehr nicht.

Mit einer Steuerungssoftware und total geringem Aufwand an Eigeninitiative sowie auch ohne große Kosten für die Rückmelderei hat man alles was man braucht.

So habe ich das jetzt auch verstanden. Ich finde es aber irgendwie seltsam, - kann mich einfach noch nicht daran gewöhnen, dass der Mobahner, wenn er denn so fahren will, immer einen PC braucht. Aber wahrscheinlich wird das sonst zu komplex?

Zitat

Warum und für wen sollte da was neues gestrickt werden, wenn perfektes vorhanden ist.

Ich hatte eben nicht den Eindruck, dass das alles so perfekt ist. Ausgenommen die "totale" Lösung mit PC-Software. Ich kenne aber Leute, die lassen das als Lösungsvorschlag garnicht zu.

Zitat

Wer eine Anlage hat wo alle Gleise einsehbar sind der wird auch nicht unbdeingt eine PC-steuerung brauchen. Mir geht es aber hier um komplexe Anlagen wo in der Regel mehr als die Hälfte der Streckenführung nicht einzusehen ist und ein großer SBH voller Komplettzüge dazugehört. Wie soll das ohne Steuerungssoftware gehen. Das geht auch nicht mit x Neuerungen von denen Du träumst.

Ok. Also ich habe auch 2 nicht voll einsehbare SBHe und ich komme im Moment noch ohne PC aus. Aber ich fahre ja auch mit einem anderen System...

Grüße,
Marius

#104 von 1001-digital , 08.04.2018 16:10

Zitat

Aber dass man im Dekoder zwischen langer und kurzer Adresse hin und herschaltet kann ich, wie du, auch nicht nachvollziehen. Auch ein Adressraum von 60000 Adressen begint bei 1.

Bei DCC unterscheidet man historisch bedingt zwischen langen und kurzen Adressen. Dabei sind das zwei verschiedene Datenformate, d.h. eine kurze Adresse 3 ist NICHT gleich einer langen Adresse 3. Man musste das damals wohl so machen, weil das alte Format nicht erweiterbar war.

Zitat
Ok. Ich dachte gerade das wäre eines DER großen Aushängeschilder der bekannten Systeme.

Kann man so sehen. Es hängt eben immer davon ab was man braucht. Wenn sichs vermeiden lässt, würde ich aber wie gesagt nicht mehrere Protokolle simultan laufen lassen.

Zitat
Also, so wie ich das sehe und ihr ein digitales System definiert habt, gibt es im Fall des neuen C-Digital (mit Rückmeldung) keine analoge Technik, die für einen automatischen Halt sorgt, weil die Halteinformation im Datenprotokoll enthalten ist und nicht lokal irgendwo erzeugt wird.

Dann muss man hier aber unbedingt noch das alte C-Digital mit der Technik aus den 90ern vom neueren unterscheiden.
Im alten System war es so, dass jeder Dekoder auf die im Datensignal enthaltene Halte-Info reagiert hat, weil es auch noch keine Rückmeldung gab und man also nicht gezielt einer Lok ein Halt zuordnen konnte. Hier war es dann so wie du das beschreibst, eine Lok fährt ins Halt und bleibt stehen, obwohl am Handregler eine gewisse Soll-Fahrstufe angezeigt wird.
Kurzschlussgefahr beim Überfahren und Brücken von Halte- und Streckenabschnitten gab es nicht und die Lok war natürlich immer voll ansprechbar, ohne Einschränkungen. Rangierfahrten waren möglich.
Im neuen System ist das ganz anders. Da geht funktional alles genauso wie früher, nur dass ein Halt lokspezifisch, genauso wie Fahrrichtung, Funktionen usw, von der Zentrale über das Gleis gesendet wird bzw. werden kann, wenn man es möchte und die Zentrale den Fahrdienstleiter mimt. Alles eine Frage der Konfiguration. Es braucht also keinen "Halteabschnitt" mehr. Am Display des Handreglers wird einem Signalhalt angezeigt und die tatsächliche Fahrstufe der Lok. Der Fahrstufenregler ist allerdings unverändert. Wird durch eine angeschlossene Taste oder ein BSW oder einen PC oder irgendeine bedingte Abfolge oder oder oder der Befehl für Weiterfahrt verlangt, geht diese Information an die Zentrale. Die nimmt bei dieser Lok dann die Halte-Info weg und die Lok beginnt wieder zu beschleunigen. Am Handregler ist das Signalhalt-Symbol verschwunden und die Angezeigte Soll-Fahrstufe entspricht wieder der des Drehreglers.

Hm, klingt nach einer Art Vermischung des Lokführer- und Fahrdienstleiterprinzips. Also auch so eine Art Herüberholens aus der analogen Welt. Nur dass eben das Signal zum Halt nicht direkt an der Bremsstelle erzeugt wird, sondern ne Art Zwangsbremsung über ein gesondertes Signal in der Zentrale kommt. Immerhin hat es den Vorteil, dass die Zentrale (und damit alle angeschlossenen Regler) weiß, dass die Lok gerade hält, obwohl die Fahrstufen etwas anderes sagen.

Ein Automatik-System ohne diesen Bruch würde eben über die Fahrstufen regeln, also sozusagen als Lokführer einspringen. Aber wie gesagt, dein System kommt dem zumindest näher als ABC oder Bremsbooster.

Zitat
Noch ein wichtiger Zusatz ist, dass hier, sowohl beim alten also auch beim neuen System nicht über die ABV angehalten wird. Ganz einfach, weil die ABV keinen konstanten Anhalteweg erzeugen kann. Das war und ist hier schon immer strickt getrennt. Nur für das Anfahren nach dem Wechsel von Halt auf Fahrt wirkt die ABV-Einstellung.

Auch bei DCC ließe sich sowas durchaus bewerkstelligen, z.B. indem eine Sonderfunktion geschaltet wird. Das müssten aber wieder die Decoder unterstützen. Derzeit wird das beispielsweise beim Rangiergang angewendet, je nach Decoder kann man die Beschleunigungswerte auf Tastendruck deaktivieren (die Lok hängt dann direkt am Regler) oder zumindest verringern.

Zitat
Ich eben schon. Das tolle an Digital war und ist doch, dass mehrere Loks gleichzeitig, unabhängig von einander, verschiedene Dinge machen können. Wenn man aber immer nur eine oder zwei Loks in einem Moment steuern kann, ist es doch naheliegent und notwendig eine Automatikfahrt zu integrieren. Daraus folgt aber, dass auch ein automatischer Halt integriert sein muss/sollte. Das nicht zu machen wäre in meinen Augen so, als würde man sagen:
- zu Digital gehört keine ABV, weil ich das als Fahrer selber übernehmen muss (-> Automation simulierter Masse)
- zu Digital gehört kein automatischer Lichtwechsel bei Fahrrichtungswechsel, weil auch das der Fahrer selbst übernehmen muss

Nein, könnte man nicht. Denn das sind lediglich Funktionen des Decoders, die man nach Belieben konfigurieren kann. Mit dem Protokoll hat das rein gar nichts zu tun.

Automatikfahrt finde ich nach wie vor sehr viel besser in der Hand einer Steuerungssoftware aufgehoben, die eben sehr viel leistungsfähiger und flexibler ist. Von daher ist das protokollseitig für mich überflüssig.

Zitat
Ich sehe das desshalb eben anders als du. Für mich gehört all das mit zum Grundprinzip von Digital, wie auch ein möglicher automatischer Halt.

Das ist das Schöne an der Modellbahn. Jeder kann sich nach seinen eigenen Wünschen und Vorstellungen austoben. Wenns bei C-Digital so funktioniert, wie du das haben willst, dann ist ja alles in Butter. Hier steckt eben einfach eine etwas andere Philosophie dahinter, deswegen würde ich, um mal wieder zum Ursprung zurückzukommen, bei beiden Systemen nicht von Designfehlern sprechen.

Zitat
Ja, das ähnelt dann von der Idee schon etwas auffällig dem C-Digital, findest du nicht? Und geben tut es sowas weder bei DCC noch Märklin, was ich dem: "man könnte eine Hardware entwickel" entnehme. Es wäre dann halt nur etwas abgekupfert ...

Spielt das eine Rolle? Es kann nie schaden über den Tellerrand zu schauen. Ich denke wie gesagt, dass es zumindest bei DCC schlicht keinen Markt dafür gibt. Es macht prinzipiell erstmal nichts anderes als das etablierte ABC, ist nur etwas zuverlässiger. Dafür braucht man teurere Hardware und railcomfähige Decoder.

Zitat
Wohingegen eine falsche Verdrahtung ein Risiko ist welches sich in allen Systemen zeigt, kommen hier noch ein paar hinzu. Klar hast du sonst recht und es ist vielleicht nicht ganz richtig von einem Fehler des Konzepts zu sprechen.
Wenn man allerdings etwas baut, so habe ich das zumindes einmal gelernt, versucht man so gut es geht Risikofaktoren auszuschalten.

Wie gesagt, hier haben sehr wahrscheinlich andere Überlegungen im Vordergrund gestanden. Man muss auch Bedenken, dass die Entwicklung inzwischen um die 40 Jahre auf dem Buckel hat. Meiner Meinung nach aber ein gutes Zeichen, denn sonst hätte das System nicht so lange überlebt und könnte auch nicht mehr um aktuelle Funktionen wie z.B. Railcom erweitert werden.

Zitat
Auch bei offenliegenden Starkstromleitungen kann ich ein Warn-Schild anbringen und mich nach einem Unfall hinstellen und sage: "Da steht die Warnung. Es handelt sich hier um eine falsche Handhabung!" Anstatt von vornherein bei der Konstruktion, hier z.B. durch Isolation, gewisse Vorkehrungen zu treffen, um das Risikopotential so weit wie nur möglich herunterzufahren.

Eigentlich ein schönes Beispiel, um dich zu widerlegen. Freilandleitungen sind nicht isoliert. Man könnte das theoretisch machen, aber solange keiner einen Masten hochklettert (falsche Handhabung) ist alles gut. Dafür spart man ne Menge Geld fürs Isoliermaterial

Viele Grüße
Carsten

#105 von aftpriv , 08.04.2018 16:38

Hallo Marius

Zitat

.... dass der Mobahner, wenn er denn so fahren will, immer einen PC braucht. Aber wahrscheinlich wird das sonst zu komplex? ...

kein Mobahner braucht unbeingt einen (PC, das ist falsch) Rechner, z.B. Einplatinencomputer wenn er was automatisieren will. Da ist aber egal, welches Gleisformat er verwendet oder mischt.

Betrifft Überschrift mfx und DCC: wenn Du C-Digital herausstellen willst, dann mach doch einen eigenen Tröt auf, hier ist dieses Thema schon lange "OFF TOPIC"

Gruß
Alf

#106 von MariusS ( gelöscht ) , 08.04.2018 17:36

Hallo Carsten,

Zitat

Bei DCC unterscheidet man historisch bedingt zwischen langen und kurzen Adressen. Dabei sind das zwei verschiedene Datenformate, d.h. eine kurze Adresse 3 ist NICHT gleich einer langen Adresse 3. Man musste das damals wohl so machen, weil das alte Format nicht erweiterbar war.

Ah, das wusste ich auch nicht. Zeigt mir aber wieder, dass das alte Format nicht erweiterbar war und man desshalb, einen kleinen Bruch gemacht hat. Es ist also nicht ungewöhnlich, dass man so etwas machen muss, wenn sonst keine Entwicklung mehr möglich wäre.

Zitat

Hm, klingt nach einer Art Vermischung des Lokführer- und Fahrdienstleiterprinzips. Also auch so eine Art Herüberholens aus der analogen Welt. Nur dass eben das Signal zum Halt nicht direkt an der Bremsstelle erzeugt wird, sondern ne Art Zwangsbremsung über ein gesondertes Signal in der Zentrale kommt. Immerhin hat es den Vorteil, dass die Zentrale (und damit alle angeschlossenen Regler) weiß, dass die Lok gerade hält, obwohl die Fahrstufen etwas anderes sagen.

Ein Automatik-System ohne diesen Bruch würde eben über die Fahrstufen regeln, also sozusagen als Lokführer einspringen. Aber wie gesagt, dein System kommt dem zumindest näher als ABC oder Bremsbooster.

Naja, vermischung? Ein Bruch sehe ich hier nicht, wenn überhaupt ein kleines "Brüchchen", sofern man bestimmt Einstellungen nutzt.

Je nachdem, was man einstellt und konfiguriert. Der Lokführer ist man in meinem Beispiel immer, nur hat sich gezeigt, dass wenn man bereits 2 Züge gleichzeitig als Lokführer fahren lassen will, man schnell überfordert ist, oder wenn man mehrere (auch Kinder) gleichzeitig Lokführer sind, es für einen nicht so leicht möglich ist, die Lok immer korrekt halten zu lassen. Bei Kindern fährt der ein oder andere auch gerne einmal über rot. Die nutzten die Moba ja manchmal als Rennstrecke....
Genau hier ist dieses automatisch Halten vor einem Signal (vielleicht auch gegen den Willen des Lokführers )aus Sicherheitsgründen eine super Sache. Wenn man das nicht will stellt man es nicht ein. Vermischt wird hier prinzipiell erst einmal garnichts....
Ich habe das bei mir praktisch immer aktiv, weil ich selbst auch einmal hier und da etwas übersehen kann und ich persönlich finde, dass das Anhalten, wenn es der Dekoder selbst übernimmt, besser aussieht. Es ist sozusagen aus einem Guss. Falls ich dann wirklich von Hand fahren will, deaktiviere ich über eine Funktionstaste das automatische Reagieren auf den Halt-Befehl zeitweise. Das hat sich für mich bewährt. Am Display sehe ich die Information zum Halten dann immer noch, nur muss ich dann wirklich über den Regler bremsen, sonst würde die Lok über das Signal fahren.
Auch für dieses Szenario lässt sich übrigens etwas einstelle, - die sog. Zwangsbremsung - , wenn man das denn möchte und aktiviert hat. Ich nutze das eigentlich nicht, finde es als Option aber nicht schlecht. Hier wird eine Lok ziemlich rabiat, schnell, zum Stehen gebracht, wenn man ein Signal überfährt.
Diese Funktion lässt sich auch in anderen Zusammenhängen nutzten. Wie man das eben so habe will....

Zitat

Zitat

Noch ein wichtiger Zusatz ist, dass hier, sowohl beim alten also auch beim neuen System nicht über die ABV angehalten wird. Ganz einfach, weil die ABV keinen konstanten Anhalteweg erzeugen kann. Das war und ist hier schon immer strickt getrennt. Nur für das Anfahren nach dem Wechsel von Halt auf Fahrt wirkt die ABV-Einstellung.

Auch bei DCC ließe sich sowas durchaus bewerkstelligen, z.B. indem eine Sonderfunktion geschaltet wird. Das müssten aber wieder die Decoder unterstützen. Derzeit wird das beispielsweise beim Rangiergang angewendet, je nach Decoder kann man die Beschleunigungswerte auf Tastendruck deaktivieren (die Lok hängt dann direkt am Regler) oder zumindest verringern.

Mag sein, dass sich das auch alles bei DCC bewerkstelligen liese, es wird aber de facto nicht gemacht. Man kann oft sagen, das könnten wir auch wenn wir nur wollten...
Wenn ich dir sage, was ich alles machen könnte !!!

Zitat

Nein, könnte man nicht. Denn das sind lediglich Funktionen des Decoders, die man nach Belieben konfigurieren kann. Mit dem Protokoll hat das rein gar nichts zu tun.

Hier denke ich wieder einmal anders, weil ich aus einer anderen "Welt" komme.
Denn bei C-Digital war die ABV, hier hieß es früher Beschleunigung, heuet Massensimulation, von Beginn an im Protokoll enthalten . Genau wie das Automatikfahrt-Bit, das Fahrrichtungs-Bit usw. Also komme ich hier logischerweise zu einer anderen Betrachtung.

Zitat

Automatikfahrt finde ich nach wie vor sehr viel besser in der Hand einer Steuerungssoftware aufgehoben, die eben sehr viel leistungsfähiger und flexibler ist. Von daher ist das protokollseitig für mich überflüssig.

Kann ich nicht ganz nachvollziehen. Eine Steuerungssoftware ist im Prinzip "dumm" und man muss sie erst intelligent machen, indem man in ihr praktisch eine Simulation der kompletten Anlage erstellt und die Anlage selbst mit entsprechenden Sensoren ausstattet. Jetzt ist sie zwar intelligent aber ist nach wie vor auf die Kommunikation zur Zentrale und von dieser zum Gleis angewiesen.
Zu einer Automatik, wo die Intelligenz nun bereits in der Zentrale vorhanden ist, sagst du aber, dass diese dort schlecht aufgehoben ist? Kann ich wirklich nicht nachvollziehen, oder ich verstehe dich hier falsch?
Ganz nebenbei noch zu den PC-Software-Steuerungen, die sind nur so "stark", so "stark" auch die verwendeten BUS-Systeme sind. Kann sein, dass das jetzt wieder nicht stimmt, aber ich habe schon von Mobahnern gehört, wo genau das, die Leistungsfähigkeit des BUSses, ein Problem darstellte.

Zitat

Spielt das eine Rolle? Es kann nie schaden über den Tellerrand zu schauen. Ich denke wie gesagt, dass es zumindest bei DCC schlicht keinen Markt dafür gibt. Es macht prinzipiell erstmal nichts anderes als das etablierte ABC, ist nur etwas zuverlässiger. Dafür braucht man teurere Hardware und railcomfähige Decoder.

Für mich jedenfalls nicht. Und wenn es eh keinen Markt gibt, wird das auch niemand machen, weil es sich bei DCC, sogern du mir das auch glauben machen willst , nicht so leicht umsetzen liese.

Zitat

Man muss auch Bedenken, dass die Entwicklung inzwischen um die 40 Jahre auf dem Buckel hat. Meiner Meinung nach aber ein gutes Zeichen, denn sonst hätte das System nicht so lange überlebt und könnte auch nicht mehr um aktuelle Funktionen wie z.B. Railcom erweitert werden.

Ja, das Thema hatten wir schon. Leicht und problemlos gingen diese Erweiterungen aber nicht. Sowohl bei Railcom gibt es Probleme mit der alten Hardware und Zuferlässigkeit (nach euren Aussagen), die man dann eben tauschen oder nachrüsten müsste - gut , als auch bei der Adresserweiterung gibt es Probleme, weil das alte Protokoll nicht erweiterbar war (auch das deine Aussage). + das was ich an der Übertragungstechnik bemängelt habe mit den potentiellen Risikofaktoren. Sooo gut ist so eine Entwicklung in meinen Augen dann nicht. flaster:
Aber ich muss zugeben, dass ich so etwas nicht wirklich beurteilen kann. Mir vermittelt es halt diesen Eindruck.
Das Argument, wie lange es sich schon gehalten hat, lasse ich nicht zählen, weil ich das einfach an der Standardisierung und Normierung und der Marktmacht gewisser Hersteller sehe.

Ich habe halt gesehen, dass ein System, welches zwar nicht vor 40 Jahren aber immerhin vor 25 Jahren entwickelt wurde, erweitert werden kann, ohne dass es irgendwelche Probleme dieser Art gäbe. Nicht beim Protokoll und etwaigen Erweiterungen und auch nicht bei der Hardware mit neuen Dekodern, Rückmeldung, uvm und bei der Verdrahtung und Handhabung ziemlich Risikoarm.
Weil ich das so sehe, denke ich wahrscheinlich so. Kaufen kann ich mir davon ja nichts... also lassen wir dieses Thema.

Zitat

Zitat
Auch bei offenliegenden Starkstromleitungen kann ich ein Warn-Schild anbringen und mich nach einem Unfall hinstellen und sage: "Da steht die Warnung. Es handelt sich hier um eine falsche Handhabung!" Anstatt von vornherein bei der Konstruktion, hier z.B. durch Isolation, gewisse Vorkehrungen zu treffen, um das Risikopotential so weit wie nur möglich herunterzufahren.

Eigentlich ein schönes Beispiel, um dich zu widerlegen. Freilandleitungen sind nicht isoliert. Man könnte das theoretisch machen, aber solange keiner einen Masten hochklettert (falsche Handhabung) ist alles gut. Dafür spart man ne Menge Geld fürs Isoliermaterial

Das habe ich mir fast gedacht, dass du damit kommst.
Das widerlegt nur leider mein Beispiel nicht, weil es sich bei der Überland-Hospannungsleitung um keine Gerätschaft im herkömmlichen Sinn handelt, die irgend einem direkten Anwendungszweck oder Handhabe dient. Hier müssen natürlich entsprchende Warntafeln reichen, sonst müsste man ja auch alle Bahnsterecken einmauern oder zumindes umzäunen, weil man da sonst vom Zug überrollt werden kann. - Nein.
Ich denke, du weißt ganz genau was ich damit sagen wollte und wolltest mir nur widersprechen
Ich könnte x-Solcher Beispiele, wie das, dass man bei einem Gerät bestimmte Leitungen nicht ausreichend gegen fehlerhafte Handhabe/Zugriff schützt, anführen und auch noch andere. Und du würdes dann immer mit so etwas wie dann z.B. der Abschirmung der Gleisanlagen kontern.
Die Konsequenz wäre, dass es allgemein reicht nur eine Wartafel aufzustellen, was nicht so ist.

Übringens noch ein Beispiel von der Bahn: Bei den Elloks ist es/war es z.B. so, dass man an die Schaltschränke und an die Sicherungen nur heran kommt, indem man eine gesonderte Tür im Maschinenraum öffnet, die diesen Bereich absichert. Der Schlüssel für diese Tür war gleichzeitig ein Hebel, der zum Heben und Senken der Pantos verantwortlich war und man konnte diesen nur entnehmen, in dem man die Hebel für Panto auf/ab auf ab gestellt hat.
Das hat man nicht aus Spass so entwickelt, weil ja eine schlichte Warntafel gereicht hätte, sondern um das Risiko zu minimieren.

Grüße,
Marius

#107 von Heinzi , 09.04.2018 12:13

Hallo
da es zwischenzeitlich wieder einige längere Beiträge gibt mal meinen Mist auch wieder dazu ohne alles gelesen zu haben:

Zitat

Der Knackpunkt ist, dass das Bremsen mit Dioden am Gleis ein klarer Bruch mit dem Gedanken ist, der hinter einem Digitalsystem steht. Bei Digital soll eigentlich einzig und allein die Zentrale über die Befehle die Decoder steuern. Es ist nicht vorgesehen, dass irgendwelche Einrichtungen am Gleis die Loks beeinflussen.

Zitat
Ich denke, was Carsten hier sagen will ist, dass bei einem Digitalsystem eigentlich alle Befehle, die einen Dekoder steuern, digital erfolgen sollten. Alle Befehle sollten ausnahmslos über das jeweilige Protokoll von einer Zentrale o.ä. zum Dekoder gelangen. Also keine Beeinflussung eines Dekoders durch ein lokales, irgendwie geartetes Signal, wie z.B. Gleichspannung, asymmetriesche Spannung (ABC), etc..
Aus dieser Forderung folgt, dass das Halten, bspw. vor einem Signal, mittels ABC-Bremsstrecken (DCC) oder Bremsstrecken durch Gleichspannung (Märklin) nicht wirklich in die digitale Welt "passen". Man kann sie natürlich bedenkenlos verwenden

Vielleicht sollten wir mal kurz etwas über den Begriff „Digital“ in der Modellbahn unterhalten.
Dazu ist ev. auch wieder ein Blick in die Geschichte hilfreich.
Die digitale Steuerung einer Modelllok wurde primär erfunden um mehrere Loks gleichzeitig und unabhängig voneinander zu steuern. Nicht mehr und nicht weniger. Rückmeldungen, entweder aus der Lok oder Positionsbestimmende Rückmeldungen, oder automatisches Anmelden an der Zentrale etc. waren dazumal noch kein Thema. Alle Digitalsysteme (Mehrzugbetriebssystem wäre ev. der richtigere Ausdruck) basierten lediglich darauf, einer bestimmten Lok (Adresse) einen bestimmten Befehl codiert mitzuteilen, sowie codierte Befehle an die Weichen und Signale ( Magnetartikel) zu senden um diese zu schalten.
Bsp: „Adresse xx = Fahrstufe 12“ oder „Adresse xx = Licht an“.
Funktionen wie das selbstständige anhalten vor Lichtsignalen waren, und sind auch heute nicht Teil von dem, was wir Modellbahner allgemein als Digitalsystem benennen. Ortsbezogene Rückmeldungen wie „Gleisbesetztmeldungen“ wurden mit einem separaten System (Rückmeldebus S8 verwirklicht.

Für irgendwelche intelligenten Aktionen wie eben das Anhalten vor roten Signalen waren (und sind nach wie vor) mehr oder weniger Intelligente Zusatzsysteme notwendig.
Das naheliegende waren damals sicherlich die Bremsmodule welche jede Lok einfach abbremst und relativ einfach mit den Signalen zu verbauen waren. PC Steuerungen (als heutige zweite Möglichkeit) waren damals, wenn überhaupt, erst am Horizont auszumachen.
PC Steuerungen als weitere Möglichkeit intelligente Funktionen auszulösen bedingen wesentlich mehr Aufwand der schon bei der Planung der Anlage beginnt. So muss der PC (respektive die Software im PC) jederzeit wissen wo sich welche Lok befindet. Auch dazu war (und ist vermutlich immer noch) historisch bedingt das S88 System das am weitesten verbreitete System. In entsprechend gebauten und Rückgemeldeten Anlagen weis nun der PC welche Lok sich dem auf rot stehenden Signal nähert und sagt dann der zwischen PC und Anlage geschalteten Zentrale : Sende jetzt der „Adresse xc“ den Befehl „Fahrstufe = 0“ was dann die Zentrale auch macht.

So, das war so ungefähr lange Zeit der Status quo, wohl bis die typischen DCC Hersteller über ein Rückmeldesystem (Railcom) aus dem Lokdecoder heraus begannen nachzudenken. Meiner Meinung nach begann das aber einige Zeit vor dem Jahr 2000. Natürlich musste das ganze mit dem DCC Protokoll kompatibel sein, weshalb das DCC-Protokoll dazu etwas verbogen wurde. Will man mit Railcom eine geografische Rückmeldung erhalten benötigt es aber genau wie das S88 System abschnittsweise Rückmeldungen. Da ich das Railcomsystem nicht näher kenne möchte ich hierzu nicht näher darauf eingehen.
Wie bereits geschrieben, kam dann 2004 Märklin mit dem neuen System mfx eine Modellbahn „digital“ zu steuern.
Primär wurden damit einige relevante Nachteile des alten Märklin Systems „mm“
Adresslimitierung, Anzahl Fahrstufen und Anzahl schaltbare Funktionen beseitigt.
Die automatische Anmeldung und die selbstständige Adressvergabe sind für mich persönlich eigentlich nur „goodies“ auf die ich aber höchst ungern verzichten würde.

Weiterhin, trotz Railcom und mfx bleibt die Intelligenz (zum Glück) aber ausserhalb der Lokdecoder.

Zitat
warum versteift Ihr Euch immer auf einen PC um eine komplexere Anlage zu steuern und sicher am Laufen zu halten. Es bedard (kann aber natürlich ein PC odr Laptop sein, finde ich aber eine Verschwendung von teuerer Hardware) lediglich eines Einplatinencomputers (z.B. Rasperry-, (ich verwende den) BananaPi oder BeagleBoneBlack um eine mächtige Steuerung laufen zu lassen, bei mir ist es Rocrail (€ 12,Jahr als Unterstützung) das via CAN-Bus eine Gleisbox steuert, später

Natürlich geht das auch. Es ist aber wohl nicht jedermanns Sache und wohl doch auch als Randgruppe zu bezeichnen!

#108 von aftpriv , 09.04.2018 12:45

Servus Heinzi

Zitat

Hallo
da es zwischenzeitlich wieder einige längere Beiträge gibt mal meinen Mist auch wieder dazu ohne alles gelesen zu haben:

bis dahin stimme ich Dir 100-prozentig zu.

Ab hier nicht mehr, das wird sich in nicht allzu ferner Zukunft ändern:

Zitat

Zitat
warum versteift Ihr Euch immer auf einen PC um eine komplexere Anlage zu steuern und sicher am Laufen zu halten. Es bedard (kann aber natürlich ein PC odr Laptop sein, finde ich aber eine Verschwendung von teuerer Hardware) lediglich eines Einplatinencomputers (z.B. Rasperry-, (ich verwende den) BananaPi oder BeagleBoneBlack um eine mächtige Steuerung laufen zu lassen, bei mir ist es Rocrail (€ 12,Jahr als Unterstützung) das via CAN-Bus eine Gleisbox steuert, später
Natürlich geht das auch. Es ist aber wohl nicht jedermanns Sache und wohl doch auch als Randgruppe zu bezeichnen!

jeder halwegs technisch affine Person, die eine SD-Karte einschieben und mit einem PC arbeiten kann wird in der Lage sein so einen Einplatinenrechner als Zentrale zu betreiben. Näheres in Kürze.

Seriöse Testkanditaten meldet Euch schon mal per PN.

Gruß
Alf

#109 von suffix ( gelöscht ) , 09.04.2018 13:44

Mal ein Gedanke zum Prinzip vom Anhalten von C-Digital, das hier ja immer so gelobt wird:

ZWEI

#110 von Heinzi , 09.04.2018 14:05

Moin Alf

Zitat
Ab hier nicht mehr, das wird sich in nicht allzu ferner Zukunft ändern:

Da bin ich mal gespannt.

Zitat
jeder halbwegs technisch affine Person, die eine SD-Karte einschieben und mit einem PC arbeiten kann wird in der Lage sein so einen Einplatinenrechner als Zentrale zu betreiben. Näheres in Kürze.

Dabei geht es nicht nur um das können, sondern auch um das wollen. und gemäss meiner Erfahrung ist das meistens nicht sooo einfach wie es (von Experten) immer versprochen wird. Anleitungen sind meist von experten, für experten etc etc.

Zitat
Seriöse Testkanditaten meldet Euch schon mal per PN.

kann das Ding, was immer da auch kommen sollen, auch mfx?
Aber jetzt kommt der Sommer, der Zeitpunkt ist schlecht.

#111 von MariusS ( gelöscht ) , 09.04.2018 14:14

Hallo,

Zitat

Mal ein Gedanke zum Prinzip vom Anhalten von C-Digital, das hier ja immer so gelobt wird:

Gelobt?, von wem denn schon, höchstens doch von mir.
Bitte, ich sage es nochmal, mir ging und geht es nicht um C-Digital verglichen mit DCC oder mfx, das gehört hier nicht her. Der Grund warum das immer wieder zur Sprche kommt und kam, liegt einfach daran, dass ich eben damit fahre und dieses System meine Sicht- und Denkweise auf Digitalsysteme prägt. Mehr nicht!
Wenn du weitere Fargen dazu hast, dann stelle diese doch am besten in dem Thread "C-Digital System ???" hier. Da wirst du dann auch eine technisch einwandfreie Antwort bekommen .

Zitat

Habe ich es richtig verstanden, dass man für diese _nette, Detail-Funktionalität_ ZWEI extra Fahrleitungen über die ganze Anlage ziehen muss (STR, GUZ und UZ)? Und jeder Booster dann logischerweise 3 statt nur einem Signal verstärken muss? Logisch löst das dieses elende Anhalteproblem, aber zum Geier es ist doch *sehr* viel Aufwand für eine Funktionalität die jetzt nicht gerade jeder braucht..

Nein, das hast du falsch verstanden, bzw. du vermischst hier 2 Dinge.

Zitat

Die 3 Fahrsignale STR GUZ und UZ unterscheiden sich doch jeweils in 2 bits? Wie genau wird dann das Kurzschlussproblem beim Überfahren von Trennstellen vermieden?

Du hast eben noch nicht verstanden wie dieses System überhaupt funktioniert, also wie die physikalische Übertragungstechnik aussieht.
Ich schicke dir auch noch eine PN, die evtl. einiges Licht ins Dunkle bringen könnte.

Grüße,
Marius

#112 von suffix ( gelöscht ) , 09.04.2018 14:28

Zitat

Hallo,
Zitat

Mal ein Gedanke zum Prinzip vom Anhalten von C-Digital, das hier ja immer so gelobt wird:
Gelobt?, von wem denn schon, höchstens doch von mir.
Bitte, ich sage es nochmal, mir ging und geht es nicht um C-Digital verglichen mit DCC oder mfx, das gehört hier nicht her. Der Grund warum das immer wieder zur Sprche kommt und kam, liegt einfach daran, dass ich eben damit fahre und dieses System meine Sicht- und Denkweise auf Digitalsysteme prägt. Mehr nicht!
Wenn du weitere Fargen dazu hast, dann stelle diese doch am besten in dem Thread "C-Digital System ???" hier. Da wirst du dann auch eine technisch einwandfreie Antwort bekommen .
Zitat

Habe ich es richtig verstanden, dass man für diese _nette, Detail-Funktionalität_ ZWEI extra Fahrleitungen über die ganze Anlage ziehen muss (STR, GUZ und UZ)? Und jeder Booster dann logischerweise 3 statt nur einem Signal verstärken muss? Logisch löst das dieses elende Anhalteproblem, aber zum Geier es ist doch *sehr* viel Aufwand für eine Funktionalität die jetzt nicht gerade jeder braucht..
Nein, das hast du falsch verstanden, bzw. du vermischst hier 2 Dinge.

Zitat

Die 3 Fahrsignale STR GUZ und UZ unterscheiden sich doch jeweils in 2 bits? Wie genau wird dann das Kurzschlussproblem beim Überfahren von Trennstellen vermieden?

Du hast eben noch nicht verstanden wie dieses System überhaupt funktioniert, also wie die physikalische Übertragungstechnik aussieht.
Ich schicke dir auch noch eine PN, die evtl. einiges Licht ins Dunkle bringen könnte.

Grüße,
Marius

Stimmt, mir ist gerade beim erneuten Lesen von http://www.c-digitalsystem.de/Dokus/C_Protokolle2016.pdf aufgefallen, dass hier die Information mit einer amplitudenmässig relativ kleinen Wechselspannung auf eine sonst konstante Gleichspannung addiert wird. Ist es diese kleine Amplitude, die kurzschliessen problemlos ermöglicht? Im pdf steht:

"Da sowohl bei STR, als auch UZ und GUZ die selbe konstante Gleichspannung anliegt, wirkt sich das Verbinden dieser Anschlüsse nicht negativ auf die 15 Volt Gleisspannung aus."

So ganz stimmen kann das ja nicht, überall dieselbe DC Spannung würde ja keine Informationsübertragung mehr zulassen.

Bezüglich der Verteilung von UZ und GUZ verstehe ich dich aber nicht so ganz. Das untere Bild von http://www.c-digitalsystem.de/Dokus/Anschlprinzip.pdf zeigt doch ziemlich deutlich auf, dass diese beiden Signale an jeden Halteabschnitt geführt werden müssen? Also wenn das leistungstechnisch ausreicht kann man von mir aus die Booster herkömmlich mit einem Signal ausführen, die anderen beiden Signale müssen aber trotzdem (+Dioden) über die ganze Anlage geführt werden? Und ich meinte, C-Digital Booster mit Anschlüssen für alle 3 Signale gesehen zu haben, kann mich aber täuschen.

PS: Da wir hier so grundlegend über die Eigenschaften von Digitalprotokollen diskutieren und es wohl viele Unklarheiten gibt, finde ich dass die grundlegende Erklärung vom so unbekannten C-Digital sehr wohl hierher gehört.

#113 von MariusS ( gelöscht ) , 09.04.2018 15:48

Hallo,
Zur Antwort auf deine Fragen lies einfach mal die PN von mir.

Zitat

PS: Da wir hier so grundlegend über die Eigenschaften von Digitalprotokollen diskutieren und es wohl viele Unklarheiten gibt, finde ich dass die grundlegende Erklärung vom so unbekannten C-Digital sehr wohl hierher gehört.

Da glaube ich bist du einer der wenigen, der einzige???, der das so sieht. Das Thema heißt ja DCC und mfx, was C-Digital nicht mal annäherungsweise beinhaltet, da technisch nicht vergleichbar.
Ich möchte mir keine weiteren "blöden" Kommentare anhören, was ich denn mit C-Digital hier will, also lasse ich das.

Aber hier kannst du deine Fragen gerne alle stellen...

Zu den von dir angeführten Links noch ganz kurz, du musst bei den Dokumenten darauf achten, von wann diese sind, und für was sie gelten. Leider ist die Dokumentation, z.B. auch gerade des neuen C-Digitals, welches ich als Prototyp/Versuchsstudie zum Testen habe, praktisch nicht vorhanden.
Martin weiß das und er kommt hier nicht schnell genug hinterher, weil er dass fast alleine nur nebenher betreibt, -so in etwa seine Worte.

Grüße,
Marius

#114 von suffix ( gelöscht ) , 09.04.2018 17:01

Zitat

Hallo,
Zur Antwort auf deine Fragen lies einfach mal die PN von mir.

Zitat

PS: Da wir hier so grundlegend über die Eigenschaften von Digitalprotokollen diskutieren und es wohl viele Unklarheiten gibt, finde ich dass die grundlegende Erklärung vom so unbekannten C-Digital sehr wohl hierher gehört.
Da glaube ich bist du einer der wenigen, der einzige???, der das so sieht. Das Thema heißt ja DCC und mfx, was C-Digital nicht mal annäherungsweise beinhaltet, da technisch nicht vergleichbar.
Ich möchte mir keine weiteren "blöden" Kommentare anhören, was ich denn mit C-Digital hier will, also lasse ich das.

Aber hier kannst du deine Fragen gerne alle stellen...

Zu den von dir angeführten Links noch ganz kurz, du musst bei den Dokumenten darauf achten, von wann diese sind, und für was sie gelten. Leider ist die Dokumentation, z.B. auch gerade des neuen C-Digitals, welches ich als Prototyp/Versuchsstudie zum Testen habe, praktisch nicht vorhanden.
Martin weiß das und er kommt hier nicht schnell genug hinterher, weil er dass fast alleine nur nebenher betreibt, -so in etwa seine Worte.

Grüße,
Marius

Ich glaube lange nicht, dass ich der erste bin der an C-Digital hier im Thread interessiert ist. Lange bevor ich geschrieben habe, haben andere gezielt danach gefragt und keine Antwort erhalten. Wenn du unbedingt per PN kommunizieren willst okay, denke aber es würde noch einige andere interessieren. Ansonsten warte ich auf die Doku des neuen C-Digital die mich brennend interessiert.

Edit: Den von dir verlinkten Thread habe ich übrigens schon vor längerem interessiert komplett gelesen. Leider kann ich mich nicht daran erinnern, dass da irgendwas von der Rückmeldefähigkeit des neuen C-Digital geschrieben worden ist.

#115 von Klaus_K , 09.04.2018 22:01

Hallo,

Zitat

So ganz stimmen kann das ja nicht, überall dieselbe DC Spannung würde ja keine Informationsübertragung mehr zulassen.

Doch, doch. Natürlich geht so etwas. Das Stichwort lautet Modulation auf ein DC Potential. Das ist eigentlich nichts ungewöhnliches in der E-Technik, nur eben für die digitale Modellbahn. Weil hier alle anderes gewohnt sind.
Was das alles für positive Effekte zur Folge hat, kann man als "normaler" Modellbahner, der seit Jahrzehnten nur das eine kennt, erst richtig nachvollziehen, wenn man das selber einmal gesehen hat oder noch besser damit umgegangen ist.

Ich selbst bin eingefleischter DCC-Fahrer und nutze seit ein paar Monaten auch embedded-PC Module (z.B Raspberry oder F&S mit ARM) zur Steuerung. Ich kann trotzdem guten Gewissens sagen, dass C-Digital ein richtig kluges System ist, was wirklich mit Weitsicht entwickelt wurde. Da sich für mich der Umstieg nicht lohnt, bleibe ich natürlich bei meiner DCC-Lösung, mit der ich auch zufrieden sein kann. Die Probleme die es hier und da gibt oder geben kann, bin ich schon gewohnt und ich weiß wie damit umzugehen ist...

Die Digitalsysteme mit DCC, MM, FMZ usw sind ja sehr stark historisch bedingt gewachsen und designt. Ich weiß mittlerweile aus ziemlich sicherer Quelle auch, warum diese so sind wie sie sind:
Man sah sich zunächst nur mit dem Problem, verschiedene Loks in ein und dem selben Stromkreis unterschiedlich bedienen zu wollen, konfrontiert. Man hat also überlegt und sich dann aus mehreren Gründen auf eine (ganz wichtig) gleichanteilfreie rechteck Wechselspannug geeinigt.
- Über die Länge der Rechteckimpulse können Informationen (digital codiert) übertragen werden, die von einem Dekoder aufgenommen und interprätiert werden können.
- Da diese rechteckige Wechselspannung gleichanteilfrei sein sollte, wäre das gleichzeitige steuern von analogen Loks weiterhin gegeben, da das Digitalsignal den analogen Loks fast nichts tut (stimmt nicht ganz, weil die Motoren die HF Digitalspannung trotzdem abbekamen und auch warm wurden, summten,...). Dies sollte im besonderen auch desshalb sehr wichtig gewesen sein, weil man zunächst für die teuere Digitaltechnik keinen großen Markt sah. Also sollte es den Mobahnern möglich sein, einfach an eine bestehende analoge Anlage, zusätzlich ein "Teil" anzuschließen, mit dem dann über beschriebene Signalübertragung auch eine digitale Lok gesteuert werden kann.
Beide Systeme sollten nebeneinander existieren und funktionieren können, damit sich ein digitaler Umbau für den Kunden auch ganz leicht stückchenweise ergeben konnte. (schleichende Übernahme )
Weiter hat man erst einmal nicht gedacht. Automatisches Halten würde für die digitale Lok noch genauso wie für die analoge Lok gehen (z.B. Stromlos, Dioden), Funktionen außer Spitzenlicht gab es praktisch nicht und auch der Adressraum war relativ eingeschränkt.

Weil man keine großartigen Gedanken an die Zukunft verschwendet hat, also z.B. an eine mögliche Erweiterung des Protokolls, längere Adressen, mehr Funktionen, automatisches Halten, Automatikfahrt usw. usf. hat man diese Lösung dann auch so gewählt. (und nicht weil man damals schon wusste, dass man das ja eh nicht braucht weil irgendwann der PC kommt mit der "fetten" Software, wie das hier behauptet wurde.)
Hätte man damals diese Dinge schon mit in eine Überlegung einfließen lassen, wäre man mit Sicherheit zu einer andern Lösung gekommen. Dieses Vorgehen war herstellerübergreifend ähnlich oder identisch (abgekupfert), wesshalb sich überall also diese Übertragung durchgesetzt hat. Außerdem war die Umsetzung auch nicht zu teuer.
Jeder Hersteller, mit einem Digitalsystem im Angebot, hatte auch sein hauseigenes Protokoll. Manche waren recht ähnlich andere unterschieden sich deutlich, nur nicht bei der Datenübertragungstechnik. Manche Hersteller liesen sich sogar ihre eigenen Microchips fertigen, so wie GFN für FMZ von Philips glaube ich.
Der digitale Markt ist weiter gewachsen, die Elektronik hat sich rasant entwickelt (tut sie heute noch) und die Ansprüche an Digitalsysteme und digitale Features sind schnell deutlich gestiegen. Die Hersteller haben sich gegenseitig mit immer neuen Lösungen übertrumpft, wie sich weitere wünschenswerte Features umsetzen liesen.

Schnell war auch das automatische Halten, also die automaische Signalerkennung ein Thema. Eine Information zum Halten, die dem Datensignal entnommen werden kann machte keinen Sinn, weil sich das Datensignal nirgends auf der Strecke unterscheiden durfte, wenn man keine Kurzschlüsse riskieren wollte. Also hat man in dieser Richtung auch nichts weiter unternehmen könne. Es hatte sich bereits hier eine Schranke durch die früher gewählte Übertragungstechnik aufgetan, die bis heute Probleme bereiten kann.
Es entstanden verschiedene Kompromisslösungen, wie z.B. das Bremsen mit Gleichspannung. Fast immer waren dafür zusätzliche Module und Technik notwendig, die sich die Hersteller auch nicht wenig kosten liesen. Oft blieb es dann doch beim altbewährten stromlos Schalten des Abschnitts. Ist jetzt zur Absicherung bei ABC noch so...
Technisch versierte Bastler hatten natürlich ihre eigenen ausgeklügelten Techniken, um gewisse funktionelle Abläufe und Automatismen zu implementieren.

Bei der Firma Lenz (Digitalanbieter der ersten Stunde) hatte man die kluge Idee, das eigene Protokoll genannt DCC als Digital-Norm klassifizieren zu lassen. Doch auch bei der Norm dieses Protokolls hat man Gedanken an die Zukunft nur geringfügig eingebracht. Somit war keine Erweiterung oder ein weiterer Ausbau dieses Protokolls eingplant. Auch das wurde dann später wieder zu einer Schranke, die bis heute Probleme bereitet. (altes Protokoll <> neues Protokoll mit langer Adresse)

Soweit eine historische Kurzfassung, die nicht alles entählt, aber doch die wichtigen Eckpfeiler, die das gezeichnete Bild wieder etwas gerade rückt und eine nüchteren Betrachtung ermöglicht.

Warum schreibe ich das alles?
Ich finde es schon ein wenig grotesk, was hier mit welchen Begründungen behauptet wird, warum das ein oder andere zu einem digitalen Steuerungsprinzip gehöre oder nicht.
Automatikfunktionen wie der automatische Halt und auch andere Dinge sind bei den großen Marken historisch bedingt nicht in die Grundidee derer Digitalsysteme und Protokolle mit eingeflossen, das ist richtig.
Daraus aber eine Art NORM ableiten zu wollen, dass das nicht zu einer digitalen Grundidee gehöre ist Unsinn. Denn der Grund für das nicht einbeziehen derartiger Features liegt ja wo ganz anders begründet, - Kompatibilität zu Analog und, zu Beginn, Glaube an nur kleinen Markt für Digital -, und nirgendwo sonst.

Wenn man schon eine Art allgemein gültige Grundidee für digitale Steuerungssysteme definieren will, dann legt diese höchstens fest, dass Steuerungsinformationen in digitaler Form übertragen, zur Steuerung anderer Hardware genutzt werden soll. Was genau für Informationen übertragen werden hat hier (bei der Grundidee) nichts verloren, weil das protokollspezifische Dinge sind.

Eine Funktion wie ein digital übertragener automatischer Halt gehört demnach genauso zu der Grundidee einer Digitalsteuerung wie er das nicht tut. Es hat hier einfach nichts verloren.

Die Frage ist eher, ob es zu einer grundlegenden Idee der Anwendung und der Sache Modelleisenbahnsteuerung gehört. Und diese Frage ist ganz klar mit 'ja' zu beantworten, sogern sich der ein oder andere hier herausreden möchte. Es war im analogen Fall schon fester Bestandteil und teilweise sogar unabdingbar, wenn sich meherere Loks in einem Abschnitt befanden. Es wurde auch im digitalen Fall ein fester Bestandteil, allerdings aus der analogen Welt, weil Digital zunächst in den analogen Bestand integrabel sein sollte und auch war.
Nur weil es aus besagten Gründen so gelaufen ist, daraus dann zu folgern es sei nicht Bestandteil einer digitale Grundidee kann man machen, so möchte man meinen. Dass das aber ein totaler Quatsch ist wird einem erst klar, wenn man sich einmal ein noch eingeschränkteres Protokoll zu Beginn von Digital vorstellt.
Ein System, dass nur eine Fahrstufe für Vorwärts und eine für Rückwärts gehabt hätte, hätte weder gegen die digitale Grundidee (Steuerungsinformation = Fahrbefehl in digitaler Form übertragen) noch gegen sonst irgendetwas verstoßen. Dass man mit Analogsystemen mit einer Vielzahl an Fahrstufen hat fahren können, hätte man hier ebenso ignoriert, wie man das beim automatischen Halten tatsächlich auch gemacht und es nicht mit in das digitale Protokoll integriert hat. Das Ende vom Lied wäre, dass man mit der gleichen unsinnigen Argumentation hätte rechtfertigen können, dass das Fahren mit mehreren Fahrstufen folglich nicht zur digitale Grundidee gehöre, weil es nicht von Beginn an im Protokoll enthalten war.
Dabei hat auch das überhaupt nichts mit einer digitalen Grundidee zu tun, wie ich oben schon erläutert habe, sondern mit dem Protokoll (dem Informationsschlüssel). Denn auch die Frage, ob mehrere Fahrstufen oder nicht, begründet man mit der grundlegenden Idee der Anwendung und der Sache Modelleisenbahnsteuerung, vollkommen zurecht ebenso mit 'ja'. Und das eben auch weil man sagen kann; "Wir hatten das im analogen Fall schon so als festen Bestandteil (wünschenswerte Funktion) und es ist auch eigentlich unabdingbar und sinnvoll."

Resumé:
Eine digitale Grundidee einer Digitalsteuerung hat nichts mit dem Protokoll und dessen Informationsinhalt zu tun. Bei der Frage der Sinnhaftigkeit einer Information wie Signalhalt in einem Protokoll können sich Systembedingt ganz unterschiedliche Antworten ergeben.
-> Im Fall von DCC etc. war und ist so etwas bis jetzt total unsinnig, da sich durch die Übertragungstechnik der digitalen Information Einschränkungen ergeben, die so eine Information (Haltebefehl), die einen Unterschied in mindestens einem Bit zum restlichen Protokoll aufweisen müsste, verletzen würde.
-> Im Fall von C-Digital sehr sinnvoll und nachvollziehbar, weil es bei der hier gewählten Übertragungstechnik keine Einschränkung gibt, was einen Unterschied im Dateprotokoll von Streckenteilen ohne Halt von denen mit Halt in irgendeiner Weise verboten hätte.

Es hat sich technologisch bedingt also im einen Fall im Protokoll etwas etabliert, was es im anderen Fall nicht hat. Auch das, finde ich, ist eigentlich gar kein Problem.
Ein Ab- oder Aufwertung kann es hier zunächst nicht geben. Die entsteht erst durch etwas anderes, nämlich durch die Wünsche der Anwender an die Funktionalität.

C-Digital hat es geschafft, eine durchaus gewünschte Sache, direkt aus der analogen in die digitale Welt zu transportieren, ohne dass es dabei zu funktionalen Problemen kommen kann und ohne dass digitale Funktionen in irgendeiner Weise beschnitten würden.
Wenn man sich ansieht, was es am digitalen Modellbahnmarkt gab und gibt, und was sich die anderen Hersteller einfallen haben lassen, dass nachträglich auch im Fall von DCC und MM ... ein automatisches, annähernd digital verträgliches Anhalten möglich wurde, zeigt:
a) Dass es sich um ein durchaus gewünschtes und verlangtes Feature handelt
b) Dass man dieses Feature später dann doch auch gerne in die digitale Welt geholt hätte, dies aber aufgrund der Einschränkung durch die früher gewählte Übertragungstechnik nicht mehr möglich war. Derartige Dinge flossen in die damaligen Überlegungen zum Digitalsystem eben nicht ein.

Wie man bis heute sehen kann, ist auch keine dieser Kompromisslösungen in der Lage, all das zu liefern, was C-Digital durch die vollständige digitale Integration dieses Features hier bietet, bzw. bieten kann. (Wobei von den Lösungen ohne PC oder embedded PC oder vergleichbares abgesehen, ABC noch am ehesten herankommt, sowohl was die Kosten als auch die integrierbarkeit in die digitale Welt angeht. Allerdings hat ABC auch mehr als nur eine Schwäche und Kritkpunkte...)

Beim heutigen Stand der Technik, wo man einen PC oder PC-ähnliche Hardware mit einer sehr leistungsfähigen Software leicht nutzen kann (vor 20 Jahren war das noch viel komplizierter), sich hinzustellen und zu sagen: "So ein unnötiges Zeug, was C-Digital hier liefert, ich mach das einfach über meinen PC mit "fetter" Software, die mir einfach gleichzeitig X Lokführer spielt und nahezu simultan steuert. Auch kann die dann gleich noch viel mehr!"
Ist vollkommener Blödsinn, weil hier Äpfel mit Steinen verglichen werden.
Wenn man an C-Digital zusätzlich eine leistungsstarke Softwarelösung in externem Rechner (embedded PC, ...) daranhängt, dann kann man vielleicht wieder einen Vergleich bei der Funktionalität, dem Verdrahtungsaufwand, der Leistungsfähigkeit und den Kosten machen, - vorher aber doch nicht. Da muss man schon das zugrundeliegende Digitalsystem in seiner Grundform nehmen, wie man das mit C-Digital hier auch macht.
Da sieht man auch schnell wie stark das Konzept ist, wenn man vergleicht wie "leicht" sich auch neue Features hinzufügen und integrieren lassen, ohne dass iregendwo Kopatibilitätsprobleme auftreten würden. Das kenne ich aus eigener Erfahrung von DCC usw. anders. Einiges wurde hier auch schon mehrmals genannt.
Aber es ist wirklich grotesk, wie man dann reagiert, wenn Marius genau diese Probleme nochmals anspricht und den Systemen hier potentielle Schwächen zuweist, die es ja auch sind...
Das ist schon fast refelxartig, wenn ein Außenstehender, - sogar mehr oder weniger nur über Zitate -, einem diese Schwächen als Mängel vor Augen führt, versucht man diese wieder doch als nichtig und fast schon nicht wirklich vorhanden abzutun.

Ich weiß nicht was das soll, dass man dieses System hier unbedingt schlechter reden will, als es ist? Es ist und bleibt doch eh ein Nieschenprodukt, weil der Entwickler das garnicht als große kommerzielle Nummer aufzieht, sondern das auch aus privatem Interesse, wie ein Hobby pflegt und entwickelt. Das stellt doch für niemanden eine Bedrohung dar. Und es wird die für die meisten bekannte digitale Welt auch nicht in seinen Grundfesten erschüttern.

Ich bin DCC-Fahrer nutzte das aus vielen Gründen auch gerne, nutze auch ABC und neuerdings integriere ich auch embedded mini Computer in meine Anlage. Trotzdem habe ich überhaupt kein Problem damit festzustellen, dass C-Digital eine Übertragungstechnik liefert, die ich für eine weitaus klügere, weitsichtigere und viel leichter handhab- und weiterentwickelbare halte , in der sogar noch viele Potentiale schlummern.
Trotzdem werde ich jetzt nicht umsteigen und ich fühle mich desshalb auch nicht schlecht, dumm oder sonst irgendwas. Ich kann so eine Tatsache feststellen und auch anerkennen ohne gleich in Selbstzweifel zu zerfallen oder mich persönlich angegriffen zu fühlen.
Klar wird ein Händler o.ä. das nicht so gerne sagen, weil er ja sein Zeug verkaufen will. Einen sachlichen Diskurs müsste man aber doch führen können, ohne dass mit aller Gewalt versucht wird mit teilweise echt haarsträubenden Argumenten, total unpassenden gezogenen Vergleichen und Beispielen Dinge klein, belanglos und unnötig hinzustellen, nur weil es anders ist als man das sonst kennt? Oder man Angst hat, ein, in ein paar Punkten, "schlechteres" System sein Eigen zu nennen?

Wertungen wie 'schlecht' und 'gut' sind doch eh total subejktiv. Technologische Felxibilität und das Verhältnis zwischen Aufwand und Funktion, sowie Koste zu Funktionen lässt sich doch alles relativ neutral beäugen.

Ich bleibe bei DCC, weil:
- Hoher Marktanteil
- sehr weit entwickelt
- viele Hersteller => viele Produkte zur Auswahl
- mit etwas technischem Sachverstand lässt sich auch in Zukunft noch hier und da etwas herausholen
- ich kenne es schon lange und damit auch viele Tücken und Krücken
- ich habe damit ein bestehendes, im Großen und Ganzen zu meiner Zufriedenheit funktionierendes System mir aufgebaut
- ein Umstieg würde auch einiges Kosten und die Zukunft wäre warscheinlich etwas ungewiss?

#116 von vinylfan , 09.04.2018 22:12

vom Namensvetter.

#117 von suffix ( gelöscht ) , 09.04.2018 22:25

Zitat

Hallo,

Zitat

So ganz stimmen kann das ja nicht, überall dieselbe DC Spannung würde ja keine Informationsübertragung mehr zulassen.
Doch, doch. Natürlich geht so etwas. Das Stichwort lautet Modulation auf ein DC Potential. Das ist eigentlich nichts ungewöhnliches in der E-Technik, nur eben für die digitale Modellbahn. Weil hier alle anderes gewohnt sind.
Was das alles für positive Effekte zur Folge hat, kann man als "normaler" Modellbahner, der seit Jahrzehnten nur das eine kennt, erst richtig nachvollziehen, wenn man das selber einmal gesehen hat oder noch besser damit umgegangen ist.

Moment - selbst in der Beschreibung des C-Digital Protokolls steht, dass die Informationen mittels aufmodulierter 450 kHz Wechselspannung mit 300-500mV Amplitude übertragen werden. Das ist doch dann eben genau nicht mehr reines DC sondern DC mit "ein bisschen" AC obendrauf. Ansonsten hätte ich mal gerne einen Link wo diese so übliche Technik erklärt wird. Es sieht eben fast wie DC aus, richtig analysiert kann man aber den kleinen AC Anteil zurückgewinnen und die enthaltenen Informationen lesen. Oder sehe ich was falsch?

#118 von StephanLeist , 10.04.2018 00:10

Guten Abend Klaus,

Echt klasse!!!

Gut, dass du dir die Mühe gemacht hast und hier einiges wieder ins richtige Licht gerückt hast. rost:

Man tut ja teilweise so als wäre DCC und mfx das beste, was war, ist und auch in Zukunft sein wird! Darum auch diese Glaubenskriege...
Manche Systeme sind eben nicht so gut, wie das einem gerne mal glauben gemacht wird. Genauso wie manche Dekoder nicht so gut sind wie behauptet wird... flaster:

@suffix?:

Zitat

Moment - selbst in der Beschreibung des C-Digital Protokolls steht, dass die Informationen mittels aufmodulierter 450 kHz Wechselspannung mit 300-500mV Amplitude übertragen werden. Das ist doch dann eben genau nicht mehr reines DC sondern DC mit "ein bisschen" AC obendrauf.

Ja, aus Sicht eines sich am Gleis hängenden Verbrauchers sieht es glaube ich so aus wie DC. Auch wenn da in ein bischen kleinem "Rauschen" eine Information mitflimmert. Die kann man anscheinend wieder herausfiltern und sie wird mit einer Trägerfrequenz von 450kHz modeliert.
Also siehst du das eigentlich richtig, denke ich.

Freundliche Grüße,
Stephan

#119 von Erich Müller , 10.04.2018 05:57

Hallo Klaus_K,

woher du nimmst, dass jemand C-Digital kleinreden will, weiß ich nicht. Da könnte man eher den Eindruck gewonnen haben, Magnus wolle DCC und mfx kleinreden...
Deine Beschreibung der "historischen Protokolle" mag für Lenz-Digital stimmen, für Märklin-Motorola ist sie technisch falsch ("gleichanteilfrei", die Möglichkeit, eine analoge Lok mitlaufen zu lassen: hat bei Märklin nie funktioniert. MM ist asymmetrisch, und weil das damals im Zweileiterbereich zu Problemen führte, hat Märklin Bernd Lenz beauftragt, noch ein System zu entwickeln, bei dem es aber dem Decoder egal ist, wenn die Zuleitungen vertauscht werden. Das war das Ur-DCC.)

Zitat

und nicht weil man damals schon wusste, dass man das ja eh nicht braucht weil irgendwann der PC kommt mit der "fetten" Software, wie das hier behauptet wurde.

Wo wurde das behauptet?

Zitat

Hätte man damals diese Dinge schon mit in eine Überlegung einfließen lassen, wäre man mit Sicherheit zu einer andern Lösung gekommen.

Sicher nicht. C-Digital ist ein Modell wie viele andere, die in den Achtzigern vorgestellt wurden und irgendwann durch die Dominanz von Märklin und dem in USA mittlerweile normierten Lenz-System (DCC) verdrängt wurden. Mit dem Unterschied, dass es erst kam, als der Zug schon abgefahren war, marktwirtschaftlich gesehen - aber auf die in jener Zeit rasante Weiterentwicklung der Halbleitertechnik zurück greifen konnte. Die "andere Lösung" war 1984 bei Vorstellung von Märklin-Digital einfach technisch noch nicht möglich, nicht auf 5cm² Platine. Die Decoder von damals sind fast ohne IC aufgebaut!

Man könnte heute ohne weiteres eine Zentrale bauen, die über den Rückmelders die Meldung "Lok x an Melder y" empfängt und daraufhin für diese Lok einen Langsam- oder Haltbefehl sendet. Kein Problem. Aber: gibt es dafür noch einen Markt?
Denn als diese Funktion möglich wurde, da waren die Steuerungsprogramme schon lange da. Denn seit es digitale Steuerungen gibt, gibt es auch den Versuch, sie mot PC auszuloten und zu mehr zu nutzen, als analog möglich war. Und flexibler - indem eben die Abläufe nicht mehr durch fest verdrahtete Elemente bestimmt werden, sondern durch Software.
Schau dir mal an, was da vor 20 Jahren schon alles auf dem Markt war! Und da gab es auch bei C-Digital keine Rückmelder den Lokdecoder.

C-Digital kann meines Wissens nur von der hauseigenen Software gesteuert werden, Das System ist derart aus einem Guss, dass kein Fremdhersteller existiert, keine andere Software - kurz: all das, was üblicherweise gegen mfx angeführt wird, ist bei C in Reinform verwirklicht. Das bedeutet aber auch, dass alle Komponenten aufeinander abgestimmt sind - und dass, wenn C ein bestimmtes Feature anbietet, es keine Möglichkeit gibt, diese Funktion durch andere Mittel aus dritter Hand zu erreichen.
Und diese Verwicklung von Protokoll und monopolistischer Komponentenentwicklung macht es unübersichtlich zu sagen, was ein Vorteil des Protokolls sein mag und was ein Vorteil der Zentrale Programmierung und -konfiguration.

#120 von Martin Lutz , 10.04.2018 07:15

[quote="Erich Müller" post_id=1820563 time=1523332648 user_id=26147]
Die Decoder von damals sind fast ohne IC aufgebaut!
[/quote]

Na fein: was ist das?
http://www.web-hgh.de/images/decoder/mae...080-proto-1.jpg

Meines Wissens haben die Decoder immer nicht viel mehr als ein IC drauf. Ist auch heute noch nicht viel anders. Ein Prozessor und mehrere Mehrfach FET (Die so aussehen, als seien sie IC's)

Das aufmodulieren von einer Wecchselspannung auf eine DC Spannung ist wirklich nichts Neues und schon gar nicht revolutionär. Ist heute schon lange Standard in der Audiotechnik. Versorgung und Tonspannung auf der gleichen Leitung bei Mikrofonen (Phantomspannung) oder schon früher bei der Modellbahn als Konstantbeleuchtung für Wagen. Oder die Spitzensperrung bei der elektrischen Energieversorgung. Da wird sogar eine höherfrequente Spoannung auf Wechselspannung aufmoduliert. Sogar der Rundfunk nutzt diese Technik seit es analoger Rundfunk gibt.

#121 von Martin Lutz , 10.04.2018 07:31

[quote="Erich Müller" post_id=1820563 time=1523332648 user_id=26147]

C-Digital kann meines Wissens nur von der hauseigenen Software gesteuert werden, Das System ist derart aus einem Guss, dass kein Fremdhersteller existiert, keine andere Software - kurz: all das, was üblicherweise gegen mfx angeführt wird, ist bei C in Reinform verwirklicht. D
[/quote]Nur weils keine Hersteller gibt, die C-Digital in ihre Software eingebunden haben, heisst das doch noch lange nicht, dass es nicht geht. Für die Erzeugung des Gleisprotokolls brauchts ne Zentrale die das kann. Die Software gibt nur der Zentrale den Befehl. Die Software muss also nicht genau wissen, wie es auf dem Gleis wirklich aussieht.
C-Digital müsste also ein Interfaceprotokoll in ihrer Zentrale haben und dieses auch kommunizieren. Das ist ja auch bei mfx nicht anders. Da sperrte sich Märklin am Anfang ja auch, so dass die bekannten Softwarehersteller gar keine Chance hatten, das mfx in ihre Software aufzunehmen. Heute geht das ja.
[quote="Erich Müller" post_id=1820563 time=1523332648 user_id=26147]
Das bedeutet aber auch, dass alle Komponenten aufeinander abgestimmt sind - und dass, wenn C ein bestimmtes Feature anbietet, es keine Möglichkeit gibt, diese Funktion durch andere Mittel aus dritter Hand zu erreichen.
Und diese Verwicklung von Protokoll und monopolistischer Komponentenentwicklung macht es unübersichtlich zu sagen, was ein Vorteil des Protokolls sein mag und was ein Vorteil der Zentrale Programmierung und -konfiguration.
[/quote]Was ja wiederum dazu führt, dass sich dieses System nie wirklich verbreiten wird, weil es eine inkompatible Insel sein wird. Und sei es noch so gut.

#122 von Klaus_K , 10.04.2018 08:15

Morgen Erich,

[quote="Erich Müller" post_id=1820563 time=1523332648 user_id=26147]
woher du nimmst, dass jemand C-Digital kleinreden will, weiß ich nicht. Da könnte man eher den Eindruck gewonnen haben, Magnus wolle DCC und mfx kleinreden...
[/quote]Steht alles da, - einfach lesen und mit den ganzen früheren Posts verifizieren....
Ich werde jetzt hier keinen Zitiermarathon anfangen.

[quote="Erich Müller" post_id=1820563 time=1523332648 user_id=26147]
Deine Beschreibung der "historischen Protokolle" mag für Lenz-Digital stimmen, für Märklin-Motorola ist sie technisch falsch ("gleichanteilfrei", die Möglichkeit, eine analoge Lok mitlaufen zu lassen: hat bei Märklin nie funktioniert.[/quote] Für Märklin AC Loks vollkommen klar!
[quote="Erich Müller" post_id=1820563 time=1523332648 user_id=26147]
MM ist asymmetrisch, und weil das damals im Zweileiterbereich zu Problemen führte, ...[/quote]auch das ist klar, dass das für analoge DC Modelle problematisch ist. (Früher war 3-Leiter Märklin strickt AC und 2-Leiter = DC.)
[quote="Erich Müller" post_id=1820563 time=1523332648 user_id=26147]
hat Märklin Bernd Lenz beauftragt, noch ein System zu entwickeln, bei dem es aber dem Decoder egal ist, wenn die Zuleitungen vertauscht werden. Das war das Ur-DCC.)[/quote] Ja, ein weiteres Detail. Was sagt 'dir' das dann? Was möchtest du hier dann gerne für einen Schluss ziehen?

[quote="Erich Müller" post_id=1820563 time=1523332648 user_id=26147]
Wo wurde das behauptet?
[/quote]Wie gesag, einfach noch einmal die älteren Posts lesen. Von mir gibt es hier keinen Zitiermarathon...

[quote="Erich Müller" post_id=1820563 time=1523332648 user_id=26147]

Zitat

Hätte man damals diese Dinge schon mit in eine Überlegung einfließen lassen, wäre man mit Sicherheit zu einer andern Lösung gekommen.

Sicher nicht. C-Digital ist ein Modell wie viele andere, die in den Achtzigern vorgestellt wurden und irgendwann durch die Dominanz von Märklin und dem in USA mittlerweile normierten Lenz-System (DCC) verdrängt wurden.[/quote]
Soweit ich weiß, hatte es nie einen Markt, unzwar nur weil die Marktmacht der bekannten Hersteller viel zu groß war und man an deren Digitaltechnik alles gemessen hat (& sehr stümperhafte Vermarktung). & sehr schlechte Vermarktung. & kein Internetauftritt, auch nicht um die 2000er.
Eine verdrängung konnte also nie stattfinden, weil es 'garkeinen' Marktanteil hatte. Mit der Idee des Systems hätte man alle damaligen Systeme in vielerlei Hinsicht "in die Tasche stecken können". Sogar heute könnte es locker mit allen anderen (auch den modernsten) Zentralensystemen mithalten und sogar mit so mancher "aufgemozter" Lösung mit PC.

[quote="Erich Müller" post_id=1820563 time=1523332648 user_id=26147]
Mit dem Unterschied, dass es erst kam, als der Zug schon abgefahren war, marktwirtschaftlich gesehen - aber auf die in jener Zeit rasante Weiterentwicklung der Halbleitertechnik zurück greifen konnte. Die "andere Lösung" war 1984 bei Vorstellung von Märklin-Digital einfach technisch noch nicht möglich, nicht auf 5cm² Platine. Die Decoder von damals sind fast ohne IC aufgebaut!
[/quote]Jein! Ja, das ist aber auch nicht die Technik, die bis heute genutzt wird. Die Entwicklung unterligt und unterlag schon immer einem Prozess und wurde bereits verändert.
Nein, denn hätte man andere Gedanken an die Zukunft einfließen lassen, hätte man ein Protokoll z.B. nicht in dieser Form restriktiv aufgebaut, egal ob eine Funktion beim damaligen technischen Stand 'noch' nicht ging.
Hier wird schon wieder so argumentiert, als wäre es, wie es gelaufen ist, die einzig sinnvolle und richtige Lösung gewesen und man konnte es nur technologisch nicht usw. usf. ...
Das ist eben Unfug. Man hatte sogut wie keine visionären Gedanken darin einfließen lassen und auch selbst nicht so richtig an einen großen Digitalmarkt geglaubt so sieht es aus. (Das man an einen großen Markt für Digital nicht geglaubt hat, weiß ich aus sicherer Quelle)
C-Digital wurde auch in den 90ern entwickelt, wo vieles technisch noch nicht möglich war, was es heute ist, trotztdem ist hier eine Idee, die sowohl updatefreundlich, als auch in Sachen Kompatibilität unproblematisch ist und noch enorme Potentiale bereithält. Das hätte man bei Märklin oder Lenz oder GFN usw. bereits 1989/90 genauso gekonnt.

[quote="Erich Müller" post_id=1820563 time=1523332648 user_id=26147]
Man könnte heute ohne weiteres eine Zentrale bauen, die über den Rückmelders die Meldung "Lok x an Melder y" empfängt und daraufhin für diese Lok einen Langsam- oder Haltbefehl sendet. Kein Problem. Aber: gibt es dafür noch einen Markt?
[/quote] Auch darum geht es überhaupt nicht, ob man das heute durch abschauen dem C-Digital nachmachen könnte. Klar kann man alles nachmachen... Was soll das jetzt für einen Mehrwert bringen?
Was soll das beweisen? Das die Big-Player in der Lage sind, durch Abschauen etwas umzusetzten, zudem sie schon vor fast 30 Jahren in der Lage gewesen wären, es aber von alleine nicht geschafft habe, es verpennt haben?
Und damals gab es definitv dafür einen Markt!

-> Wieder: Was soll das für eine Argumentation sein, wenn man sagt, dass man das dem C-Digital doch nachmachen könnte? Und desshalb ist DCC oder mfx dann was? .... irgendwie besser???

[quote="Erich Müller" post_id=1820563 time=1523332648 user_id=26147]
Denn als diese Funktion möglich wurde, da waren die Steuerungsprogramme schon lange da.[/quote]
1995? -> wie war da der Marktanteil, von den paar Lösungen?

[quote="Erich Müller" post_id=1820563 time=1523332648 user_id=26147]
Denn seit es digitale Steuerungen gibt, gibt es auch den Versuch, sie mot PC auszuloten und zu mehr zu nutzen, als analog möglich war. Und flexibler - indem eben die Abläufe nicht mehr durch fest verdrahtete Elemente bestimmt werden, sondern durch Software.
Schau dir mal an, was da vor 20 Jahren schon alles auf dem Markt war! Und da gab es auch bei C-Digital keine Rückmelder den Lokdecoder.[/quote] Ja, aber nur weil man aus Kostengründen nicht alles auf einmal auf den Markt werfen konnte, die Entwicklung hätte Conrad ja auch mehr Geld gekostet und man musste erst einmal sehen, ob man damit überhaupt zahlende Kundschaft erreicht.
Mit der damaligen mickrigen Vermarktung usw. kein wunder, dass das dann nicht geglückt ist. Technologisch wäre es natürlich schon möglich gewesen und auch noch vieles andere. Darum ergibt sich auch nicht der kleinste Bruch durch die nun hinzugefügte Rückmeldung usw. nicht wie bei Railcom, wo nachträglich etwas hineingebastelt wurde, weil man eben nicht schon früher soetwas bedacht hatte.
Du kannst die Idee und das Potential einer Technik oder eines Verfahrens nicht nur daran messen, was zum Zeitpunkt X auf dem Markt ist. Man muss da ganz andere Dinge mit betrachten, sonst geht man als Unternehmen evtl. in den Ruin. Sieh Nokia, die das Potential des Smartphones unterschätzten oder Kodak das der digitalen Photografie...

[quote="Erich Müller" post_id=1820563 time=1523332648 user_id=26147]
C-Digital kann meines Wissens nur von der hauseigenen Software gesteuert werden, Das System ist derart aus einem Guss, dass kein Fremdhersteller existiert, keine andere Software - kurz: all das, was üblicherweise gegen mfx angeführt wird, ist bei C in Reinform verwirklicht.
[/quote]Klar, hat niemand anders behauptet und ist auch logisch, weil es keinen Markt hat und sogar fast nur aus einer Hand entwickelt wird. Allso alles vollkommen logisch.
[quote="Erich Müller" post_id=1820563 time=1523332648 user_id=26147]
Das bedeutet aber auch, dass alle Komponenten aufeinander abgestimmt sind - und dass, wenn C ein bestimmtes Feature anbietet, es keine Möglichkeit gibt, diese Funktion durch andere Mittel aus dritter Hand zu erreichen.[/quote]Stimmt zwar auch. Liegt aber weder daran, dass alles aus einer Hand ist, noch daran, dass alles aufeinander abgestimmt ist, sondern schlicht und ergreifend an der Tatsache, das sich kein zweiter Hersteller damit befassen will, weil es keinen Markt gibt. Ich könnte thoretisch für mich selbst jeder Zeit eigene Dinge dazu basteln, mir eine eigene Software schreiben, ...
Und wieder, was soll das zur Frage der Qualität der Idee und wie gut eine Lösung ist oder wie hoch das darin noch schlummernde Potential ist oder wie einfach strukturiert ein System ist, bringen?

[quote="Erich Müller" post_id=1820563 time=1523332648 user_id=26147]
Und diese Verwicklung von Protokoll und monopolistischer Komponentenentwicklung macht es unübersichtlich zu sagen, was ein Vorteil des Protokolls sein mag und was ein Vorteil der Zentrale Programmierung und -konfiguration.
[/quote]Das stimmt natürlich. Hier tut sich jemand mit entsprechenden Sachkenntnissen (z.B. Ahnung von Nachrichtentechnik) leichter. Man könnte bei ehrlichem Interesse, also wenn man wirklich wissen will wie gut etwas ist, sich auch mit dem Entwickler unterhalten und in einen Diskurs treten. Das mancht man aber wohl nicht, lieber stellt man sich hin und behauptet Sachen, die nicht haltbar sind.

Ich bleibe doch auch bei meiner DCC-Lösung und habe die wichtigsten Gründe dafür genannt. Und es bleibt jedem unbenommen, dass genauso zu machen. Ich verstehe nicht warum man mit fadenscheinigen Argumenten die Idee und Technik von C-Digital kleinreden muss? Sie ist (aus anwendungsbezogener nachrichtentechnischer Sicht) nun einmal besser, was bei der Gestaltung vom Protokoll, der Rückmeldung und der Verdrahtung Vorteile liefert, liefern kann. Davor muss man sich doch nicht fürchten oder sein System und sich bedroht fühlen.
Ich kann den Aufstand hier nicht verstehen. ???

So mir reicht es jetzt wieder von der ganzen Zitiererei

Liebe Grüße,
Klaus

#123 von StephanLeist , 10.04.2018 09:08

Hallo Martin und Klaus,

Ich stimme euch auch voll und ganz zu.
Die Idee von C-Digital war und ist nicht schlecht. Sie ist nichts bahnbrechend neues und man kennt das aus anderen Bereichen schon seit über 50 Jahren. Nur weil es dem landläufigen Modellbahner nicht bekannt war, zu sagen, dass es erst mit moderner Microcontroller-Elektronik möglich ist, halte ich auch für haltlos.

Ich weiß auch nicht, warum man nicht eingestehen kann, dass sich damalige Hersteller beim Markt für Digital so unsicher waren und der Fokus auf anderen Dingen lag, dass man zu einer für zukünftige Entwicklungen und den schnellen technischen Zuwachs eher ungünstigen Lösung gekommen ist.

Ich finde es durchaus interessant zu lesen, was sich der Entwickler hier und da gedacht hat und was sich so für Eigenschaften und Funktionalitäten ergeben. Das kann ich dann mit meinen Erfahrungen aus dem DCC-Segement vergleichen.
Und auch mir sind die Schwächen der Übertragungn des DCC-Protokolls schon weit mehr als nur einmal begegnet. Da ist es dann natürlich noch interessanter zu lesen, dass es eben doch auch anders gehen würde.
Die Interpretation, ob man dann etwas verschlafen hat oder man einfach nicht absehen konnte, bleibt ja jedem selbst überlassen. Ich bin ja vor allem auch von den C-Digital Dekodern mit dieser Motorregelung sehr angetan.

Den Streit um den Vergleich zwischen Zentralenlösung mit irgendeiner angehängten Form von Computer (embedded oder PC) und zusätzlicher Software zu einer "einfachen" Zentralensteuerung, kann ich auch nicht verstehen. Da werden doch Fahrräder mit Flugzeugen verglichen.
Fahrräder = Zentralensteuerung: Man kann damit von A nach B allerdings nicht besonders schnell und manches (übers Meer) kann eben nicht gehen.
Flugzeuge = PC-Lösungen: Man kann damit fast überall hin, ist flexibel, und ist nach der Landung aber trotzdem z.B. auf ein Fahrrad o.ä. angewiesen. Ausschließlich Fliegen alleine geht nämlich nicht richtig.

Ich hoffe mein kleines metaphorisches Beispiel wird verstanden trotz der Schwächen die es natürlich hat...

Freundliche Grüße,
Stephan

P.S. Fast alles ist zu einem Zeitpunkt doch einmal ein Produkt, eine Entwicklung, aus einem Guss. Wie sich das ändert, liegt doch auch immer am Interesse andere Mitbewerber und der enthaltenen Marktchancen. C-Digital ist in der Hinsicht für keinen Hersteller attraktiv, also warum sollte sich hier ein herstellerunabhängiges Protokoll oder so entwickeln?
Martin könnte ja eine Art Übersetzer-Interface bauen, wo seine Datenbefehle hineingehen und diese dann in eine DCC-konforme Form gewanelt werden und schon hätte man die Anbindung zum DCC-Markt und könnte auch andere PC-Software nutzen.

#124 von Martin Lutz , 10.04.2018 10:06

Zitat

Den Streit um den Vergleich zwischen Zentralenlösung mit irgendeiner angehängten Form von Computer (embedded oder PC) und zusätzlicher Software zu einer "einfachen" Zentralensteuerung, kann ich auch nicht verstehen. Da werden doch Fahrräder mit Flugzeugen verglichen.
Fahrräder = Zentralensteuerung: Man kann damit von A nach B allerdings nicht besonders schnell und manches (übers Meer) kann eben nicht gehen.
Flugzeuge = PC-Lösungen: Man kann damit fast überall hin, ist flexibel, und ist nach der Landung aber trotzdem z.B. auf ein Fahrrad o.ä. angewiesen. Ausschließlich Fliegen alleine geht nämlich nicht richtig.

Dem kann ich auch nicht zustimmen. Was ist den ein PC? Oder handelt es sich bei einer ECoS oder Cs nicht um eine Art Computer. Ein Raspery hat eigentlich alles zum Computer. Man muss nur eine Maus, Tastatur und einen Monitor anschliessen und fertig ist der PC.

Das Wort PC heisst Personalcomputer, ein altes Wort. Nach meiner Meinung verschwimmt sowieso alles ineinander. Daher ist eine moderne Modellbahnsteuerung (nur über eine CS oder Ecos) nicht so weit weg von dem was man PC Steuerung nennt.

#125 von MariusS ( gelöscht ) , 10.04.2018 11:05

Hallo an alle,

[quote="Martin Lutz" post_id=1820615 time=1523347577 user_id=124]

Zitat

Den Streit um den Vergleich zwischen Zentralenlösung mit irgendeiner angehängten Form von Computer (embedded oder PC) und zusätzlicher Software zu einer "einfachen" Zentralensteuerung, kann ich auch nicht verstehen. Da werden doch Fahrräder mit Flugzeugen verglichen.
Fahrräder = Zentralensteuerung: Man kann damit von A nach B allerdings nicht besonders schnell und manches (übers Meer) kann eben nicht gehen.
Flugzeuge = PC-Lösungen: Man kann damit fast überall hin, ist flexibel, und ist nach der Landung aber trotzdem z.B. auf ein Fahrrad o.ä. angewiesen. Ausschließlich Fliegen alleine geht nämlich nicht richtig.

Dem kann ich auch nicht zustimmen. Was ist den ein PC? Oder handelt es sich bei einer ECoS oder Cs nicht um eine Art Computer. Ein Raspery hat eigentlich alles zum Computer. Man muss nur eine Maus, Tastatur und einen Monitor anschliessen und fertig ist der PC.

Das Wort PC heisst Personalcomputer, ein altes Wort. Nach meiner Meinung verschwimmt sowieso alles ineinander. Daher ist eine moderne Modellbahnsteuerung (nur über eine CS oder Ecos) nicht so weit weg von dem was man PC Steuerung nennt.
[/quote]

Da möchte ich mich doch auch gleich noch mit meiner Frage anhängen. Ich glaube ich habe hier eine wichtige Sache (egal ob DCC oder mfx) noch nicht ganz verstanden. :
Ist es nicht so, dass die Steuerungslösungen, deren Eigenschaften mir zum C-Digital von Carsten, Erich usw. entgegen gehalten wurden, dann immer aus einem "Basissystem", also einer rudimentären DCC oder mfx Zentrale bestehen, an die dann immer zusätzlich eine Art Computer, - egal ob Raspberry oder PC - angeschlossen wird, damit sich durch eine Software dann all diese Eigenschaften ergeben können?
Und hier ist es dann völlig egal ob die Zentrale, also das Basissystem eine "einfache" Zentrale ist, oder bereits selbst schon praktisch ein Computer oder embedded PC, wie die EcoS und die CSx?
Man benötigt in jedem Fall einen zusätzlichen PC oder eben etwas vergleichbares für so eine Steuerung, oder? Oder anders ausgedrückt; die Systeme alleine, auch wenn sie selbst schon aus einer Art Computer bestehen, können das nicht bieten.

Wenn dem so wäre, macht es natürlich garkeinen Sinn auf dieser Basis Vergleiche anzustellen.

Übrigens vielleicht fühlt sich der ein oder andere auch besser, wenn ich auch einmal schreibe, was mir an diesen DCC oder mfx Lösungen mit Softwaresteuerung sehr gefällt.
Ich finde es toll, dass hier das Rückmelden unabhängig vom System geschehen kann. Für die Rückmeldung und damit eigentlich für die komplette Softwaresteuerung ist es fast unerheblich, ob die Anlage eine DCC, mfx, MM oder evtl. sogar analoge Anlage ist. Das ist doch klasse und räumt dem Anwender einen enorm flexiblen Spielraum ein.

Dazu dann gleich wieder ein kleines Kontra:
Da diese Lösung eine System unabhängige darstellt, können deren Funktionen weder DCC, mfx oder sonst irgendetwas zugeschrieben werden. Damit ist auch jegliche Funktion, die sich hierdurch ergibt, nicht als Pro für eines dieser Systeme anzurechnen.
Alle Argumente, die sich hierdurch ergeben und genannt wurden, sind für die Diskussion DCC, mfx, oder oder oder also nichtig, oder?

Grüße,
Marius

Beiträge:	1.279
Registriert am:	03.04.2012
Ort:	MKK, Hessischer Spessart
Gleise	K-Gleis und Selbsbau-Pickel-Gleis (DC-Gleis mit Mittelleiter ausrüsten)
Spurweite	H0
Steuerung	Rocrail + Rocnetnode auf Raspi
Stromart	Digital

Beiträge:	806
Registriert am:	16.07.2015

Beiträge:	1.279
Registriert am:	03.04.2012
Ort:	MKK, Hessischer Spessart
Gleise	K-Gleis und Selbsbau-Pickel-Gleis (DC-Gleis mit Mittelleiter ausrüsten)
Spurweite	H0
Steuerung	Rocrail + Rocnetnode auf Raspi
Stromart	Digital

Beiträge:	4.882
Registriert am:	26.04.2006

Beiträge:	1.279
Registriert am:	03.04.2012
Ort:	MKK, Hessischer Spessart
Gleise	K-Gleis und Selbsbau-Pickel-Gleis (DC-Gleis mit Mittelleiter ausrüsten)
Spurweite	H0
Steuerung	Rocrail + Rocnetnode auf Raspi
Stromart	Digital

RE: Mfx und DCC

RE: Mfx und DCC

RE: Mfx und DCC

RE: Mfx und DCC

RE: Mfx und DCC

RE: Mfx und DCC

RE: Mfx und DCC

RE: Mfx und DCC

RE: Mfx und DCC

RE: Mfx und DCC

RE: Mfx und DCC

RE: Mfx und DCC

RE: Mfx und DCC

RE: Mfx und DCC

RE: Mfx und DCC

RE: Mfx und DCC

RE: Mfx und DCC

RE: Mfx und DCC

RE: Mfx und DCC

RE: Mfx und DCC

RE: Mfx und DCC

RE: Mfx und DCC

RE: Mfx und DCC

RE: Mfx und DCC

RE: Mfx und DCC

Bitte geben Sie einen Grund für die Verwarnung an

Beiträge:	864
Registriert am:	07.01.2015
Ort:	Wirges WW
Gleise	Zweileiter
Spurweite	H0
Steuerung	Can Digital
Stromart	Digital