THEMA: Ecos und Lokprogrammer steuern Plötzlich keine D&H Decoder m

Hallo,

betrifft das auch ältere DH die schon länger nicht upgedated wurden, oder hast Du überall die verschärfte DCC Erkennung rein gezogen?

Checke einmal die Kabelverbindung.

Grüße, Peter W

Hallo Peter

Es betrift auch etwas ältere Decoder, habe bei einigen versucht die Neue Firmware aufzuspielen, bring keinen erfolg.
Wir haben auch eine ander Ecos mit ältere Firmware versucht, es schein so das es die Drcoder sind.
Ich könnte Expl........ , es sieht so aus das die Decoder von alleine in den Himmel gehen.
Vor einem Jahr die Loks in die Vitrine gestellt, und jetzt raus geholt und dann das.
Ein ähnliches Phänomen hatte ich Damals so um 2003 mt D&H 838 Decodern die waren einfach nach einem Jahr Tod.
Ich habe keine Erklärung dafür, suche weiter nach einer idee.
Grüße
Thomas

Hallo Thomas,

ich hoffe, diese Frage ist nicht zu "dumm": Welches Gleisprotokoll verwendest Du ? DCC, Sx oder Sx2 ?

Viele Grüße, Joni

PS: Peter, stimmt, hieß es nicht neulich D&H habe bei einem Update die Gleissignalerkennung verschärft ?

hallo

bei mir habe ich mit denn dh10c und der neue firmware 3.13.53

mit denn lokprorammer 5.2..4  mann kann die cv auslesen und fahre tut sie auch

mfg
ono

Hallo Joni

Nur DCC, aber an alle das Proplem scheint gelöst zu sein.
Es scheint der D&H Programmer zu sein.
Da bei Langen Adressen  bei D&H die einstellungen kompliziert sind benutze ich dafür den Programmer.
Jetzt warum auch immer scheint es wohl so zu sein das wenn ich z.b. Adresse 140 einprogramiere, auch 140 ausgekesen wird, aber 140 ist nicht sauber vorhanden, lök läuft nicht.
Wenn ich jetzt mit der Ecos auf dem Programiergleis 140 einprogrammiere läuft die Lok.
Warum die Loks vor einem JAhr noch liefen und jetzt nicht mehr bleibt ein Rätsel, aber zumindest kann ich sie wieder zum Leben erwecken.
Jedenfalls hat es bis jetzt bei 10 Loks so Funktioniert,
Grüße
Thomas

Hallo,

das ist also kein Problem der Gleissignal Erkennung sondern der "gefährlichen" Adressen 100 .. 255.

Bei diesen Werten muss man unbedingt sicherstellen ob die verwendeten Geräte das als kurze Adresse in CV1 oder lange Adresse in CVs 17+18 einschreiben und in CV29 steht.

Grüße, Peter W

Jaja, die "gefährlichen" Adressen 100...255! Ich hatte früher mal auch dieses Problem, aber ich habe es auf die Schnelle gerade nicht gefunden. Ich habe dann diese Adressen bei jenem bestimmten Decodertyp gemieden.

Heinzpeter

Lenz wahrscheinlich

Hallo Peter
In der tat scheint es nur die langan adressen zu betreffen.
Verwunderlich ist halt nur, wenn man sie mit dem teuer erkauften programmer und der d&h software als lange adresse einprogramiert.
Mit der firmen eigenen Software laufen die dinger dann auch noch.
Halt nur mit keiner ecos mehr.
Im klartext der programmer und oder die Software programmieren fehlerhaft und vertuschen es such noch.
Diese pleite passiert bei zimo und esu nicht, die funktionieren tadellos.
Nun man lernt nie aus.
Muss dann wohl die langen adressen wie Peter beschreibt penibel von  Hand unter beachtung der cv werte 17,18 und 29 programmieren.
Danke für eure mithhilfe.
Grüsse Thomas

Hallo Tomas,

Das verstehe ich nicht.
Wieso sollte es einen Unterschied machen mit welcher Zentrale die CV geschrieben werden?
Liest denn die Ecos die gleichen Werte in den CVs 1, 17, 18, 29 aus, die dein Programmer zuvor geschrieben hat?

Machst du mit dem D&H Programmer auch DCC Programmierung? Ich meine mich daran zu erinnern, dass wenn man SX2 par-Rogrammierung macht, die Decoder anschließend nur auf SX hören. Fährst du die Loks am Programmer auch mit reinem DCC Gleissignal?

Grüße Fabian

Guten Morgen
dann möchte ich etwas Erleuchtendes dazu posten

1. Betroffen ist nur der Adressbereich 100-127.
Adressen bis 99 werden von allen Systemen als kurze Adressen (CV01) unterstützt.
Adressen ab 128 werden von allen Systemen als lange Adressen (CV17/CV18) unterstützt.

2. Unterschiede gibt es dahingehend, dass manche Systeme die kurzen Adressen 100-127 nicht ausgeben können, wie zum Beispiel Lenz.
Oder auf der anderen Seite die langen Adressen 100-127 nicht ausgeben können, wie zum Beispiel Intellibox.

3. Die Software zum D&H Programmer programmiert immer in dem Format, dessen Reiter oben angewählt ist. Hat man auf SX2 (zum Beispiel versehentlich gedrückt), wird die lange Adresse in par001 und par002 programmiert und dann ist das Modell nicht mit der ECoS steuerbar, da die kein SX2 unterstützt.
Was das mit dem Preis des Programmers zu tun haben soll, erschließt sich mir nicht.

Solche Probleme kann man ganz einfach umgehen: Die Adressen immer mit dem System programmieren, das man einsetzt!
Ein Lenz oder Roco Handregler weiß, ob er 100-127 lang oder kurz haben will und macht es entsprechend einfach richtig.
Die Oberfläche der ECoS auch.
Allerdings kann nicht erwartet werden, dass ein Decoder, dessen Adresse 110 auf dem einen System programmiert wurde, auf dem anderen einfach so nutzbar ist!

Abschließend ist zu sagen, dass das Thema schon so alt ist, wie DCC existiert.
Das hat mit D&H an für sich gar nichts zu tun. Irgendwelche Zusammenhänge zum Preis usw. ableiten zu wollen, sind nicht relevant.

Und selbst rechnen, muss der Kunde auch nicht.
Einfach die ECoS im Programmiermodus verwenden, die stellt CV17/CV18 automatisch korrekt ein.

grüße
hajo

Hallo Hajo!

Deine Erklärung ist im Prinzip vollkommen richtig, aber Thomas hat in #5 Adresse 140 als Beispiel angeführt, aber die ist doch in jedem Fall eine lange.

Beste Grüße

Boris

Hallo,

das mit 1...99 bei Lenz kommt daher dass die alten Geräte nur eine 2-stellige LED Anzeige hatten, das war ja auch bei der Roco Lokmaus 2 noch so. Die Adressen 100...127 sind eine Grauzone, das ist nicht eindeutig definiert. Das kann man z.B. bei der z21 konfigurieren.

Die Werte 128...255 darf man laut Norm eigentlich nicht in CV1 eintragen, ich denke es wird auch keine Software und kein Handregler machen, manche User versuchen es aber doch per Hand und wundern sich warum die Lok nicht fährt. Oder es wird die lange Adresse inkl. CV29 zuerst richtig programmiert, später aber CV29 umgestellt um z.B. Railcom zu aktivieren oder Analogbetrieb abzuschalten und auf die lange Adresse vergessen, weil es gefühlt eine kurze Nummer ist, z.B. BR 103 oder 111.

Wie hajo richtig schreibt, das Problem ist so alt wie DCC und leider in den CVs nicht benutzerfreundlich implementiert, da wollte man um jeden Preis Bits und Bytes sparen.

Dass der "teure" DH Programmer das schlecht macht glaube ich eigentlich nicht, der teure Esu Programmer bietet die Funktion gar nicht erst an. Wenn man der jeweiligen Zentrale oder Software nicht vertraut, es gibt genug online CV-Rechner für dieses Problem.

Grüße, Peter W.

@11 noch leichter wäre es wenn sich die Hersteller an, die meist ohnehin selbst geschriebenen, Normen halten würden. Die Verwirrung entsteht ja erst wenn willkürlich ohne technischer Notwendigkeit irgendwelche Abkürzungen gegangen werden. Passiert das dann noch Systemübergreifend potenziert sich das Problem. Da man ohnehin seit 30-40 Jahren SW warten muß, das auch macht und die Mechanismen dafür hat für die Verteilung, ist es nur noch Sturheit Unsinnigkeiten durchsetzen zu wollen.
Beispiele: DCC Adressraum 100-127, Konflikt DCC Weichennummer und tatsächliche DCC Adresse, MTC21 mit den Ausgängen (sri H0 Welt), MTC14 ohne Masse und Lautsprecher und vieles andere.

Meist ist es so, daß man eine Idee hat, mit den Scheuklappen der eigenen Firma. Der Kollege vom Konkurrenten hatte die Idee manchmal auch schon gehabt und hat aufgrund von erkannten Problemen diesen Weg abgebrochen. Den könnte man ja befragen die Leut' kennen sich ja eeh alle. Wenn man aber seine Idee schon an Verkauf , Management, Marketing angebracht hat, muß man die Größe haben den Anker zu schmeißen. Das ist halt irre schwer. Ausbanden müssen es eeh die Kunden, daher wird das unterlassen. Die Entwickler haben selbst mit dem Mist ja nix zu tun. Das ist die Ursache für so offensichtlich sonderbare Entwicklungen.

Also was steht in der Norm, warum steht es so da - will ich Kunden helfen oder verwirren?
-AH-

Mir ist keine Norm bekannt die Adresse 100-127 als kurze DCC Adresse verlangt. Es gibt Firmen die das missachten, daher die Diskussion hier im Thread.

Beim Übergang von älteren Produkten mit 2-stelliger Adresse auf neuere warum sollte man dann so einen kleinen Bereich des Adressraums normwidrig behandeln? Neuere Geräte die 3 oder mehr Stellen bieten wurden erst später entwickelt da war's bereits genormt, daß die kurzen Adressen bis 127 gehen weil das auch im Protokoll am Gleis schön als 2'er Potenz passt. Das hätte auch die alten Geräte nicht gestört wäre man beim Genormten geblieben.
Kein Vorwurf an Peter ja richtig manche Firmen haben das gemacht ohne wirklichem Grund - es gibt keine Ausrede Unfug nicht als solchen zu benennen.
-AH-

Moin,

Nur mal so als Info: Die Arnolddecoder der letzten Generation (81210, 81220) mit Lastregelung usw. hatten nur "kurze" Adressen bis 119.

Viele Grüße von Jens

Hallo, das ist ein spannendes Thema geworden und ich bin froh, dass die D&H Decoder kein Fall für den####sind, und der Fehler gefunden wurde.

Ich bin gerade beim umsteigen auf die Z21 und kann dort einstellen, wie die Adressen 100-127 gehandhabt werden sollen.
Welche Einstellung würde der Norm entsprechen und kann der D&H Programmer ebenfalls mit dieser Einstellung umgehen?

Viele Grüße
Roberto

Hi!
Norm fordert 1-127 kurze Adresse über CV1, darüber lange Adresse CV17/18.

Technisch gehen auch 1-127 als Lange, um eben keine Probleme zu machen gilt die obige Norm, an die sich mache eben nicht halten
-AH-

Hallo Roberto!

Der Norm entspräche 0-127 = kurze Adresse, 128-9999 = lange Adresse. Der Programmer, so kann man in dem wunderbaren PDF nachlesen, das sich D&H die Mühe gemacht hat zu erstellen und zum Download anzubieten ( https://doehler-haass.de/cms/media/pdf2/PROG_Bedienungsanleitung.pdf ), interpretiert 1-99 als kurze Adresse und 100-9999 als lange Adresse.

Gruß

Boris

Hallo,

da liegt wohl das genau Problem: 1...99 und 100...9999 ist die alte (Lenz'sche) Interpretation.

Nach aktuellem DCC Normenwerk ist übrigens beides falsch
1...127 kurz (RCN-211)
128...10,239 lang

Auch wenn viele Zentralen bzw. Handregler nur 4-stellige Adressen erlauben, in einem Programmer sollte es nicht bei 9999 gekappt werden.

Grüße, Peter W

Hallo,
Natürlich kann man auswählen, was programmiert werden soll.
Kurz 1-127 oder lang 1 bis 10239.

Screenshot:
https://doehler-haass.de/cms/media/bilder4/programmer6.png

Es gibt daher alle Freiheiten.
Die FCC konnte auch schon seit ihrem Erscheinen 2008 1-127/1-10239. Ob die Handregler mehr als 9999 beherrschen ist aber ein anderes leidiges Thema.

Grüße
Hajo

Hallo Hajo (#21)!

Was willst Du uns damit sagen? Ist die verlinkte Anleitung falsch oder missverständlich? Oder kann man alles programmieren aber nur 0-99 kurz und 100-9999 lang fahren? Oder was?

Beste Grüße

Boris

Hallo Hajo, Hallo Peter W, Hallo Arnold,

Ich glaube nicht, dass es um die Adressen zwischen 100-127 ging, wie auch schon von Boris in #12 angemerkt.
ThomasW schrieb ja explizit in #5 von der Adresse “140”, programmiert “als lange Adresse” (siehe #8)

Das seitliche Modul “lange Adresse” schreibt ja automatisch CV17,18 u. 29.
Der Programmer liest das ja wohl auch 140 zurück.

Daher bleibt ja eigentlich nur als einzig vernünftige Erklärung, dass ThomasW’s Programmierung via D&H Programmer versehentlich über SX2 Par-Programmierung erfolgt sein muss. Sonst wäre das ja nicht zu erklären, dass die Lok unter DCC nicht mehr angesprochen wird?

@ThomasW: kannst du das nochmal verifizieren? Bzw. Ist es nach wie vor so, dass wenn du einer Lok eine lange DCC Adresse z.B. 141 über den Programmer gibst, dass sie per Ecos nicht steuerbar ist?

Grüße Fabian

Und genau DA könnte DAS bzw. ein weiteres Problem liegen, wird nämlich versehentlich die Consist-Adresse (für Mehrfach/Multitraktion unter DCC) gesetzt, ist diese Adresse im Bereich 0-255 nämlich eine "kurze Adresse"!

Gruß, Micha

Die Consist-Adresse ist auch nur von 1-127.

Da steht ein wischiwaschi "sollte".

Außerdem wäre das kein Problem wenn

* die Hersteller deutlich angeben würden was ihre Zentrale sendet

* die Unwissenden aufhören würden Mist zu verbreiten (kurze Adressen bis 255 z.B)

* die Norm sich nicht selber widersprechen würde und damit auch noch nicht konforme Zentralen entschuldigen würde



Ein Decoder braucht das nicht wissen denn er hört entweder auf lange oder kurze Adressen (warum eigentlich, könnte doch mit CV einstellbar auf beides reagieren und Problem gelöst) und warum bekommt die Zentrale die lange Adressen von 1 anwenden will nicht auch ein Bit spendiert? Zentralen die das können gibt es auch. Was heißt hier eigentlich "als lange"? Weil was hier oft als "103 kurz" und "103 lang" bezeichnet wird sind ganz klar zwei verschiedene Nummern, da muss man sich nur das DCC Paket angucken.

Grüße,
Harald.

PS: die RCN Webseite könnte auch Mal in diesem Jahrhundert ankommen und die Normen über https liefern so dass ich nicht immer meinen Browser überzeugen muss dass er sie trotzdem runterladen soll.

Hallo Boris (#22),


Die Anleitung zum Programmer beschreibt es korrekt
Es wird bei der Programmierung mit dem Programmer CV29 entsprechend des in der Anleitung angegeben Adressraumes automatisch gesetzt und damit als kurze bzw. lange Adresse interpretiert.
Dementsprechend wird die Adresse 140, wie vom Eröffner gepostet, als lange Adresse interpretiert.
Das bedeutet, dass in Abhängigkeit von CV29 von den Zentralen eine kurze oder lange Adresse erkannt wird..
Es ist mit dem Programmer möglich, den Adressraum für kurze DCC-Adressen bis 127 zu schreiben und mit einer Zentrale zu nutzen.

Die Programmierung bzw. Erkennung des möglichen Adressraumes von kurzen und langen Adressen durch eine Zentrale kann durchaus einem anderen Algorithmus folgen.

Das wäre dir aufgefallen, wenn du das in der Praxis getestet hättest.

grüße
hajo

Hallo Harald,


Nachdem es technisch beide Befehle am Gleis hintereinander geben kann, müsste man im Decoder eine Logik einbauen was zuerst zieht, so ähnlich wie bei Multiprotokolldecodern mit automatischer Umschaltung - mit allen möglichen Problemen bei entgegen gesetzten Befehlen (wildes Ruckeln, Blinken).


Ich habe mich auch schon gewundert warum am Handy der PDF Download immer blockiert. Da sind die Links einfach falsch (http statt https). Ich schreibe ihnen.

Grüße, Peter W.

Was wäre an einer HTTP Seite verboten oder inhaltlich anders gegenüber einer HTTPS Auslieferung? Klar falsch eingestellte Browser meckern da, und Browserhersteller meinen HTTPS erzwingen zu müssen - macht keinen Sinn bei Daten die nicht sensibel sind. Stell' Deinen Browser korrekt ein und Du hast keinen Ärger, da kann der Infoanbieter nix dafür.
-AH-

Also bitte, ändert das einfach auf https und gut ist es. Mixed Content muss man jetzt nicht diskutieren.

Hätte man das nicht auf eine Subdomain gelegt sondern einen relativen Link gesetzt, gäbe es keine Probleme. So ist das ein Mixed Content und das wird in zunehmendem Maße blockiert. Am Handy mit Chrome/Android macht der Browser seit einem der letzten Updates einfach gar nichts mehr wenn man auf der Normenseite einen Link klickt. Keine Meldung, keine Option, nichts. Da kann man kaum etwas einstellen und wenn, ist es beim nächsten Update sowieso wieder weg.

Ich kämpfe in der Arbeit auch ständig mit dem Security Wahnsinn.

Grüße, Peter W.

Hallo Hajo!

1. bin ich noch Old-School, ich lese Anleitungen und denke, dass sie dafür geschrieben wurden😉.
2. einem Tipp hier im Forum aus meiner Anfangszeit als digitaler Modellbahner folgend, vermeide ich Fahrzeugadressen zwischen 99 und 128, was mir auch leicht fällt, weil auf meiner Anlage keine E-Loks verkehren 😊.
3. auf Anleitungen, die ich auf der Homepage eines Herstellers finde, verlasse ich mich.
4. wenn ich - warum auch immer - eine falsche / missverständliche Anleitung gefunden habe und Du die korrekte kennst, wäre es nett, wenn Du diese auch verlinkst, wie ich das getan habe.
5. dass Adressen > 127 vom Programmer als lange Adressen programmiert und interpretiert werden, habe ich nie bestritten, ich habe in #19 lediglich auf Roberto (#17) geantwortet, wo er explizit nach Adressen 100 - 127 gefragt hatte. Dass man diese beim Programmieren mit dem Programmer selbst als lang oder kurz festlegen kann, habe ich vermutet, so wie auch, dass man Adressen < 100 als lange Adressen festlegen kann. Man kann den Programmer aber auch als einfachen Fahrregler für eine Lok benutzen und die Frage ist dann (siehe von mir verlinkte Anleitung), ob der Programmer im Fahrmodus eine Lok auch steuert, wenn eine Adresse zwischen 99 und 127 als kurz oder eine Adresse <100 als lang programmiert wurde. So zumindest habe ich Robertos Frage verstanden.

Gruß

Boris

Hallo,

an den D&H Decodern liegt es nicht, die sind NRMA konform. Kann also nur an versehentlicher Fehleinstellung liegen.
Auch darf nochmals darauf hingewiesen werden, D&H hält sich an die NRMA Norm, andere Hersteller nicht unbedingt - und dies führt dann ggf. zu Problemen.

Gruss,
Gerhard

Man kann's runterladen aber das ist dann ein ich will wirklich das seperat runterladen und dann auch noch bestätigen dass es total gefährlich ist und ich meine Seele verkauft habe. Anwenderfreundlich ist was anderes.

Aber da kann man als Browseranwender nix groß gegen machen, also bitte am anderen Ende https setzen und gut isses.

Grüße,
Harald.

Hallo!

Hatte ich mit Firefox auch schon, bis mir aufgefallen ist, dass man in der Symbolleiste rechts oben ein zusätzliches Symbol sieht, das Downloads anzeigt. Wenn man darauf klickt / tippt, kommt der Hinweis auf die unsichere Seite mit Wahlmöglichkeiten, eine davon ist dann "trotzdem lasen".

Beste Grüße

Boris

Ich müsste nicht Historiker sein, wenn ich nach meiner schwammigen Aussage weiter oben nicht noch genauer nachgeforscht hätte... Hier also der Link zu jenem Faden:

https://www.1zu160.net/scripte/forum/forum_show...nkt&sb3=#x577166

für den Fall, dass jemand genauer nachsehen möchte.

Heinzpeter