RE: Mfx und DCC

#26 von Heinzi , 29.03.2018 13:53

Moin Zusammen.

Zitat
Eine Lok unter DCC anlegen geht schneller als die langsame mfx Anmeldung?
................ Mir ging es nur darum zu verstehen, was denn im Betrieb unter DCC besser als mfx sein soll, wie hier behauptet wird.

Ehrlich gesagt kann ich diese Argumentationen auch nicht nachvollziehen. Ebenso wenig, dass das Anlegen einer (komplizierten) Lok unter DCC schneller sein soll als unter mfx. Selbst bei meiner langsamen CS1R,
Die Nachteile von mfx sehe ich persönlich woanders.
z.B. beim Löschen einer mfx Loks aus der Zentrale wenn nicht alle mfx Loks auf der Anlage sind, oder die fixe Vorgabe der erreichbaren Parameter durch die Bedienoberfläche was die Einführung neuer Decoderseitiger Parameter erschwert.


Gruss Heinzi
------------------
CS1R / ControlGui


 
Heinzi
Metropolitan (MET)
Beiträge: 4.880
Registriert am: 26.04.2006


RE: Mfx und DCC

#27 von 8erberg , 29.03.2018 13:59

Hallo,

allerdings.
Vor allen Dingen wundert mich immer der hübsche Satz "DCC ist Marktführer" - würd mich wundern, denn bei Märklin fährt in H0 min. 70 % digital, im "Rest der Welt" höchstens 30 %...

Die Diskussionen gab es schon vor Jahren und werden wohl nie aufhören.

MFX ist technisch eigentlich das bessere Digitalsystem wenn man sich die Möglichkeiten anschaut, allerdings operiert Märklin dort eher im Halbschlaf - anscheinend solange bis der letzte User entnervt auf DCC umsteigt.

Peter


Spur N Digital Selectrix/DCC
Spur 1 Teppichbahning Selectrix/MM


 
8erberg
ICE-Sprinter
Beiträge: 6.355
Registriert am: 06.02.2007
Ort: westl. Münsterland
Spurweite N, 1
Stromart Digital


RE: Mfx und DCC

#28 von digitalo , 29.03.2018 14:10

Hallo Peter

Zitat

allerdings operiert Märklin dort eher im Halbschlaf - anscheinend solange bis der letzte User entnervt auf DCC umsteigt.



Ironie Start:
Dann ist da also noch Hoffnung.
und Ende.

Zitat

"DCC ist (Welt) Marktführer"

ich habe mal die (Welt) eingefügt praktisch alles was nicht deutsch spricht im Ausland, halb Europa, Amerika und Asien.
deutschsprachiger Raum = mfx Marktfüher


digitalo (Stephan) enjoy the day !

Zentrale: C1 FW 1.402, LoPro, MXULFA & D&H Programmer
Decoder: Zimo, D&H, ESU & UB, only DCC auf K-|:|
Loks von Brawa, RoFl, Märklin, Primex, Piko, Liliput & Rivarossi
JEDEM, WAS IHN ANTREIBT! Frei von ... mm/²/mfx/+


 
digitalo
Metropolitan (MET)
Beiträge: 3.006
Registriert am: 26.12.2009
Spurweite H0
Stromart Digital


RE: Mfx und DCC

#29 von aftpriv , 29.03.2018 14:35

Hallo Peter

Zitat

... "DCC ist Marktführer" - würd mich wundern, denn bei Märklin fährt in H0 min. 70 % digital, im "Rest der Welt" höchstens 30 %...



mußt schon mal über den Tellerand (von Deutschland und auch diesem Forum) hinwegschauen, da ist M*rklin & 3L-AC ein absolutes Fremdwort und kaum vertreten

Gruß
Alf


Pickel-Bahner seit 1958 / K-Gleis + ZIMO-Decoder (MX633P22/MX645P22)
RocRail & RocNetNode jeweils auf RasPi
Email bezüglich MobaLedLib-Belange: LedLib@yahoo.com


aftpriv  
aftpriv
EuroCity (EC)
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

#30 von 8erberg , 29.03.2018 14:43

Hallo,

ok, USA. Da ist es auch durch den NMRA im Großen und Ganzen auch genormt.
Das war es dann auch.

Denn in Asien fährt fast keiner Digital.

Ausgerechnet die Japaner haben damit nicht wirklich was, Tomix bietet garnix an und Kato nachdem sie mit einem eigenen Digitalsystem auf die Nase gefallen sind bieten nur recht halbherzig Digitrax-Zeuchs an was auch nicht gerade vor Modernität strotzt (und mit Railcom auch nix am Hut hat, von ABC reden wir erst mal garnicht).

Schade nur, dass Märklin das so halbherzig anpackt, denn das automatische Anmelden hätte wie auch endlich ein einheitlich GUTER Rückmeldebus einen echten Fortschritt gebracht.
Aber so wirds daraufhinauslaufen, dass der DCC-Rahmen aus Kompatiblitätsgründen nicht mehr angepackt wird und solche Dinge wie Austastlücke und weitere Tricks in den Rahmen gedrückt werden, die nicht technikaffinen Nutzer älterer Decoder in den Wahnsinn treiben weil ihre Decoder dann nicht mehr das DCC-Signal erkennen.
Ob das besser ist?
Gut, der, der sich der neuen Technik nicht verschließt und gerne mal nen Decoder wechselt kein Thema... Normen auf dem Modellbahnmarkt sind langlebig, wieviele Leute haben noch Rollmaterial aus den 70er und 80er Jahren???

Weiterhin: Märklin verkauft auch fleissig |:|-Material in den benachbarten Ländern, nicht umsonst können eigentlich fast alle Digitalzentralen am europäischen Markt neben DCC auch mindestens MM.

Peter


Spur N Digital Selectrix/DCC
Spur 1 Teppichbahning Selectrix/MM


 
8erberg
ICE-Sprinter
Beiträge: 6.355
Registriert am: 06.02.2007
Ort: westl. Münsterland
Spurweite N, 1
Stromart Digital


RE: Mfx und DCC

#31 von 1001-digital , 29.03.2018 15:00

Hallo Peter

Zitat
Aber so wirds daraufhinauslaufen, dass der DCC-Rahmen aus Kompatiblitätsgründen nicht mehr angepackt wird und solche Dinge wie Austastlücke und weitere Tricks in den Rahmen gedrückt werden, die nicht technikaffinen Nutzer älterer Decoder in den Wahnsinn treiben weil ihre Decoder dann nicht mehr das DCC-Signal erkennen.


Wir sind nicht bei SX, bei DCC gibt es keinen "Rahmen". Die Pakete werden einfach nach Priorität gesendet. Railcom "verfälscht" das DCC-Signal auch nicht, d.h. die Decoder erkennen das problemlos. Der Hase liegt vielmehr bei der eingebauten Pufferkapazität im Pfeffer. Für Railcom wird das Gleis jeweils kurz stromlos gemacht und kurzgeschlossen, diese Zeit müssen die Decoder überbrücken können. Können sie das mangels ausreichend großer Kapazität in den Kondensatoren nicht, geht der Prozessor in den Brown-Out oder fällt gar in irgendwelche undefinierten Zustände. Darum fangen die Decoder dann an zu spinnen.

Über DCC lassen sich praktisch beliebige Daten senden, damit kommen die Decoder auch klar. Was sie nicht kennen, wird schlicht und einfach verworfen. Auch aus dem Grund laufen noch heute die alten Arnold-Digital-Decoder völlig problemlos mit aktuellen Modellen zusammen.

Viele Grüße
Carsten


 
1001-digital
InterCity (IC)
Beiträge: 806
Registriert am: 16.07.2015


RE: Mfx und DCC

#32 von drum58 , 29.03.2018 15:13

Zitat von 8erberg im Beitrag Mfx und DCC
wieviele Leute haben noch Rollmaterial aus den 70er und 80er Jahren???


Hallo Peter,

also ich habe da ziemlich viel und inzwischen das meiste auch digitalisiert.

Zitat von 8erberg im Beitrag Mfx und DCC
Weiterhin: Märklin verkauft auch fleissig |:|-Material in den benachbarten Ländern,


Nach meiner Wahrnehmung ist Märklin in genau einem Nachbarland sehr stark, in der Schweiz. Österreich oder Frankreich, Belgien etc. sind definitiv kein "Märklin-Land", da überwiegt DC/DCC.

Zitat von 8erberg im Beitrag Mfx und DCC
nicht umsonst können eigentlich fast alle Digitalzentralen am europäischen Markt neben DCC auch mindestens MM.


Das dürfte schlicht damit begründet sein, dass eben in den starken Modellbahnmärkten D und CH Märklin stark ist und die Konkurrenz vom kaufkräftigen Märklin-User auch etwas abhaben möchte. Wenn ich hier die genutzten Formate und Zentralen anschaue, dann sind auch Märklin-User nicht abgeneigt Zentralen anderer Anbieter zu nutzen, zu dem die Original-Märklin-Zentralen auch nicht zu den preiswertesten gehören. Und damit ihre älteren Märklin-Fahrzeuge ohne Decodertausch einsetzbar bleiben, braucht es halt auch mm.

Das ändert jedenfalls nichts daran, dass DCC weiter verbreitet als mm/mfx ist, sobald auch nur der Rest von Europa betrachtet wird.

Und nun mach ich Schluss mit t:

Gruß
Werner


drum58  
drum58
Metropolitan (MET)
Beiträge: 3.610
Registriert am: 17.01.2014
Homepage: Link
Ort: Moos-Bankholzen
Spurweite H0
Steuerung Lenz LZV 200 und LZV 100
Stromart DC, Digital


RE: Mfx und DCC

#33 von digitalo , 29.03.2018 15:18

Hallo Peter

Zur "digitalen Steinzeit" gehört auch, das Märklin anfangs DCC sprach. Aus was für Gründen auch immer dann dieses unseelige mm/mm² aus der Taufe gehoben wurde ... kann niemand mehr so genau sagen.
Fakt ist, das mm/mm² historisch bedingt nötig waren, so zusagen als "Krücke" benutzt wurden, um Mehrprotokoll Zentralen wie die Intellibox von Uhlenbrock unters Volk zu bringen.
Die Adaption des CAN-Busses aus der Autoindustrie bei mfx war ein kluger Schachzug von Märklin, denn damit ist ein schnelles Melden möglich, aber wie Du schon schreibst wird dieser Vorteil ohne Not vergeben. Dieser CAN-Bus ist jedoch nicht nur für mfx prädistiniert, sondern wurde lange vor Märklin von der Fa. Zimo genutzt ... zuerst mit dem hauseigenem Protokoll und in jüngerer Zeit eben mit DCC. Hier wurde also abgekupfert seitens Märklin/ESU. Allerdings wirkt sich dieser Vorteil (schnelles Melden) erst bei sehr großen Anlagen aus.
Ich denke nicht, das irgend ein Privatmann solch eine Groß-Anlage sein Eigen nennt, bzw. hat. Falls doch wird das Ganze mit an Sicherheit grenzender Wahrscheinlichkeit mit dem PC gesteuert, was wieder andere Möglichkeiten bietet.


digitalo (Stephan) enjoy the day !

Zentrale: C1 FW 1.402, LoPro, MXULFA & D&H Programmer
Decoder: Zimo, D&H, ESU & UB, only DCC auf K-|:|
Loks von Brawa, RoFl, Märklin, Primex, Piko, Liliput & Rivarossi
JEDEM, WAS IHN ANTREIBT! Frei von ... mm/²/mfx/+


 
digitalo
Metropolitan (MET)
Beiträge: 3.006
Registriert am: 26.12.2009
Spurweite H0
Stromart Digital


RE: Mfx und DCC

#34 von Gleichstromer ( gelöscht ) , 29.03.2018 15:50

Zitat

Die Adaption des CAN-Busses aus der Autoindustrie bei mfx war ein kluger Schachzug von Märklin, denn damit ist ein schnelles Melden möglich, aber wie Du schon schreibst wird dieser Vorteil ohne Not vergeben. Dieser CAN-Bus ist jedoch nicht nur für mfx prädistiniert, sondern wurde lange vor Märklin von der Fa. Zimo genutzt ... zuerst mit dem hauseigenem Protokoll und in jüngerer Zeit eben mit DCC. Hier wurde also abgekupfert seitens Märklin/ESU.



Was hat denn der CAN-Bus mit mfx zu tun?

Der CAN-Bus wird zwischen den Steuergeräten verwendet, also Zentrale, MS2, Booster etc., aber nicht zwischen Zentrale und Lok. Auf dem Gleis liegt kein CAN-Bus sondern eben mfx, DCC, MM etc.


Gleichstromer

RE: Mfx und DCC

#35 von Erich Müller , 29.03.2018 21:15

Zitat von Heinzi im Beitrag Mfx und DCC

Die Nachteile von mfx sehe ich persönlich woanders.
z.B. beim Löschen einer mfx Loks aus der Zentrale wenn nicht alle mfx Loks auf der Anlage sind



Was hat das mit mfx zu tun? Ich habe hier eine MS1 liegen, die seit Jahren nicht mehr als Master gedient hat (die Endstufe ist nämlich kaputt) - aber wenn ich sie an die Master-Buchse anschließe, werden die Loks angezeigt, die sich 2004 mal daran angemeldet haben.
Vielleicht - nein: ganz sicher liegt dieses Verhalten deiner Zentrale nicht am Protokoll, sondern am Programmierer der Zentrale.

Zitat

Zur "digitalen Steinzeit" gehört auch, das Märklin anfangs DCC sprach. Aus was für Gründen auch immer dann dieses unseelige mm/mm² aus der Taufe gehoben wurde ... kann niemand mehr so genau sagen.



Das ist meines Wissens falsch: Märklin-Digital mit dem MM-Protokoll kam 1984 auf den Markt und war das erste weiter verbreitete System, das mehr als eine Handvoll Loks ansteuern konnte. Märklin-Digital= bzw. Arnold-Digital, also gewissermaßen das Ur-DCC, das Bernd Lenz später unter eigenem Namen vertrieb, kam erst 1987 oder 1988 - und zwar wurde es entwickelt, weil MM asymmetrisch ist, was für das (grundsätzlich eindeutig gepolte) Mittelleitersystem kein Problem darstellt, für das Zweileitersystem, bei dem der rote Pol mal links und mal rechts am Rad liegen kann, aber mit den damaligen Decodern nicht funktionierte. Also musste ein neues, symmetrisches System her, dem es egal ist, ob rot nun rechts oder links liegt: Märklin-Digital=.

Zitat

Fakt ist, das mm/mm² historisch bedingt nötig waren, so zusagen als "Krücke" benutzt wurden, um Mehrprotokoll Zentralen wie die Intellibox von Uhlenbrock unters Volk zu bringen.



Nö. Das ist bestenfalls eine auf einem historischen Irrtum beruhende Hypothese.

Zitat

Nach meiner Wahrnehmung ist Märklin in genau einem Nachbarland sehr stark, in der Schweiz. Österreich oder Frankreich, Belgien etc. sind definitiv kein "Märklin-Land", da überwiegt DC/DCC.



Belgien betreffend würde ich meine Hand da nicht ins Feuer legen - immerhin gibt es in diesem kleinen Land mindestens einen Händler, der speziell auf Märklin-Modellen basierende belgische Modelle herstellen lässt. In den französischsprachigen Foren sind die belgischen Mittelleiterfahrer gefühlt stärker vertreten als die französischen, ungefähr auf gleichem Niveau wie die Schweizer. Und das sind nur die Frankophonen...
Und die Niederlande sind traditionell auch ein recht starker Dreileitermarkt.


Freundliche Grüße
Erich

„Es hat nie einen Mann gegeben, der für die Behandlung von Einzelheiten so begabt gewesen wäre. Wenn er sich mit den kleinsten Dingen abgab, so tat er das in der Überzeugung, daß ihre Vielheit die großen zuwege bringt.“
Friedrich II. über Fr. Wilhelm I.


Erich Müller  
Erich Müller
ICE-Sprinter
Beiträge: 6.319
Registriert am: 03.12.2015


RE: Mfx und DCC

#36 von MariusS ( gelöscht ) , 01.04.2018 23:52

Guten Abend,

Zitat

Vor allen Dingen wundert mich immer der hübsche Satz "DCC ist Marktführer" - würd mich wundern, denn bei Märklin fährt in H0 min. 70 % digital, im "Rest der Welt" höchstens 30 %...


Ich für meinen Teil bin eher erstaunt, dass sich diese Systeme, die sich schon vom Konzept her in einer technologischen Sackgasse befinden, überhaupt so lange halten. Seit geraumer Zeit versucht man mit aller Macht diese Systeme durch gewaltsame Änderungen weiter annähernd "fortschrittlich" zu halten.


Zitat
Aber so wirds daraufhinauslaufen, dass der DCC-Rahmen aus Kompatiblitätsgründen nicht mehr angepackt wird und solche Dinge wie Austastlücke und weitere Tricks in den Rahmen gedrückt werden, die nicht technikaffinen Nutzer älterer Decoder in den Wahnsinn treiben weil ihre Decoder dann nicht mehr das DCC-Signal erkennen.
Ob das besser ist?

Ja, diese Probleme liegen bereits im Konzept begründet.

Zitat
Schade nur, dass Märklin das so halbherzig anpackt, denn das automatische Anmelden hätte wie auch endlich ein einheitlich GUTER Rückmeldebus einen echten Fortschritt gebracht.

Einen GUTEN Rückmeldebus? Meines erachtens kann es den hier nie geben, denn unter GUT verstehe ich:

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

- Rücksenden, dass sich auch Dekoder gegenseitig benachrichtigen können und nicht mehr jede Funzel-Information über die Zentrale oder den PC laufen muss

- dauerhaftes Rücksenden; auch von größeren Informationspaketen

- Rücksendegeschwindigkeiten die es ermöglichen, dass bei 100 Dekodern jeder in höchstens 500ms mindestens 10Byte senden kann

- zum Senden wird kein Verbraucher am Dekoder benötigt

- das Senden darf den Dekoder nicht über Gebühr belasten

Wie soll das mit der bei MM, mfx oder DCC verwendeten Technik gehen??? Hier bieten wohl nur die neuen wireless Lösungen wie ALAN usw. einen "Ausweg" bzw. eine Option. - Aber auch nicht wirklich. Das wäre praktisch auch ein kompletter Systemumstieg.

Zitat
Der Hase liegt vielmehr bei der eingebauten Pufferkapazität im Pfeffer. Für Railcom wird das Gleis jeweils kurz stromlos gemacht und kurzgeschlossen, diese Zeit müssen die Decoder überbrücken können.

Ja, eine Krücken-Lösung!

Zitat
Über DCC lassen sich praktisch beliebige Daten senden, damit kommen die Decoder auch klar. Was sie nicht kennen, wird schlicht und einfach verworfen. Auch aus dem Grund laufen noch heute die alten Arnold-Digital-Decoder völlig problemlos mit aktuellen Modellen zusammen.

Nur lässt sich halt die komplette Datenstruktur hier nicht ändern, auch wenn es sinnvoll wäre. Ein Beispiel aus der Vergangenheit wäre die damalige Neuerung mit "langen Lokadressen". Das Konzept ist nicht so gewählt, dass man es, ohne die Abwärtskompatibilität zu verlieren, neu strukturieren kann.

Zitat
Die Adaption des CAN-Busses aus der Autoindustrie bei mfx war ein kluger Schachzug von Märklin, denn damit ist ein schnelles Melden möglich, aber wie Du schon schreibst wird dieser Vorteil ohne Not vergeben.

Zunächst hat Märklin hier ja nur den seit Jahren existierenden und zahlreich bewehrten CAN-BUS verwendet, (wie andere auch schon lange vor ihnen), und damit nichts wirklich "Neues" gemacht.
Ein wirklich schnelles Melden liegt hier nicht primär beim CAN-BUS sondern bei den Dekodern, dem Protokoll und der Informations-Übertragungstechnologie. Durch dies kann sich kein schnelles Melden ergeben, so gut der CAN-BUS an sich auch wäre.


Gruß,
Marius


MariusS

RE: Mfx und DCC

#37 von JoMa , 02.04.2018 11:35

Zitat von transalpin115 im Beitrag Mfx und DCC
... Ich beschäftige mich seit kurzer Zeit mit Märklin Digital und bin daher ein Einsteiger in dieses Thema. In einem Youtube Video sah ich wie ein Märklin Freund eine Dampflok, die einen Mfx Sounddecoder eingebaut hat (BR 24), auf DCC umstellte und diese Lok dann mit einer DCC Zentrale (Digikeijs)betrieben hat.

Dazu meine Frage: 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+?...

Hallo Zusammen,

also ich als Einsteiger hätte jetzt wenig Hilfestellung erfahren, wenn Ihr alle wieder nur reflexartig Eure Vorlieben schildert in einem zwar kleinen, aber doch schon ein bißchen Glaubenskrieg...

Hast Du, lieber Transalpin, eine Märklin-Zentrale, dann ist meiner Ansicht nach DCC für mfx-fähige Lokdecoder und gerade auch Märklin-mfx-Decoder außer in sehr seltenen Anwendungen nicht von Vorteil. Die mfx-Loks melden sich immer innerhalb von 30 sec., sobald sie aufs Gleis gestellt oder in einem zuvor stromlosen Abschnitt zugeschaltet werden, automatisch an. Man muß sie nirgends in irgendwelchen Menüs suchen, über das mfx-Symbol sind sie anwählbar. Zweite Möglichkeit ist das Auswählen aus der zentraleninternen Lokliste. Zumindest bei CS2 und CS3 ist das eineindeutig, wenn man Loks richtig benennt und aussagekräftige Bilder verwendet. Lokkarten braucht es keine, sie kosten zusätzlich und machen zusätzlich Arbeit. Ein Backup der CS2 kann ich schnell auch auf einen USB-Stick machen. Wenn Du Loks zu einer anderen Anlage mitnimmst, liest die Lok ihre Daten mit allen Deinen Konfigurationen außer dem Lokbild auch dort ein. Die Lokkarte, glaube ich, überträgt auch das Lokbild, das wäre der einzige Vorteil, auf Deiner Zentrale ist die Eindeutigkeit immer in soweit gewährleistet, wie Du diese von vornherein Dir überlegst und umsetzt. Wo da der Kollege "Gleichstromer" ein Problem sieht, konnte er zumindest mir nicht schlüssig erläutern.
Daß mfx-Loks sich unter DCC besser steuern lassen, ok, habe ich noch nicht bemerkt, aber auch noch nicht so häufig probiert, wozu auch. Ich schalte doch einen Hauptvorteil von mfx nicht ab, um mit umständlichen Hilfestellungen über Workarounds diese wieder hereinzuholen. Übrigens verhandeln mfx-Zentralen die Lokadresse selbst mit der Lok, man muß da nicht von Hand eine Eindeutigkeit herstellen. Hier gibt es nur bei einem Spezialfall einen leichten Vorteil von DCC. Wenn man z. B. einen Triebzug digitalisiert und den Lokdecoder in den angetriebenen Zugiteil packt und z. B. im rückwärtigen Zugteil die Stirn-/Schlußbeleuchtung mit einem Funktionsdecoder schalten möchte, brauchen beide die gleiche Lokadresse, um auf einem Fahrpult konfigurierbar zu sein. Das ist in DCC leicht lösbar, bei mfx wenn nur über Umwege, eben wegen der automatischen Lokadressengenerierung. Falls das bei Dir häufiger vorkäme, hätte DCC vielleicht Vorteile...
Ich persönlich würde das Protokoll wählen, daß meinen Anforderungen genügt und die Mehrheit meiner Decoder spricht. In meiner persönlichen Märklin-Welt mit zwischen 10 und 20 % Fremdprodukten und ca. 20 alten digitalisierten Märklin-Loks (Uhlenbrock 76200) ist das mfx. Ich verstehe nicht, weshalb die grafische Darstellung des mfx hier gerne zerredet wird. Es käme doch auch niemand in den Sinn, seinen Computer mit DOS 6.2.2 und Windows 3.11 von Hand einzurichten, jeden Treiber einzeln in das extended Memory auszulagern und Netzwerktreiber richtig einzubinden. Das war ein Mal, das braucht kein Mensch mehr. Jeder ist doch heute froh, daß das alles via Oberfläche und Assistenten automatisch geschieht. Auch Smartphones werden nicht auf Systemebene konfiguriert. Natürlich begrüße ich, daß alle Märklin-Decoder auf Basis der mld/3- bzw. msd/3-Architektur (seit ca. zwei Jahren auf dem Markt) DCC sprechen, das ermöglicht auch den Einsatz der Lok, wenn kein mfx zur Verfügung steht.
In der Märklin-Welt ist halt mfx vorgesehen und wird am besten unterstützt. Das ist aber auch nicht verwerflich. Das ist bei allen Produkten in anderen Branchen auch so. Mit einer Panasonic-Fernbedienung lassen sich nur die Grundfunktionen eines Samsung-Fernsehers steuern und umgekehrt. Das volle Bedienkonzept läßt sich nur in der jeweils eigenen Welt nutzen, genießen und erleben. Das ist normal. Ich habe mir mit Templates die DCC-Programmierung von Fremddecodern erleichtert, es bleibt in der Märklin-Welt dennoch eine Strafe. Mehr als 200 CVs sind selbst mit einer PC-Tastatur an der CS2 kein Vergnügen. Deshalb habe ich meine Zentrale von Märklin gewählt, da bei mir deren Produkte in der Mehrheit sind. Bei Euch, wenn Produkte anderer Firmen dominieren, wäre das falsch. Dann braucht Ihr eine auf DCC optimierte Zentrale. Einem Einsteiger würde ich aber niemals ein Protokoll empfehlen, das seine Produkte der Kompatibilität wegen auch beherrschen, sondern immer das seiner Welt eigene Protokoll. Anders führt das nur zu Frust. Diejenigen, die weit fortgeschritten sind, sollten darüber nachdenken, daß die von ihnen genommene 5473ste Abzweigung niemandem hilft, der an der ersten steht. Will sagen, Ihr habt Euch in vielen Jahren zu solch ausgefallenen Konfigurationen vorgewagt, die ungewöhnlicher Bedienkonzepte oder auch Ausrüstung bzw. Ausrüstungskombinationen bedürfen, das ist aber weder allgemeingültig noch allgemeinbrauchbar - für Euch aber das genau passende. Bei Empfehlungen könnt Ihr das aber nicht an Einsteiger vermitteln, sondern müßt vielleicht Dinge empfehlen, die Euch nicht so leicht fallen, aber dem Einsteiger gerecht werden. Andernfalls ist kein Rat manchmal der bessere Rat.

Nun denn, mfx ist gut, DCC ist gut, Pickelgleis ist gut, Nicht-Pickelgleis ist gut. Und Dir, lieber Transalpin, rate ich, bleibe bei mfx, probiere aber gerne mal eine einfache DCC-Lok (ohne Sound), wenn Dir das DCC-Programmieren besser gefällt, dann wechsle, bei neuen Märklin-Loks geht das problemlos, ältere OEM-Decoder auf mld/2- oder msd/2-Basis oder älter können kein DCC, würden dann einen Decodertausch benötigen.

Liebe Grüße aus BaWü, Stefan


 
JoMa
EuroCity (EC)
Beiträge: 1.351
Registriert am: 17.06.2011
Ort: nördliches BaWü
Spurweite H0
Steuerung CS2/CS3, Trafos für analog
Stromart AC, DC, Digital, Analog


RE: Mfx und DCC

#38 von Heinzi , 03.04.2018 10:55

Hallo Erich.

Zitat
Heinzi hat geschrieben: ↑
29 Mär 2018 13:53
Die Nachteile von mfx sehe ich persönlich woanders.
z.B. beim Löschen einer mfx Loks aus der Zentrale wenn nicht alle mfx Loks auf der Anlage sind
.
.
.
. Was hat das mit mfx zu tun? Ich habe hier eine MS1 liegen, die seit Jahren nicht mehr als Master gedient hat (die Endstufe ist nämlich kaputt) - aber wenn ich sie an die Master-Buchse anschließe, werden die Loks angezeigt, die sich 2004 mal daran angemeldet haben.
Vielleicht - nein: ganz sicher liegt dieses Verhalten deiner Zentrale nicht am Protokoll, sondern am Programmierer der Zentrale.


Guckst du hier:
http://www.skrauss.de/modellbahn/Schienenformat.pdf
Kapitel 3.2.6 und angrenzende


Zitat
Einen GUTEN Rückmeldebus? Meines erachtens kann es den hier nie geben, denn unter GUT verstehe ich:
- Rücksenden unabhängig von der "Hin-Sendung"
- Rücksenden, dass sich auch Dekoder gegenseitig benachrichtigen können und nicht mehr jede Funzel-Information über die Zentrale oder den PC laufen muss
- dauerhaftes Rücksenden; auch von größeren Informationspaketen
- Rücksendegeschwindigkeiten die es ermöglichen, dass bei 100 Dekodern jeder in höchstens 500ms mindestens 10Byte senden kann
- zum Senden wird kein Verbraucher am Dekoder benötigt
- das Senden darf den Dekoder nicht über Gebühr belasten

Und wozu soll das ganze gut sein? Wer braucht so was und wozu? Das einzig worin ich einen Sinn sehe ist die Information welche Lok in welchem Abschnitt steht. Und wie uns railcom zeigt, ist das auch (aktuell) mit einigem Aufwand verbunden und wird nach meinem Empfinden nur von einer Randgruppe auch wirklich genutzt.


Gruss Heinzi
------------------
CS1R / ControlGui


 
Heinzi
Metropolitan (MET)
Beiträge: 4.880
Registriert am: 26.04.2006


RE: Mfx und DCC

#39 von aftpriv , 03.04.2018 11:39

Hallo Forianer

vielleicht kann man das so ausdrücken; beide Systeme haben ihre Berechtigung :

mfx ist für den (unerfahrenen) normalen Modell- und Vitrinenbahner eins super Sache (Göppinger Philosophie läßt grüßen), alles geht automatisch, man braucht nur die beiden Drähte von der Zentrale am Gleis anschließen und die Lok aufgleisen. Dann kann man (nach ca. 30 Sekunden) fahren - sollte es nicht funktionieren, geht man zum Händler (oder ins Internet, z. B. in dieses Forum usw.) zur Beratung.

Hat man sich für DCC entschieden, muß man etwas Zeit zum Lernen und Begreifen investieren, dann fährt man mindestens genau so gut wie mit obigem System, nur mit wesentlich vielfältigeren Möglichkeiten - und hat auch (speziell die 2L-Fraktion oder auf 3L umgebaute Produkte) bedeutend mehr Auswahl an Modellen - sollte es ebenfalls nicht funktionieren, geht man zum Händler (oder ins Internet, z. B. in dieses Forum usw.) zur Beratung.

Gruß
Alf


Pickel-Bahner seit 1958 / K-Gleis + ZIMO-Decoder (MX633P22/MX645P22)
RocRail & RocNetNode jeweils auf RasPi
Email bezüglich MobaLedLib-Belange: LedLib@yahoo.com


aftpriv  
aftpriv
EuroCity (EC)
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

#40 von supermoee , 03.04.2018 11:50

Zitat

dann fährt man mindestens genau so gut wie mit obigem System, nur mit wesentlich vielfältigeren Möglichkeiten



Hallo Alf,

hier muss ich nochmal nachfragen, welche diese vielfältigeren Möglichkeiten sind? Die Frage ist nicht ketzerisch sondern ernst gemeint.

Also zwei Punkte haben wir:

-ABC Bremsen. Zwar erkennen auch MM und mfx Dekoder Bremsstrecken, aber ABC bietet eben mehr Möglichkeiten und ist mit Dioden recht günstig zu erstellen, auch wenn etwas Schaltungsaufwand nötig ist, wenn auch die Wagen im Zugverband Strom leiten.
- Railcom Rückmeldung: ist zwar eine teure Angelegenheit und wird anscheinend fast von niemandem benutzt, ist aber eine Möglichkeit. mfx könnte es auch, der Entwickler ist aber auf diesem Ohr anscheinend taub.

Was gibt es noch für erweiterte (und nutzbare) Möglichkeiten?

Gruss

Stephan


Der Trend geht deutlich zur Zweitanlage hin.


supermoee  
supermoee
Tankwart
Beiträge: 13.696
Registriert am: 02.06.2006
Gleise Maerklin K Gleise / Kato N / Fleischmann N / Peco N
Spurweite H0, N
Steuerung Maerklin CS3 2.4.0 / Fichtelbahn BiDiB
Stromart Digital


RE: Mfx und DCC

#41 von Heinzi , 03.04.2018 12:09

ja lieber Alf

zum Punkt

Zitat

Hat man sich für DCC entschieden, ..... und hat auch (........) bedeutend mehr Auswahl an Modellen -

möchte ich gerne intervenieren.
Erstens hat das eigentlich nicht viel mit DCC an sich zu tun, sondern mit dem 2L Gleissystem (aber wir haben verstanden), und zweitens bietet fast jeder "typische" 2L Hersteller fast alle seine Modelle auch für das Märklin Gleissystem an mit Ausnahmen einiger Spezialitäten wie US-Modelle und Schmalspurbahnen . Und Märklin bietet vielleicht nicht so schnell x Farbvarianten an wie das im 2L Segment ev. geschieht.


Gruss Heinzi
------------------
CS1R / ControlGui


 
Heinzi
Metropolitan (MET)
Beiträge: 4.880
Registriert am: 26.04.2006


RE: Mfx und DCC

#42 von MariusS ( gelöscht ) , 03.04.2018 13:41

Hallo Heinz,

Zitat

Zitat
Einen GUTEN Rückmeldebus? Meines erachtens kann es den hier nie geben, denn unter GUT verstehe ich:
- Rücksenden unabhängig von der "Hin-Sendung"
- Rücksenden, dass sich auch Dekoder gegenseitig benachrichtigen können und nicht mehr jede Funzel-Information über die Zentrale oder den PC laufen muss
- dauerhaftes Rücksenden; auch von größeren Informationspaketen
- Rücksendegeschwindigkeiten die es ermöglichen, dass bei 100 Dekodern jeder in höchstens 500ms mindestens 10Byte senden kann
- zum Senden wird kein Verbraucher am Dekoder benötigt
- das Senden darf den Dekoder nicht über Gebühr belasten

Und wozu soll das ganze gut sein? Wer braucht so was und wozu? Das einzig worin ich einen Sinn sehe ist die Information welche Lok in welchem Abschnitt steht.



Zunächst einmal halte ich es für gewagt, einfach zu sagen, dass man das nicht braucht, weil auch RailCom zum Rückmelden der Adresse kaum genutzt wird. Aber gut...

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.

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.

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.

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

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)

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

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

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

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.

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



Zitat

Und wie uns railcom zeigt, ist das auch (aktuell) mit einigem Aufwand verbunden und wird nach meinem Empfinden nur von einer Randgruppe auch wirklich genutzt.

Ja, klar. Hab ich ja geschrieben, dass die ganze Datenübertragung, wie schon die hinwärts bei DCC, mfx, SX Systemen vom Konzept her schlecht ist. Darum geht das Rückmelden auch nur mit "enormem" Aufwand und haufenweise Kompromissen -> Es ist eben eine Krückenlösung.
Früher hätte man auch schon vor 15, 20 Jahren sehen können, wie "schlecht", ungeeignet diese Art der Digital-Steuerungen ist, wenn man sich einmal angesehen hat, was für ein Aufwand getrieben werden musste, um einen autom. Signalhalt zu ermöglichen. Vor ABC konnte man die Loks im Halt dann nicht einmal mehr voll Ansprechen!
Was für ein Mi*** und in totalem Widerspruch zu dem was Digital größtenteils ausmacht (Stichwort betrieblich, funktionelle Vielfalt). Dann musste man teilweise 3 Abschnitte für einen Halt vorsehen...
Mit ABC hat sich dann einiges verbessert, jedoch gibt es hier auch einige Probleme und Tücken.
Die Gefahr eines bösen Kurzschlusses beim Überfahren von Trennstellen ist weiterhin gegeben und mit Railcom sogar erweitert worden! (Stichwort: Asynchrones Cut-out)

Für mich also nicht verwunderlich, wenn railcom (noch) nicht so stark genutzt wird. Mehr verwundert mich, dass man immernoch auf so ein Konzept setzt und dieses auch noch als Standard gilt.
Mit massig Soundfunktionen, farbigen Displays und Apps wird dem Kunden ein Fortschritt und Modernität vorgegaukelt, die es eigentlich nicht gibt. (siehe Motorsteuerung, fragt mal Stephan = StephanLeist hier im Forum, der kann euch ein lied davon singen)


Gruß,
Marius


MariusS

RE: Mfx und DCC

#43 von aftpriv , 03.04.2018 16:43

Hallo Stephan

Zitat

Zitat

dann fährt man mindestens genau so gut wie mit obigem System, nur mit wesentlich vielfältigeren Möglichkeiten


hier muss ich nochmal nachfragen, welche diese vielfältigeren Möglichkeiten sind? Die Frage ist nicht ketzerisch sondern ernst gemeint.




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.

Gruß
Alf


Pickel-Bahner seit 1958 / K-Gleis + ZIMO-Decoder (MX633P22/MX645P22)
RocRail & RocNetNode jeweils auf RasPi
Email bezüglich MobaLedLib-Belange: LedLib@yahoo.com


aftpriv  
aftpriv
EuroCity (EC)
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

#44 von stephan_bauer , 03.04.2018 22:15

Zitat

- Railcom Rückmeldung: ist zwar eine teure Angelegenheit und wird anscheinend fast von niemandem benutzt, ist aber eine Möglichkeit. mfx könnte es auch, der Entwickler ist aber auf diesem Ohr anscheinend taub.


Wie kommst Du den darauf?
Bei OpenDCC, Digikey, Roco und Tams gibt es günstige Railcom-Komponenten.
Railcom verbreitet sich immer mehr.

Grüße
Stephan


http://www.opendcc.de/


stephan_bauer  
stephan_bauer
InterCity (IC)
Beiträge: 653
Registriert am: 18.11.2007
Spurweite Z
Stromart Digital


RE: Mfx und DCC

#45 von stephan_bauer , 03.04.2018 22:24

Hallo Marius,

Zitat

Einen GUTEN Rückmeldebus? Meines erachtens kann es den hier nie geben, denn unter GUT verstehe ich:


Verstehe nicht, was diese Funktionen mit dem Rückmeldebus zu tun haben. Das sind doch alles Decoder-Funktionen

Zitat

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


Geht bei Railcom

Zitat

- Rücksenden, dass sich auch Dekoder gegenseitig benachrichtigen können und nicht mehr jede Funzel-Information über die Zentrale oder den PC laufen muss


Das wird dann wohl eher ein Kuddelmuddel, halte ich nicht für sinnvoll

Zitat

- dauerhaftes Rücksenden; auch von größeren Informationspaketen


Das wird schwieriger, wirklich nötig?

Zitat

- Rücksendegeschwindigkeiten die es ermöglichen, dass bei 100 Dekodern jeder in höchstens 500ms mindestens 10Byte senden kann


8 Byte in ca. der doppelten Zeit sind bei Railcom möglich.

Zitat

- zum Senden wird kein Verbraucher am Dekoder benötigt


Bei Railcom möglich

Zitat

- das Senden darf den Dekoder nicht über Gebühr belasten


Unklare Defintion, Railcom funktioniert problemlos, wenn der Hersteller das sauber implementiert hat, sowohl in Software als auch in Hardware.
Das ist aber wohl überall so.

Zitat

Wie soll das mit der bei MM, mfx oder DCC verwendeten Technik gehen??? Hier bieten wohl nur die neuen wireless Lösungen wie ALAN usw. einen "Ausweg" bzw. eine Option. - Aber auch nicht wirklich. Das wäre praktisch auch ein kompletter Systemumstieg.


ALAN ist nicht wireless.

DCC + Railcom ist sicher nicht perfekt, aber ich denke, es ist wesentlich mehr möglich, als Du Dir z.Z. vorstellst.

Grüße
Stephan


http://www.opendcc.de/


stephan_bauer  
stephan_bauer
InterCity (IC)
Beiträge: 653
Registriert am: 18.11.2007
Spurweite Z
Stromart Digital


RE: Mfx und DCC

#46 von MariusS ( gelöscht ) , 03.04.2018 23:55

Guten Abend Stephan,

Zitat

Zitat

Einen GUTEN Rückmeldebus? Meines erachtens kann es den hier nie geben, denn unter GUT verstehe ich:


Verstehe nicht, was diese Funktionen mit dem Rückmeldebus zu tun haben. Das sind doch alles Decoder-Funktionen


Das Wort Rückmeldebus entsprang einem Zitat. Ich würde Railcom nicht als Bus bezeichnen. (für mich ist ein Bus z.B. I2C, CAN, RS232, USB, usw.)

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?
Wird neuerdings neben dem DCC (etwa 16 bis 22 Volt TTL) Signal neuerdings noch etwas anderes mit auf die Schiene gegeben, wäre mir neu.

Zitat

Zitat

- Rücksenden, dass sich auch Dekoder gegenseitig benachrichtigen können und nicht mehr jede Funzel-Information über die Zentrale oder den PC laufen muss


Das wird dann wohl eher ein Kuddelmuddel, halte ich nicht für sinnvoll


Darüber lässt sich natürlich streiten, liegt aber in erster Linie an der Struktur, die zugrunde gelegt wird. Wenn man es schlecht macht, wahllos in der Gegend herum sendet, mag das zutreffen. Mit einer entsprechenden Systematik ist das aber überhaupt kein Problem und kann enorme Vorteile bringen, wie ich sie schon angedeutet habe.
(ein etwas weit hergeholter Vergleich aus unserer heutigen Zeit: Car-to-Car-Communication)

Zitat

Zitat

- dauerhaftes Rücksenden; auch von größeren Informationspaketen


Das wird schwieriger, wirklich nötig?


Hier lässt sich natürlich auch streiten, wobei nicht genau spezifiziert wurde was "größere" Informationspakete sind. -> nicht schlecht wäre z.B. eine unabhängige Rücksende-"Leitung", die fast ebenso viel Informationen transportieren kann, wie die Hin-"Leitung"

Zitat

Zitat

- Rücksendegeschwindigkeiten die es ermöglichen, dass bei 100 Dekodern jeder in höchstens 500ms mindestens 10Byte senden kann


8 Byte in ca. der doppelten Zeit sind bei Railcom möglich.


Ok, das wusste ich so auch nicht. Das wäre ja dann schon einmal garnicht sooo schlecht, wenn da nicht die ganzen anderen Problemchen, Einschränkungen und negativen Aspekte wären.


Zitat

Zitat

- zum Senden wird kein Verbraucher am Dekoder benötigt


Bei Railcom möglich


Das ist schön, dass das bei Railcom geht. Trotzdem bleibt das Problem mit den Schaltströmen am Dekoder und durch den Cut-out.

Zitat

Zitat

- das Senden darf den Dekoder nicht über Gebühr belasten


Unklare Defintion, Railcom funktioniert problemlos, wenn der Hersteller das sauber implementiert hat, sowohl in Software als auch in Hardware.
Das ist aber wohl überall so.


Natürlich ist das überall so. Siehe Problematik mit den Strömen oben - die kann man höchstens eindämmen mehr aber auch nicht, weil konzptionell bedingt. Ein dauerhaftes Senden macht wohl kaum ein Dekoder lange mit. Hier und da mal eine kurze Rücksendung geht vielleicht, aber wie sieht es aus, wenn bspw. pro Sendungsempfang auch 2 bis 4 Byte zurückgesendet werden?
Weiteres Problem sind die sehr hohen Einschaltströme, die nach dem Cut-out entstehen können, wenn es an entsprechender Pufferung mangelt.

Zitat

Zitat

Wie soll das mit der bei MM, mfx oder DCC verwendeten Technik gehen??? Hier bieten wohl nur die neuen wireless Lösungen wie ALAN usw. einen "Ausweg" bzw. eine Option. - Aber auch nicht wirklich. Das wäre praktisch auch ein kompletter Systemumstieg.


ALAN ist nicht wireless.


Da habe ich das dann wohl verwechselt, kann ja mal vorkommen. Aber ich meinte nur, dass es so "ganz moderne" Systeme gibt, die vermeintlich alles können. Hier wirds dann allerdings richtig teuer und man kann seine alten Sachen komplett weghauen.

Zitat

DCC + Railcom ist sicher nicht perfekt, aber ich denke, es ist wesentlich mehr möglich, als Du Dir z.Z. vorstellst.


Klar, das mag stimmen. Ich sehe halt nur schon die Probleme des zugrundeliegenden Konzepts. Diese Probleme lassen sich evtl. etwas einschränken bzw. eindämmen, da sie konzeptionell bedingt sind, werde sie aber nicht verschwinden. Siehe Kurzschlussgefahr bei DCC-, MM-, mfx-, SX- Systemen wegen 18V TTL. Dieses Problem bestand von Beginn an und zeigt sich bis heute. Übrigens ja auch bei Railcom, wenn der Cut-out nicht überall auf der Anlage komplett synchron ist und es durch brückende Wagen oder Loks zu einer Verbindung kommt. (mein persönliche Schlussfolgerung: Schlechtes Konzept! Und das geht so weiter, auch bei Railcom. Es wird hier und da etwas "hingebogen", um so eine Rückmeldung überhaupt zu ermöglichen -> Krücken-Lösungen, die bei alten Dekodern und Hardware zu einigen Problemen führen.)

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.
Da hatte aber wohl niemand die Ei** zu, diesen Schritt zu gehen oder man ignoriert tatsächlich die Probleme und ist davon überzeugt eine 1a Lösung zu haben : .
Auf jeden Fall bietet man lieber bunte Displays, Touchfunktionalität, Apps und schon fast lächerlich viele Soundfunktionen (es scheinen die Ideen aus zu gehen?) und zeigt sich "modern", "innovativ" und "fortschrittlich". Für mich teilweise nur Augenwischerei, - darum habe ich mich auch schon vor mittlerweile 12 Jahren von diesen Systemen abgewandt und bereuhe es bis heute keine Sekunde!

Gruß,
Marius


MariusS

RE: Mfx und DCC

#47 von Erich Müller , 04.04.2018 07:48

Zitat

Für mich teilweise nur Augenwischerei, - darum habe ich mich auch schon vor mittlerweile 12 Jahren von diesen Systemen abgewandt und bereuhe es bis heute keine Sekunde!



Und deshalb musst du hier wortreich niedermachen, was du seit 12 Jahren verlassen oder gar noch nie in der Hand gehabt hast...

Meine Nachbarin meckert seit 12 Jahren über ihren Ex-Mann. So lange ich sie kenne, seit sie wieder geheiratet hat und hier hergezogen ist.
Ich hab ihr mal gesagt: "Greg hier, Greg da... Tom ist zu bedauern, denn er muss sich ständig anhören, dass du noch so an Greg hängst und nicht an ihm."
Als müsste sie sich selbst dauernd davon überzeugen, dass es richtig war, Greg zu verlassen...


Freundliche Grüße
Erich

„Es hat nie einen Mann gegeben, der für die Behandlung von Einzelheiten so begabt gewesen wäre. Wenn er sich mit den kleinsten Dingen abgab, so tat er das in der Überzeugung, daß ihre Vielheit die großen zuwege bringt.“
Friedrich II. über Fr. Wilhelm I.


Erich Müller  
Erich Müller
ICE-Sprinter
Beiträge: 6.319
Registriert am: 03.12.2015


RE: Mfx und DCC

#48 von 1001-digital , 04.04.2018 10:20

Hallo Marius,
es ist grade eine große Stärke von DCC, dass solche Erweiterungen wie Railcom integriert werden können. 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. Ich kann den wutentbrannten Aufschrei der versammelten Hobbykollegenschaft deutlich hören. Sehen wir es doch mal realistisch, ohne Abwärtskompatibilität wäre Digital heute bei weitem nicht so verbreitet wie es ist. Mit einigen Kompromissen muss man dabei eben leben.

Zitat
Darüber lässt sich natürlich streiten, liegt aber in erster Linie an der Struktur, die zugrunde gelegt wird. Wenn man es schlecht macht, wahllos in der Gegend herum sendet, mag das zutreffen. Mit einer entsprechenden Systematik ist das aber überhaupt kein Problem und kann enorme Vorteile bringen, wie ich sie schon angedeutet habe.
(ein etwas weit hergeholter Vergleich aus unserer heutigen Zeit: Car-to-Car-Communication)


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. Hinzu kommt, dass auch die Hardware deutlich leistungsfähiger und damit teurer werden müsste. Und wozu? Ein Raspberry Pi kostet z.B. um die 40 € und kann diese Aufgaben problemlos bündeln. Ausreichend leistungsfähige Busse gibt es zuhauf, man muss sie nur einsetzen. Aber klar, solange noch Schieberegister als Bus eingesetzt werden (Stand der Technik vor ca. 30 - 40 Jahren!), solange wird es Probleme geben.

Zitat
Hier lässt sich natürlich auch streiten, wobei nicht genau spezifiziert wurde was "größere" Informationspakete sind. -> nicht schlecht wäre z.B. eine unabhängige Rücksende-"Leitung", die fast ebenso viel Informationen transportieren kann, wie die Hin-"Leitung"


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.

Zitat
Trotzdem bleibt das Problem mit den Schaltströmen am Dekoder und durch den Cut-out.


Was für Schaltströme denn bitte?! Mit Railcom wird nichts geschaltet. Oder meinst du den Ladestrom der Kondensatoren nach dem Wiedereinschalten der Gleisspannung? Nur so als Denkanstoß: Ströme kann man begrenzen, im einfachsten Fall mit einem Widerstand...

Zitat
Ein dauerhaftes Senden macht wohl kaum ein Dekoder lange mit. Hier und da mal eine kurze Rücksendung geht vielleicht, aber wie sieht es aus, wenn bspw. pro Sendungsempfang auch 2 bis 4 Byte zurückgesendet werden?


Was willst du denn unbedingt dauerhaft senden? Mir fällt beim besten Willen kein Szenario ein, das das erforderlich machen würde.

Zitat
Weiteres Problem sind die sehr hohen Einschaltströme, die nach dem Cut-out entstehen können, wenn es an entsprechender Pufferung mangelt.


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

Zitat
Siehe Kurzschlussgefahr bei DCC-, MM-, mfx-, SX- Systemen wegen 18V TTL.


Was genau soll ich da sehen? Wo Plus und Minus sind, kanns Kurzschlüsse geben - egal ob mit 5, 15 oder 150 V. Und was genau hat das TTL hier zu suchen? Versuchen wir durch Fachbegriffe Kompetenz zu suggerieren?

Zitat
Übrigens ja auch bei Railcom, wenn der Cut-out nicht überall auf der Anlage komplett synchron ist und es durch brückende Wagen oder Loks zu einer Verbindung kommt. (mein persönliche Schlussfolgerung: Schlechtes Konzept!


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. Ich bin mir ziemlich sicher, dass sich die Entwickler damals durchaus Gedanken gemacht und die Optionen abgewogen haben. Ihre Entscheidung mag für dich nicht nachvollziehbar sein, aber das macht das Konzept noch lange nicht schlecht.

Zitat
Es wird hier und da etwas "hingebogen", um so eine Rückmeldung überhaupt zu ermöglichen -> Krücken-Lösungen, die bei alten Dekodern und Hardware zu einigen Problemen führen.)


Ja, unfassbar, dass technische Neuerungen nicht von uralter Hardware unterstützt werden. Mit meinem Volksempfänger kann ich kein Digitalradio mehr hören, Skandal! Nur mal zur Info: In den meisten Fällen kann man die unwilligen Decoder "Railcom-tolerant" machen, indem man sie etwas besser puffert. Das ist jetzt nicht sooo der große Akt, dass man deswegen Sturm laufen muss.

Zitat
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.


Man muss nicht zwingend alles erneuern. Speziell die Lokdecoder können durchaus drinbleiben, man kann auch einfach zusätzlich einen Railcom-Sender einbauen. Und wer nicht gleich alles umrüsten will, kann seine Loks ohne Railcom immernoch erstmal parallel mitlaufen lassen.

Für die Hersteller hätte ein komplett neues System auch einen erheblichen finanziellen, materiellen und personellen Aufwand bedeutet. 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.

Viele Grüße
Carsten


 
1001-digital
InterCity (IC)
Beiträge: 806
Registriert am: 16.07.2015


RE: Mfx und DCC

#49 von MariusS ( gelöscht ) , 04.04.2018 10:40

Hallo,

@Erich:
[quote="Erich Müller" post_id=1818316 time=1522820897 user_id=26147]

Zitat

Für mich teilweise nur Augenwischerei, - darum habe ich mich auch schon vor mittlerweile 12 Jahren von diesen Systemen abgewandt und bereuhe es bis heute keine Sekunde!



Und deshalb musst du hier wortreich niedermachen, was du seit 12 Jahren verlassen oder gar noch nie in der Hand gehabt hast...
[/quote]
Niedermachen muss ich doch garnicht und mache ich auch nicht, dass erledigt sich, wenn schon, von selbst oder machen andere schon, indem sie nicht schweigen und die Probleme ansprechen. Ich habe zu Beginn fast nur mit Zitaten aus der bestehenden Diskussion geantwortet und mit meinen bestehenden Kenntnissen ergänzt, die ebenfalls aus Unterhaltungen mit anderen Mobahnern stammen. (Ich lese eben auch hier und da einmal gerne mit)
Die negativen Kritiken kamen zunächst von anderen, die diese auch zu Recht äußern, weil sie die Probleme richtig erkannt habe. Ich habe dann nur die eigentliche Ursache für das Entstehen dieser Probleme gezeigt und mich auch nur desshalb für einen Einstieg in die Diskussion entschlossen, weil ich eine Konsequenz vermisst habe.
Wenn man ein Problem erkennt, dem dann auf den Grund geht und die Ursache sieht, dann sollte man das auch ansprechen können, - dann die Konsequenz ziehen und evtl. umdenken.
(Ganz prakmatisch gesehen: "Probleme", die sich nicht ändern oder lösen lassen, existieren auch nicht. Warum sollte man sich mit Problemen herumschlagen, auf die man null Einfluss hat? Es macht auch keinen Sinn sich Tag für Tag über die größe der Erde zu beklagen, wenn das für jemanden ein Problem darstellen sollte. Die Existenz so eines Problems kann dann gut und gerne vernachlässigt werden.)

Was meinst du was ich mir schon alles anhören durfte, wie schlecht, veraltet/unmodern und ungeeignet meine und andere Lösungen/Systeme sein!? "Nur DCC- oder Märklin-Systeme sind das wahre, die haben die bessere Technik, sind flexibler, können viel mehr und und und..."
Da fand gar keine sachliche Diskussion statt, man hat einfach "niedergemacht", ohne davon nur den Hauch einer Ahnung zu haben. Sachlichkeit = 0. Probleme verschweigen, um das eigene System besser darzustellen stand an der Tagesordnung.
Besonders krotesk, wenn teilweise die gleichen Leute, die ihr System in den Himmel loben und regelrechte Glaubenskriege fechten, in Diskussionen mit Gleichgesinnten über dieses und jenes Problem jammern und sich hier und da beklagen. ??? - so können sich die Hersteller natürlich zurücklehnen und müssen nichts ändern.

Die Marktmacht hat gerade hier beim Hobby doch nun wirklich der Kunde und ich kann nicht verstehen, wie man auf der einen Seite die ganzen Probleme kennt und diskutiert, auf der anderen Seite aber nicht reagiert. Wie gesagt das Thema Rückmeldung wäre ein guter Zeitpunkt gewesen, einen Schritt zu wagen, aber der Zug scheint wohl abgefahren zu sein.
Ich habe es damals versucht, nur wurde mir aus den eigenen Reihen (andere Mobahner) enormer Gegenwind entgegen gebracht und man hat lieber die Augen verschlossen und macht das auch heute noch so.

Ich gebe zu, dass es mir hier und da auch eine gewisse Genugtuung bereitet von diesen Problemen zu lesen, weil ich eben selbige auch schon erkannt hatte und dies nur zu oft als Quatsch abgetan wurde.
Ich meine eigentlich bringt mir so eine Diskussion recht wenig, anderen könnte sie aber die Augen öffnen und so einen entsprechenden Druck bei den Herstellern erzeugen?

@Stephan:
Ich habe mich heute auf ?deiner? Seite umgesehen, die du in deiner Signatur stehen hast.
https://www.opendcc.de/
Die Seiteninhalte sind sehr interessant und ehrlich, das gefällt mir sehr. Auch die Ideen finde ich ansprechend.
Eine Frage stellt sich mir nun aber doch. Einige meiner Kritikpunkte an Railcom, - eigentlich an DCC-Systemen, denn Railcom trägt diese Probleme in erster Linie ja nur fort - werden sogar explizit so auf deiner Seite genannt. Andere kann man zwischen den Zeilen herauslesen. Das ist schön und zeugt von einer nüchternen ehrlichen Betrachtung.
Hier ein paar bsp. Zitat:
"Bei einer gemischten Verwendung von Boostern mit BiDi und solchen ohne BiDi ergibt sich ein Kurzschluß, wenn während der Cutout diese Booster über ein Fahrzeug verbunden sind. Man muß also die Anlage komplett umstellen.
Es fehlt noch ein genaueres Timing der Cutout, wenn mehrere Booster installiert sind. Wenn der Ausgang zweier Booster verbunden ist (z.B. durch eine Lok über der Trennstelle), dann kann es sein, dass ein Booster noch Signal erzeugt, während der Nachbar bereits Cutout macht. Da könnten dann zwei Treiber gegeneinanderstehen. Also müßte die Spec noch um eine kurze Totzeit ergänzt werden, in der jeder Booster abschaltet, d.h. der Cutout muß eine kurze Idlezeit vorangehen bzw. folgen.
"

"Bisherigen Beobachtungen zufolge weichen einige bereits verfügbare Booster (offenbar wegen Kompatibilitätsproblemen mit Dekodern) von der 26µs/30µs Empfehlung ab und starten mit der Cutout z.B. erst 38µs nach dem Endebit."

"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!). Dieser hohe Einschaltstrom entsteht primär durch eine zu geringe Abblockkapazität und fehlende Bedämpfung im Dekoder / in der Lok. Wenn die Abblockkapazität zu klein ist, fällt in der Cutoutzeit die interne Spannung des Dekoders zu weit ab und am Ende der Cutout kommt es dann bei fehlender Bedämpfung zu einer extremen Einschaltspitze. Diese Einschaltspitze kann fallweise Booster zu einer Überstromabschaltung bringen
."

"Beim Rücksenden der Daten sieht man sich einer Reihe von Schwierigkeiten gegenüber:
Ein mobiler Dekoder hat normalerweise keine eigene Energiequelle, die Rücksendung muß also aus zwischengespeicherter Energie gewonnen werden.
"

"Es sind fallweise viele Verbraucher vorhanden, welche die Leitung im Rücksendefall belasten. Glücklicherweise sind diese Verbraucher i.d.R. über Dioden abgetrennt, so dass zum einem bei einem niedrigeren Spannungsniveau kein Strom fließt (da die hinter den Dioden liegenden Lade-C's noch voll sind) und zum anderen erst ab einer gewissen Mindestspannung überhaupt erst Strom fließt. Probleme entstehen daher hauptsächlich durch direkte ohmsche Verbraucher , wie z.B. Zugbeleuchtungen und leitende Achsen. Deshalb ist der zulässige Spannungsabfall an einem Detektor auf 200mV (bei einem Strom von 34mA) begrenzt."


Quelle

Wenn das alles und noch mehr schon bekannt ist, warum findest du dann, dass das so wie jetzt eine gute Lösung ist?
Warum denkt man nicht um? Ich meine das DCC-Protokoll, also die Bit-Struktur würde slbstverständlich bleiben, nur die technik des Systems müsste sich ändern.
Man sieht die Probleme, kennt auch die Schwierigkeiten für zukünftige Änderungen und Erweiterungen, will aber trotzdem dabei bleiben?
Oder ist es schlicht und ergreifend der Grund, dass weniger Interesse seitens der Hersteller besteht, Neuerungen herauszubringen, die zu keinen Kompatibilitätsproblemen mit alten Produkten führen?
-> klar verkauft man mehr, wenn bei Neuerungen auch vieles der bestehenden Hardware getauscht werden muss.

Interessant auch, was man in einem Kommentar auf der Seite lesen kann. Hier fordert der Autor genau das, was ich oben auch Erich geschrieben habe, was bei Problemen zu tun ist.
"Kommentar: über die Gründe kann man rätseln. Technisch wäre es ein elegante Möglichkeit gewesen, die vorhandenen Designfehler beim Channel 1 zu umschiffen und zugleich hätte es einen erheblichen Kundennutzen gebracht. Ich kann die Anwender eigentlich nur ermutigen, bei den Herstellern auf diese Probleme hinzuweisen und Abhilfe einzufordern."


Da meine Kritk hier nicht gerne gesehen wird, bin ich jetzt wieder raus...

Viel Spaß weiterhin, wünscht euch,
Marius


MariusS

RE: Mfx und DCC

#50 von supermoee , 04.04.2018 11:14

Zitat

Wie kommst Du den darauf?
Bei OpenDCC, Digikey, Roco und Tams gibt es günstige Railcom-Komponenten.
Railcom verbreitet sich immer mehr.



Hallo Stephan,

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.

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.



Hallo Alf,

ok, das Argument lass ich gelten. Bei mfx kann man Mehrfachtraktionen in der Zentrale bilden und auflösen, aber das geht nicht bei allen Zentralen. Dekoderseitig ist das natürlich zentralenunabhängig. Ich brauche die Funktion nicht, da meine Zuglängen keine Doppeltraktionen rechtfertigen und meine Personenzüge im festem Verband fahren und nie rangiert werden und daher eine abschaltbare Innenbeleuchtung nicht relevant ist.

Also die Vorteile von DCC gegenüber mfx, wenn es der Dekoder untserstü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.

Gruss

Stephan


Der Trend geht deutlich zur Zweitanlage hin.


supermoee  
supermoee
Tankwart
Beiträge: 13.696
Registriert am: 02.06.2006
Gleise Maerklin K Gleise / Kato N / Fleischmann N / Peco N
Spurweite H0, N
Steuerung Maerklin CS3 2.4.0 / Fichtelbahn BiDiB
Stromart Digital


   


Xobor Einfach ein eigenes Forum erstellen
Datenschutz