THEMA: Neues Z21 Update

Hi Aron,

könntest Du bitte kurz das, nun gelöste, Problem schildern, oder einen Link zum geschilderten Problem einstellen?
Danke Dir!

BG, Lutz!

Nach unten scrollen: https://www.stummiforum.de/t217536f7-Z-Maintenance-Tool-WLan-Maus-Update.html

Ich les da nix von am Problem mitn Verbund?

Vielleicht war es das?

Grüße, Peter W

Moin,
ich habe eine dumme Frage.
Meine z21 hat noch V 1.43 drauf. Muss ich jetzt  alle Vorgänger Versionen upaten bevor ich V1.18.3 aufsetzen kann ?
Sprich V1.16, V1.17, und V,1.17.2 ?

Danke für die Hilfestellung:

Gruß
Andreas

Grüß dich Andreas

Nein, einfach das aktuelle Maintenance Tool runterladen und Update klicken.

lg
Vincent

Grüß dich Vincent,

Danke und Gruß

Andreas

Hallo Andreas,
du schreibst, dass du die Version 1.43 drauf hast. Das ist doch aber die neue Version, oder?
LG Tommes

Hallo Thommes,

ja das weiß ich eben nicht. Bei mir steht V1.43

habe das Tool V1.18.3 (03.05.25) runtergeladen und ausgeführt. Es wird immer auf die V1.43 aktualisiert.
Müsste da im Anschluß  nicht V1.18.3 stehen als aktuelle Version ?

Gruß
Andreas

Hallo Andreas,

Version 1.43 ist doch "höher" als 1.18.3
Oder sehe ich das jetzt falsch?

Grüße
Hartmut

Hallo Hartmut,

dachte ich auch, aber die neue Version lautet 1.18.3

https://www.z21.eu/de/produkte/z21-maintenance-tool


Gruß
Andreas

hallo

die firmware fur die z21  ist 1.43 das wird nach ein ubdate angezeigt

das Maintenance tool ist version 1.18.3 version nummer vom programm

wenn ich alte version nehme kann ich die fimware dowgraden auf auf 1.42
und benutze Maintenance tool sage wir 1.16



mfg
ono

Und warum sollte man das? Idle wird doch nur benötigt wenn nix zu senden da ist und eine Lok ist mehr als nix. Hat jemand da mehr Grips als ich und begreift das?

Grüße,
Harald

ono

danke für die Aufklärung

Gruß
Andreas

Was das Z21 Firmware Update für mich gebracht hat.

Ich habe 6 Loks mit D&H PD10MU Decoder. Diese fahren problemlos, wenn ich sie über die Adresse in CV1 oder CV17/18 steuere. Auch in Doppeltraktion, mit Steuerung über Adresse in CV19, funktionierte es.

Jetzt fügte ich der Doppeltraktion, die ABC-Bremsung mit konstantem Bremsweg hinzu. Und obwohl alle Decoder die gleiche Firmware haben, tanzten jetzt zwei Loks aus der Reihe. Sie bremsten viel zu spät oder gar nicht. Selbst, habe ich nach vielem Probieren herausgefunden, dass die Loks richtig bremsen wenn CV1 auf der gleichen Adresse wie CV19 steht. D&H Technik hat eine zweite Lösung präsentiert. Eine weitere Lok auf einer anderen Adresse fahren lassen oder auf einer fiktiven Adresse das Licht einschalten.

Das ganze hat offensichtlich mit dem Z21 Bugfix

DCC: Bugfix DCC Idle Befehl auch ausgeben, falls nur eine DCC Lok aktiv ist.

zu tun. Ich bin aber nur Anwender und kann das nicht begründen.

Gruß von Aron

Hallo Andreas,

so wie ich das verstehe, ist die "Firmware" die 1.43 . Nur das Updatetool (mit einigen Zusätzen), ist jetzt 1.18.3 .

Somit zeigt die Z21/Z21 immer die Firmware an und nicht die Versionsnr. des Updatetools.

Grüße
Hartmut

Das sieht mir sehr nach einem Bug im Decoder aus, also dass bei Fahren in Verbundadresse während dieses Paket ausgewertet wird die ABC Info dann nicht beachtet wird. Also dass der Decoder beschäftigt ist jedes Mal wenn das Paket reinkommt und dann keine ABC Messung (langsamer ADC) durchgeführt wird. Wenn das stimmt und Roco demnach seinen DCC Refreshcyklus  für D&H geändert hat dann sind sie nett und/oder sie hatten genug Fehlermeldungen ihrer Anwender so dass es sich lohnt das einzubauen.

Na dann weiss ich zumindest etwas falls bei DCCEX auch solche Fehlermeldungen eintrudeln.

Grüße,
Harald.

zu #aw17
D&H hatte keinen Kontakt diesbezüglich mit Roco, es scheint Zufall zu sein. Außerdem kam die Kundenanfrage von aron erst bei D&H an, nachdem Roco bereits das Z21-Update veröffentlicht hat.
Die DCC-Norm schreibt vor, dass zwischen zwei Datenpaketen an denselben Decoder mindestens 5ms vergehen müssen. Wenn am Gleis immer nur Datenpakete an einen einzigen Decoder vorhanden sind, kann man durch Einschieben des Idle-Pakets diese Timinganforderung einhalten.
Das Problem war übrigens nicht die ABC-Messung, sondern die Zeitdauer der Berechnung der Bremsstrecke. Dieser Vorgang kann beim PD-Decoder nur erfolgen, sobald der Decoder eine Adresse am Gleis vorfindet, die er nicht beachten muss, also ungleich CV01/17/18 und ungleich CV19, falls Consist aktiv ist.
Ein Bug im Decoder liegt nicht vor, der Decoder verlässt sich einfach darauf, dass wenigstens ab und an die 5ms Abstand zwischen zwei Datenpaketen an dieselbe Adresse eingehalten werden.
informativ Hajo

@Allgemein. Danke für den Hinweis auf Roco / Fleischmann IT. Ist was für die W-LAN Multimaus dabei?


@Hajo, Beitrag #18

Womit wieder bewisen ist, dass D&H ein spitzen Produkt ist.

Weiter so bitte. Grüße gehen raus an die Technikabteilung unter der Leitung von Hr. Regensburger. Decoder die einfach Spaß machen.

@HaBa, Beitrag #17
Die D&H laufen mit der DCC-EX OS absolut sauber und rein. Und via JMRI PC Software lassen sie sich prima warten.
Es muss nur regelmäßig das aktuelle Handbuch auf Englisch (und Deutsch für die Registerkarten) an die Jungs geschickt werden. Dann bauen sie Änderungen in die DecoderPro Software ein. Bei Decoder Pro gefällt mir einfach dass man mit übersichtlichen Registerkarten mit viel Text für arbeitet.

Obacht: ein Firmwarewechsel geht aber nur mit der hauseigenen D&H Programmer Hardware!


Gilt auch für das DCC-EX Projekt. Was sie von Euch bekommen, bauen sie in die Software ein.

Also weiter viel Spaß und Erfolg mit IT.

Grüße.

Frank

Ok, was hat das Update nun für einen Sinn ? Ich habe auch von vorher die 1,43 drauf...
Hat wer mal Roco angeschrieben ?
Gruß
Gert

#15
Danke Aron!

BG Lutz!

Hallo zusammen,

die FW 1.43 habe ich schon lange drauf. Ich vermute, nur das Maintenance Tool selbst hat ein Update.

Gruß
Jürgen

Wenn man sich den #2 verlinkten Thread durchliest, sieht man ja, dass bereits im August 2023 die FW V1.43 per Maintenance Tool V1.18 verteilt wurde.
Im September 2023 gabs dann V1.18.1 des Maintenance Tools, im Januar 2025 die V1.18.2 und jetzt im April die V1.18.3.
Die Z21 FW bleibt wie gehabt bei V1.43.

Referenz zur NMRA Norm inkl. Sektion wäre geschickt.

Ich sehe keinen Grund warum ein Decoder nicht anfangen kann eine Bremsrampe zu berechnen während er Pakete die an ihn gerichtet sind empfängt. Zwischen jedem Interrupt sind mindestens 50 Mikrosekunden Zeit.

Grüße,
Harald.

@24 das sind Normen die den Stand der Technik vor 30 Jahren berücksichtigen. Heutzutage wohl nicht mehr erforderlich, es gibt aber schwache Implementation die das dann doch wieder erforderlich machen.

Welchen Grund sollte es aber geben auf Zentralen Seite so simple Dinge nicht einzuhalten? Wozu gibt's den Normen? MMn um das Zusammenleben einfacher zu halten.
-AH-

Hallo Harald,

auf einem.8 Bit PIC kann es vielleicht schon eine Herausforderung sein, die Interrupts sind langsam und man verbraucht einige Zyklen um festzustellen, welche IRQ Quelle es war.

Grüße, Peter W

https://normen.railcommunity.de/RCN-211.pdf#page=9
6 Wiederholung der DCC-Pakete

Grüße
Stephan

Danke für RCN aber RCN ist nicht NMRA. Ich hab nach NMRA gefragt. Oder wollen wir Decoder die nur mit den RCN Normen funktionieren?

Da steht aber gar nicht dass die Zentrale eine Pause machen muss sodern:



Das bedeutet ein Decoder darf kurz weghören aber nicht länger als 5ms. Da steht nicht dass die Zentrale irgendwie das Paket nicht so oft wiederholen darf. Bitte Normen genau lesen.


Wenn man das nicht mit Interrupts hinbekommt dann steht ja nix im Weg dass der Decoder nach einem empfangenen Paket selber 5ms weg hört und sich um ABC oder was auch immer kümmert. Das der Zentrale anzulasten finde ich sehr sagen wir Mal kurios.

Grüße,
Harald.

Für die W-LAN Multimaus hat sich nichts geändert, alles wie gehabt. Also an der Stelle uninteressant.
Wenn ich das richtig sehe wurde nur am Maintenencetool was geändert um Bedingungen zu erfüllen. Heisst stellst Du was an der Z21/z21 damit ein, ist eine Korrektur mit enthalten. Das würde dann erklären, warum die Firmware der Zentrale sich diesmal nicht mit anhebt. Was genau steht ja in der Beschreibung.

#23: Danke !

Hallo,

heute kam auf meinem iPad die Z21 App 1.5.0 herein. Neu ist die Unterstützung für das Fleischmann Drehscheiben-Steuergerät, laut Beschreibung muss dieses allerdings über Loconet angeschlossen werden, die Funktion ist also nur mit der schwarzen Z21 verwendbar.

Grüße, Peter W

Sehe nirgendwo im Text dass es eine Anforderung an die Zentrale wäre.

Und apropos simple Dinge einhalten... Von 6 Millisekunden plus minus eine kann ich ein Liedchen singen.

Edit, noch was gefunden, in einer Fußnote, im laufenden Text steht nur die Anforderung an den Decoder (formuliert mit "A digital decoder shall..."), nix über Zentrale.

In RP 9.2 Seite 4 Fußnote 11 steht:
(so steht's, inklusive doppeltem are not)

Also ja, es gibt ein Problem im Standard und deswegen die 5ms, aber nicht wegen dem Problem des PD decoders, das ist hausgemacht. Weil der fällt ja nicht in den service mode sondern vergisst nur seine Bremsrampe. Ich würde auch den PD nicht als "older Decoder" bezeichnen, also von 2004 aus gesehen, der rp 9.2.3 noch auf die alte Weise behandelt. Auch betrifft das Problem nur die oben genannten Adressen 112 bis 127 (kurz).


Grüße,
Harald

@32 Das bedeutet also übersetzt Normen sind schön, wenn sie einen Hersteller nicht zu Pass sind ignoriert man das einfach und der Anwender ist selbst schuld.

Warum nicht den Sinn der Normtexte versuchen zu verstehen und einhalten. Das erleichtert das Leben für alle. Die VHDM Normen basieren auf den ursprünglichen NMRA Texten. Diese sind eine Mischung von US / GB Englisch und Übersetzungen aus den Deutschen. Das sorgte für schlechte Lesbarkeit, alleine was bedeutet shall/will in US/GB Englisch, das kann fast gegenteilige Bedeutung haben abhängig auf welcher Seite vom Teich man steht. Um 2010 haben wir im VHDM alle überarbeitet und auf Inkonsistenzen durchforstet. Es gibt mehrere einzelne RCNs die sich durch ein Fortschritt in Details widersprechen. Das wird man Möglichkeit gefixt. Die NMRA Texte sind großteils inzwischen Rückübersetzungen der deutschen RCNs in US Englisch. Das hat die Qualität der Texte deutlich gehoben. Wir schauen auch immer das NMRA und VHDM Normen kompatibel bleiben. Die sind nicht ganz ident weil US Bedarf und Europäischer Wunsch Anspruch unterschiedlich sind.

Es ist ein irrer Aufwand die Normen zu warten und weiter zu entwickeln. So gibt es 2 Meetings pro Jahr in Berlin mit 3 Tagen. Da hocken dann 20 Personen und arbeiten an den Texten. Man kann daran mitmachen und bei Unklarheiten über den Vorstand auch nachfragen. Wirklich hilfreich ist nicht Schlupflöcher für Missbrauch zu suchen sondern die grundsätzliche Einstellung Normen einzuhalten.

Die Forderung an einen Decoder nicht 2 Pakete hintereinander zu senden ist sehr alt gab's seit Anfang an. Begründund dafür gibt es viele, manches heutzutage nicht mehr wichtig, aber Anwender wollen weiterhin mit alten Decodern weiterfahren. Das kann man nicht entsorgen. Es gibt immer noch Selektrix, trotz geringer Funktionslität will das auch niemand verbieten oder? Wenn die Zentrale nur eine Adresse kennt dann kommen halt 5ms lauter 1'er oder sonst was. Bei nur einer bekannten Adresse gibt's auch kein Bandbreite Problem. Wenn man das nicht einhält ist das ein Fehler oder grober böswilliger Vorsatz.
-AH-

Jetzt mal bitte nix unterstellen. Die einzige Anforderung an die Zentrale steht in der Fußnote 11 und die gilt nur für ganz spezielle Adressen. Alles andere was in der Norm steht ist nur eine Anforderung an den Decoder. Wenn irgendjemand daraus was für die Zentrale ableitet ist das eine Konstruktion die nirgendwo in der Norm niedergeschrieben ist. Da es dafür in diesem Fall 2025 auch  keine technische Notwendigkeit gibt das plötzlich einzuführen sollte es auch aus zukünftigen Normen fern bleiben. Als Konstrukteur von einer Zentrale kann man nicht in die Köpfe der VHDM oder NMRA Mitglieder schauen um rauszubekommen was sie denn gemeint haben könnten. Das nicht zu tun und keine magische Glaskugel zu besitzen ist auch kein böswilliger Vorsatz.

Bis jetzt hat mir noch niemand den Satz gezeigt (außer der Fußnote 11 die ich selber gefunden habe)  wo steht dass die Zentrale das so machen muss, sollte oder was auch immer.

Die Fußnote 11 beschreibt übrigens einen Workaround der für Decoder neuer als 2004 nicht mehr relevant sein sollte. Wenn man die kurzen Adressen bei 99 aufhören lässt braucht man den übrigens gar nicht.

Ich sehe von außen dass dieses Verhalten es schwerer macht für die Enthusiasten die sich nicht im VHDM Dunstkreis befinden wo vor langer Zeit scheinbar eine 5ms Regel für Zentralen als selbstverständlich beschlossen wurde ohne dass das so in der Norm formuliert wurde.

Grüße,
Harald

Hab ich auch nicht geschrieben. Ich hab behauptet "es steht nicht drin". Was nicht drin steht kann ich nicht ignorieren.

Grüße,
Harald.

RCN-211
Mindestzeitabstand zwischen 2 DCC-Datenpaketen an einen Decoder: tD > 5 ms Distanzzeit

Grüße
Stephan

Folks!
Es steht in allen Normen, daß man einen Abstand halten muß. Hauptgrund alte Decoder die das brauchen. Das war schon immer so - warum diskutiert man über Text der immer gleichbedeutend in allen Papiervarianten steht.
Die Sach' mit dem Reset ist nur ein weiteres Beispiel ...

Also will man auch Bestand bewahren, auch alte Decoder nicht verwirren?

Alternative ist Verwirrung rein bringen und Anwender ärgern, das ist das Ergebnis wenn man Normen ignoriert. WOLLEN WIR DAS?
-AH-

Es steht also in RCN211. Vielleicht auch in einer Vorgänger NEM. Zwar nicht mit "Zentrale muss" aber immerhin. Danke Stephan. Es steht nicht in S-9.2 letztes Update 2004. Auch hat keiner der englischsprachigen mit denen ich zusammenarbeite die S 9.2 so aufgefasst. Es steht nicht in den Änderungen in RCN211 wann die Zusammenfassung die Fußnoten ersetzt hat. Ich hab jetzt kein NEM Archiv von 2004 bis 2024 um herauszubekommen wann das gewandelt wurde. Es gibt aber auch in 20 Jahren von der NMRA kein Update der 9.2,  warum auch immer, so wenn wir nicht aufpassen gibt es bald ein DCC/EN und ein DCC/DACH. Ich glaube da sind wir alle einer Meinung, das wollen wir Anwender nicht. Wie es damit bei den Herstellern aussieht lass ich dahingestellt.

Grüße,
Harald.

NEIN! das war immer schon so, schon in der Zeit von Lenz vor NMRA in den 1980'ern. Da gibt's nix zu rütteln!
-EOD-

-AH-

Ich hab die NEM671 von 2007 im Netz gefunden, da steht drin die soll der S-9.2 (2004) entsprechen.

https://www.morop.eu/index.php/de/nem-normen.html





So, jetzt kann sich jeder ein Bild machen davon was wahrscheinlich damals zur Zeit der Übersetzung da stand und damit vergleichen was in S-9.2 und in der heutigen RCN steht. Auch spricht die Änderung im Z21 Update 2025 dafür dass das nicht ganz glasklar war als die Software der Z21 implementiert wurde.

Übrigends steht nirgendwo in der Norm dass in den 5ms ein DCC Paket gesendet werden muss. Man könnte auch eine größere Menge Einsbits oder Nullbits senden (Ein anderer Typ von Steuersignal darf nur zwischen dem Stop-Bit eines Paketes und dem Beginn der Synchronisations-Sequenz des folgenden Paketes aufs Gleis übertragen werden.) Nur so falls die Entrwickler von Decodern mitlesen und überlegen ob ihr Decoder eine robuste Dekodierung des DCC Signals beinhaltet.

Grüße,
Harald.

Ich würde sagen es ist für den Hersteller des Decoders ein Glück dass wir in DCC-EX eine Ändrung einbauen werden so dass der Decoder  ab und zu seine 5ms Denkpause bekommt. In Zukunft vielleicht nicht nur ab und zu sondern zwischen allen Paketen mit selber Adresse (also auch PoM und Funktionsgruppe 1 bis 5).

Doch sollten (alle) Decoderhersteller von Decodern die sich auf die  5ms Lücke verlassen auch noch Digitrax kontaktieren weil ich denke dass deren Zentralen mit sehr großer Wahrscheinlichkeit (lese: Da wo ich gemessen habe) die S-9.2 auch so interpretieren dass sehr wohl DCC Pakete mit gleicher Adresse ohne Lücke aufeinander folgen wenn nur eine Lok angewählt wurde. Digitrax als größer Hersteller von DCC Zentralen kann vielleicht darüber Auskunft geben wie sie die S-9.2 interpretiert haben und ob ihre Zentalen eine Idlepaket einfügen. Ich nehme an Decoderherstelller haben auch so eine Zentrale für Kompabilitätstests.

Grüße,
Harald

Moin zusammen,

eventuell sollte man dazu einen gesonderten Thread aufmachen. Mit dem z21 Update hat das jetzt meiner Meinung nach weniger zu tun.

Entscheidend für Veränderungen ist die FW der z21, die allerdings nicht mit dem Update des Maintenance-Tools verändert worden.

Gruß
Jürgen