THEMA: Passender Decoder für alte Minitrix Loks

Hallo Alfons,
da bist du ja an nen echten Fachmann geraten... Die ESUs sind mit Abstand die schlechtesten Decoder, die mir bisher untergekommen sind. Die Regelung ist schlicht eine Katastrophe. An deiner Stelle würd ich die Dinger zurückbringen. Gute Erfahrungen hab ich dagegen mit Tran und Zimo gemacht. Fährst du eigentlich SX oder DCC? Der Rautenhaus kann ja beides, wobei DCC eher unter "kann er auch" läuft, er aber einen reinen DCC-Decoder nicht ganz erreicht. In Sachen Regelung machte er auf meinem Prüfstand auf jeden Fall keine schlechte Figur.

Viele Grüße
msfrog von 1001-digital

Hallo Alfons,

hast du mal die automatische Motoreinmessung des LoPi 4 probiert?
http://www.1zu160.net/scripte/forum/forum_show.php?id=570564

Die Firmware sollte aber möglichst aktuell sein, wenn du keinen Lokprogrammer hast einfach mal deinen Händer fragen.

Grüße
Winnie

Hallo msfrog von 1001-digital ,
jetzt halte mal den Ball flach.Hast du die ESU Decoder mal getestet und mit anderen verglichen ?aber die Aussage :
<Der Rautenhaus kann ja beides, wobei DCC eher unter "kann er auch" läuft, er aber einen reinen DCC-Decoder nicht ganz erreicht. >
fällt bei dir wieder Einmal unter Unkenntnis oder Halbwissen. Die Rautenhaus RMX Decoder sind doch auch DH- Decoder und haben auch unter DCC die SSD Regelung ( Super-sorft- drive), denn wie dir schon von verschiedenen Leuten ( die was von der Meterie verstehen) hier bestätigt wurde, sind das Decoder von D&H und diese haben alle SSD, egal ob sie DHP ; DH ; Trix, Viessmann oder RMX in der Bezeichnung haben, an dieser Motorregelung muß erst mal ein "reiner DCC Decoder" herankommen.
LG Röhricht
Modellbahnservice

Hallo,
wer Probleme hat unter DCC einen Motor richtig einzustellen,
und sich nicht schlüssig ist welches System er bevorzugt,
ist mit den Decodern von Doehler & Haass,
und dessen Derivaten (Rauthenhaus; Trix; manche Viessman; etc...),
ganz gut beraten.
Wobei man sich auf RMX von Rauthenhaus festlegen könnte,
und wäre damit von einem einzigen Anbieter abhängig.

Ich empfehle die neueren DH 010 und DH05.

Die ESU-Decoder nur in Loks verwenden,
bei denen man sicher ist,
dass beider Motorregelung, nicht nachgestellt werden muß.
MEIN Fazit:
Bei den ESU locmicrobruchpilot (oder wie diese verd... Mistdinger auch heißen),
kann man unheimlich viel einstellen,
nur eben nicht den PID-Regler des Motors.
Eine Katastrophe!! -Daumen tief nach unten!-

Wer DCC fährt ist mit dem Tran CT DCX75 gut bedient.
Ein bisserl Interesse und Freude am Einstellen der CV´s,
wenn man ältere Lokomotiven hat,
sollte man schon mitrbringen.

Das großte Marktsegment bietet DCC mit vielen Anbietern.

Hans-I.

Also ich bin noch am Anfang und die Anlage ist noch Analog!
Ich habe mich für Selectrix entschieden und der LokPilot
kann ja auch Beides!
Das automatische Einmessen habe ich gemacht, damit fährt
die 64er ja auch sogar recht vernünftig, nur das Motorgeräusch
passt eher zu einer  Zahnradbahn als zu einer Dampflok.
Einen weiter ESU habe ich in eine FLM 62er eingebaut, läuft wie Samt
und Seide! Werde also den DH10 wenn ich ihn habe einmal in der 64er
testen.
Mfg. Alfons

Hi Alfons!

Ob das nicht vorrangig an der Lok selbst liegt?
Hast Du sie denn mal analog gefahren und gehört? Ich kann dazu nur sagen, dass meine beiden 64er so ziemlich das lauteste sind, was ich habe und das ändert sich, im Gegensatz zu dan alten Arnolds (die von Haus aus auch recht laut sind und mit Decoder deutlich erträglicher werden), bei den 64ern überhaupt nicht (ausprobiert mit Decoder am Gleis angeschlossen und so die analoge 64 fahren lassen).
Darum sind die auch von mir vom Decodereinbau ausgeschlossen worden.

Viele Grüsse
Mathi

Hallo Röhricht,
schön ein weiteres Mal von Ihnen zu lesen!


Im Gegensatz zu Ihnen (Stichwort Pufferkondensator) teste ich solche Sachen auch mal, bevor ich im Forum was zerreiße. Und wie man sieht, bin ich mit meiner Meinung über die ESU-Teile nicht allein. In meiner Fleischmann-V60 (Ost) tut ein LoPi seinen Dienst - gerade noch akzeptabel. In einer Brawa BR118 dagegen ist der ESU eine echte Krücke. Beim Anfahren macht die Lok manchmal erstmal einen Satz nach vorn eh sie langsam anfährt. Drehe ich den Regler auf 0 behält die Lok bei Höchstgeschwindigkeit noch eine ganze Weile ihre Geschwindigkeit bei, ehe sie abbremst. Verwende ich stattdessen einen Tran oder Zimo (getestet mit SL75 und MX620), sind beide Fehler sofort verschwunden.


Es geht dabei nicht um die Regelung, die ist in Ordnung. Im Gegensatz zum ESU kommt der Rautenhaus auch ohne Fummelei an den CVs mit meinen Problemmotoren am Prüfstand klar. Der RMX990A ist trotzdem ein SX-Decoder mit DCC-Fähigkeiten, ihm fehlt z.B. die freie Geschwindigkeitskennlinie und auch einige Effekte für die Funktionsausgänge. So lassen sich z.B. die Funktionsausgänge nicht fahrtrichtungsabhängig machen, abgesehen von Lv und Lh. Deswegen schrieb ich, dass er einen reinen DCC-Decoder nicht ganz erreicht.


Wie schon geschrieben bin ich mit der Regelung zufrieden. Aber um mal ein Beispiel zu nennen, wie eine gute Regelung bei DCC-Decodern aussieht, empfehle ich Ihnen mal einen Tran oder Zimo zu testen. Die sind in meinen Augen bisher unerreicht, was die reinen DCCler angeht.

Viele Grüße
msfrog von 1001-digital

Nun,
wenn die GFN 62 mit dem ESU Decoder nun wie "Samt und Seide" läuft.

Dann sage ich. "Respekt an den Schneider!".

MfG
Hans-G. Kerner

Hallo msfrog,
<Im Gegensatz zu Ihnen (Stichwort Pufferkondensator) teste ich solche Sachen auch mal, bevor ich im Forum was zerreiße.>
na das mit dem testen hat wohl nicht so ganz geklappt ?
<So lassen sich z.B. die Funktionsausgänge nicht fahrtrichtungsabhängig machen, abgesehen von Lv und Lh. >
Falsch , denn siehe BA DH10-a-x / DH05-A-x unter unter par 75 oder cv 47 - AUX Ausgänge richtungsabhängig
und das funktioniert.
Motorkennlinien stehen 7 unter par 51 oder cv 48 zur Auswahl , dazu ist noch die Anfahrspannung unter par 14 oder cv 2 einstellbar bzw. unter par 53 oder cv 49 die Impulsbreite zur Motoranpassung, damit lassen sich die verschiedensten Motoren optimal anpassen.
LG Röhricht
Modellbahnservice

Hallo Röhricht


Wer lesen kann ist klar im Vorteil. Ich beziehe mich ausdrücklich auf den RMX990A, von denen mir Herr Radtke freundlicherweise 2 Testmuster leihweise zur Verfügung gestellt hat. Wie Ihnen als SX-Händler hoffentlich bekannt ist, haben die RMX-Decoder eine andere Firmware als die hardwareseitig identischen D&H-Modelle. In der Anleitung der RMX990A finde ich keinen Hinweis in den CV-Listen, dass ein Ausgang abhängig von der Fahrtrichtung geschaltet werden kann, wie das z.B. bei Tran mit den CVs 154 ff. mit den Bits 6 und 7 bewerkstelligt werden kann. CV47 ist beim RMX990A gar nicht aufgeführt.


Sie werfen wie bei den Pufferkondensatoren schon wieder mehrere Dinge in einen Topf. Eine freie Geschwindigkeitskennlinie ist keine Motorkennlinie. Üblicherweise verfügen DCC-Decoder mit den CVs 2, 5 und 6 über eine Drei-Punkt-Kennlinie, mit der Startgeschwindigkeit, Mittengeschwindigkeit und Höchstgeschwindigkeit eingestellt werden können. Zusätzlich kann in den CVs 67 - 94 eine freie Kennlinie angegeben werden, mit der diese Einstellungen wesentlich feiner gemacht werden können. Der RMX990A bietet diese Möglichkeit nicht. Die Motorregelung ist dann nochmal eine ganz andere Baustelle, die aber auch gar nicht zur Debatte stand.

Viele Grüße
msfrog von 1001-digital

Hallo Jungs,

Ich möchte nun auf keinen-Seite stehen, aber ich hab, Alfons, mit dem D&H DHP160 sehr gute Erfahrung gemacht. Natürlich kann ich nicht sagen, wie ein anderer läuft, aber bis auf EINEN Ruckler beim Hochbeschleunigen ist das Ding eine feine Sache! Er lässt sich bestens programmieren und hat auch viele Einstellmöglichkeiten (zB Motor-, Licht-, Funktionsausgang lassen sich einzeln vertauschen).
Bitte, Röhricht und Carsten, versteht das jetzt nicht parteiisch, aber der Dec. gefällt mir eben und ich würde ihn wieder einbauen (lassen )

Daher Zwischenfrage an Röhricht: Wann nehme ich welchen Dec. von D&H, was für Unterschiede muss ich beachten, passen die D&H vom Steckerdurchmesser in die Normschächte der Fahrzeuge oder gibt es leichte Komplikationen?

Alfons, kann das Ding nur empfehlen!

Grüße von
   Phips

Ohne mich in die Frequenz etc. Diskussion einmischen zu wollen, kann ich Dir sagen dass ich auch bei älteren MTX Loks (CC6500 in den versch. Versionen, BR 184.1, etc. immer mit Kühn N025 am Besten gefahren bin.

Wenn nu die Lok schon vorher nicht gut läuft, dann ist es ein Irrweg zu glauben dass ein Dekoder, das gross ändern kann. Denn Probleme mit der Stromabnahme sind konstruktionsbedingt, und ausser wenn der Dekoder einen Strompuffer hätte, was in N mehr als kompliziert ist, dann bleibt eine schlecht fahrende Lok, normalerweise eben dies, eine schlechtfahrende Lok.

Ich würde sie dann eher in der Bucht entsorgen, als da nochmals Geld zu investieren, oder ggf. die Lok schon im Analogbetrieb sowei zu optimieren, dass sie fährt, und dann umzubauen.

MFG

Patrick-Madrid

Hallo msfrog,
ehe hier weiterin der Eindruck entsteht ich bin des lesens nicht mächtig und spinne mir was zusammen.
Hier war nach dem DH10-A-x gefragt und nicht nach dem RMX990A.
Wie sie ja wissen sind diese Decoder up-datefähig, dann ziehen sie sich doch die neuesten Decoderup-dates (V1.02) auf ihre  Decoder und siehe da der Röhricht kann doch lesen und hat das sogar schon getestet und es funktioniert.
BA der Decoder zum nachlesen.
http://doehler-haass.de/cms/media/pdf/DH05A_DH10A.pdf
LG Röhricht
Modellbahnservice

Hallo Herr Röhricht,
wenn Sie mich ansprechen und ich D&H mit keinem Wort erwähnt habe sondern vom RMX schrieb, ist es schon etwas befremdlich, wenn Sie mich mit Argumenten, die nur auf die D&H zutreffen, festnageln wollen. Ich hab langsam den Eindruck, dass Sie mich seit der Kondensator-Diskussion "gefressen" haben und mich mit aller Macht bloßstellen wollen. Das führt doch zu nichts. Falls Sie dazu noch was zu sagen haben können Sie mich gerne anmailen oder meinetwegen auch nochmal anrufen.

Hallo Phips,
warum sollte dir jemand vorschreiben wollen, welchen Decoder du zu nehmen hast? Hier kann man nur seine eigenen Erfahrungen zum Besten geben. Wenn du mit den Decodern zufrieden bist, wär es doch Quatsch was anderes zu nehmen :)

Hallo Alfons,
erstmal bitte ich um Entschuldigung, dass der Thread etwas abgeglitten ist. Da du Selectrix fährst und schon RMX-Decoder hast, würde ich dir empfehlen bei Rautenhaus zu bleiben. Das System macht auf mich einen recht guten Eindruck und Herr Radtke leistet auch einen guten Support, falls es mal zu Problemen kommt. Vor allem weiß er im Gegensatz zu manchem "Fach"-Händler wovon er redet. Deiner wollte jedenfalls nur seinen ESU-Kram an den Mann bringen. Die Rautenhaus-Decoder spielen ihre größten Stärken erst im Zusammenspiel mit der Rautenhaus-Zentrale aus. Wenn du noch keine hast, sollte das also vielleicht deine nächste Anschaffung werden.

Viele Grüße
msfrog von 1001-digital

Hallo,

im Ausgangsposting wurden sowohl Rautenhaus als auch DH angesprochen.

Fakt ist, die fahrtrichtungsabhängigen Funktionen leiden allgemein am Standardisierung-Problem bzw. eben an der Nicht-Standardisierung. Bei "reinen" DCC Decodern gemäß NMRA Norm war das nie definiert, somit warten nun viele Hersteller mit einer eigenen Lösung auf. Leider.

Welcher Decoder ist nun "rein"? Einer, der an der NMRA Norm fest hält oder einer, der die Featuritis frönt? Die Beurteilung ist in höchstem Maße subjektiv.

D&H bietet nicht wirklich eine wahlfreie Parametrisierung von richtungsabhängigen Ausgängen, sondern eine zusätzliche Richtungsabhängigkeit der Taste F1 nach System Lenz.
Bei ESU, Tran und Zimo gibt es wieder andere Ansätze.

Solange wir bei der Funktionsmatrix auf CV- bzw. PA-Sätze angewiesen sind, ist die Umsetzung einer universellen Lösung schwierig.

Grüße, Peter W.

Hallo Carsten, #14,

Man kann ja auch mal etwas anderes ausprobieren, aber das muss nicht sein. Ich wollte es Alfons nur erzählen, denn bei mir sind die auch in alten MTX-Dampfern verbaut (Bj ´86).

Viele Grüße von
   Phips

Hallo Digital-Kenner,

Weil ich gerade als DCC-Multimaus Anfänger suche nach einen passenden DCC-decoder für meine MTX V36.325 (Artnr 12535) mit NEM-Schnittstelle, hatte mich fast zur ESU Lokpilot 4.0 Micro  DCC entschlossen.

Aber.... Wenn ich Euere Meinungen über ESU höre, ist das glaube ich nicht die richtige Wahl....

Wer von Euch hat gute Erfahrungen (also am liebsten Plug-und-Play) mit welchem DCC Decoder in Zusammenhang mit MTX V36.325 (Artnnr 12535)?

Und, sind Euere Erfahrungen mit ESU Lokpilot 4.0 tatsächlich so schlecht wie ich hier verstehe?

Viele Grüße aus NL,

Bert

Hallo Bert,
ohne es vor dem Kauf zu testen würde ich keinen ESU mehr nehmen. Meine Lokpiloten waren mir da eine Lehre. Gute Erfahrungen habe ich bisher mit Tran und Zimo gemacht, die haben bei mir noch jeden Motor zum Laufen gebracht, ohne dass ich etwas an der Regelung einstellen musste. Du kannst dir wegen der technischen Daten der verschiedenen Tran-Decoder ja mal ein Bild auf unserer Webseite machen:
http://www.1001-digital.de/pages/lokdecoder.php
Zimo habe ich leider noch nicht drauf. Bei Tran musst du aber auf die Gleisspannung achten. Da die Decoder sehr klein sind, vertragen sie keine hohen Spannungen. Mit ca. 15 V Gleisspannung laufen sie aber perfekt.

Viele Grüße
msfrog von 1001-digital

Hallo Bert
meine Meinung: es muss nicht immer unbedingt alles schlecht sein, jedoch habe ich mit anderen Decodern bessere Erfahrungen gemacht.
Was man bitte auch berücksichtigen soll und was hier bzw. oft etwas übersehen wird: wenn es einen guten Decoder gibt, dann heißt das noch lange nicht, dass dieser Decoder mit allen Loks bzw. Motoren bestens zurecht kommt. Es gibt durchaus Decoder, die in einer Lok wunderbar laufen und in anderen Loks erhebliche Probleme machen.
Auch wenn ich persönlich z.B. die Decoder von Zimo immer sehr lobe, heißt das noch lange nicht, dass ich diese für jede Lok empfehlen würde. Wobei ich aber da die Aussage von msfrog aufgreifen möchte bezügl. "ohne dass ich etwas an der Regelung einstellen musste". Und genau das ist ja der Knackpunkt. Decoder rein und die Lok MUSS laufen. Und genau das ist bei Zimo der Fall.

Zur V36 kann ich aber leider nicht viel sagen, da ich diese noch nicht mit Decoder ausgerüstet habe. Vielleicht melde sich ja noch jemand anderes und kann hier noch ein paar Tipps geben.

Viele Grüße
Tomi (der sich über manche Aussagen hier mal wieder köstlich amüsiert hat )

Gute Betrachtungsweise!

Hallo Bert,

ich habe in meiner den Trix 66838 eingebaut, die Lok fährt damit hervorragend. Ich denke mal, mit einem Tran oder Zimo würde sie genau so gut fahren, aber ich habe keine Lust, das Gehäuse nochmal abzumachen, um es auszuprobieren. Ist halt eine sch.... Angelegenheit.

LG

Berti

Hallo,

da der 66838 nun echt preislich überteuert ist, habe ich nun die neuen DH10 in einigen anderen Loks eingelötet.
Vt 62 von Trix...das Uralt-Modell mit der Artikelnummer 51 2096 00.....das bekommt der DH10 gut geregelt.
V36  #12625...auch dort ein gutes Verhalten des DH10.

GFN 64 ...da sieht man kaum dass sich die Lok bei Fahstufe 1 bwegt...Zehntelmillimeter schleicht die Lok dahin.

So ein DH10 kostet so um die 28€...ein 66838 kostet in die 40€ rein.

Nur mal so mein bescheidener Beitrag

Gruß
Andy

Hallo liebe Digitalisten, oder wie darf ich euch nennen?
Ich habe mich bisher kaum mit dem Digitalisieren befast. Aber in unserem Verein soll nun unsere H0 und teilweise die N-Anlage mit Digitalloks betrieben werden.
Als wir abstimmten wurde bei 16 zu 4 Stimmen für Digital entschieden.
Ich selbst habe kontra gestimmt weil ich immer wieder hier über Probleme damit gelesen habe.
Für mich als Digitallaie solte es so sein, einen Decoder einstecken, nichts mit löten, an ein digitalfahrpult anschließen, und ab sollte die Post gehen.
Da dies aber wohl nicht der Fall ist, bleibe ich privat weiterhin beim Analogbetrieb, denn auch dieser Thread gibt mir keinen Anlaß auf Digital zu wechseln.
Ist eigentlich schade, denn ich dachte mit Digital geht alles Besser. Will sagen, 2 Kabel an die Schienen, einen beliebigen Decoder in das Fahrzeug bzw. an die Weiche und es sollte laufen.
Lieben Gruß
Gerd

Hallo Gerd,
bei einer Lok mit Schnittstelle steckst du den Decoder auch nur rein und musst nix löten. Wenn du vernünftige Decoder kaufst, wirst du in 99 % der Fälle auch hier kein Problem haben. Für das restliche Prozent nimmt man eben einen anderen Decoder oder spielt ein bisschen mit den Einstellungen. Das Problem ist, dass die Leute sich alles verkaufen lassen, nur weil ein selbsternannter Fachhändler es sagt. Gut, man kann ihnen nicht direkt einen Vorwurf machen, aber ein bisschen belesen sollte man sich vor dem Einkauf schon. Ich gestehe.. Ich habs damals auch nicht gemacht, ich hab einfach die günstigsten Decoder verlangt, die da waren und das waren leider ESU :)


Tja, bei einer kleinen Anlage stimmt das auch. Bei größeren hat man aber mehr Aufwand. Die Digitaltechnik erleichtert schon vieles, aber Wunder vollbringt sie nicht. Die Physik setzt da einfach gewisse Grenzen, die man dann eben anderweitig umgehen muss. Und so lange die Hersteller irgendwelche 10-Cent-Billiggurken als Motoren verbauen, so lange wird es auch Decoder geben, die damit Probleme bekommen. Einen Glockenanker z.B. treibt sogar der ESU vernünftig an.

Viele Grüße
msfrog von 1001-digital

Hallo Gerd

siehe meine Anmerkung in @19:

ansonsten stimme ich den Ausführungen von Carsten in @24 voll und ganz zu.

Bezügl. "bei größeren Anlagen mehr Aufwand" ist zu sagen, dass es immer darauf ankommt, was man möchte. Ich hatte eine vollautomatische analoge Anlage, die so "vollgestopft" mit Technik war, dass die Kosten leicht über denen lagen, was es heute mit der Digitaltechnik kosten würde. Was ich damit sagen möchte: je nach Anforderung des Modellbahners variieren die Kosten sehr stark. Daher kann man nicht pauschal sagen, ob das eine oder das andere besser, billiger oder sonstwas ist. Man muss immer jeden einzelnen Fall beurteilen.

Gruß
Tomi

Hallo nochmal,

Erstmals Danke für die Hilfe bis jetzt



Und das ist eben das Problem der Digital-Anfänger:  Wie unterscheidet man einen Fachhändler von einen selbsternannter Fachhändler?   Ich denke die Fachhändler haben sich alle selbsternannt....

Für meinen Minitrix V36 gibt es also bis jetzt zwei Decoder-Lösungen die aus der 1zu160 Praxis keine Probleme geben: Minitrix 66838 (teuer) und DH10A (billiger), also DH10A sollte es dann werden?

Vielleicht hat noch jemand Erfahrungen?

Viele Grüße aus NL,

Bert

Hallo Bert

ein Fachhändler versteht etwas von seinem Fach. Das ist mal das Wichtigste.
Spaß beiseite. Ganz auffällig ist es, wenn ein Digitalanfänger in einem Ladengeschäft sofort eine digitale Startpackung angeboten bekommt, die auch noch im Schaufenster (oder Regal) liegt. Da sollten zuerst mal ein paar Fragen des Händlers kommen, damit er auch einschätzen kann, was der Kunde eigentlich möchte.
Wenn er dann Dinge anbietet, die nicht im Regal liegen, die er aber besorgen kann, siehts schon mal besser aus. Das bedeutet, dass er nicht unbedingt das los bringen möchte, was ihm vielleicht im Wege liegt.
Und dann sollte er sich am besten noch mit Details auskennen. Ich hatte mal ein nettes Erlebnis: ein Kunde fragte, welche Zentrale denn zum Schalten von Weichen geeignet sei. Die Antwort des "Fachhändlers": "Digital ist doch nur fürs Fahren der Loks. Die Weiche schaltet doch nur von gerade auf abzweig, da funktioniert kein Digital oder was meinen Sie, was die Weiche mit dem Digitalstrom anfangen soll? Das ist so ähnlich wie der Wechselstrom bei Märklin. Da ginge die Weiche eher kaputt".

.... ohne Worte...

Viele Grüße
Tomi

Hallo Bert,

ich habe meine V36 2005 gekauft und bin 2006 auf Digital umgestiegen, da war der Trixdecoder uptodate und ich habe mir seinerzeit mit Mengenrabatt ein paar zum Einstieg gekauft, heute würde ich auch den DH10 nehmen.

Gruß

Berti

Hallo Alfons,
in dem Fall solltest Du auch Decoder verwenden, die primär für Selectrix gebaut wurden. Wenn Du 'ne Banane essen willst kaufst Du Dir auch keinen Apfel, schnitzt ihn krumm und malst ihn gelb an.

Ernst beiseite: Die Selectrix-Decoder - auch die hier immer wieder zitierten aktuellen D&H-Modelle - bieten nur ein kleines Subset des bei DCC Möglichen. RailCom - Fehlanzeige. FunctionMapping mit wenigstens mal zwei richtungsabhängigen Funktionen - jetzt endlich verfügbar. Lenz ABC oder Zimo HLU oder andere kurzschlußfreie Bremsverfahren - Fehlanzeige!

Umgekehrt werden wohl die DCC-Decoder, die Selectrix unterstützen wahrscheinlich auch dort wiederum nur einen Bruchteil des Möglichen anbieten.

Das mag auch damit zu tun haben, daß, wie mir von anderen SLX-Nutzern berichtet wurde, die bei beiden Systemen verwendeten Verfahren hardwaretechnisch unvereinbar seien.

Ich kenne Selectrix nicht im Detail - warum auch, ich hatte mich seinerzeit für DCC entschieden.

Wenn Du mit DCC-Multiprotokoll-Decodern experimentierst: Vom ESU würde ich gerade in Bezug auf veraltete Motoren (gerade genutete Dreipoler wie z. B. bei Fleischmann selbst heute noch überwiegend anzutreffen) ebenfalls dringend abraten. Außerdem ist der ESU sehr empfindlich gegen kurze Unterbrechungen, d. h. die Pufferung der Daten im RAM ist wohl recht unzulänglich realisiert.

Gruß,
Torsten

Hallo,
es kommt auch darauf an,
was man mit DCC-Steuerung,
an seiner Lok,
sinnvoll einstellen will.

Meißt reicht die Möglichkeiten der DH-Decoder vollkommen aus.

Freilich Selektrix2 ist (noch) ein Randsystem,
über das die "Richtigen Digitaler" immer wieder nur spötteln.
Als wäre es ein Mrklin Haussystem....


Trotzdem oder besser, gerade deshalb, werde ich mit nun noch eine
Zentrale zulegen, die dieses Protokoll auch beherrscht.

Ältere reine SX-Decoder müßte man eigendlich billig in der EBucht angeln können.
Die kommen mit (fast) allen älteren Minitrixlok gut zurecht.
Wenn man sowieso für Selektrix entschieden hat,
kann man hier ganz schön sparen.

DCC ist zwar viel  langsamer,
diese Reaktonszeit von zehntel Sekunden,
sind bei der Eisenbahn "so was von egal..".

Hans-I.

Hallo Torsten,


Das gilt nur für reinen SX1-Betrieb! Wer erweitert, also noch SX2 im Körbchen hat, kann ziemlich genauso viel Einstellen wie unter DCC. Zudem ist das SX1.Format in der Übertragung schneller und hat weniger Datenmenge. Du kannst unter SX1 fahren und unter SX2 programmieren, die SX2-Werte werden in SX1 übernommen und du hast wieder eine kleine Datenmenge! Versuchs mal: Dreh einen Schienenbus per Regler Stufe für Stufe von Hand nach oben, und versuche dabei das Licht oder Soundfunktionen zu schalten. Resultat: Zusatzfunktionen wie eben genannt haben eine Verzögerung von bis zu 2 Sek. Das passiert bei SX1 nicht, ich habe es selbst ausprobiert!!!!!!!!

Bitte vesteh das nicht falsch, wenn du mit DCC zufrieden fährst ist das schön! Aber für Fragensteller, die noch nicht so ganz sicher sind im Terrain sollte auch bei Antworten auch Platz für andere Möglichkeiten sein!

Viele Grüße von
   Phips

Ich nochmal an Hans,


Das ist ja das Schlimme: Das neueste System in N und auch noch das Langsamste!

Warum ist das egal? Bei einer Lok oder bei 5 bemerkt man es vllt nicht sehr. Aber wenn zB bei Automatischen Anlagen mehrere Befehle vom Recher aus gleichzeitig weggehen, dann viel Gedult beim Abwarten! Da kannste nebenher noch groß auf´s Klo und ne Stange trinken!

Viele Grüße von
   Phips

Hallo Phips,
was ist da falsch zuverstehen?

Du bist auch schon ein "SX-Ritter".

Weiter SO!!
Hans-I.

Hallo Torsten@29,


Welche DCC-Decoder würdest Du denn in diesem Fall vorschlagen?

Viele Grüße aus NL,

Bert

Hallo,
ich hab mir auf der Messe in Karlsruhe einen Zimo und einen Tran besorgt und bin mit beiden im Vergleich zu Lenz Mini Silver und EsU allerdings noch die 3er Version sehr zufrieden. Meine Frage jetzt wo bekommt man die "Österreicher" denn am günstigsten? Mit welchen Bezugsquellen habt ihr gute Erfahrungen gemacht?

Björn

Hallo Björn,
versuche es doch mal beim Arnold Hübsch.

Hans-I.

Hallo Björn,
zumindest Tran-Decoder kannst du bei uns kaufen -> www.1001-digital.de
Wenn du Zimos mit bestellen willst, bietet sich aber der Shop von Arnold Hübsch an, da sparst du etwas Porto :)

Hallo Phips

Jetzt übertreibst du aber maßlos. Zudem ist je nach Zentrale eh bei einer gewissen Anzahl Loks Schluss. Bei SX sind das generell 103, glaube ich, bei DCC können, wenns die Zentrale hergibt, auch deutlich mehr gleichzeitig gesteuert werden. Und da die Loks nicht alle gleichzeitig neue Befehle bekommen, fällt die langsamere Übertragung nicht ganz so sehr ins Gewicht. Das ist einer der großen Unterschiede zwischen SX und DCC. Bei SX wird immer alles gesendet, für jede Adresse und jede Lok. Bei DCC werden die Befehle zwar auch wiederholt, aber bei einer Lok, die länger keine neuen Befehle erhalten hat, nicht mehr so oft.


Damit hat Torsten vollkommen Recht. Auch wenn man unter SX2 mehr Sachen einstellen kann, bieten die Multiprotokoll-Decoder nicht den kompletten Funktionsumfang von reinen DCC-Decodern. Einiges hat Torsten dazu aufgezählt, anderes steht in einem Beitrag von mir weiter oben. Das soll kein Schlechtmachen sein, aber wer die Decoder kauft sollte es wissen.

Viele Grüße
msfrog von 1001-digital

Hallo,
das eigendliche Problem,
ist nach meiner Meinung und Erfahrung,
der sog. Rad-Schienen-Kontakt.

DCC sendet bei Bedarf sein Datenpaket aus.
Der Decoder erkennt das Signal schlecht,
wenn bei der Gleisverlegung, der Sauberkeit
etwas nicht stimmt.
So kann es länger dauern bis der Decoder
das gesamte Datenpaket erkennt.

Bei Selektrix1 werden ständig wesentlich kürzere
Datenpakete übertragen.
Die Wahrscheinlichlichkeit dass ein Datenpaket
ankommt ist deshalb wesentlich größer.

Bei Selektrix 2 mit einem größeren Datenpaket
als bei Selektrix 1 wird sich, meiner Meinung,
dann ein ähnlicher Effekt einstellen wie bei DCC.

Je höher die Übertragungsfrequenz wird,
desto größer werden auch die Fehler im Datenpaket.
Da höhere Frequenzen viel leichter reflektieren,
und damit gedämpft werden.

Ergo: Bei einigermaßen sauber verlegtem
Gleisplanum wird man auch mit dem "langsamen" DCC
keine Probleme bekommen.

Etwas Anderes ist es mit  "Locobus" oder ähnliche.
Hier kommt es vorallem auf das handshaking an.

Man kann schon "Äpfel mit Birnen" vergleichen.

Hans-I.

Phips, bei allem Respekt, aber so einen Nonsens habe ich noch nicht gehört. Zu dieser Aussage erwarte ich jetzt Belege. Hast du das selbst schon auf deiner Anlage reproduzieren können?
Dass es bei den genannten Systemen Unterschiede gibt, dürfte den meisten Digitalbahnern, die sich etwas näher mit der Materie beschäftigt haben, klar sein. Aber man sollte sich schon darüber im klaren sein, dass hier keine Unterschiede wie zwischen Tag und Nacht zu erwarten sind.
Wer die von dir genannten Probleme hat, hat definitiv irgendwo anders einen Fehler, aber sicherlich liegts nicht am System.

und vor allem sollte man keine Aussagen machen, die Anfänger verwirren könnten.
Das was Profis vielleicht mit Messgeräten nachweisen können (das ach so "langsame" DCC...), ist für 99,9 % der Digitalbahner völlig uninteressant, da es sich auf nichts auswirkt.

Gruß
Tomi

Hallo,

DCC sendet nicht nur bei Bedarf, sondern wiederholt im Umlauf alle aktiven Adressen. Bei wenigen gleichzeitig aufgerufenen Adresse ist DCC sogar ein klein Wenig im Vorteil, da SX1 immer alle 112 Adressen sendet. Ein PC kann niemals mehrere Kommandos gleichzeitig senden, sondern immer nur nacheinander, da ein Interface nur einen Befehl nach dem anderen auf das Bussystem der jeweiligen Zentrale transponieren kann. Das schwächste Glied in der Kette ist dabei meistens das PC-Interface selbst.

Grüße, Peter W.

Hi!

Das erinnert mich an die 80er Jahre, wo man Festplatten mit schnelleren Zugriffzeiten (Millisekunden) beworben hat. Jeder Wannabe meinte nun, dass er sowas haben muss.
Die schnelleren Zugriffe haben sich allerdings nur per benchmarktest ermitteln lassen, im praktischen Gebrauch war da natürlich kein Unterschied feststellbar.
Aber, wie man sieht, solch ein Unsinn kommt heute noch gut an und fällt auf fruchtbaren Boden!!!

Viele Grüsse
Mathi

Hallo Hans, #33

Kann schon sein, ich denke aber auch, jedes Format hat seinen Vorteil und Nachteil. DCC ist eben genormt, das gibts überall gleich (oder so ungefähr )

Viele Grüße von
   Phips

Hallo Phips,
eigentlich ist mir meine Zeit zu schade, auf den Unsinn, den Du da schreibst, auch noch zu antworten. Ich mag es aber trotzdem nicht so unkommentiert stehen lassen.

Also: Bleib' mal ein wenig sachlich und würfel hier auch nicht Reaktionszeiten und Features durcheinander - auch umschalten auf SX2 zum Konfigurieren und zurück auf SX1 zum Fahren ist ein Bananenvergleich - das könnte ich mit Multiprotokolldecodern auch machen (zum herumkonfigurieren das eine System verwenden, zum Fahren das andere)!!!!!!!!!!

Also mal langsam zum mitdenken:

SX1 hat vor allem deshalb definierte Reaktionszeiten (76,8ms für einen kompletten Scheduler-Umlauf), weil sämtliche Adressen reihum gesendet werden - das geht aber nur WEGEN der extremen Beschränkung auf 112 Adressen, 31 Fahrstufen und 2 Funktionen. Das hat per se erstmal nichts mit den Möglichkeiten zu tun, den ein Multiprotokolldecoder dann unter DCC bietet. Nur: Warum sollte ein Anbieter wie D&H oder Rautenhaus Features in einen Decoder einbauen, die mit dem eigenen System überhaupt nicht nutzbar sind? Und genau das tun sie halt auch nicht oder mittlerweile lediglich rudimentär.

Ich habe mir die Anleitungen zu den vielgepriesenen aktuellen D&H Decodern mal angeschaut. Zugegeben, mittlerweile erreichen sie immerhin schon den Funktionsumfang eines DCC Einfachst-/Einsteigerdecoders wie dem Lenz Silver Mini +.

Wenn Du aber mehr als die zwei Funktionen haben willst mußt Du auf das (offenbar nicht genormte) SX2 ausweichen (bei SX2 wohl an die 16000 Adressen, 128 Fahrstufen und incl. Licht 18 Funktionen). Damit bekommt SX2 aber dieselben Probleme wie DCC! Die Datenmenge steigt dabei um mehr als den Faktor 150, bis alle Adressen mal gesendet werden.

SX2 scheint wie gesagt nicht normiert zu sein, zumindest finde ich bei der NEM nichts, ich meine aber mal gelesen zu haben, daß dann ebenfalls eine Dynamik hinzukommt, um die Datenmenge bewältigen zu können. Anders kann es eigentlich auch nicht gehen.

Damit ist es dann aber mit Deiner ach-so-tollen garantierten Reaktionszeit ebenfalls vorbei. Wenn ein Decoder mal einen Befehl verpaßt, dann dauert es bei vielen aktiven Adressen sicherlich ähnlich lang wie bei DCC, bis die Daten aufgefrischt werden.


Mit welcher Gurke von Zentrale hast Du das denn ausprobiert? Und hast Du den Vergleich dann wenigstens auch mit SX2 und gleich großer Datenbank (aktive Adressen) gemacht. Sonst ist dieser "Vergleich" einfach nur Murks.

Eine brauchbare DCC-Zentrale wird die Fahrbefehle natürlich mit höhrer Prio in den Schedule einhängen als die Zusatzfunktionen - hier unterscheidet sich DCC maßgeblich von SX1 insofern, als daß zwischen Fahrstufen- und Funktionsgruppen-Paketen unterschieden wird, bei SX1 steckt wie Du sicherlich weißt alles in einem Paket. Frage an Dich als SX-Fachmann: Wie genau ist das denn bei SX2? Der normale Schedule-Umlauf jedenfalls wird dann "On Event", also, wenn eine Funktion/Fahrstufe sich ändert, entsprechend abgeändert, um die geänderten Daten bevorzugt zu senden. Anders geht das bei bei mehreren Tausend möglichen Adressen und je drei erweiterten Paketen pro Adresse (Fahrstufe, Funktionsgruppe 0, Funktionsgruppe 1 - bei bis zu 12 Funktionen, DCC kennt mittlerweile aber bis zu 28!) auch gar nicht! Weiterhin wird eine brauchbare Zentrale auch inaktive Adressen aus dem Schedule herausnehmen.

Und um dies zu untermauern habe ich Dein Beispiel nochmal an meiner Zentrale durchgespielt. Und weißt Du was? Keine 2s Verzögerung, nein, oh Wunder über Wunder, die Reaktion kommt sofort, egal, wie ich gleichzeitig an Fahrregler und Zusatzfunktionen spiele.

Unterbreche ich die Stromzufuhr, dann geht es bei meiner Zentrale relativ schnell, bis die Fahrinformation wieder restauriert ist, während das Wiederherstellen der Funktionen deutlich länger dauert (eben im Sekundenbereich). Das ist aber primär eine Sache der Implementation in der Zentrale, der DCC-Standard fordert aber zumindest den möglichst häufigen Versand der Basispakete mit den Fahrstufen. Grundsätzlich könnte man natürlich auch die Funktionen schneller auffrischen (oder nach Funktionsgruppen unterscheiden).

Wie gesagt, für das grundsätzliche Problem bei der Übertragung großer Datenmengen und vergleichsweise langsamem Übertragungsweg, nämlich eine relativ lange Umlaufzeit durch die Schedule Table, gibt es kein Wundermittel. Da werden sich DCC und SX2 nichts nehmen.

Das Problem an sich sind ja nicht mal die paar Bits mehr für Zusatzfunktionen, sondern die durch den vergrößerten Adreßraum stark wachsende Schedule-Tabelle. Ein SX1 Paket hat so um die 25 Bits (Du als Fachmann kannst mir das sicher genau sagen). Bei eine Ausweitung auf - sagen wir mal - 12 Funktionen (statt 2), würden dann 35 Bits draus. Damit würde ein Schedule-Umlauf auf ca. 104ms anwachsen, was noch kein Problem wäre. Aber: Bei 16000 Adressen würde der Umlauf rd. 14s dauern!

Gruß,
Torsten

Hallo Torsten,

Als Digital-Laie bleibe ich lieber weit von Euere Diskussion, aber vielleicht hast Du noch eine Antwort auf meine Frage #34? Das würde wenigstens mich etwas weiter helfen

Viele Grüße aus NL,

Bert

Edit: Rechtschreibung Laie

Hallo Torsten,

Das tut mir leid, dass bei dir mein Vergleich nicht angeschlagen hat!
Welche Gurke ich habe: Die GB für MS1, was in meinen Augen in gewisser Weiße auch eine Gurke ist .
Ich habe bei dir aber noch ein Haar in der Suppe gefunden :

Nicht unbedingt! Da ich noch kein solches, vllt für dich, "Dilemma" habe, kann ich dir das nur sehr grob erklären, Kollege Röhricht hat mir das vor nem 1/2 Jahr am Telefon nähergebracht, kann mir´s aber noch nicht ganz behalten! Was das ist: Eine Zusatzadresse des SX-Decoders, die mit der Adresse für das Fahren gleichgestellt wird und so trotz SX,  Funktionen (außer Licht) wie Sound, Dampf, etc. Schalten kann. Falls es dir nicht ganz schlüssig war, wie mir , wende dich bitte an Hajo oder Röhricht, die wissen da besser Bescheid, sind ja vom "SX1-Schlag".

Vllt. wäre in dieser Ansicht noch zu erwähnen, dass DCC nach einem "Not-Halt" (Strom weg) oder bei diesem alle direkt einstellbaren Eigenschaften (zB eingeschaltetes Licht, Horn, etc., aber auch die Fahrstufe auf 0) auf 0 setzt und die Lok (oder der Zug) nach der "Wiedereingliederung" des Stroms stehen bleibt und von Hand auf V gesetzt werden muss. Bei SX ist dies nicht so, die fahren einfach weiter wie vorher (natürlich mit ACC-Beschleunigung!). Oder wie kann man das in DCC lösen, würde mich auch interessieren, da ich den Schienenbus in DCC laufen habe.

Leider ist Alfons´ Fred mal wieder abgeraten, ich hoffe, wir haben ihn nicht verscheucht mit unseren "Rivalitäten" ,

Viele Grüße von
   Phips
Der kar kein SX-Spezi ist!!

Ok, der Hajo weiss da bestimmt Bescheid.
Grüsse, Kessi

Hallo Kessi,


den frag ich, wenn´s Brot hart ist
Spaß beiseite, weiß nicht was ihr da habt, ich kann gegen ihn wirklich nichts sagen! Er hat mir meine Aufträge bestens erfüllt und seinen verdienten Lohn bekommen!

Grüße von
   Phips

Tja, auch ein blindes Huhn findet mal ein Korn...

Hallo Phips


Bei mir funktioniert das. Strom weg -> Loks bleiben stehen. Strom wieder da -> Loks fahren wieder los. Vielleicht ist das eine Einschränkung deiner "Gurke", dass es nicht klappt. Ich fahre mit OpenDCC.

Viele Grüße
msfrog von 1001-digital

Das kann sein, ich werde später vermutlich auf die FCC umsteigen!

Grüße von
   Phips

Hallo zusammen,
hallo Torsten @43,


Es ist richtig, dass es keine offizielle NEM-Norm für SX2 gibt. Die Spezifikation gibt es natürlich trotzdem und ist den relevanten Herstellern bekannt, die es unterstützen (wollen).

SX2 (wohlgemerkt das Gleisformat - nicht der irreführenderweise gleich benannte Bus!) hat sowohl Eigenschaften von DCC als auch von SX1 "geerbt".
Als da wären:
-paketorientiert ohne festen Übertragungsrahmen (~DCC)
-langer Adressraum bis 9999, 127 Fahrstufen, 16 Zusatzfunktionen plus Licht (~DCC)
-Tristate-Signal: Nullen und Einsen sind gleich lang, Takt wird mit übertragen (~SX1)
-alle Infos in einem Paket (~SX1)
-je nach Digitalzentrale (sicher weiss ich es bei RMX) gibt es auch einen intelligenten Scheduler, der zudem Änderungen sofort ausgibt (~DCC)
-CVs heissen bei SX2 "Parameter", bedient werden sie fast gleich, nur die Programmiertechnik unterscheidet sich
-bei SX2 gibt es keine definierten Schaltbefehle auf dem Gleis, allenfalls per SX1 oder DCC bei einer Multiprotokollzentrale
-bei SX2 gibt es POM (~DCC)

DCC hat im Laufe seiner Entwicklung viele neue Features beigebracht bekommen, daher verteilt sich z.B. die Information für 128 Fahrstufen, lange Adresse und Zusatzfunktionen bis F28 auf mehrere Pakete, die in Summe bis zu 40ms Übertragungszeit auf dem Gleis benötigen können. Beim "auf grüner Wiese" entwickelten SX2 sind diese Informationen (allerdings nur bis F16) alle in einem Paket, das ca. 3,6ms benötigt. Es wäre falsch zu behaupten, SX2 ist dadurch generell und immer 10x schneller als DCC. Allerdings kann sich dieser Unterschied je nach Betriebssituation, Grösse der Anlage, Fähigkeiten der Zentrale, usw. durchaus auswirken.

Grüsse
Daniel

Hallo,
bei DCC kann man einstellen,
ob die Loks nach einer Stromunterbrechung,
stehen bleiben oder wie zuvor weiter fahren können.

Ob das jede DCC-Zentrale bietet entzieht sich meiner Kenntnis.

Höhere Übertragungsraten, gehen mit höherer Dämpfung einher.
Es ist deshalb in der Praxis mehr als fraglich ob das schneller geht.

Aber das habe ich oben bereits erläutert.
Stichwort: Rad-Schiene-Kontakt.

SX2 ist ein junges System, und wird hier hauptsächlich theoretisch betrachtet,
und mit der Praxis des DCC verglichen.

Und das führt zu falschen Annahmen!

Aber das kennt man aus der Soziologie.
http://de.wikipedia.org/wiki/Soziologie

Hans-I.

Hallo Bert,
eine sehr gute Motorregelung haben die Zimo Decoder. Leider gibt's derzeit aber keinen Spur N Decoder von Zimo mit vollem Funktionsumfang.

Wenn Du bestimmte Features nicht brauchst (ABC, HLU, RailCom) kannst Du es auch mit den Teilen von CT Elektronik (z. B. DCX75) versuchen. Allerdings hat der entweder keinen PID-Regler oder irgendeine dämliche Beschränkung im Regelalgorithmus, bei meinem Roco ET90 mußte ich die CV für die Anfahrspannung nämlich massiv hochdrehen. Das sollte bei einem Regelkreis mit Integralanteil (nur so kannst Du vollständig ausregeln) nicht sein.

Lenz ist meist mein Notnagel, wenn ganz wenig Platz ist oder der Zimo einfach überhaupt nicht harmonieren will. Eine Lenz-Krankheit ist aber die firmenpolitisch gewollte viel zu hohe Kriechgeschwindigkeit.

Bei Neuanschaffungen habe ich derzeit ausschließlich noch Zimo im Einsatz.

Wenn Du aber mit SX fahren willst, solltest Du m. E. auch Decoder von Firmen aussuchen, die das als primäre Betriebsart betrachten. Umgekehrt gilt das genauso.

Viele Grüße,
Torsten

Hallo Torsten,

Danke für die Antwort.

Ich habe soeben eine DH10A bei Doehler & Haass zur Probe bestellt, der entweder im MTX V36 oder GFN V100 seine Zukunft finden soll. Wie ich verstanden habe soll es damit wenig Probleme geben bei "Uralt-Motoren"....

Ich hoffe dass es eine gute DCC-Lösung sein wird...

Viele Grüße aus NL,
Bert

Stimmt. Nur diejenigen, die beides kennen, sollten sich ein Urteil darüber erlauben können. Was mir hier auffällt, dass das leider nicht der Fall ist. Bei näherem nachfragen merkt man schnell, wer Quatsch mit Sauce erzählt.

Gruß
Tomi (der immer noch auf belegbare Fakten zu Phips´s Aussage wartet)

@Kerner & Tomi: volle Zustimmung, es gibt hier leider noch viel Erklärungs-, Dokumentations-, Informations- und Praxisbedarf. Daran wird gearbeitet, das weiss ich. Ob wir damit auch Halb- und Unwissens-Postings verhindern können? Wohl kaum, fürchte ich.

Ich selbst fahre jeden Decoder, der das kann, mit SX2. Wer tut das sonst noch? Wer hat sich SX2 mal genauer angeschaut? Welche Fachzeitschrift hat hierzu mal einen fundierten Artikel mit Praxistest und Vergleich der SX2-fähigen Systeme veröffentlicht? - Fehlanzeige, Schweigen im Walde. Somit stützt sich verfügbares Wissen und Praxiserfahrung auf ein paar wenige Leute. Diese von den unwissenden zu unterscheiden ist für Digitaleinsteiger systemunabhängig betrachtet schon schwierig genug.

Zur Übertragungssicherheit: es wird das gleiche Verfahren wie bei SX1 verwendet, das unbestritten sehr sicher ist - Tristate bei ca. 20kHz. Den grösseren Funktionsumfang erkauft man sich mit längeren Refreshzeiten: ca. 400ms für 103 aktive Loks im Vergleich zu den ca. 80ms bei SX1. Rad-Schiene-Kontaktprobleme treffen alle Digitalsysteme, das Problem löst auch SX2 nicht.

Noch hat SX2 nicht den kompletten Funktionsumfang mancher DCC-Decoder/Zentralen, ja. Gegenfrage: braucht man tatsächlich alles das?
Lässt sich per Update einspielen, sofern sinnvoll und sobald verfügbar - in Decoder und Zentrale.

Grüsse
Daniel

Hallo Daniel,



Ich

Der da viel Spass mit hat

Gruß Jürgen

Hallo Tomi,


Ich weiß nicht welche!
Du sagtst, nur wer beides kennt, sollte sich ein Urteil darüber erlauben. Das würde auf mich zutreffen. Nun schreibe ich meine Meinung, und sie wird gerade gebogen. Wenn du nicht die gleichen Erfahrungen mit DCC gemacht hast, dann kannst du ja froh sein, dass das Ganze zB ohne 2sek Verzögerung funzt.
Ich will mich auch weiters nicht tiefer vergraben, sonst komme ich nicht mehr heraus!

Ihr könnt gerne weiter diskutieren, ich halt mich in Zukunft raus!

Schade ist nur, dass das Thema von Alfons etwas in den Hintergrund gerät!

Viele Grüße von
   Phips

Roger
Ende
Basta

Hallo Phips

sei mir nicht böse, aber du kannst nicht beides kennen, wenn man so manchen Beitrag von dir liest. Auch aus älteren Beiträgen schließe ich ganz klar daraus, dass da noch nicht wirklich alles richtig verstanden wurde. Ich will dich keineswegs hier kritisieren, ganz im Gegenteil, ich will kommunizieren. Und dazu gehört eben auch, dass man Fakten auf den Tisch legt. In meinem Beitrag in @39 habe ich nachgehakt. Deine Aussage:
ich würde hierzu gerne mal konkrete Belege haben. Hast du das nur mal irgendwo bei jemandem gesehen? Oder hast du gar Messungen gemacht??? Oder mach doch mal ein Video, auf dem du uns das vorführst, dass es zwei Sekunden dauert, bis bei Tastendruck ein Licht einer Lok einschaltet.
Ich kanns einfach nicht glauben. Und der Grund warum ich es nicht glauben kann, ist: ich habe mich schon ein paar Jahre intensiv mit Digital beschäftigt und sowas ist mir einfach noch nicht passiert. Wie gesagt... möglich ist das alles. Das hat dann aber nichts mit dem Protokoll zu tun sondern lediglich mit einer ungünstigen Konstellation verschiedener Bauteile. Aber NICHTS mit dem Protokoll.

Also, falls du da genauere Daten zur Verfügung stellen könntest, wäre ich dir sehr dankbar. Wenn nicht, ists auch nicht schlimm.

Danke und Gruß
Tomi

Okay,
da werfe ich mal was ganz Neues auf den Markt:
Die "alten" Uhl 73400/410 hatten ein Problem bei Loks mit Birnchenbeleuchtung, weil die Werksvorgabe für die Kurzschluss/Überlasterkennung zu früh ansprach (mittlerweile ist u. a. das geändert worden und funzt einwandfrei)
Man musste die Voreinstellung höher setzen, damit die Lok nicht ständig ab- und anschaltete.
War der Wert immer noch nicht hoch genug, lief die Lok zwar soweit fehlerlos, aber das Licht schaltete sich mit deutlicher Verzögerung ein.
Solltest Du, Fips, solch einen Decoder verwendet haben, dann wäre das eine Erklärung.

Viele Grüsse
Mathi

Hallo Tomi,

Video: Kann ich nciht machen bzw geht von der Umsetzung nicht, da ja gerade mein DCC Schienenbus nicht richtig will.
DCC liefert die Infos/Befehle von Lok zu Lok bzw Dec. zu Dec. aus, also nacheinander.
SX macht alle gemeinsam, also auf einmal.

Aber Hans meint ja eh, "das ist sowas von egal", also, Weg vom Tisch!

Gruß

Hallo Phips


Das ist falsch. SX kann auch nicht alle Daten auf einmal an alle Adressen senden. Richtig ist, dass auch SX alle Loks nacheinander "anspricht", samt aller Informationen für Funktionen. DCC hingegen kann diese Informationen voneinander trennen und nach Wichtigkeit sortiert senden. Ein Bremskommando sollte so z.B. immer eher übers Gleis gehen als die Hupe.

Viele Grüße
msfrog von 1001-digital

Hallo Herr Berger,

<Das ist falsch. SX kann auch nicht alle Daten auf einmal an alle Adressen senden. Richtig ist, dass auch SX alle Loks nacheinander "anspricht", samt aller Informationen für Funktionen. DCC hingegen kann diese Informationen voneinander trennen und nach Wichtigkeit sortiert senden. Ein Bremskommando sollte so z.B. immer eher übers Gleis gehen als die Hupe.>

Soviel Unkenntnis habe ich schon lange nicht mehr gelesen.
Ehe mann so etwas von sich gibt sollte man sich mit den Protokollen der einzelnen Datenformaten auseinandersetzen: Bei Sx werden tatsächlich 13,8 mal pro Sek. alle (egal ob physikalisch vorhanden oder nicht) Decoder (Adressen) angesprochen und bekommen einen refresh der Daten.
Siehe:
http://www.1zu160.net/digital/selectrix.php
Sie hatten mir vor kurzem vorgehalten: "Wer lesen kann ist im Vorteil"
Kleiner Tip : fassen sie sich doch mal an die eigene Nase und verbreiten sie nicht noch mehr "Blödsinn" über Sx , wenn sie nicht wissen, was das eigendliche Protokoll beinhaltet, nach diesem sich alle Hersteller von SX Komponenten , im Gegensatz zu der derzeitigen Diskusion (Offener Brief der Arbeitsgruppe RailCom) richten. Das was dort diskutiert wird funktioniert im Übrigen schon seit Jahren mit D&H Decodern und Belegtmeldern von MÜT 8i  und MTTM und ist auch noch abwärts kompatibel.
LG Röhricht
Modellbahnservice

Aha....
Na, dann noch weiterhin viel Spass beim Mobahnern.

Gruß
Tomi

Achja, Herr Röhricht: Sie sollten das nochmal genauer lesen, was Herr Berger geschrieben hat und auch auf die Antwort von Phips eingehen. Denn es geht darum, dass Phips meint, dass SX die Daten alle auf einmal übers Gleis schickt. Herr Berger sagte, dass auch bei SX alle Adressen nacheinander angesprochen werden. Der Unterschied ist nur, dass bei SX immer ALLE Adressen mit ALLEN Daten versorgt werden. Daher ist auch die Übertragungsdauer relativ exakt definiert.
Meinen Sie, die Übertragung an ALLE Adressen wird in nur einem Datenpaket übertragen??? Das MUSS nacheinander geschehen. Bei SX aber demnach in einem festen Takt.

Von daher finde ich Ihre Aussage gegenüber Herrn Berger bezügl. Blödsinn etwas übertrieben.

Und noch etwas zu Ihrem Vergleich bezügl. Railcom und Müt 8i etc. : haben Sie sich schon einmal näher mit Railcom beschäftigt? Wenn nicht, möchte ich Sie höflichst bitten, erst nach eingehenden Tests und Erkenntnissen Vergleiche zu ziehen. Danke.

Hallo Herr Röhricht

Es ging hierum. Vielleicht hat Phips das etwas unglücklich ausgedrückt, aber: Auch SX sendet die Daten für alle Loks nacheinander und nicht alles gleichzeitig. Eine Lok wartet also im schlimmsten Fall bis einmal alle Adressen durch sind, ehe sie wieder ein komplettes Paket bekommt. Bei DCC kann das im günstigen Fall schneller gehen, wenn
a) nur wenige Adressen bedient werden
oder b) ein Paket mit hoher Priorität gesendet wird.

Der Unterschied zwischen SX und DCC ist nun, dass SX alle Adressen nacheinander durchgeht, während DCC unbenutzte Adressen rausfiltert und die Befehle für die verbleibenden noch nach Priorität sortiert. Ich denke, diese Dinge sind Ihnen bekannt und Sie wollen mich absichtlich falsch verstehen? Ich warte übrigens immernoch auf Ihren Anruf. Nur zu, beim ersten Mal waren Sie doch auch nicht so schüchtern.

Wenn sie es besser wissen, beschreiben Sie doch einmal wie SX es schafft die Informationen jeder Adresse zeitgleich (= parallel) zu übertragen. Ich bin gespannt.

Viele Grüße
msfrog von 1001-digital

@63,


Vielleicht sollten Sie mal das lesen, was Sie hier so schreiben.....

Als Rautenhaus Digital Händler sollten Sie im "Nebenthread" auch korrekte Antworten geben können.Ihre Beiträge dort sehen auch nach sehr viel Unkenntniss aus....

http://www.1zu160.net/scripte/forum/forum_show.php?id=572026&start=2

Hallo Röhricht,
so eine Äußerung zeugt schon von gnadenloser Unkenntnis. Das Gleis ist ist nun mal eine serielle Schnittstelle, da gibt's nichts dran zu rütteln. Wenn Ihre Gleise jeweils aus - ca. - 25*12, also 300 Profilen bestehen würden (plus Masse), könnten Sie natürlich alle Lokadressen und Fahrdaten parallel übertragen (quasi ein dicker Druckerport).

Auch SX überträgt die Pakete Stück für Stück seriell, nur geht das aufgrund des beschränkten Funktionsumfangs eben deutlich schneller als bei SX2 oder DCC.

Gruß,
Torsten

Der mittlerweile rd. 14 Jahre als Softwareentwickler für Embedded Systeme im Geschäft ist und damit schon glauben darf Ahnung zu haben, wovon er spricht...

und genau das ist es, was viele nicht verstehen, dass dadurch eventuell das vermeintlich langsamere System vielleicht sogar etwas schneller ist.
Ich sagte ja bereits, nur wer sich ausgiebig mit BEIDEN Systemen beschäftigt hat, kann das auch beurteilen.

Gruß
Tomi

Hallo Herr Berger,
nochmal zum Mitmeisseln:
Wie funktioniert Selectrix?
Das Selectrix System arbeitet nach einem festen Ablaufschema bei einem festgelegten Takt. Dabei werden immer alle (gleich ob genutzt oder ungenutzt) Systemadressen in einem festen Ablauf angesprochen und der Zustand aller 8 Bit pro Adresse übertragen. Da immer alle Adressen und alle Informationen gesandt werden, ändert sich nie die Länge eines gesamten Durchganges, sondern lediglich die darin enthaltenen Informtionen. Ein kompletter Durchgang dauert 76,8 ms - somit werden alle Informationen, ganz gleich wie stark das System ausgenutzt wird, pro Sekunde 13 mal übertragen.
Aus :
http://www.1zu160.net/digital/selectrix.php
und ob sie es nun glauben oder nicht, es ist so.
Beispiel. Kunde von mir wollte unbedingt in einen Wagen nach der Lok einen 2. Decoder DCC mit SUSI und Sound ( Beide gleiche Adresse). Ergebnis : Lok steht schon und dann kommt das Bremsenquitschen . Verstanden , warum ?
LG Röhricht
Modellbahnservice

Wenn sie ahnung hätten, von den Decodern die Sie verbauen, dann wüssten sie das man die Bremssequenz passend einstellen kann...
http://www.tams-online.de/htmls/produkte/Micro-XS/MicroXS_DE.PDF

Siehe dazu Seite 16.

Vielleicht, weil Sie ihm das falsche Equipment aufgequatscht haben???

Sorry, Herr Röhricht. Sie haben es immer noch nicht verstanden. Lesen Sie doch nochmal die Beiträge weiter oben, dann verstehen vielleicht auch Sie, worum es geht. In den von Ihnen genannen Millisekunden werden nunmal alle Daten hintereinander gesendet. Paket für Paket, eins nach dem anderen. Mehr wollen wir Ihnen doch gar nicht sagen.

Gruß
Tomi

Hallo Herr Röhricht,
na, da haben Sie sich jetzt aber ein Ei gelegt...


Ich schon, bei Ihnen hab ich erhebliche Zweifel... Das Quietschen wird nicht übers Gleis "angeschaltet", sondern direkt vom Decoder anhand der Bremsschwelle. Will heißen, das macht der Decoder ganz ohne Zutun der Zentrale.

Viele Grüße
msfrog von 1001-digital

Hallo N-Freunde.....

Wie eine Meinungsverschiedenheit.....

Und das alles nur weil der Alfons wissen wollte welchen Selectrix Decoder er am besten für seine alte Minitrix Loks nützen kann.....

Und jetzt wird ganz tief diskutiert über Datenpakete, Reaktionszeiten und ob DCC oder Selectrix schneller ist und stürzen sich alle über einander.....

Ob das unser Alfons weiter hilft?

Im Eintrag #58 war es schon geschrieben:


Wie lange wird es noch dauern bis auch diesen Thread von Ismael geschlossen wird?

Fragt sich in NL,

Bert

Und hier nochmal was von Alfons 8-))

Den ersten Beitrag... hatte ich sofort editiert mit dem Hinweis!
dass ich nach dem Thema gesucht habe, nichts gefunden (gesehen) und
nach dem schreiben der Frage sofort über das Thema in einem älteren
Beitrag dann doch gestolpert bin.
Macht aber nichts, so sind die Meinungen jetzt auf dem aktuellsten Stand.
Habe aber jetzt meinen DH10 schon vor mir liegen und werde ihn morgen
einbauen und dann berichten.
Einen schönen Abend noch und trotzdem vielen Dank für die Antworten.

Hallo Alfons,

Schön etwas von Dir zu hören!

Ich bin neugierig wie es weiter geht mit Deinem DH10 im MTX unter Selectrix, nächste Woche werde ich meine DH10 bekommen und der wird im MTX V36 seine Zukunft finden unter DCC

Viele Grüße aus NL,

Bert

Hallo Alfons,
darf ich fragen, warum du dich für den D&H entschieden hast, wenn du bisher RMX-Decoder hattest?

Viele Grüße
msfrog von 1001-digital

Hallo Bert, Hallo Alfons,

der DH10 ist im Vergleich zum 66838 schon echt ein tolles Ding.

Meiner bescheidenen Meinung nach, regelt der DH10 noch feiner den Motor.
Und das Licht lässt sich auch ganz fix unter SX2 dimmen.

Ich bin eigentlich ein bescheidener Digitalo, ich kann auf Sound echt verzichten.

Wichtig fütr mich ist eine feine Ansteuerung des Lokmotors um schöne sanfte Fahreigenschaften herauszukitzeln...und da ist der DH10 echt ein Hit.

Das ist meine bescheidene Meinung

Mit DCC und RMX kenn ich mich nicht aus....

Gruß
Andy

Hallo,

ich kann dem Andy100 nur zusprechen, fahre nur D&H Decoder und diese unter DCC.

Ich bin mit diesen sehr zufrieden und habe damit super Fahreigenschaften herausgekitzelt

...sogar eine Roco BR44 aus der ersten Serie läuft mit einem DH10 sehr fein !!!

Grüße,
Dirk

Warum habe ich mich für den dh10 entschieden!

Der Preis 1 x DH10A-3 und 1 x DHF253 für 33.85 € in der Bucht geschossen!

und zumindest die gleiche Hardware wie der RX990.
Ich habe Heute in Köln für 70,-€ eine Minitrix 85er mit Decoder gekauft.
Leider ist das Teil so perfekt eingebaut das man nicht mehr ohne Gewalt rankommt.
Die Herstellerkennung, wenn es denn eine ist unter CV-8 ist, wirft 157 aus!
Mfg. Alfons

157 ist Kühn: http://www.nmra.org/standards/DCC/mfgnumbers.html

Gruß,
Harald.

Vielleicht noch einen Tipp evtl. welches Modell?

Verhalten beim ersten Test:
Lok aufgesetzt und sie rannte sofort mit Fullspeed los!
Adresse eingegeben und sie fährt zwar sehr schnell aber leise
und lässt sich gut Regeln.
Dann Geschwindigkeit besser eingestellt für Vmax.
Diodenhalt funktioniert, aber komisches Verhalten wenn die Lok
aus der Gegenrichtung die Bremsstrecke durchfährt.
In der Strecke keine Reaktion aber sobald der Abschnitt verlassen
wird beschleunigt die Lok auf Höchstgeschwindigkeit (nicht den gespeicherten Wert!)
Übrigens noch zur 64er mit dem DH10A.
Mit diesem Decoder fährt die Lok zwar immer noch brummig, was aber wohl am Motor
selbst liegt aber sie lässt sich ohne viel am Parameter drehen sofort vernünftig
fahren. Obwohl die Motorfrequenz auf 32kHz stand verschluckt sich der Motor
nicht. Bei 16kHz und Soft fast perfekt!

Schau mal nach ob der Analogmodus in CV29 aktiviert ist, u.U. könnte das damit zusammenhängen. Den bitte abschalten und erneut testen

Mfg
Christian W.

@51:

Hallo Daniel,
ich lese mich auch gerne mal in solche Normen ein, um eine qualifizierte Entscheidung fällen zu können. An diese Informationen komme ich als rein privater Interessent aber offenbar nicht ran.  Und genau das ist das Problem, wenn eine kleine Gruppe von Herstellern da was Proprietäres machen (solange es nicht genormt ist ist es halt so) und unter Verschluß halten.

So kann ich letztlich nur anhand der wenigen bekannten Infos spekulieren, denke aber, daß ich mit meinem Spekulatius nicht grundsätzlich falsch liege.

Viele Grüße,
Torsten

Hallo Alfons,
wenn es ein Kühn N45 sein sollte - ich habe gerade feststellen müssen, daß da in der Firmware ein saublöder Fehler in Bezug auf das Diodenbremsen drin ist (ob der bei aktuellen Decodern behoben ist weiß ich nicht).

Viele Grüße,
Torsten

Hallo Torsten (@83),

da stimme ich zu, es gibt hier wie gesagt noch Nachholbedarf an öffentlich verfügbarer (aktueller) Dokumentation. Schau mer mal...

Du liegst ja annähernd richtig, auch mit der Dynamik. Bei 9999 Adressen kann man natürlich nicht die komplette Information in einen festen Rahmen packen.

Grüße
Daniel