...die Verbundadresse hatten wir schon vor Alf in #37, insofern kam nichts neues, was DCC in Vorteil setzt, aber alle drei Anwendungen betreffen wahrscheinlich auch nicht die Mehrheit der MoBa-Kunden...

LG aus BaWü, Stefan

Hallo Stephan,

Zitat

---

Zitat

---

Als Beispiel: Ich habe 2 Lokomotiven die haben individuale Adressen (z.B. 1020 + 1021), wenn ich die im Verbund (Normalfall) fahre kriegen die die Verbundadresse (CV19 & 20) (z.B. 1022), nun fahre ich damit 3 verschiedene Personenwagenganituren, die alle je einen Decoder haben, diesen stelle ich auf Adresse 1022 ein, die erste Wagengruppe hat Rücklicht auf F15 und Innenbeleuchtung auf F16, die 2. hat F17 & 18 und die 3. F19 & F20. Wenn ich nun nicht im Verbund (Sonderfall) fahre, kann ich mit einem 2. Fahrregler (mit Adresse 1022) immer noch bei allen 3 Gruppen das Licht autark schalten.

---

Also die Vorteile von DCC gegenüber mfx, wenn es der Dekoder unterstützt, sind bis jetzt:
- ABC Bremsen
- Railcom Detektion im Rückmeldebus
- Verbundsadresse
Ich muss aber feststellen, dass diese Punkte, bei Einsatz einer PC Steuerung, sich stark relativieren.

---

Mich hat bei meiner Festlegung auf DCC eher folgendes beeinflußt:
- Plux-Schnittstelle anstelle mtc (da werden 3 Eingänge wegen Hallsensoren verschwendet, Hickhack verstärkte/unverstärkte FU-Ausgänge, kein FU-Eingang)
- DCC-System wird von Allen (nicht Pickel-) Herstellern unterstützt
- 9 FU-Ausgänge (10 mit Indexpin - dann aber kein DCC-Standard) möglich, 2 davon für Servo und/oder SUSI
- war mir damals nicht sicher ob MM nicht bald stirbt, außerdem damals bei MM 80 Adressen, 14 Fahrstufen
- es gibt auf Internetbörsen viele schöne (nicht so Detailierte, dafür Robuste) Altloks, wenn Analog schon rausfliegt, dann natürlich auch in von Göppingen gefertigte Produkte DCC-Komponenten rein

Ich will jetzt sicher nicht sagen, das ein System besser als das Andere ist, aber für mich war die Entscheidung nach gründlicher Recherche einfach

Gruß
Alf

Nebenbei: Roco-AC-Modelle sind heute mit Plux-Schnittstelle ausgerüstet

Hallo Alf,

Mittlerweile gibt es auch mfx Dekoder mit Plux Schnittstelle. ESU hat den Anfang gemacht, Zimo und Uhlenbrock folgen.

Bei den Umbauten bevorzuge ich mittlerweile auch die Plux Schnittstelle wegen der Anzahl Funktionen.. Es gibt aber auch mtc21 Dekoder, die schon AUX1 bis AUX6 auf der Schnittstelle ausgeben.

Gruss

Stephan

Hallo,

Jetzt sehe ich mich leider gezwungen, aufgrund der persönlichen Anfeindung, hier doch nochmal entwas zu schreiben.

@Carsten
Ich finde es nicht nett, dass du mich hier auf persönlicher Ebene derart angreifst, ja fast schon beleidigst.

Ich mag vielleicht nicht studiert haben, aber die Probleme die ich angesprochen habe sind nicht meiner Phantasie entsprungen, sonder wurden auch schon zahlreich von anderen Mobahnern beanstandet.

Ich weiß nicht was das soll, dass du mich so schwach "anreden" musst. Du willst mich wohl einfach nur als Idioten hinstellen?

Zitat

---

Was für Schaltströme denn bitte?! Mit Railcom wird nichts geschaltet

---

Ich weiß, dass bei Railcom vom Dekoder Ströme geschaltet werden. Wie meldet er denn deiner Meinung nach zurück?
Ich weiß auch, dass man dafür eine Lücke im DCC-Signal braucht, die sowohl bei Dekodern als auch bei Boostern und Zentralen wegen des möglichen Stroms beim Wiedereinschalten zu Problemen führen kann.
Ich weiß auch, dass bei DCC auf Schiene A z.B. 15V liegen und auf B 0 und im nächsten Moment auf B -15V und auf A 0, unzwar als Rechtecksignal. Bei abschnittsweiser Trennung wegen Booster oder anderer Modulen, kann es bei etwas asynchronem DCC Signal dazu kommen, dass eine Lok oder Wagen beim Überfahren mit einem Rad noch 15V mit dem anderen aber schon 0V einer Schienenseite erfährt. Da gibt es also einen Kurzschluss an 15V und es kann so viel Strom fließen, wie er nur durch den Rad-Schleifer-Widerstand begrenzt ist. Die Zentrale oder Booster sieht diesen Strom ja nicht also kann auch keine Strombegrenzung greifen.

So, und diese Problematik ist alleine schon durch die Übertragungstechnik gegeben. Also nix von wegen, wo es +- Spannungen gibt ist immer eine Kurzschlussgefahr. Hier ist die Gefahr alleine schon aufgrund des Protokolls gegeben!
Ich lass mich doch nicht für blöd verkaufen.

Zitat

---

Wo nimmst du denn immer wieder diesen Käse her? Ein typischer Decoder hat nicht sonderlich viel Kapazität an Bord.

---

Zitat von hier:

Zitat

---

Inrush-Problematik am Ende der Cutout
Es gibt (abhängig vom Dekoder) nach der Cutout fallweise einen sehr kurzen und sehr hohen Einschaltstrom. Beobachtet wurden von mir bereits Stromspitzen über 12A (bei H0 oder N-Dekoder!)

---

Vielleicht solltest du dir erst einmal ein paar Gedanken machen und (was hast du bei mir gleich wieder bemängelt? -Ach ja) etwas auch zu Ende Denken, bevor du mich als Ahnungslosen hinstellen willst.

Zitat

---

Ah, du meinst, wir legen einfach noch eine Schiene zwischen die beiden vorhandenen Pickelbahn für alle sozusagen? Danke, aber nein danke.

Die Alternative wäre Funk. Das aber braucht Platz und ist störanfällig.

---

Und ich soll keine Ahnung von technik haben. Ich habe nie von Mittelleiter gesprochen. Du legst ja auch nicht für jeden Fernsehsender (bei Kabelanschluss) ein eigenes Kabel, oder? Kannst aber trotzdem über ein Kabel X-Sender mit unterschiedlichen Daten empfangen. Wie geht das nur??? Aber klar ich bin hier der Ahnungslose.

Zitat

---

Nein, darüber gibts eigentlich nichts zu streiten. Wenn wir damit anfangen alles dezentral zu machen, landen wir ganz schnell wieder bei so unüberschaubaren Konstruktionen wie zu Analogzeiten. Zudem muss jedes Teil einzeln konfiguriert werden, die Komplexität stiege enorm.

---

So, interessant, - jedes Teil muss einzeln konfiguriert werden und das stört dich. Wie machst du das bei deinen Fahrzeugdekodern und den Weichen, Signal oder Servo-Dekodern?
Wieder totaler Blödsinn den du hier verzapfst. Selbst ein Rückmeldemodul-Gleisbesetztmodul muss bei einigen Anbietern eingestellt werden.

Zitat

---

Sicher könnte man jedesmal ein komplett neues Protokoll entwickeln, was solchen Dingen direkt Rechnung trägt und das perfekt integriert. Die Konsequenz wäre, dass man sich alle paar Jahre komplett neu ausrüsten müsste - Zentrale, Lokdecoder und wahrscheinlich auch die sonstige Peripherie.

---

Erstens habe ich nie gesagt, dass man alle paar Jahre ein komplett neues Protokoll entwickeln muss oder sollte. Ich habe gesagt, dass der Schnitt der sich durch die Rückmeldung ergeben hat man hätte nutzen können, um die bestehende Übertragungstechnik zu überdenken und vergangene Fehler und Fehleinschätzungen zu korrigieren. Zweitens hätte man dann die Möglichkeit gehabt es auch gleich so zukunftssicher zu gestalten, dass man es in Zunkunft leicht und ohne Kompatibilitätsprobleme erweitern kann. Das war meine Aussage, also dreh mir nicht das Wort im Mund um. Der jetzige Zustand ist es, der bei Neuerungen deutliche Kompatibilitätsprobleme aufweist!

Zitat

---

Tut mir leid, das ist schlicht und ergreifend Unfug. Dieses Problem tritt nur auf, wenn du a) inkompatible Booster verwendest oder b) eine zweite Zentrale ans Gleis hängst. Man hätte das vielleicht vermeiden können, indem man auf Gleichspannung am Gleis gesetzt hätte, aber ich vermute, dass es mit Wechselspannung einfacher umsetzbar war, das Signal an beide Schienen anzulegen und außerdem digitale Loks sonst nicht auf analogen Anlagen hätten fahren können.

---

Mir tut es auch leid, dass du so einen Schmarn behauptest. Du vermutest, dass es besser umsetzbar war. -> also reine Spekulation
Wieso sollten Digitalloks so auf analogen Anlagen nicht laufen können? So ein Unfug. Sie könnten dann nicht mit digitalen Funktionen laufen, wie z.B. Licht, dass auch im Stand bei Trafo-Nullstellung leuchtet, aber ganz normal fahren, wie man das von analogen Loks gewohnt ist, ist überhaupt kein Problem. Woher nimmst du nur immer diesen Käse?

Zitat

---

Eine Entwicklung über mehrere Firmen hinweg muss koordiniert werden. Das war schon in der Railcom-Gruppe ein extrem heißes Eisen, der Zwist zwischen Zimo und ESU ist mir noch sehr deutlich vor Augen. Ich will nicht wissen, wie das gelaufen wäre, wenn es um ein komplett neues Digitalprotokoll gegangen wäre. Nicht zuletzt müssten die Hersteller aber auch zwei komplett unterschiedliche Produktlinien fahren, wahrscheinlich auf Jahrzehnte hinaus. Im kleinen MoBa-Markt eine Utopie. Was du vorschlägst, ist schlicht und einfach nicht zuende gedacht.

---

Soso, wie viele Firmen waren denn an der Entwicklung von DCC beteiligt? Und selbst wenn hier mehr als eine Firma hätte tätig werden müssen, ist es für mich kein richtiges Argument zu sagen: Tut mir leid wir würden uns ja gerne weiterentwickeln aber der Hersteller xy macht nicht mit und darum lassen wir alles so wie es schon ist.
Aber gut es hört sich von dir ja schon fast wie ein Eingeständnis an, dass man eigentlich schon lange Neuerungen gebraucht und gemacht hätte, diese Vorhaben nur immer scheitern, weil man es nicht schafft sich zu einigen.

Ich wollte dir das eigentlich nur als PN schreiben, weil ich kein niveauloses, beleidigendes Wortgefecht in die Öffentlichkeit tragen will. Da es sich aber nur um eine Antwort auf deinen Post in gleichwertigem Tonfall handelt, kann ich es für mich noch vertreten. Und anscheinend wünschst du dir so einen Umgangston.

Gruß,
Marius

Hallo,

möchte etwas andere Richtung setzen, nämlich Betrieb Märklin Loks an der Uhlenbrock Intellibox II: Für mfx Loks habe ich gerade 5 Funktionen schaltbar unter der glrichen Adresse, lt. einem Forumsmitglied unter Dcc mehr, wenn man das mfx unter CV 50 abschalte (wozu ich testweise noch nicht gekommen bin), vielleicht haben andere schon da wertvolle Erfahrungen, da das mfu-Modul von Uhlenbrock seit 2 Jahren nur versprochen, aber njcht geliefert wird.

Schöne Grüsse

Länderbahnmartin

Hallo Länderbahnmartin,

stell deine Frage bitte in einem neuen Thread, die ist hier absolut nicht Thema.

Marius, nach welchen Kriterien entscheidest du eigentlich, ob eine Info auf einer Internetseite zuverlässig ist oder nicht?

Ruhig Blut Gemeinde

Bei allen frommen Wünschen ... letztendlich wird nur produziert, was sich auch verkaufen lässt. Das muss nicht immer das von allen geforderte "IDEAL" sein ... siehe Video2000 vs Betamax vs VHS oder der Beispiele mehr. Letztendlich hat es fast immer das System geschafft, welches auf Produktionslinie am einfachsten herstellbar ist und den höchsten Durchdringunggrad erreichen kann. Das ist auch nicht viel anders in der "MoBa-Welt". Der Markt schrumpft und ich ... wäre ich ein Hersteller ... würde einen Teufel tun noch ein System zu entwickeln. Ich muss die Millionen, die solch eine Forschung fressen, ja auch wieder reinholen können. Das sehe ich nicht ... jedenfalls nicht bei dem rasant wegsterbenden Humankapital (Kunden) bei gleichzeitigem spärlichen Neuzugängen in diesem Hobby.
Mag ja ketzerisch von mir klingen aber so ist die Realität und "hätte/würde/könnte" sind bestenfalls fromme Wünsche.

So ... nun lasst uns wieder vertragen !

Hallo Erich,

Titel des Threads heisst hier wie...? Da gehört meine Anmerkung dazu, dass es Konstellationen gibt, in denen es sinnvoll sein kann, eine Märklin mfx lok unter DCC zu steuern.

Ausserdem: Meine Einschränkung war keine Frage, sondern nur ein Hinweis, dass ich es selbst noch nicht ausprobiert habe.

L.

Zitat

---

Hallo Erich,

Titel des Threads heisst hier wie...?

---

Hallo Martin,

die Frage des Threads lautet:

Zitat

---

Kann jeder Mfx und Mfx+ Decoder grundsätzlich auch im DCC Format betrieben werden? Wenn ja, mit welchen Einschränkungen gegenüber Mfx und Mfx+?

---

Daraus ist die Frage entstanden, was der DCC Betrieb eines mfx Dekoders für Vorteile bietet und als Ergänzung dazu, was DCC allgemein im Betrieb für Vorteile gegenüber mfx bietet.

Es wurde nicht auf spezifische Zentralen (und ihren Einschränkungen) oder Erfahrungen damit eingegangen. Das mfx Protokoll kann nichts dafür, dass deine Zentrale mfx Dekoder nur mit MM Protokoll ansprechen kann und hier im Thread geht es nicht um das MM Protokoll

Gruss

Stephan

Hallo Stephan

Zitat

---

Mittlerweile gibt es auch mfx Dekoder mit Plux Schnittstelle. ESU hat den Anfang gemacht, Zimo und Uhlenbrock folgen.

---

Meine selbst erstellte Hausnorm, an der ich weiterhin festhalte, wird derzeit nicht geändert/ergänzt - werde sie, nachdem niedergeschrieben, mal ins Forum stellen

Zitat

---

Bei den Umbauten bevorzuge ich mittlerweile auch die Plux Schnittstelle wegen der Anzahl Funktionen.. Es gibt aber auch mtc21 Dekoder, die schon AUX1 bis AUX6 auf der Schnittstelle ausgeben.

---

Ich will aber prinzipiell auch AUX7 bis 9 und AUX10 haben

Gruß
Alf

Moin Marius
Deine vermeintlichen Vorteile möchte ich wie folgt kommentieren:

Zitat

---

1. Ich kann mit einer "guten" Rückmeldung bspw. auf eine stromführende Kupplung und PC verzichten, wenn ich Wagen-Züge mit Triebkopf voraus fahren, automatisch halten und steuern können will. Ich kann also meinen Zug mit flexibler länge erstellen, Triebkopf am Ende und er reagiert mit Triebkopf voraus genauso wie mit Lok voraus.

---

Dann verwendest du sehr wahrscheinlich das falsche Rückmeldeprinzip! Rückmeldung per Reedkontakt sind unabhängig von alledem!

Zitat

---

2. Weiß ich (respektive meine Zentrale und damit mein Handregler) immer in Echtzeit welche Lok sich auf der Anlage befindet und wo, und ich kann in Echtzeit verschiedene Betriebsinformationen (Geschwindigkeit, Funktionsstatus aller F., Signalqualität, und und und) erfahren

---

.
a) wie willst du denn die geografische Ortung machen wenn alleine durch einen guten Rückmeldebus alles viel einfacher werden soll?
b) Wozu braucht eine Zentrale ohne Intelligenz diese Informationen?

Zitat

---

3. Ich kann den Rest meiner Anlagenperipherie gezielt auf ganz bestimmte Loks (Adressen) und Züge reagieren lassen, ohne dass dafür ein PC von nöten wäre. => entlastung der Bus-Systeme, Verringerung der Informationsflut an Stellen, wo diese eigentlich nicht zwingend nötig wären.

---

Nun ich kenne C-digital nicht, aber irgendwo benötigst du für solche Funktionen im allgemeinen eine Intelligenz. Und ist es nur ein Umsetzer von "WENN DANN" Funktionen. Wenn das in den Lokdecoder verschoben werden soll, dann kann man Punkt 6 wohl vergessen?

Zitat

---

4. Pendelzug-Betrieb ist so ganz leicht möglich, egal wieviel Zwischenstops zwischen Start und Ziel liegen.

---

Das verstehe ich echt nicht wie das gehen soll, irgendwo benötigst du eine Intelligenz welche der Lok die Fahrtrichtung umdreht!

Zitat

---

5. es gibt keines der bei RailCom auftretenden Probleme, wie:
-Belastung der Dekoder durch Schaltströme von etwa 50 bis über 100mA, - problematisch v.a. bei dauerhafter Rückmeldung
-Austastlücke (Cut-out) von nöten => Pfeifen der Dekoder; Problem älterer Dekoder, wegen zeitweisem Verlust der Stromversorgung; sehr hohe Einschaltströme nach Cut-out; erhöhte Kurzschlussgefahr
-Probleme bei mehrfach, gleichzeitiger Rückmeldung, (bspw. beim Acknowledge)

---

Zu Railcom kann ich nichts sagen. Aber ich stelle mir vor das hierin auch der/die Gründe verborgen sein könnten dass Märklin mit mfx da noch nichts gebracht haben was mit Railcom vergleichbar ist.

Zitat

---

6. Viel viel einfacheres Handling bei der Programmierung und Konigurierung einer Lok bzw. eines Dekoders

---

. Da sehe ich keinen Zusammenhang mit dem Rückmeldebus!

Zitat

---

7. keine direkte Adressierung der Dekoder mehr von nöten. Ein mehr oder weniger beliebg langes Alias aus Buchstaben und/oder Zahlen reicht aus. => sehr schnelle, eindeutige Zuordnung

---

Genau das hast du doch bei mfx?

Zitat

---

8. Kein Problem mehr mit beleuchteten Wagen, die beim Überfahren von Abschnitten brücken können.

---

Da komme ich zurück auf die Geographische Ortung ?

Zitat

---

9. Eine Dekoder ist in der Lage in einem anderen eine Funktion oder was auch immer auszulösen, ohne PC und mords Software- und Hardware-Zeugs.

---

Und dabei soll das Konfigurieren der Lokdecoder einfacher werden?

Zitat

---

Die Liste liese sich noch um einiges erweitern, aber ich denke es ist etwas klarer geworden...?

---

Leider nein eher das Gegenteil ist der Fall. Bei den Meisten Punkten sehe ich nicht was das mit dem Rückmeldebus zu tun hat. Wobei ich unter Rückmeldebus ein reines System zur unidirektionalen Datenübertragung von A nach B verstehe. Aber irgendwo braucht es auch die Erfassung zum Beispiel der ISTgeschwindigkeit. und eine Auswertung und Aktioneenauslöser. Und das ist nach heutigen Stand der Technik meisten ein PC oder ähnliches Gerät mit entsprechender SW

Zitat

---

Soso, wie viele Firmen waren denn an der Entwicklung von DCC beteiligt? Und selbst wenn hier mehr als eine Firma hätte tätig werden müssen, ist es für mich kein richtiges Argument zu sagen: Tut mir leid wir würden uns ja gerne weiterentwickeln aber der Hersteller xy macht nicht mit und darum lassen wir alles so wie es schon ist.
Aber gut es hört sich von dir ja schon fast wie ein Eingeständnis an, dass man eigentlich schon lange Neuerungen gebraucht und gemacht hätte, diese Vorhaben nur immer scheitern, weil man es nicht schafft sich zu einigen.

---

Hier geht es nicht um die Entwicklung, die ist ja schon lange her, sondern um Standardisierung und das ist immer aufwendig und langwierig.
Damit etwas voran geht, wurde die Railcommunity gegründet: http://railcommunity.org/
Du nutzt ein System, wofür es nur einen Hersteller gibt. Da ist es sehr einfach Neuerungen umzusetzten.

Du kannst ja mal ausprobieren, Ordnung in ein gewachsenes System zu bringen und gleichzeigt konkurierende Hersteller unter einen Hut bringen. Wenn Du das schnell und ohne graue Haar schaffst, dann musst Du so entspannt sein wie Budda

Grüße
Stephan

Zitat

---

10 € pro Eingang bei Tams sind für mich nicht gerade günstig. Digikeys liegt schon mal besser bei 5.6€/Eingang. ESU hat Mondpreise. Bausätze lasse ich mal aussen vor.

Normale s88 Rückmelder gehen so ab 1.5 €/Eingang los.

Wie du siehst, kosten Railcom Rückmelder immer noch ein Vielfaches von normalen Rückmeldern. Das ist für mich teuer.

---

Vergleichst Du hier vielleicht einen Selbstbau-Rückmelder mit Massekontakt?

Der günstigst mir bekannte S88-Rückmelder ist der von Digikeijs und der kostet 40€, also 2,5€ pro Kanal.
Allerdings schaltet der nur den Massekontakt. Ein Railcom-Rückmelder muss schon mit einem GBM verglichen werden. Der kostet 50€, also 3,12€.
Die meisten anderen fertig aufgebauten Rückmelder liegen vom Preis her gar nicht so weit weg von Railcom-fähigen Rückmeldern, teilweise nicht mal darunter.

Grüße
Stephan

Zitat

---

Zitat

---

Was für Schaltströme denn bitte?! Mit Railcom wird nichts geschaltet

---

Ich weiß, dass bei Railcom vom Dekoder Ströme geschaltet werden. Wie meldet er denn deiner Meinung nach zurück?

---

Der Decoder sendet mit 30mA, also nichts dramatisches und sicher nichts, was den Decoder irgendwie belastet.
Vielleicht liest Du Dir mal die Spezifikation durch:
http://normen.railcommunity.de/RCN-217.pdf
Ein paar Aussagen von Dir kommen mir schon ein bisschen komisch vor.

Zitat

---

Zitat

---

Wo nimmst du denn immer wieder diesen Käse her? Ein typischer Decoder hat nicht sonderlich viel Kapazität an Bord.

---

Zitat von hier:

Zitat

---

Inrush-Problematik am Ende der Cutout
Es gibt (abhängig vom Dekoder) nach der Cutout fallweise einen sehr kurzen und sehr hohen Einschaltstrom. Beobachtet wurden von mir bereits Stromspitzen über 12A (bei H0 oder N-Dekoder!)

---

Vielleicht solltest du dir erst einmal ein paar Gedanken machen und (was hast du bei mir gleich wieder bemängelt? -Ach ja) etwas auch zu Ende Denken, bevor du mich als Ahnungslosen hinstellen willst.

---

Das ist ein klarer Schaltungs-Design-Fehler des Decoders.

Grüße
Stephan

Zitat

---

Zitat

---

Zitat

---

- Rücksenden unabhängig von der "Hin-Sendung"

---

Geht bei Railcom

---

Das höre ich zum ersten Mal. Wie sieht das dann aus? Was melden die Dekoder dann zurück und vor allem woher bekommen sie die Energie fürs Rückmelden, wenn die Hinsendung (respektive das DCC-Signal) entfällt?

---

Ist natürlich eine Defintionsfrage was man damit meint. Einfach irgendwann lossenden macht der Decoder natürlich nicht, allerdings in keinem System. Das darf er nur, wenn er angesprochen wurde. Da aber DCC-Decoder zyklisch angesprochen werden, können sie natürlich dann was senden.
Ich habe das so verstanden, dass der Decoder was senden kann, obwohl er nicht nach etwas gefragt wurde. Z.B. kann der Decoder seine aktuelle Geschwindigkeit oder die Gleisverschmutzung selbstständig senden, wenn er dran ist. Da DCC immer vorhanden ist, kann er natürlich im Cutout senden.

Zitat

---

Gerade als das Thema Rückmeldung aufkam, wäre ein günstiger Zeitpunkt gewesen, sich das ganze Konzept der Datenübertragung noch einmal zu überlegen und ggf. komplett zu ändern. Für den Kunden bedeutet/e die Entscheidung "mit Rückmeldung" sowieso eine komplette Hardwareerneuerung. Zentrale + Booster müssen das können, entsprechende Rückmeldemodule müssen her, sowie Dekoder die dieses können.

---

Ich denke, da war es wegen Kompatibilitätsgründen schon zu spät.

Grüße
Stephan

Kurz gesagt: Interaktion zwischen Fahrzeugführern a la fahr du mal erst und ich fahr dann gibt es auf der Straße, nicht aber auf der Schiene. Da wird gerade im Gegenteil zentral überwacht und wer einen Fahrbefehl bekommt, fährt auch.
Und wir wollen doch ein Modell der großen Bahn haben?

Auch bei C-Digital interagieren die Lokdecoder nicht. (Das tun nur manche Piko-Loks mit esu-Decoder, und es ist pfui.)
Da werden lediglich andere Prinzipien bzgl. Bremszonen etc verwendet - aber auch in DCC oder mfx kann man Bremsbausteine verbauen. Wenn man denn unbedingt digital als besseres analog mit Hardwarecodierung haben will.

Zu den Rückmeldebussen ist viel geschrieben worden; es muss nicht immer das Teuerste eingesetzt werden, nur weil es technisch möglich ist - und ich sehe für mich (! Andere haben andere Bedürfnisse!) und meine kleine Anlage weder Bedarf an Rückmeldern, die das Fahrzeug identifizieren, noch an was höher entwickeltem als s88.

Hallo Stephan

Zitat

---

Vergleichst Du hier vielleicht einen Selbstbau-Rückmelder mit Massekontakt?

---

du hast Recht. Auf der Übersicht der HP von Tams war nichts von Bausatz vermerkt. In der Detailansicht aber schon. ok, dann sind es 2,18 Euro/Eingang für den fertigen Tams Baustein.

Zitat

---

Der günstigst mir bekannte S88-Rückmelder ist der von Digikeijs und der kostet 40€, also 2,5€ pro Kanal.
Allerdings schaltet der nur den Massekontakt. Ein Railcom-Rückmelder muss schon mit einem GBM verglichen werden. Der kostet 50€, also 3,12€.

---

Auf der Digikeijs HP konnte ich den einzigen Railcom-fähigen Melder DR5088RC mit 89,95 Euro ausfindig machen. Das sind nach meiner Rechnung immer noch 5.6 Euro/Eingang.

Als 3-Leiter Fahrer ist für mich der Massekontakt immer noch die günstigste Variante. Das ist nun mal Fakt. Will ich Railcom haben, wird es teuer. Auf meiner Anlage habe ich 176 Kontakte. Eine schnelle Überschlagsrechnung ergibt:

176 x 2.18 Euro = 383.68 Euro
176 x 5.6 Euro = 985.6 Euro

Der Unterschied beträgt über 600 Euro. Für den Preis kann ich mir eine Vollversion von Traincontroller (499€ oder Windigipet (449 Euro) leisten. Den ausrangierten PC habe ich zum Nulltarif. Damit kann ich meine Züge am Bildschirm bestens verfolgen und habe dazu noch fast unendliche Möglichkeiten, ausgefeilte Steueraufgaben auf der Anlage zu lösen.

Deswegen gibt es für mich keinen ersichtlichen Grund, in Railcom investieren zu müssen.

Gruss

Stephan

Hallo Marius,
ich hab bei deinen Texten den Eindruck, du versuchst auf Krampf alles madig zu reden. Das geht so in die Richtung "alles Idioten, weil sie es nicht so machen wie ich mir das vorstelle". Du wirst entschuldigen, dass ich meinen Ton daran angepasst habe.

Zitat

---

Ich weiß, dass bei Railcom vom Dekoder Ströme geschaltet werden. Wie meldet er denn deiner Meinung nach zurück?

---

Ach, das meinst du mit Schalten. Das sind Ströme im mA-Bereich, ich glaub 30 mA waren es, wenn ich mich recht erinnere. Das willst du hoffentlich nicht als gefährlich für den Decoder deklarieren? Bedenke, dass dieser Strom aus den decodereigenen Kondensatoren kommt und da nicht übermäßig viel Kapazität drauf ist - da passiert nichts, versprochen.

Zitat

---

Ich weiß auch, dass man dafür eine Lücke im DCC-Signal braucht, die sowohl bei Dekodern als auch bei Boostern und Zentralen wegen des möglichen Stroms beim Wiedereinschalten zu Problemen führen kann.

---

Welche sollten das sein? Das einzige mir bekannte Problem, das tatsächlich auftritt, sind Probleme einiger Decoder mit dem Cutout, weil die zu wenig Puffer an Bord haben. Das betrifft in aller Regel Uraltkonstruktionen und kann mit etwas "angeflanschtem" Zusatzpuffer behoben werden.

Zitat

---

Bei abschnittsweiser Trennung wegen Booster oder anderer Modulen, kann es bei etwas asynchronem DCC Signal dazu kommen, dass eine Lok oder Wagen beim Überfahren mit einem Rad noch 15V mit dem anderen aber schon 0V einer Schienenseite erfährt.

---

Das streitet auch keiner ab und ja, man hätte durchaus andere Lösungen finden können. Die hätten aber wieder ihre eigenen Nachteile gehabt. Wenn du hier von einer "schlechten Lösung" schreibst, nur weil du diese Entscheidung und den Gedanken dahinter nicht nachvollziehen kannst, lehnst du dich seeeehr weit aus dem Fenster.

Zitat

---

Hier ist die Gefahr alleine schon aufgrund des Protokolls gegeben!

---

Und das ist falsch. Die Gefahr entsteht lediglich bei unsachgemäßem Aufbau. Verwende die richtigen Booster und schließe sie korrekt an - fertig. Wenn du eine Wasserleitung baust und alle halbe Meter das System wechselst, brauchst du dich über undichte Stellen nicht beklagen.

Zitat

---

Vielleicht solltest du dir erst einmal ein paar Gedanken machen und (was hast du bei mir gleich wieder bemängelt? -Ach ja) etwas auch zu Ende Denken, bevor du mich als Ahnungslosen hinstellen willst.

---

Da fehlen so einige Infos, z.B. verwendete Hardware, Anzahl der Decoder am Gleis etc. Der Text deutet aber darauf hin, dass es um fehlerhaft konstruierte Decoder geht. Das ist nun wirklich kein Fehler von Railcom.

Zitat

---

Und ich soll keine Ahnung von technik haben. Ich habe nie von Mittelleiter gesprochen. Du legst ja auch nicht für jeden Fernsehsender (bei Kabelanschluss) ein eigenes Kabel, oder? Kannst aber trotzdem über ein Kabel X-Sender mit unterschiedlichen Daten empfangen. Wie geht das nur??? Aber klar ich bin hier der Ahnungslose.

---

Dir ist schon klar, dass über das Fernsehkabel die Sender nur in eine Richtung kommen? Du wolltest aber gleichzeitig senden und empfangen können, dazu brauchst du für jede Richtung eine Leitung + GND. Ergo 3 Schienen. Ja, sicher könnte man auch Lösungen finden, wie man das über nur 2 Leitungen hinbekommt, aber ob das unter den bei der MoBa gegebenen Verhältnissen (ungeschirmte Schienen, begrenzte Frequenzen etc.) funktioniert kann ich nicht sagen. Da bin ich auch nicht Techniker genug.

Zitat

---

So, interessant, - jedes Teil muss einzeln konfiguriert werden und das stört dich.

---

Das hab ich nicht gesagt, ich sagte nur, dass diese Art des Aufbaus eine große Komplexität mit sich bringt. Und zu welchem Zweck? Um einen Rechner an der Anlage zu vermeiden? Die zusätzlichen Kosten für die intelligenten Bausteine dürften selbst bei mittelgroßen Anlagen weit höher liegen als ein einfacher PC oder gar ein Raspberry Pi. Und wenn es nur um das Prinzip geht, keinen Rechner an der Anlage haben zu wollen: Was meinst du, was solche Bausteine wären? Nichts anderes als kleine Computer.

Zitat

---

Wie machst du das bei deinen Fahrzeugdekodern und den Weichen, Signal oder Servo-Dekodern?
Wieder totaler Blödsinn den du hier verzapfst. Selbst ein Rückmeldemodul-Gleisbesetztmodul muss bei einigen Anbietern eingestellt werden.

---

Denen muss ich aber keine Abhängigkeiten und ähnliches beibringen. Du vergleichst hier grade sehr grüne Äpfel mit ziemlich saftigen Pflaumen.

Zitat

---

Ich habe gesagt, dass der Schnitt der sich durch die Rückmeldung ergeben hat man hätte nutzen können, um die bestehende Übertragungstechnik zu überdenken und vergangene Fehler und Fehleinschätzungen zu korrigieren.

---

Und ich sage gern nochmal: Nur weil DU etwas für einen Fehler oder eine Fehleinschätzung hälst, muss es noch lange keine sein.

Zitat

---

Der jetzige Zustand ist es, der bei Neuerungen deutliche Kompatibilitätsprobleme aufweist!

---

Ich sehe dein Problem nicht. Ich selber habe den Cutout am Gleis, obwohl ich Railcom nicht nutze. Probleme bisher? 0. Selbst in meinem Bekannten- oder gar Kundenkreis ist das Thema bisher vielleicht 2 oder 3 Mal aufgetaucht, weil da uralte Decoder am Werk waren. Die Dinger wurden ersetzt und fertig, seitdem freuen sich die Kollegen sogar noch über die besseren Fahreigenschaften. Alternativ wurde Railcom abgeschaltet und das Problem war ebenso behoben. Also wo genau sind nun deine "deutlichen" Kompatibilitätsprobleme?

Zitat

---

Sie könnten dann nicht mit digitalen Funktionen laufen, wie z.B. Licht, dass auch im Stand bei Trafo-Nullstellung leuchtet, aber ganz normal fahren, wie man das von analogen Loks gewohnt ist, ist überhaupt kein Problem. Woher nimmst du nur immer diesen Käse?

---

Analogerkennung ist bereits jetzt kein einfaches Thema. Mit reiner Gleichspannung funktionierts meist gut, aber z.B. bei PWM-Fahrpulten, Halbwelle und was es noch alles gibt, gibt es je nach Decoderhersteller teils massive Probleme bis hin zur völligen Funktionsverweigerung. Meinst du, das wäre einfacher erkennbar, wenn man bei Digital eine Gleichspannung statt einer Wechselspannung verwendet hätte?

Zitat

---

Soso, wie viele Firmen waren denn an der Entwicklung von DCC beteiligt? Und selbst wenn hier mehr als eine Firma hätte tätig werden müssen, ist es für mich kein richtiges Argument zu sagen: Tut mir leid wir würden uns ja gerne weiterentwickeln aber der Hersteller xy macht nicht mit und darum lassen wir alles so wie es schon ist.

---

DCC wurde anfangs von einer Firma allein entwickelt. Das ist aber nicht mehr vergleichbar zu heute, denn das war zu einer Zeit, als praktisch jeder Hersteller seine eigene Hausnorm gebastelt hat. Heute ist DCC DER Digitalstandard außerhalb der Märklinwelt. Willst du den ablösen, musst du die verschiedenen Hersteller ins Boot holen UND unter einen Hut bringen. Die lange, lange, lange Entwicklungsgeschichte von Railcom sollte dir ausreichend deutlich zeigen, wie schwierig das ist. Und selbst da versuchen Lenz und ESU noch, die anderen mit proprietären Erweiterungen zu übervorteilen (Stichwort: Railcom+).

Selbstverständlich kannst du auch im Alleingang das beste System aller Zeiten entwickeln. Es nützt nur keinem was, wenn die anderen dann nicht aufspringen und alles irgendwann versickert. Beispiele dafür gibts genug, Märklin mit mfx fasst außerhalb der eigenen Welt keinen Fuß, Selectrix 2 fristet eine winzige Nische, C-Digital kennt praktisch keiner usw. usf.

Zitat

---

Aber gut es hört sich von dir ja schon fast wie ein Eingeständnis an, dass man eigentlich schon lange Neuerungen gebraucht und gemacht hätte, diese Vorhaben nur immer scheitern, weil man es nicht schafft sich zu einigen.

---

Das ist nun wirklich kein Geheimnis. Railcom z.B. hätte viel früher kommen können und müssen. Auch die Endgeräte sollten Railcom endlich mal unterstützen, dabei gehts mir z.B. um solche Sachen wie das Auslesen und Schreiben von CVs. Das Drama mit den Ack-Impulsen ist ja nun wirklich von vorvorvorgestern. Neben dem Problem mit der Einigung der Hersteller gibts aber noch andere Gründe, nämlich die Entwicklungskosten (Modellbahn ist einfach kein übermäßig lukratives Geschäft) und auch die Trägheit der Nutzerbasis. Letzteres ist jetzt nicht negativ gemeint, aber mir fällt kein besserer Begriff für den Umstand ein, dass die Nutzer nicht sofort jede Neuerung adaptieren und ihre bisherige Technik ersetzen. Modellbahn ist eben ein langfristiges Hobby.

So richtig verstehe ich aber nicht, was du hier eigentlich bezweckst. Du nutzt gar kein DCC, machst aber ein Riesenfass auf und beschreibst Probleme, die 99,9% der Anwender überhaupt nicht kennen oder die nichtmal existieren. Was soll das? Willst du dich einfach besser fühlen, weil du das vermeintlich bessere System gewählt hast? Nur zu, nutze es und sei glücklich. Niemand nimmts dir weg

Viele Grüße
Carsten

Hallo,

Da mir jetzt nochmal so viele Fragen gestellt worden sind, versuche ich noch dazu Stellung zu beziehen.
Es scheint, als wüsste ich doch einfach viel zu wenig von DCC oder mfx, sodass sich bei mir ein falsches Bild ergeben hat.
Dann möchte ich noch klarstellen, dass es mir nicht um einen Vergleich zwischen dem von mir genutzten C-Digitalsystem (größtenteils in einer Prototypenversion) und DCC oder mfx ging und geht. Ich wollte doch nur über die Probleme mit der Übertragungstechnik bei diesen Systemen reden, die nach meinem bisherigen Verständnis die Ursache für Probleme darstellt, wie sie hier und anderen Ortes schon genannt wurden.
Natürlich betrachte ich DCC und mfx von außen und mit dem gedanklichen Hintergrund der sich durch mein System ergibt, - trotzdem sollte das hier nicht Thema sein.

Zitat

---

Der Decoder sendet mit 30mA, also nichts dramatisches und sicher nichts, was den Decoder irgendwie belastet.
Vielleicht liest Du Dir mal die Spezifikation durch:
http://normen.railcommunity.de/RCN-217.pdf
Ein paar Aussagen von Dir kommen mir schon ein bisschen komisch vor.

---

Ich habe wohl bei der Stromhöhe für die Rückmeldung DCC und mfx verwechselt? Ein Märklin-Kollege hat mir gesagt, dass beim Rückmelden bis zu 120 oder 130mA : fließen, also 4 mal so viel bei mfx.

Zitat

---

Zitat

---

Zitat von hier:

Zitat

---

Inrush-Problematik am Ende der Cutout
Es gibt (abhängig vom Dekoder) nach der Cutout fallweise einen sehr kurzen und sehr hohen Einschaltstrom. Beobachtet wurden von mir bereits Stromspitzen über 12A (bei H0 oder N-Dekoder!)

---

---

Das ist ein klarer Schaltungs-Design-Fehler des Decoders.

---

Alles klar. Wusste ich nicht. Dann entstehen die Probleme durch Design-Fehler, ok. Warum kommen die Hersteller damit durch?
Trotzdem gilt, dass eine andere physikalische Übertragungsform dieses Problem erst garnicht aufkommen liese.

Zitat

---

Hier geht es nicht um die Entwicklung, die ist ja schon lange her, sondern um Standardisierung und das ist immer aufwendig und langwierig.
Damit etwas voran geht, wurde die Railcommunity gegründet: http://railcommunity.org/
Du nutzt ein System, wofür es nur einen Hersteller gibt. Da ist es sehr einfach Neuerungen umzusetzten.

Du kannst ja mal ausprobieren, Ordnung in ein gewachsenes System zu bringen und gleichzeigt konkurierende Hersteller unter einen Hut bringen. Wenn Du das schnell und ohne graue Haar schaffst, dann musst Du so entspannt sein wie Budda

---

Ok. Ist es nicht so, dass wenn eine Sache funktionsmäßig praktikabel ist, sich einfach und güstig umsetzten lässt, es automatisch zum Standard wird? - naja, trotzdem müsste man sich dann noch über die genaue Struktur einig werden, - wie z.b. einzelne Byte-Informationen strukturiert sein sollen usw.
Also seis drum...

Zitat

---

Deine vermeintlichen Vorteile möchte ich wie folgt kommentieren:

Zitat

---

1. Ich kann mit einer "guten" Rückmeldung bspw. auf eine stromführende Kupplung und PC verzichten, wenn ich Wagen-Züge mit Triebkopf voraus fahren, automatisch halten und steuern können will. Ich kann also meinen Zug mit flexibler länge erstellen, Triebkopf am Ende und er reagiert mit Triebkopf voraus genauso wie mit Lok voraus.

---

Dann verwendest du sehr wahrscheinlich das falsche Rückmeldeprinzip! Rückmeldung per Reedkontakt sind unabhängig von alledem!

---

Ja, das habe ich so früher gemacht, als ich noch analog fuhr. Das ist natürlich immer eine Option, gerade auch weil es den Vorteil der Unabhängigkeit hat.
Es ist halt nur eine punktuelle Rückmeldung möglich. Für das Fahren mit Triebkopf voraus, kann es eine Lösung sein. Mich hat später einfach der Reedkontakt im Gleisbett und die eingeschränkte Flexibilität gestört und noch ein paar andere Dinge.
Jetzt brauche ich soetwas praktisch garnicht mehr.

Zitat

---

Zitat

---

2. Weiß ich (respektive meine Zentrale und damit mein Handregler) immer in Echtzeit welche Lok sich auf der Anlage befindet und wo, und ich kann in Echtzeit verschiedene Betriebsinformationen (Geschwindigkeit, Funktionsstatus aller F., Signalqualität, und und und) erfahren

---

.
a) wie willst du denn die geografische Ortung machen wenn alleine durch einen guten Rückmeldebus alles viel einfacher werden soll?
b) Wozu braucht eine Zentrale ohne Intelligenz diese Informationen?

---

zu a) Naja, das habe ich hier jetzt nicht weiter ausgebaut. Alleine durch den Bus wird zunächst natürlich nichts einfacher. Der beste PC mit Software nützt aber auch nichts, wenn von der Anlage keine entsprechend "guten" Daten kommen. Man ist doch auch auf einen guten Bus angwiesen..?
Ist es nicht so, dass die Grundlage für eine echte geografische Ortung ein rückmeldefähiger Dekoder und die entsprechenden Module sind? Ein Rückmeldesystem, dass obiges beherrscht, kann eine gute geografische Ortung überhaupt erst möglich machen, oder nicht? Zusätzlich bekomme ich noch in "Echtzeit" verschiedene andere Informationen des Dekoders.
zu b) 1.Wieso darf die Zentrale keine Intelligenz haben? 2. Sie braucht sie um bspw. bestimmte Informationen an den Handregler weiter zu geben. Sofern man möchte, kann man Informationen natürlich auch an ein BSW oder ein Tablett, Handy oder PC weiter geben, woraus sich weitere Möglichkeiten ergeben. Irgendwie glaube ich, ich verstehe deine Frage hier nicht richtig?

Zitat

---

Zitat

---

3. Ich kann den Rest meiner Anlagenperipherie gezielt auf ganz bestimmte Loks (Adressen) und Züge reagieren lassen, ohne dass dafür ein PC von nöten wäre. => entlastung der Bus-Systeme, Verringerung der Informationsflut an Stellen, wo diese eigentlich nicht zwingend nötig wären.

---

Nun ich kenne C-digital nicht, aber irgendwo benötigst du für solche Funktionen im allgemeinen eine Intelligenz. Und ist es nur ein Umsetzer von "WENN DANN" Funktionen. Wenn das in den Lokdecoder verschoben werden soll, dann kann man Punkt 6 wohl vergessen?

---

Siehe oben, mir ging es hier nicht um den Vergleich DCC mit C-Digital oder so. Mein Thema war einzig und alleine die Problematiken, die, so von mir angenommen, durch die Übertragungstechnik der Digitalsysteme kommen und die Frage, warum man immer noch daran festhält.
Und natürlich was sich für Möglichkeiten durch ein (in meinen Augen) gutes Rückmeldesystem ergeben können. Dass einige Punkte sich mit C-Digital decken sollte garkeine Rolle spielen.
Wenn dich wirklich interessiert, was alles oder was nicht und v.a. wie bei C-Digital geht, kannst du das am besten in einem anderen Thread fragen.
Das ich selbst mit C-Digital fahre, sollte nicht Thema sein, - aber klar beeinflusste es auch etwas mein Denken.
Noch eine kleine Antwort zu der Frage, ob das in den Dekoder verschoben werden soll: Klar, nein. Ist bei C-Digital übrigens auch nicht der Fall.

Zitat

---

Zitat

---

4. Pendelzug-Betrieb ist so ganz leicht möglich, egal wieviel Zwischenstops zwischen Start und Ziel liegen.

---

Das verstehe ich echt nicht wie das gehen soll, irgendwo benötigst du eine Intelligenz welche der Lok die Fahrtrichtung umdreht!

---

Ja, klar. Das könnte z.B. der Dekoder machen. Das ist nichts anderes als eine Softwarefunktion wie Sound ein/aus, oder bremsen usw..

Zitat

---

Zitat

---

5. es gibt keines der bei RailCom auftretenden Probleme, wie:
-Belastung der Dekoder durch Schaltströme von etwa 50 bis über 100mA, - problematisch v.a. bei dauerhafter Rückmeldung
-Austastlücke (Cut-out) von nöten => Pfeifen der Dekoder; Problem älterer Dekoder, wegen zeitweisem Verlust der Stromversorgung; sehr hohe Einschaltströme nach Cut-out; erhöhte Kurzschlussgefahr
-Probleme bei mehrfach, gleichzeitiger Rückmeldung, (bspw. beim Acknowledge)

---

Zu Railcom kann ich nichts sagen. Aber ich stelle mir vor das hierin auch der/die Gründe verborgen sein könnten dass Märklin mit mfx da noch nichts gebracht haben was mit Railcom vergleichbar ist.

---

Da bin ich überfragt, zumal es scheint, als würde ich allgemein viel zu wenig darüber wissen...
Mit der Stromhöhe von über 100mA habe ich mich ja anscheinend eh getäuscht. Das ist wohl nur bei mfx so?

Zitat

---

Zitat

---

6. Viel viel einfacheres Handling bei der Programmierung und Konigurierung einer Lok bzw. eines Dekoders

---

. Da sehe ich keinen Zusammenhang mit dem Rückmeldebus!

---

Na bei einem guten Rückmeldebus, können Programmierungen sofort bestätigt und am Handregler angezeigt werden - beim Programmieren überall auf der Anlage. So hatte ich das gemeint. Ich halte das schon für vorteilhaft. Wenn man nicht im Betrieb rückmelden kann, kann man doch nur auf einem Programiergleis programmieren und auslesen=verifizieren.

Zitat

---

Zitat

---

7. keine direkte Adressierung der Dekoder mehr von nöten. Ein mehr oder weniger beliebg langes Alias aus Buchstaben und/oder Zahlen reicht aus. => sehr schnelle, eindeutige Zuordnung

---

Genau das hast du doch bei mfx?

---

Ja. Ich wollte auch nie mit meinen Aussagen feststellen, dass all das bei DCC oder mfx nicht möglich ist. Es ging mir darum zu zeigen, zu was ein gutes Rückmeldesystem alles befähigen kann.

Zitat

---

Zitat

---

8. Kein Problem mehr mit beleuchteten Wagen, die beim Überfahren von Abschnitten brücken können.

---

Da komme ich zurück auf die Geographische Ortung ?

---

Das verstehe ich leider nicht. Es gibt Rückmeldesysteme, da soll es vorkommen, dass gerade beleuchtete Wagen Probleme bereiten können. Auch gibt es Probleme des Überbrückens z.B. bei ABC Bremsstrecken, oder? -weil die Asymmetrie beim Brücken verschwindet...

Zitat

---

Zitat

---

9. Eine Dekoder ist in der Lage in einem anderen eine Funktion oder was auch immer auszulösen, ohne PC und mords Software- und Hardware-Zeugs.

---

Und dabei soll das Konfigurieren der Lokdecoder einfacher werden?

---

Ja, eigentlich schon, aber vielleicht auch nicht wirklich? In diesem konkreten Fall ergäbe sich keine Verbesserung aber auch keine Verschlimmerung. Es bliebe also alles wie gehabt.

Zitat

---

Zitat

---

Die Liste liese sich noch um einiges erweitern, aber ich denke es ist etwas klarer geworden...?

---

Leider nein eher das Gegenteil ist der Fall. Bei den Meisten Punkten sehe ich nicht was das mit dem Rückmeldebus zu tun hat. Wobei ich unter Rückmeldebus ein reines System zur unidirektionalen Datenübertragung von A nach B verstehe. Aber irgendwo braucht es auch die Erfassung zum Beispiel der ISTgeschwindigkeit. und eine Auswertung und Aktioneenauslöser. Und das ist nach heutigen Stand der Technik meisten ein PC oder ähnliches Gerät mit entsprechender SW

---

Natürlich reicht ein Rückmeldesystem alleine nicht aus. Ebeso wie es der USB Bus ohne PC oder irgendwelche anderen Geräte täte. Wenn man aber doch fragt, was, wieviel und wie schnell übertragen werden soll, sucht man sich einen geeigneten BUS. Dieser muss dann von einer entsprechenden Hardware zur verfügung gestellt werden, ist doch klar oder?
Wenn ich mir also die Frage stelle, was ich gerne übertragen haben will und wie oft, dann kann ich doch näherungsweise Aussagen über den nötigen BUS treffen und feststellen, ob der ein oder andere dafür überhaupt geeigent ist, oder? Die umliegende Hardware ist wieder ein anderes Thema.

Zitat

---

Bei allen frommen Wünschen ... letztendlich wird nur produziert, was sich auch verkaufen lässt. Das muss nicht immer das von allen geforderte "IDEAL" sein ... siehe Video2000 vs Betamax vs VHS oder der Beispiele mehr. Letztendlich hat es fast immer das System geschafft, welches auf Produktionslinie am einfachsten herstellbar ist und den höchsten Durchdringunggrad erreichen kann. Das ist auch nicht viel anders in der "MoBa-Welt". Der Markt schrumpft und ich ... wäre ich ein Hersteller ... würde einen Teufel tun noch ein System zu entwickeln. Ich muss die Millionen, die solch eine Forschung fressen, ja auch wieder reinholen können. Das sehe ich nicht ... jedenfalls nicht bei dem rasant wegsterbenden Humankapital (Kunden) bei gleichzeitigem spärlichen Neuzugängen in diesem Hobby.
Mag ja ketzerisch von mir klingen aber so ist die Realität und "hätte/würde/könnte" sind bestenfalls fromme Wünsche.

So ... nun lasst uns wieder vertragen !

---

Das habe ich nicht beachtet. Kann sein, dass es grundsätzlich erst einmal gar keinen Sinn mehr macht noch einen größeren Umbruch anzuzetteln, vielleicht auch vor 10 Jahren schon nicht, wo sich einige Hersteller in der Kriese befanden.


[quote="Erich Müller" post_id=1818733 time=1522896411 user_id=26147]
Auch bei C-Digital interagieren die Lokdecoder nicht. (Das tun nur manche Piko-Loks mit esu-Decoder, und es ist pfui.)
Da werden lediglich andere Prinzipien bzgl. Bremszonen etc verwendet - aber auch in DCC oder mfx kann man Bremsbausteine verbauen. Wenn man denn unbedingt digital als besseres analog mit Hardwarecodierung haben will.
[/quote]Zum Thema C-Digital siehe oben. (C-Digital braucht keine Bremsbausteine oder eine Hardwarecodierung und das ganze System ist schon von der Grundstrucktur anders und desshalb physikalisch nicht vergleichbar. Man kann Funktionalität, Kosten, Verdrahtungsaufwand, Dekoder und all sowas vergleichen mehr aber nicht. Meine Meinung.)
Wie meinst du das mit Digital als besseres Analog mit Hardwarecodierung?

[quote="Erich Müller" post_id=1818733 time=1522896411 user_id=26147]
Kurz gesagt: Interaktion zwischen Fahrzeugführern a la fahr du mal erst und ich fahr dann gibt es auf der Straße, nicht aber auf der Schiene. Da wird gerade im Gegenteil zentral überwacht und wer einen Fahrbefehl bekommt, fährt auch.
Und wir wollen doch ein Modell der großen Bahn haben?
[/quote]Sehe ich ganz genauso, - mit Selbstabsicherung des eigenen Blocks. Allerdings möchte ich nicht in ALLEN Punkten ein Modell der großen Bahn .

Zitat

---

MariusS hat geschrieben: ↑
Di 3. Apr 2018, 22:55

stephan_bauer hat geschrieben: ↑
Di 3. Apr 2018, 21:24

MariusS hat geschrieben: ↑
So 1. Apr 2018, 22:52
- Rücksenden unabhängig von der "Hin-Sendung"

Geht bei Railcom

Das höre ich zum ersten Mal. Wie sieht das dann aus? Was melden die Dekoder dann zurück und vor allem woher bekommen sie die Energie fürs Rückmelden, wenn die Hinsendung (respektive das DCC-Signal) entfällt?

Ist natürlich eine Defintionsfrage was man damit meint. Einfach irgendwann lossenden macht der Decoder natürlich nicht, allerdings in keinem System. Das darf er nur, wenn er angesprochen wurde. Da aber DCC-Decoder zyklisch angesprochen werden, können sie natürlich dann was senden.
Ich habe das so verstanden, dass der Decoder was senden kann, obwohl er nicht nach etwas gefragt wurde. Z.B. kann der Decoder seine aktuelle Geschwindigkeit oder die Gleisverschmutzung selbstständig senden, wenn er dran ist. Da DCC immer vorhanden ist, kann er natürlich im Cutout senden.

---

Alles klar, wenn du es so verstanden hast, hast du natürlich recht. Ich hatte gemeint, dass ein Dekoder zurücksenden kann, ohne dass er über sein übliches Datensignal für die Hin-Richtung verfügen muss.
Er meldet dann z.B.: - kein Datensignal. - unbekanntes Protokoll. ö.ä.

Zitat

---

MariusS hat geschrieben: ↑
Di 3. Apr 2018, 22:55
Gerade als das Thema Rückmeldung aufkam, wäre ein günstiger Zeitpunkt gewesen, sich das ganze Konzept der Datenübertragung noch einmal zu überlegen und ggf. komplett zu ändern. Für den Kunden bedeutet/e die Entscheidung "mit Rückmeldung" sowieso eine komplette Hardwareerneuerung. Zentrale + Booster müssen das können, entsprechende Rückmeldemodule müssen her, sowie Dekoder die dieses können.

Ich denke, da war es wegen Kompatibilitätsgründen schon zu spät.

---

Alles klar, hier weiß ich einfach zu wenig darüber.

Grüße,
Marius

edit: falsche Formatierung...

Guten Abend Carsten,

Schön, dass wir wieder in gesittetem Ton reden. Wie gesagt, scheint es als hätte ich doch zu wenig Ahnung von DCC und desshalb manches falsch interpretiert.

Zitat

---

ich hab bei deinen Texten den Eindruck, du versuchst auf Krampf alles madig zu reden. Das geht so in die Richtung "alles Idioten, weil sie es nicht so machen wie ich mir das vorstelle". Du wirst entschuldigen, dass ich meinen Ton daran angepasst habe.

---

Alles klar, so war das von mir nicht gemeint, siehe meinen Post darüber.

Zitat

---

Zitat

---

Ich weiß, dass bei Railcom vom Dekoder Ströme geschaltet werden. Wie meldet er denn deiner Meinung nach zurück?

---

Ach, das meinst du mit Schalten. Das sind Ströme im mA-Bereich, ich glaub 30 mA waren es, wenn ich mich recht erinnere. Das willst du hoffentlich nicht als gefährlich für den Decoder deklarieren? Bedenke, dass dieser Strom aus den decodereigenen Kondensatoren kommt und da nicht übermäßig viel Kapazität drauf ist - da passiert nichts, versprochen.

---

Hier habe ich anscheinend etwas verwechselt und evtl. auch falsch verstanden...?

Zitat

---

Zitat

---

Ich weiß auch, dass man dafür eine Lücke im DCC-Signal braucht, die sowohl bei Dekodern als auch bei Boostern und Zentralen wegen des möglichen Stroms beim Wiedereinschalten zu Problemen führen kann.

---

Welche sollten das sein? Das einzige mir bekannte Problem, das tatsächlich auftritt, sind Probleme einiger Decoder mit dem Cutout, weil die zu wenig Puffer an Bord haben. Das betrifft in aller Regel Uraltkonstruktionen und kann mit etwas "angeflanschtem" Zusatzpuffer behoben werden.

---

Das war mir so auch nicht bekannt, dass das nur an den alten Dekodern liegt. Was bedeutet in diesem Fall eigentlich alt? 10 Jahre oder älter?

Zitat

---

Zitat

---

Bei abschnittsweiser Trennung wegen Booster oder anderer Modulen, kann es bei etwas asynchronem DCC Signal dazu kommen, dass eine Lok oder Wagen beim Überfahren mit einem Rad noch 15V mit dem anderen aber schon 0V einer Schienenseite erfährt.

---

Das streitet auch keiner ab und ja, man hätte durchaus andere Lösungen finden können. Die hätten aber wieder ihre eigenen Nachteile gehabt. Wenn du hier von einer "schlechten Lösung" schreibst, nur weil du diese Entscheidung und den Gedanken dahinter nicht nachvollziehen kannst, lehnst du dich seeeehr weit aus dem Fenster.

---

Das mag sein, aber ich sehe die Vorteile leider nicht? Kannst du mir welche nennen?

Zitat

---

Zitat

---

Hier ist die Gefahr alleine schon aufgrund des Protokolls gegeben!

---

Und das ist falsch. Die Gefahr entsteht lediglich bei unsachgemäßem Aufbau. Verwende die richtigen Booster und schließe sie korrekt an - fertig. Wenn du eine Wasserleitung baust und alle halbe Meter das System wechselst, brauchst du dich über undichte Stellen nicht beklagen.

---

Das stimmt. Potentielle Gefahrenstellen werden hier durch korrekte Anwendung und passendes Hardware-Design entschärft. Vorhanden sind sie vom Prinzip her dann trotzdem, auch wenn sie dann "unbedeutend" sein mögen.
Ich meine desshalb, dass ein Konzept, dass noch mehr dieser potentiellen Gefahrenstellen von Grund auf garnicht erst entstehen lässt besser wäre, oder nicht?

Zitat

---

Zitat

---

Vielleicht solltest du dir erst einmal ein paar Gedanken machen und (was hast du bei mir gleich wieder bemängelt? -Ach ja) etwas auch zu Ende Denken, bevor du mich als Ahnungslosen hinstellen willst.

---

Da fehlen so einige Infos, z.B. verwendete Hardware, Anzahl der Decoder am Gleis etc. Der Text deutet aber darauf hin, dass es um fehlerhaft konstruierte Decoder geht. Das ist nun wirklich kein Fehler von Railcom.

---

Da habe ich auch keine Ahnung, ich habe die Seite ja auch erst vorgestern das erste mal gesehen (durch Stephan_Bauer) und überflogen. Dabei hatte ich eben festgestellt, dass dort das gleiche steht, was ich anderswo schon von anderen Mobahnern gehört hatte. Daher der Link.
Aber gut, wenn es sich hier um Fehlkonstruktionen handelt, frage ich mich, warum ein Hersteller dann damit durchkommt?

Zitat

---

Zitat

---

Und ich soll keine Ahnung von technik haben. Ich habe nie von Mittelleiter gesprochen. Du legst ja auch nicht für jeden Fernsehsender (bei Kabelanschluss) ein eigenes Kabel, oder? Kannst aber trotzdem über ein Kabel X-Sender mit unterschiedlichen Daten empfangen. Wie geht das nur??? Aber klar ich bin hier der Ahnungslose.

---

Dir ist schon klar, dass über das Fernsehkabel die Sender nur in eine Richtung kommen? Du wolltest aber gleichzeitig senden und empfangen können, dazu brauchst du für jede Richtung eine Leitung + GND. Ergo 3 Schienen. Ja, sicher könnte man auch Lösungen finden, wie man das über nur 2 Leitungen hinbekommt, aber ob das unter den bei der MoBa gegebenen Verhältnissen (ungeschirmte Schienen, begrenzte Frequenzen etc.) funktioniert kann ich nicht sagen. Da bin ich auch nicht Techniker genug.

---

Ok, ein blödes Beispiel ... hätte ich evtl. genauer beschreiben sollen? Also noch einmal:
Nehmen wir einen Anbieter wie Vodafone (+ ehemalig Kabeldeutschland). Die geben dir über eine Leitung, nämlich deinen Kabelanschluss, Fernsehen + Internet welches bidirektional ist und Telefon, auch bidirektional. Und das alles über eine Leitung, coaxial. Glaub mir, es ist keine Seltenheit, das bidirektionale Kommunikationssysteme über nur eine Leitung + Schirm (GND) aufgebaut werden.

Zitat

---

Zitat

---

So, interessant, - jedes Teil muss einzeln konfiguriert werden und das stört dich.

---

Das hab ich nicht gesagt, ich sagte nur, dass diese Art des Aufbaus eine große Komplexität mit sich bringt. Und zu welchem Zweck? Um einen Rechner an der Anlage zu vermeiden? Die zusätzlichen Kosten für die intelligenten Bausteine dürften selbst bei mittelgroßen Anlagen weit höher liegen als ein einfacher PC oder gar ein Raspberry Pi. Und wenn es nur um das Prinzip geht, keinen Rechner an der Anlage haben zu wollen: Was meinst du, was solche Bausteine wären? Nichts anderes als kleine Computer.

---

Ja. Das Stimmt. Eigentlich ist jeder Taschenrechner ein kleiner Computer. Genauso wie jeder Dekoder usw.. Eigentlich jede el. Baugruppe, wo ein Microcontroller drauf ist, oder?
Bei der Steuerung über einen PC entfällt die Hardware doch nicht, oder? Woher weiß das PC-Programm sonst, wo sich wann ein Zug befindet. Mindestens Gleisbesetzmelder braucht man doch.?
Warum sollte es da einen Unterschied bei der Komplexität geben?

Zitat

---

Zitat

---

Wie machst du das bei deinen Fahrzeugdekodern und den Weichen, Signal oder Servo-Dekodern?
Wieder totaler Blödsinn den du hier verzapfst. Selbst ein Rückmeldemodul-Gleisbesetztmodul muss bei einigen Anbietern eingestellt werden.

---

Denen muss ich aber keine Abhängigkeiten und ähnliches beibringen. Du vergleichst hier grade sehr grüne Äpfel mit ziemlich saftigen Pflaumen.

---

Wie meinst du das? Natürlich MUSS man keine Abhängigkeiten irgend einem Teil beibringen, nur wenn man es will. Das musst du in deiner PC-Software doch auch? Wo soll da der Unterschied sein, verstehe ich nicht? Wenn man irgendeine Funktionalität habe will, muss man diese irgendwo einstellen können, ob das nun am PC geschieht oder der Zentrale oder einem Handregler oder über den PC üder die Zentrale, oder über ein Tablett und dann die Zentrale ist doch Jacke wie Hose ...

Zitat

---

Zitat

---

Ich habe gesagt, dass der Schnitt der sich durch die Rückmeldung ergeben hat man hätte nutzen können, um die bestehende Übertragungstechnik zu überdenken und vergangene Fehler und Fehleinschätzungen zu korrigieren.

---

Und ich sage gern nochmal: Nur weil DU etwas für einen Fehler oder eine Fehleinschätzung hälst, muss es noch lange keine sein.

---

Das stimmt. Durch einige Aussagen anderer Mobahner kam ich halt zu diesem, anscheinend falschen, Schluss.

Zitat

---

Zitat

---

Der jetzige Zustand ist es, der bei Neuerungen deutliche Kompatibilitätsprobleme aufweist!

---

Ich sehe dein Problem nicht. Ich selber habe den Cutout am Gleis, obwohl ich Railcom nicht nutze. Probleme bisher? 0. Selbst in meinem Bekannten- oder gar Kundenkreis ist das Thema bisher vielleicht 2 oder 3 Mal aufgetaucht, weil da uralte Decoder am Werk waren. Die Dinger wurden ersetzt und fertig, seitdem freuen sich die Kollegen sogar noch über die besseren Fahreigenschaften. Alternativ wurde Railcom abgeschaltet und das Problem war ebenso behoben. Also wo genau sind nun deine "deutlichen" Kompatibilitätsprobleme?

---

Naja, als bei der Methode, so wie ich das verstanden habe, gibt es Pobleme mit den alten Dekodern, bestimmten Hardwarekomponenten (evtl. Herstellerfehler?). Sowas hätte vermieden werden können, meine ich, wenn man das Konzept von Anfang an ander gewählt hätte.
Aber gut, das ist alles "hätte", "könnte", "würde" ... also halte ich hier lieber meine Klappe flaster:

Zitat

---

Zitat

---

Sie könnten dann nicht mit digitalen Funktionen laufen, wie z.B. Licht, dass auch im Stand bei Trafo-Nullstellung leuchtet, aber ganz normal fahren, wie man das von analogen Loks gewohnt ist, ist überhaupt kein Problem. Woher nimmst du nur immer diesen Käse?

---

Analogerkennung ist bereits jetzt kein einfaches Thema. Mit reiner Gleichspannung funktionierts meist gut, aber z.B. bei PWM-Fahrpulten, Halbwelle und was es noch alles gibt, gibt es je nach Decoderhersteller teils massive Probleme bis hin zur völligen Funktionsverweigerung. Meinst du, das wäre einfacher erkennbar, wenn man bei Digital eine Gleichspannung statt einer Wechselspannung verwendet hätte?

---

Nein, dazu habe ich keine Information. Ich hatte das auch so nicht betrachtet. Ich meinte nur den klassischen analog DC-Fall mit Trafo. Vom Rest habe ich wieder einmal keine Ahnung.

Zitat

---

Zitat

---

Soso, wie viele Firmen waren denn an der Entwicklung von DCC beteiligt? Und selbst wenn hier mehr als eine Firma hätte tätig werden müssen, ist es für mich kein richtiges Argument zu sagen: Tut mir leid wir würden uns ja gerne weiterentwickeln aber der Hersteller xy macht nicht mit und darum lassen wir alles so wie es schon ist.

---

DCC wurde anfangs von einer Firma allein entwickelt. Das ist aber nicht mehr vergleichbar zu heute, denn das war zu einer Zeit, als praktisch jeder Hersteller seine eigene Hausnorm gebastelt hat. Heute ist DCC DER Digitalstandard außerhalb der Märklinwelt. Willst du den ablösen, musst du die verschiedenen Hersteller ins Boot holen UND unter einen Hut bringen. Die lange, lange, lange Entwicklungsgeschichte von Railcom sollte dir ausreichend deutlich zeigen, wie schwierig das ist. Und selbst da versuchen Lenz und ESU noch, die anderen mit proprietären Erweiterungen zu übervorteilen (Stichwort: Railcom+).

---

Ok. Davon weiß ich auch zu wenig. Aber wenn du das so sagst, wirds wahrscheinlich stimmen...

Zitat

---

Selbstverständlich kannst du auch im Alleingang das beste System aller Zeiten entwickeln. Es nützt nur keinem was, wenn die anderen dann nicht aufspringen und alles irgendwann versickert. Beispiele dafür gibts genug, Märklin mit mfx fasst außerhalb der eigenen Welt keinen Fuß, Selectrix 2 fristet eine winzige Nische, C-Digital kennt praktisch keiner usw. usf.

---

Da hast du auch recht. Schade finde ich es dann trotzdem.

Zitat

---

Zitat

---

Aber gut es hört sich von dir ja schon fast wie ein Eingeständnis an, dass man eigentlich schon lange Neuerungen gebraucht und gemacht hätte, diese Vorhaben nur immer scheitern, weil man es nicht schafft sich zu einigen.

---

Das ist nun wirklich kein Geheimnis. Railcom z.B. hätte viel früher kommen können und müssen. Auch die Endgeräte sollten Railcom endlich mal unterstützen, dabei gehts mir z.B. um solche Sachen wie das Auslesen und Schreiben von CVs. Das Drama mit den Ack-Impulsen ist ja nun wirklich von vorvorvorgestern. Neben dem Problem mit der Einigung der Hersteller gibts aber noch andere Gründe, nämlich die Entwicklungskosten (Modellbahn ist einfach kein übermäßig lukratives Geschäft) und auch die Trägheit der Nutzerbasis. Letzteres ist jetzt nicht negativ gemeint, aber mir fällt kein besserer Begriff für den Umstand ein, dass die Nutzer nicht sofort jede Neuerung adaptieren und ihre bisherige Technik ersetzen. Modellbahn ist eben ein langfristiges Hobby.

So richtig verstehe ich aber nicht, was du hier eigentlich bezweckst. Du nutzt gar kein DCC, machst aber ein Riesenfass auf und beschreibst Probleme, die 99,9% der Anwender überhaupt nicht kennen oder die nichtmal existieren. Was soll das? Willst du dich einfach besser fühlen, weil du das vermeintlich bessere System gewählt hast? Nur zu, nutze es und sei glücklich. Niemand nimmts dir weg

---

Ich wollte eigentlich nur diskutieren und ein paar Fragen in die Runde werfen...
Weiter nichts. Was soll ich davon haben, irgend etwas kaputt zu reden? V.a. wenn die Behauptungen haltlos sind?

Grüße,
Marius

Hallo Marius,
schön, dass wir jetzt wieder gut miteinander sind.

Zitat

---

Das war mir so auch nicht bekannt, dass das nur an den alten Dekodern liegt. Was bedeutet in diesem Fall eigentlich alt? 10 Jahre oder älter?

---

Das lässt sich nicht pauschal sagen, es kommt einfach drauf an, wieviel Kapazität der Hersteller auf den Decoder gepackt hat. Ein bisschen Speicher brauchten die Decoder schon immer, denn auch ohne Cutout gibt es immer wieder Aussetzer, die gebrückt werden müssen. Ist der zu knapp bemessen, geht dem Prozessor der Saft aus.

Zitat

---

Das mag sein, aber ich sehe die Vorteile leider nicht? Kannst du mir welche nennen?

---

Ich bin kein Techniker, aber soweit ich weiß lässt sich das Gleissignal mit der Wechselspannung einfacher erzeugen. Es braucht praktisch nur eine H-Brücke. Das ist vergleichsweise Low-Tech. Du hast das Signal dann auch gleich auf beiden Gleis-Seiten anliegen. Ich vermute außerdem, dass noch ein Gedanke eine Rolle gespielt hat. Lenz hat bis heute eine Funktion drin, dass die Wechselspannung mit einer Gleichspannung überlagert werden kann. So kann eine analoge Lok mitfahren. Speziell bei neueren Loks sollte man sowas natürlich keinesfalls machen, aber damals dürfte das ein Verkaufsargument gewesen sein. Aber wie gesagt, das ist nur eine Vermutung.

Zitat

---

Potentielle Gefahrenstellen werden hier durch korrekte Anwendung und passendes Hardware-Design entschärft. Vorhanden sind sie vom Prinzip her dann trotzdem, auch wenn sie dann "unbedeutend" sein mögen.
Ich meine desshalb, dass ein Konzept, dass noch mehr dieser potentiellen Gefahrenstellen von Grund auf garnicht erst entstehen lässt besser wäre, oder nicht?

---

Kommt drauf an. Technik ist grundsätzlich immer auf korrekte Anwendung angewiesen. Man kann natürlich potentielle Fehlerquellen ausschließen, aber diese Lösungen können wieder andere Schwachstellen auftun oder eben gewünschte eigenschaften des Systems unmöglich machen. Was die "bessere" Lösung ist, hängt also sehr von den Umständen ab.

Zitat

---

Aber gut, wenn es sich hier um Fehlkonstruktionen handelt, frage ich mich, warum ein Hersteller dann damit durchkommt?

---

Weil keiner im realen Einsatz die Auswirkungen spürt oder weil Railcom noch nicht übermäßig breit eingesetzt wird oder ...

Die Hersteller kommen mit allem möglichen Blödsinn durch, beispielsweise die Unart von Lenz, die Bits in den CVs nicht mit 0 - 7 zu zählen, sondern mit 1 - 8. Und das ist nur ein einziges von vielen Beispielen.

Zitat

---

Nehmen wir einen Anbieter wie Vodafone (+ ehemalig Kabeldeutschland). Die geben dir über eine Leitung, nämlich deinen Kabelanschluss, Fernsehen + Internet welches bidirektional ist und Telefon, auch bidirektional. Und das alles über eine Leitung, coaxial. Glaub mir, es ist keine Seltenheit, das bidirektionale Kommunikationssysteme über nur eine Leitung + Schirm (GND) aufgebaut werden.

---

Ja, aber da gibts wie gesagt doch sehr andere Grundvoraussetzungen. Ich will mich jetzt nicht an dem dritten Leiter festbeißen, das war eigentlich eher ein flapsiger Einwurf.

Zitat

---

Ja. Das Stimmt. Eigentlich ist jeder Taschenrechner ein kleiner Computer. Genauso wie jeder Dekoder usw.. Eigentlich jede el. Baugruppe, wo ein Microcontroller drauf ist, oder?
Bei der Steuerung über einen PC entfällt die Hardware doch nicht, oder? Woher weiß das PC-Programm sonst, wo sich wann ein Zug befindet. Mindestens Gleisbesetzmelder braucht man doch.?
Warum sollte es da einen Unterschied bei der Komplexität geben?

---

In der "normalen" Form hast du nur "dumme" Komponenten, die von einer zentralen Stelle aus gesteuert werden. Willst du intelligente Bauteile miteinander vernetzen, steigt der Aufwand, denn jedes Modul muss die anderen kennen. Wie soll es sonst wissen, welche Daten wohin gesendet werden müssen? Du musst außerdem jedem Modul sagen, wo es sich befindet etc. pp. und dann Beziehungen zwischen den Modulen herstellen. Dann willst du ja noch den Bus entlasten, also Nachrichten möglichst effizient zwischen den Geräten austauschen. In Computernetzen wird das über Switches gemacht, je größer das Netzwerk, desto höher auch der Aufwand, der getrieben werden muss, damit das effizient funktioniert. Man könnte auch zusammengefasst sagen: Hardware, die mehr kann, muss komplexer sein. Ich sehe schlicht und einfach nicht, was dieser Aufwand bringen soll.

Bei der Steuerung über den PC hast du die gesamte "Intelligenz" gebündelt an einer Stelle. Die Rückmelder, Decoder etc. können dadurch einfacher und somit billiger gebaut werden. Du sparst dir außerdem den Verwaltungsaufwand um die Daten zwischen den Geräten auszutauschen. Und wenn mal ein Gerät kaputt geht, ersetzt du es, stellst die gleiche Adresse ein und es sollte alles wieder laufen.

Zitat

---

Nein, dazu habe ich keine Information. Ich hatte das auch so nicht betrachtet. Ich meinte nur den klassischen analog DC-Fall mit Trafo. Vom Rest habe ich wieder einmal keine Ahnung.

---

Das bedenken viele Analogis nicht, wenn sie über die "mangelhafte" Analogerkennung von Decodern schimpfen. Nur ist Analog eben nicht Analog, sondern der Begriff deckt eine Vielzahl von Techniken ab. Selbst "den" klassischen DC-Trafo gibts nicht wirklich...

Zitat

---

Ok. Davon weiß ich auch zu wenig. Aber wenn du das so sagst, wirds wahrscheinlich stimmen...

---

Wenns dich interessiert findest du darüber genug Lesestoff. Aber noch einfacher wärs, wenn du in einem Verein aktiv bist. Selbst wenn man sich untereinander gut kennt, ist es manchmal schwer zusammenzukommen. Und jetzt stell dir das Ganze vor, wenn mindestens zwei der Akteure ziemlich "chefige" Typen sind und alle unterschiedliche geschäftliche Interessen haben.

Gute Nacht!
Carsten

Zitat

---

....Ich sehe schlicht und einfach nicht, was dieser Aufwand bringen soll.

Bei der Steuerung über den PC hast du die gesamte "Intelligenz" gebündelt an einer Stelle. Die Rückmelder, Decoder etc. können dadurch einfacher und somit billiger gebaut werden. Du sparst dir außerdem den Verwaltungsaufwand um die Daten zwischen den Geräten auszutauschen. Und wenn mal ein Gerät kaputt geht, ersetzt du es, stellst die gleiche Adresse ein und es sollte alles wieder laufen.....

---

Moin,

eben. So ist es. Den ganzen Thread kann man ja gar nicht lesen ohne dass es einem schwindelig wird

Es gibt für die Pickelfahrer zumindest nix einfacheres und auch zuverlässigeres als den "uralten S88 Bus" / Schieberegister nebst PC-Steuerung. Selbst wenn der Bus 100 Jahre alt wäre würde ich ihn noch benutzen. Aber auch für die "2-Leiter Fahrer sieht es nicht viel anders aus. Auch da funzzt das. Nur eben mit etwas mehr Aufwand und Kosten. Bei meiner großen und komplexen Anlage funktioniert der S88 seit Jahren zu 100 %. Wer Problem mit dem Bus hat und das wird ja hier tausendmal als Grund für eine neues besseres System heraufbeschworen, der soll sich an die eigene Nase fassen. Es funktioniert alles mehr als zu Genüge und fast immer auf den cm genau, egal welche Zuglänge z.B. im Bahnhof Halt macht. Der Zug steht immer mittig. Egal ob Lok voraus, Steuerwagen voraus, vorwärts rückwärts und das alles ist mit einfachen Mitteln zu erreichen. da muß man sich gewiß nicht für verbiegen

Bei meiner Anlagen-Übersichtlichkeit (x-Ebenen etc.) würde sicher jedes andere System kläglich versagen (Funk/GPS)


Gruß Markus

Tach Marius

Zitat

---

Das ich selbst mit C-Digital fahre, sollte nicht Thema sein, - aber klar beeinflusste es auch etwas mein Denken

---

.deshalb habe ich auch C-Digital ins spiel gebracht

Zitat

---

Mein Thema war einzig und alleine die Problematiken, die, so von mir angenommen, durch die Übertragungstechnik der Digitalsysteme kommen und die Frage, warum man immer noch daran festhält.

---

Dazu hast du dich aber sehr weit aus dem Fenster gelehnt. und hast dann wohl ein bisschen viel Probleme angenommen, die theoretisch ev. gar vorhanden sind, praktisch aber keine Auswirkungen zeigen und negiert werden können.

Weshalb man an den bekannten Systemen festhält?
Ganz einfach: Weil es keinen Markt gibt für neue revolutionäre Systeme.
Die Digitalsysteme sind historisch gewachsen und waren zum Zeitpunkt der Hochblühte der Modellbahn vermutlich nicht mehr gerade revolutionär, aber zu der Zeit sicher noch Zeitgemäss.
Selbst neue Systeme wie z.B. ALAIN kommen nicht an den bekannten Digitalsystemen vorbei. Im Gegenteil, die bringt neben einem anderen Hardwareaufbau diesbezüglich auch nichts neues.
Die Probleme eines neuen Systems sind:
Es muss kompatibel sein zu bestehenden Systemen, sonst kommt es nie über den Randgruppenstatus oder Individualistenstatus hinaus (Siehe C-Digital, dem durchaus eine gute Idee zugrunde liegt) Dazu darf es bei gleichbleibender Funktionalität nicht teurer sein und Wow-Funktionalitäten die mit den bestehenden Systemen nicht abgedeckt werden sind auch sehr schwierig auszumachen.
Sind wir mal gespannt was mit ALAIN in Zukunft passiert.

Hallo,
hm, ich weiß nicht so recht, woher immer diese "Heilserwartungen" in Sachen ALAN kommen. Das Ding ist kein neues Digitalsystem. Man teilt lediglich die Anlage in Blöcke ein und ALAN speist in jeden Block die jeweils benötigte Spannung ein - je nach System digital oder analog. Praktisch ein Gahler & Ringstmeier mit zusätzlicher Zentrale. Im Übrigen gibts noch ein zweites System, das das gleiche kann, für weniger Geld: Dinamo. Die Jungs sind sogar schon länger an der Geschichte dran als ALAN.

Für mich ist sicher, dass dieses System, egal ob nun ALAN oder Dinamo, eine Nische bleiben wird. Es ersetzt schließlich nicht den Decodereinbau, wer Licht im Stand und schaltbare Funktionen etc. haben will, oder auch einfach den vollkommen freizügigen Mehrzugbetrieb, unabhängig von den Blöcken, der kommt da nicht drum herum. Setzt also keine zu großen Erwartungen in ALAN. Da wird nichts Großes draus werden, weils einfach nichts wirklich Neues bietet.

Viele Grüße
Carsten

Zitat

---

hm, ich weiß nicht so recht, woher immer diese "Heilserwartungen" in Sachen ALAN kommen.

---

Also ich hege keine Heilserwartungen an ALAN. Ich sehe ALAN genauso wie du als Nichenprodukt.
Das C-Digitalsystem ist da wirklich innovativer, aber leider komplett inkompatibel zu bestehenden Digitalsystemen. Daher noch weniger Verbreitungschancen.
Aber das wollten wir ja nicht diskutieren.