Morgen an die Runde,
@Erich:
Auch wenn das nicht an mich ging, ...
[quote="Erich Müller" post_id=1821234 time=1523518463 user_id=26147]Nun spann mal den Karren nicht vor den Gaul. DU hast behauptet, bei der Entwicklung der heute marktbeherrschenden Systeme sei man nicht vorausschauend vorgegangen. Das (deine Behauptung) ist aber Unfug, denn in den Achtzigern liefen zwar ein paar Utopisten herum, die immer noch davon träumten, im Jahr 2000 würden wir alle in kleinen glaskugelartigen selbstfahrenden Gefährten durch die Gegend getragen werden und das klassische Kraftfahrzeug längst abgeschafft haben, aber die Leute, die Technik entwickelten und verkaufen mussten, mussten sich auch an das halten, was nach den damaligen (!) Perspektiven in absehbarer Zeit machbar sein würde.[/quote]würde ich gerne von dir wissen, da du hier diesen Vergleich ziehst,
1) was von C-Digital sich in den 80ern noch nicht bewerkstelligen lies?
2) welche Funktionalität von C-Digital aus sicht eines Technikers aus den 80ern total utopisch war?
3) warum man schon seit den 80ern (damit also fast von Beginn an) fest mit einer Computersteuerung gerechnet haben soll, aber anderes Utopien gewesen sein sollen?
@Klaus und Erich:
[quote="Erich Müller" post_id=1821234 time=1523518463 user_id=26147]Du steckst in einer Schleife: du willst unbedingt beweisen, dass eins besser oder schlechter ist als das andere. Was mich auf den Anfang zurückbringt - nur DU hast gelesen, dass jemand C-Digital niedermachen will. [/quote]
Mir persönlich ist es eigentlich vollkommen schnuppe, was hier wer über C-Digital denkt und meint zu wissen. Wenn ich was genau wissen will, frage ich den Entwickler. 
Das wurde doch nur Thema, weil ich mit diesem Hintergrund eine bestimmte Denkweise hatte/habe.
Was mich gestört und etwas geärgert hatte, war, dass man, wenn ich irgendeine Schwäche des DCC Protokolls nannte, gesagt hat, es wäre 1. keine Schwäche, weil ich "Digital" FALSCH verstehen würde und das nur so - wie bei DCC - richtig sei oder 2. dass es, praktisch nicht vorhanden sei und ich da etwas falsch verstanden hätte. Wenn jemand anderes (mit anderem Hintergrund) irgendwo hier im Forum allerdings genau die gleiche Sache bemängelt, versucht man demjenigen zu helfen, um sein Problem in den Griff zu bekommen und es gibt oft einige, die eben genau das gleiche Problem bereits hatten.
Nur wenn ich solche Probleme dann als Mangel aufzeige und auch meine die grundlegende Problematik erfasst zu haben, stellt man alles in Abrede und lässt mich als einen ahnungslosen Quacksalber dastehen.
Schaut hier doch mal im Forum, wie oft Anwender irgendwelche Probleme haben und die Lösung dann darin bestand z.B. Multiprotokoll im Dekoder zu deaktivieren oder Railcom zu deaktivieren oder Analogerkennung zu deaktivieren oder mehr Dioden in der ABC-Schaltung zu verwenden, was dann wieder andere unschöne Effekte nach sich zieht!? Aber klar, die Probleme kommen nur, weil einige Hersteller hier Designfehler gemacht haben oder Anwender zu "blöd" sind ... etc.
[quote="Erich Müller" post_id=1821234 time=1523518463 user_id=26147]Du behauptest, weil das nicht in DCC integriert wäre (mfx und MM und SX blendest du offensichtlich aus deiner Argumentation aus), wäre es nicht ohne PC möglich.[/quote]Nein Erich, das hatte ich behauptet. Und ich habe damals, als bei mir die Digitalisierung anstand, mich lange und breit damit befasst, was wie bei mir mit welchem Aufwand möglich ist. Fakt ist, es wäre weder mit DCC, noch mfx oder SX möglich. Und das gilt bis heute.
Was evtl. tehoretisch möglich wäre ist mir als Anwender zunächst doch total egal! Fakt ist, mit keinem anderen System liese und lässt sich das Umsetzten, was ich heute habe. Außer wahrscheinlich, wenn man zusätzlich einen PC oder ähnliches daranhängt und sich eine Software kauft, die dann aber auch erst einmal beherscht werden muss. (etwas was auch oft vergessen wird bei diesen komplexen "High-End-Lösungen")
Zitat
Fragen wir doch Marius, was eine gleichwertige, also gleich-funktionale Lösung, ihn im Fall eines DCC-Systems gekostet hätte. ????
So eine Lösung wäre mich fast doppelt so teuer gekommen! Es ginge natürlich auch billig, indem man freeware nutzt und günstigere Rückmelder oder eine günstige Basiszentrale und evtl einiges selber baut. Aber da bin ich mir dann nicht sicher, ob das alles dann so richtig und zuverlässig funktioniert. Wer billig kauft, kauft meist zwei mal!
Ausnahmslos alle Mobahner mit denen ich bis jetzt zu tun hatte, die meine Anlage und/oder deren Auf- und Abbau miterlebt haben, waren über die einfachheit des Systems und der darin enthaltenen Funktionalität erstaunt. Da waren auch einige PC-Fahrer dabei ...
Und KEINER hat jemals nur einen Ton zu mir gesagt, von wegen, dass das doch mit einer PC-Steuerung und DCC leichter ging, oder dass sie das für umständlich, unzweckmäßig oder sonst was halten.
Ganz im Gegenteil, nur zu oft kamen Aussagen, wie: "Echt interessant dieses System. Erstaunlich, dass das nicht bekannt ist ...?"
[quote="Erich Müller" post_id=1821234 time=1523518463 user_id=26147]Es gab schon PC-Steuerungsprogramme, bevor C-Digital überhaupt vorgestellt wurde - sieh mal an. (Wer hat denn dann da wohl "nachgemacht", wenn du diese Argumentationsschiene unbedingt weiterführen willst?)[/quote]
Also das ürde mich allerdings auch brennent interessieren, was C-Digital hier von irgendeinem Hersteller abgeschaut haben soll? Da musst du jetzt aber wie du es nennst "Butter bei die Fische tun" 
[quote="Erich Müller" post_id=1821234 time=1523518463 user_id=26147]Dass du immer wieder das "Problem" aufgreifst, dass ein paar wenige Methusalem-Decoder mit ein paar Dingen des DCC von heute nicht klarkommen, weil sie damals nicht für die heute verwendete Lösung optimiert wurden, ist eine Politiker-Argumentation.[/quote]Ist z.B. ein Lopi V3/4 ein Methusalem-Decoder?
In dieser Auflistung hier finden sich einige Dekoder, die nach meinem Verständniss weit von einem Methusalem entfernt sind, jedoch was Railcom angeht problematisch sein können.
In meinem Modellbahnerkreis wird Railcom kaum, bis garnicht verwendet und immer mit der gleichen Begründung: Zu teuer und zu Problematisch (entweder wegen Kompatibilität oder der Funktionsweise an sich)
Das mag nicht representativ sein, für mich aber dennoch ein deutlicher Hinweise auch wenn man mal sieht, was man hier und da in Foren lesen kann.
Ähnliches gilt übrigens für ABC. Fast alle die ich kenne und das verwenden, so habe ich feststellen können, arbeiten mit 2 Abschnitten pro Halt und verwenden nur allzuoft nur noch eine Dekoder-Marke, damit das ganze sicher läuft. Ältere Dekoder und das müssen nicht einmal Methusalems sein, kommen da auch nicht in Frage.
[quote="Erich Müller" post_id=1821234 time=1523518463 user_id=26147]Das C-Digital-Protokoll hat bestimmt Vorteile an bestimmten Stellen, so wie es an anderen Stellen hinter anderen Protokollen zurückstehen muss.[/quote]Diese würden mich auch interessieren. Vorausgesetzt du meinst damit nicht, welche Informationsstruktur momentan über das Protokoll gejagt wird sondern eben das Protokoll an sich.
Denn die Informationsstruktur ist im Fall von C-Digital problemlos anpassbar, so zumindest meine Erfahrung.
[quote="Erich Müller" post_id=1821234 time=1523518463 user_id=26147]Hallo Marius,
auf dem Markt sieht es aktuell (und seit 30 Jahren) so aus, ja. Wie gesagt, technisch wäre es keine Schwierigkeit, Langsamfahrfunktion und andere Automatikfunktionen in die Zentrale einzubauen, aber das macht derzeit niemand - es wäre ein zu großes unternehmerisches Risiko, meiner Ansicht nach.[/quote]
Ok. Und meine Frage von Beginn an war doch, warum man genau das irgendwann in diesen 30 Jahren nicht einfach gemacht hat?
Und kommt jetzt nicht wieder mit, "... weil dann ein digitales Prinzip verletzt werden würde." Dieses sog. Prinzip wird bei ABC und Halten mit Gleichstrom u.a. allemal verletzt.
Oder dass es dafür keinen Markt gäbe. Da muss man sich nur einmal umhören. Alle ABC-Fahrer, die ich kenne, würde bspw. sofort so etwas bevorzugen.
[quote="Erich Müller" post_id=1821234 time=1523518463 user_id=26147]
Zitat
Wenn dem so wäre, macht es natürlich garkeinen Sinn auf dieser Basis Vergleiche anzustellen.
Richtig. [/quote]Wenn du mir das jetzt so einfach doch bestätigst, muss ich mich schon fragen, warum wir hier dann überhaupt seitenweise herumdiskutieren, wenn es doch unsinnig ist, die Eigenschaften des C-Digital-Protokolls mit einem DCC oder mfx System + PC + Software zu vergleichen und nicht ausschließlich die Protokolle untereinander? Beim ganze Thema dieses Thread, geht es doch um die Protokolle.
[quote="Erich Müller" post_id=1821234 time=1523518463 user_id=26147]Auch Grünwald bietet übrigens PC-Steuerung an - ich habe aber nicht weiter nachgelesen, was das Programm kann und tut.[/quote]Das ist nur eine Software um zusätzlich zu den Handreglern noch mit dem PC steuern zu können und Programmierungen zu überwachen und zu tätigen. Kompatibel zum alten C-Digital aus den 90ern. Also keine große Sache. Das ist eher eine kleine Zugabe für die alte Steuerung, darum auch das nötige Interface.
[quote="Erich Müller" post_id=1821234 time=1523518463 user_id=26147]
Und um den Vergleich der Protokolle mal festzuhalten: Beide sind in der Lage, 126 oder 128 Fahrstufen zu übertragen mit zweieinhalb Dutzend Sonderfunktionen. Bei beiden ist es möglich, dass der Decoder seine Identität übermittelt - bei mfx wird das verwendet, um die Adresse auszuhandeln, unter der die Zentrale den Decoder anspricht, und die Belegung der Funktionstasten an die Zentrale zu übermitteln, aber Rückmelderfunktionen im laufenden Betrieb werden derzeit nicht angewandt; bei DCC-Railcom wird bisher m.W. nur die identifizierte Rückmeldung verwendet, Railcom+ kann auch die Anmeldung an die Zentrale, ist aber ein Sonderprotokoll, das nicht offengelegt wurde und nicht normiert ist. mfx+ bietet die Möglichkeit, dass die Lok "Betriebsmittelstände" simuliert und an die Zentrale zurücksendet - ein Feature, das "ernsthafte" 
Modellbahner nicht benützen, aber wer auch gern mal einfach Lokführer spielen will, könnte es schätzen.
Alle mfx-Features sind allen mfx-Decodern gemein (M4 von esu nur eingeschränkt), mfx+ nur bei ab Werk mit einem solchen Decoder ausgerüsteten Loks. Mit den CentralStations 2 und 3 von Märklin kann mfx+ genutzt werden, mfx auch mit esu-Zentralen und MobileStations von Märklin, ein eingeschränktes Funktionieren (keine automatische Anmeldung), m3 genannt, geht auch bei tams.
Railcom funktioniert nur mit entsprechend ausgerüsteten Decodern und Rückmeldern.
Rückmeldung, auch Railcom-Rückmeldung, erfolgt nicht übers Gleis (Railcom-Erkennung in einem isolierten Gleisabschnitt, Meldung an Zentrale bzw. PC über den Bus abseits des Gleises) - abgesehen von der mfx-Erkennung, die übers Gleis und ohne isolierte Abschnitte erfolgt.
C-Digital kann ich daneben nicht genügend einordnen, das kannst du vielleicht nachfügen.[/quote]
Okay, ich habe nocheinmal mit Martin Rücksprache halten müssen und hoffe jetzt alles richtig verstanden zu haben. 
ops:
Über das C-Digital Protokoll können bis zu 12 Bit für Fahrstufen verwendet werden (macht über 4000 Fahrstufen, die der Dekoder interprätieren kann)
Momentan werden 5 Bit also 32 verwendet, weil er keinen Mehrwert in einer genaueren Abtastung sieht und weil so auch problemlos die Dekoder der ersten Stunde betrieben werden können. hier zu lesen
Der Adressraum beinahltet maximal 3 mal 16Bit, also fast 200.000 Adressen, (Funklösungen nicht einbezogen). Von diesen werden momentan 1 mal 10Bit also etwa 1000 Adressen genutzt. Auch hier sieht der Entwickler momentan keinen Mehrwert eines größeren Adressraums, weil Aliasse zum Einsatz kommen können.
Die mögliche Anzahl der maximal angehängten Funktionen sind dem Entwickler nicht bekannt, "... das müsste man testen, wie viele sich senden lassen, bis es die Geschwindigkeit der Empfangsübertragung negativ beeinträchtigt." Momentan werden 13 gesendet, von denen aber nur 11 dekoderseitige Verwendung finden.
Angehängt wurden testweise bereits 2 Byte also 16 Bit was Problemlos möglich war. Damit kann man mit Sicherheit sagen, dass 16 möglich sind, sehr wahrscheinlich aber auch noch mehr.
Es werden fest 2 Bit für Halteinformation, also 4 Zustände, mitgeschickt. => autom. Signalhalteerkennung ohne zusätzlich Hardware.
Es wird fest mindestens 1Bit für die Massensimulation (ABV) mitgeschickt.
Die Übertragungsgeschwindigkeit kann je Kanal unterschiedlich ausfallen und kann in einem Kanal in festen Grenzen variiert werden.
Die Übertragung von der Zentrale je Kanal läuft Zyklisch mit 4 Prioretisierungsstufen.
Die Übertragung eines Kanals kann parktisch simultan zu einem anderen erfolgen.
Die Rückmeldung kann sowohl in einen Datensatz integriert, also auch völlig alleinstehend auf einem anderen "Kanal" erfolgen, (als auch per Funk. - wird nicht genutzt)
Momentan geschieht das integriert in das hinwärts gesendete Protokoll. Hierfür sind Trennabschnitte mit Empfangsmodulen vorgesehen, da das Signal bei Streckenlängen über 5m zu niedrigen Signal-Rauschabstand aufweist. Also muss hier Segmentweise das Signal aufgenommen und dann über einen einheitlichen C-Digital-BUS, welcher ein Konglomerat aus standard Industrie-BUSen wie CAN darstellt, zur Zentrale übertragen werden. Über eine Wireless-Lösung wird noch nachgedacht???
Die Rückmeldung funktioniert wärend des laufenden Betriebs, überall dort, wo ein Rückmlede-Empfangsmodul ans Gleis angeschlossen ist.
Das Rückmelden der eigenen Adresse macht ein Dekoder, um sich bei der Zentrale zu melden, von alleine.
Bestätigen tut der Dekoder auch von alleine. Alle anderen gewünschten Informationen in der Rückmeldung sind Sache der Einstellung (aktuelle Geschwindigkeit, Funktionen, Empfangsqualität, Dekodertemperatur, Last, ...).
Für die Rückmeldung muss der Dekoder entsprechend in der Lage dazu sein. Alte können das nicht.
Gleiches gilt selbstverständlich für die Anzahl der Funktionen.
Für automatisches Halten, Signalhalterkennung und Langsamfahrterkennung ist keine Eigenschaft des Dekoders oder besondere Hardware am Gleis notwendig. Das System bringt das standardmäßig mit.
Ich hoffe ich habe nichts vergessen und keinen Fehler irgendwo gemacht. Von manchem was ich hier geschrieben habe, habe ich leider selber nur sehr wenig Ahnung, aufgrund mangelnden techn. Fachwissens. ops:
Grüße,
Marius
verwirklicht.
