Anzeige:
THEMA: Hersteller Decoderliste Kennnummer
THEMA: Hersteller Decoderliste Kennnummer
Wuffychris - 28.06.20 13:50
Ist vieleicht intressant für euch.
https://www.nmra.org/sites/default/files/standa...pendix_a_s-9.2.2.pdf
Seite 4 bis 6 sind die Nummern geordnet aufgelistet.
Viele Grüße,
Christian
https://www.nmra.org/sites/default/files/standa...pendix_a_s-9.2.2.pdf
Seite 4 bis 6 sind die Nummern geordnet aufgelistet.
Viele Grüße,
Christian
Mobafan160 - 28.06.20 15:22
Hallo
Interessant sind die viele unbekannte Hersteller..?!
Gruß
Christian
Interessant sind die viele unbekannte Hersteller..?!
Gruß
Christian
Wuffychris - 28.06.20 15:43
Hallo Christian,
ja, dachte ich mir. Hatte einfach mal danach gesucht, weil ich nur eine Liste hatte, die so eigentlich nicht stimmen konnte.
Ob jetzt diese Liste alle zeigen, weiß ich nicht, aber immerhin gibts da jede Menge, die ich gar nicht kenne.
Christian
ja, dachte ich mir. Hatte einfach mal danach gesucht, weil ich nur eine Liste hatte, die so eigentlich nicht stimmen konnte.
Ob jetzt diese Liste alle zeigen, weiß ich nicht, aber immerhin gibts da jede Menge, die ich gar nicht kenne.
Christian
Hallo Christian,
die NMRA vergibt die Nummern in CV8, das ist also die offizielle Liste.
Grüße
Stephan
die NMRA vergibt die Nummern in CV8, das ist also die offizielle Liste.
Grüße
Stephan
Hallo,
früher haben Amis die IDs an Hinz und Kunz vergeben und wenn man heute serös eine haben möchte, geben sie keine mehr her - sie wollen Testmuster, wollen das testen, haben eine keinen definierten Prozess dafür und kein Personal!
Das ist eher suboptimal was die im Moment machen.
Grüße, Peter W.
früher haben Amis die IDs an Hinz und Kunz vergeben und wenn man heute serös eine haben möchte, geben sie keine mehr her - sie wollen Testmuster, wollen das testen, haben eine keinen definierten Prozess dafür und kein Personal!
Das ist eher suboptimal was die im Moment machen.
Grüße, Peter W.
Hallo Peter W,
warum beklagst du dich?
Wenn du einen eigenen Decoder entwickeln willst, dann bleibt dir zunächst die 13.
und schon genügst du der Norm
meint
Günter
warum beklagst du dich?
Wenn du einen eigenen Decoder entwickeln willst, dann bleibt dir zunächst die 13.
und schon genügst du der Norm
meint
Günter
Beitrag editiert am 28. 06. 2020 23:34.
Hallo,
einen Decoder mit ID #13 kann man nicht kommerziell vermarkten, auch nicht bei ebay.
Wenn ich etwas nur für mich selbst oder für den Verein mache, ist es mir natürlich egal.
Das erfährt dann aber auch sonst keiner, und schon brauche ich keiner Norm zu entsprechen.
Grüße, Peter W.
einen Decoder mit ID #13 kann man nicht kommerziell vermarkten, auch nicht bei ebay.
Wenn ich etwas nur für mich selbst oder für den Verein mache, ist es mir natürlich egal.
Das erfährt dann aber auch sonst keiner, und schon brauche ich keiner Norm zu entsprechen.
Grüße, Peter W.
Hallo Peter W.,
ich habe aber noch nicht verstanden warum du dich in #4 beklagt hast?
möchtest du eine ID für dich haben?
oder möchtest du vermarkten?
grüßt fragend
Günter
ich habe aber noch nicht verstanden warum du dich in #4 beklagt hast?
möchtest du eine ID für dich haben?
oder möchtest du vermarkten?
grüßt fragend
Günter
Hallo,
ich sage so: Schau'n wir mal. Mir geht es in erster Linie um Fairness in der Branche - gleiches Recht für alle.
Grüße, Peter W.
ich sage so: Schau'n wir mal. Mir geht es in erster Linie um Fairness in der Branche - gleiches Recht für alle.
Grüße, Peter W.
Arnold_Huebsch - 29.06.20 09:31
Folks!
Die NMRA hat sich selbst ein Haxerl gestellt. Kurz nach 2000 hat man versucht durch destruktives Verhalten die europäischen Entwicklungen zu be-/verhindern. Dabei ist auch das Definieren von Testszenarien und das Testen selbst unter die Räder gekommen. Viele Versuche das zu beheben wurde durch Abwesenheit bei den Entscheidenden Abstimmungen boykottiert. Daher gibt es jetzt hier in Europa den VDHM, der aber auch mit der Festlegung von Normen kämpft. Immerhin gibt es jetzt die Kerndefinitionen in einem lesbaren Format. Die NMRA Normen werden derzeit nach unseren VHDM Normen entlang überarbeitet. Wobei der Hauptvorwurf an uns ist weshalb der Text in deutsch veröffentlicht worden ist, nur so nebenbei. Bei den NMRA Dokumenten geht's oft gar nicht um technisches sondern sprachliche Unschärfen die es in einer Norm nicht geben darf. Wenn doch dann ist die Norm ein Mist. Das ist drüben auch erkannt worden.
Es gibt Tests beidseits des Teichs, es gibt auch Neuvergaben von Vendor-IDs. Zum Testen wurde Spezial-HW gebaut die die Gleissignale definiert erzeugen kann und die Antworten messen kann. Im Test wird ein Decoder über viele Stunden lang "gequält" und muß immer korrekt reagieren. Auffällig ist daß derzeit nur europäische Hersteller die Tests einigermaßen schaffen, aber auch nicht komplett. Was aus US Sicht so natürlich nicht sein kann/darf/soll also ganz nach dem Gedankenmodell "Amerika first" ist das völlig indiskutabel! Versucht einmal einen US Decoder mit der RailCom Lücke zu füttern oder Einschaltströme zu messen erlebt man keine Überraschung es geht faktisch nie oder schlecht. Das sind Banalitäten die seit den 1980'ern außer Streit sind, sich drüben aber keiner drum kümmert. Daher haben viele Hersteller drüben innerhalb der eigenen Produktfamilie technische Probleme. So haben die Tester ein Reputationsproblem. Entweder es gibt ehrliche Tests bei denen viele Produkte durchfallen, was zu Unmut führen wird. Alternative ist es wird geschummelt und dann bringt die Sache nicht einmal nix.
Von den 255 Vendor IDs sind gut 50% vergeben also noch kein Problem, es gibt aber eine "Verlängerung" bereits auf 16-Bit. Interessant ist aber daß einige Hersteller die dafür reservierten CVs seit Jahren missbrauchen. OK kein wirkliches Problem weil man in CV8 ja abfragen kann ob die 16Bit Version benutzt werden soll, dennoch ein Verhalten das tief blicken lässt.
-AH-
Die NMRA hat sich selbst ein Haxerl gestellt. Kurz nach 2000 hat man versucht durch destruktives Verhalten die europäischen Entwicklungen zu be-/verhindern. Dabei ist auch das Definieren von Testszenarien und das Testen selbst unter die Räder gekommen. Viele Versuche das zu beheben wurde durch Abwesenheit bei den Entscheidenden Abstimmungen boykottiert. Daher gibt es jetzt hier in Europa den VDHM, der aber auch mit der Festlegung von Normen kämpft. Immerhin gibt es jetzt die Kerndefinitionen in einem lesbaren Format. Die NMRA Normen werden derzeit nach unseren VHDM Normen entlang überarbeitet. Wobei der Hauptvorwurf an uns ist weshalb der Text in deutsch veröffentlicht worden ist, nur so nebenbei. Bei den NMRA Dokumenten geht's oft gar nicht um technisches sondern sprachliche Unschärfen die es in einer Norm nicht geben darf. Wenn doch dann ist die Norm ein Mist. Das ist drüben auch erkannt worden.
Es gibt Tests beidseits des Teichs, es gibt auch Neuvergaben von Vendor-IDs. Zum Testen wurde Spezial-HW gebaut die die Gleissignale definiert erzeugen kann und die Antworten messen kann. Im Test wird ein Decoder über viele Stunden lang "gequält" und muß immer korrekt reagieren. Auffällig ist daß derzeit nur europäische Hersteller die Tests einigermaßen schaffen, aber auch nicht komplett. Was aus US Sicht so natürlich nicht sein kann/darf/soll also ganz nach dem Gedankenmodell "Amerika first" ist das völlig indiskutabel! Versucht einmal einen US Decoder mit der RailCom Lücke zu füttern oder Einschaltströme zu messen erlebt man keine Überraschung es geht faktisch nie oder schlecht. Das sind Banalitäten die seit den 1980'ern außer Streit sind, sich drüben aber keiner drum kümmert. Daher haben viele Hersteller drüben innerhalb der eigenen Produktfamilie technische Probleme. So haben die Tester ein Reputationsproblem. Entweder es gibt ehrliche Tests bei denen viele Produkte durchfallen, was zu Unmut führen wird. Alternative ist es wird geschummelt und dann bringt die Sache nicht einmal nix.
Von den 255 Vendor IDs sind gut 50% vergeben also noch kein Problem, es gibt aber eine "Verlängerung" bereits auf 16-Bit. Interessant ist aber daß einige Hersteller die dafür reservierten CVs seit Jahren missbrauchen. OK kein wirkliches Problem weil man in CV8 ja abfragen kann ob die 16Bit Version benutzt werden soll, dennoch ein Verhalten das tief blicken lässt.
-AH-
Zitat - Antwort-Nr.: | Name:
Zum Testen wurde Spezial-HW gebaut die die Gleissignale definiert erzeugen kann
Wo bekomme ich die Bauanleitung und das Programm das da gefahren wird?
Grüße,
Harald.
Arnold_Huebsch - 29.06.20 14:35
Zitat - Antwort-Nr.: 10 | Name: haba
Wo bekomme ich die Bauanleitung und das Programm das da gefahren wird?
Das war einmal eine ISA Platine, inzwischen eine Platine mit einem Embedded PC drauf. Irgendwie sind PCs mit ISA Bus schon vor längerer Zeit ausgestorben. Die Steuerung erfolgt über Python scripts. Die HW und begleitende SW bekommen Hersteller via der NMRA oder über den VHDM so nötig. Hier in Europe ist ein so ein Ding in Berlin. Die Hersteller können das auch kaufen weiß aber nicht ob das jemand gemacht hat.
"Normales" Publikum hat AFAIK keinen Zugriff darauf wird auch schwierig sowas zu supporten.
-AH-
Hallo,
es ist zwar schön wenn so ein Ding in B ist, das ist ja schon mal gut, aber wenn aus welchen Gründen auch immer keine Tests stattfinden, wir man auch keinen neuen IDs vergeben können und somit auch keine neuen Hersteller an Bord holen können - weder im globalen, noch im lokalen Markt.
Der Kritik betreffend die Sprachwahl schließe ich mich an, ich finde es ist nicht mehr zeitgemäß, multinationale Normen in einer nationalen Sprache zu verfassen. Resultat ist Denglisch und Fachchinesisch mit krampfhaften Übersetzungen - Siemens' Zentralprozessoreinheit (ZPE) mit integriertem Wahlfreier-Schreib-Lese-Speicher (WSLS) und Elektrisch-Löschbarem-Nur-Lese-Speicher (ELNLS) lassen grüßen.
Grüße, Peter W.
es ist zwar schön wenn so ein Ding in B ist, das ist ja schon mal gut, aber wenn aus welchen Gründen auch immer keine Tests stattfinden, wir man auch keinen neuen IDs vergeben können und somit auch keine neuen Hersteller an Bord holen können - weder im globalen, noch im lokalen Markt.
Der Kritik betreffend die Sprachwahl schließe ich mich an, ich finde es ist nicht mehr zeitgemäß, multinationale Normen in einer nationalen Sprache zu verfassen. Resultat ist Denglisch und Fachchinesisch mit krampfhaften Übersetzungen - Siemens' Zentralprozessoreinheit (ZPE) mit integriertem Wahlfreier-Schreib-Lese-Speicher (WSLS) und Elektrisch-Löschbarem-Nur-Lese-Speicher (ELNLS) lassen grüßen.
Grüße, Peter W.
Gibt es irgendeinen Grund das nicht Open Source zu machen, also sowohl das Testprogram als auch dir Beschreibung der Hardware?
Das Argument das dann oft kommt: "Da könnte dann ja jeder... "
Ja, stimmt, und das wäre dann wie ein Problem?
Dass Hardware aus der Zeit geht ist ja mit ein Grund das eben nicht proprietär zu machen, weil dann wenn der Letzte, der das mal gebaut hat nicht mehr kontaktbar ist, und dann auch noch die Hardware verreckt, dann steht man als Testinstanz erst mal da und guckt blöd aus der Wäsche und darf gegebenenfalls das Ganze neu machen. Auch will "man" doch eigentlich dass jeder Hersteller den Nutzen einsieht so ein Teil zu haben und sich dann auch sowas für nicht allzu großes Geld (weil wenn zu teuer dann wird das wieder nix) in die Testabteilung stellen kann.
Alternativ ist auch eine Spezifikation des Tests an sich was wert, weil wenn man weiß, bis zu welchen Grenzwerten die DCC-Pulse während des Test verändert werden dann kann man ja mal nachsehen ob man das mit dem eigenen Program auch kann. Die Tests wären auch als erklärende Kommentare zur Norm recht nützlich. Nur so mal zum Beispiel: Wenn in der Norm steht "repeat packet twice", ist dann inklusive oder exklusive des Orginalpakets gemeint? Bei einem offiziellen Testprogram könnte man leicht nachzählen ob da insgesamt zwei oder drei gleiche Pakete rauskommen wenn diese Funktion getestet wird und dann weiss man zumindest eine offizielle Interpretation des Standards.
Das ist jetzt garantiert keine Massenware für "normale", so das Probem des Supports seh ich da jetzt nicht.
Grüße,
Harald.
Das Argument das dann oft kommt: "Da könnte dann ja jeder... "
Ja, stimmt, und das wäre dann wie ein Problem?
Dass Hardware aus der Zeit geht ist ja mit ein Grund das eben nicht proprietär zu machen, weil dann wenn der Letzte, der das mal gebaut hat nicht mehr kontaktbar ist, und dann auch noch die Hardware verreckt, dann steht man als Testinstanz erst mal da und guckt blöd aus der Wäsche und darf gegebenenfalls das Ganze neu machen. Auch will "man" doch eigentlich dass jeder Hersteller den Nutzen einsieht so ein Teil zu haben und sich dann auch sowas für nicht allzu großes Geld (weil wenn zu teuer dann wird das wieder nix) in die Testabteilung stellen kann.
Alternativ ist auch eine Spezifikation des Tests an sich was wert, weil wenn man weiß, bis zu welchen Grenzwerten die DCC-Pulse während des Test verändert werden dann kann man ja mal nachsehen ob man das mit dem eigenen Program auch kann. Die Tests wären auch als erklärende Kommentare zur Norm recht nützlich. Nur so mal zum Beispiel: Wenn in der Norm steht "repeat packet twice", ist dann inklusive oder exklusive des Orginalpakets gemeint? Bei einem offiziellen Testprogram könnte man leicht nachzählen ob da insgesamt zwei oder drei gleiche Pakete rauskommen wenn diese Funktion getestet wird und dann weiss man zumindest eine offizielle Interpretation des Standards.
Das ist jetzt garantiert keine Massenware für "normale", so das Probem des Supports seh ich da jetzt nicht.
Grüße,
Harald.
Nur registrierte und eingeloggte User können Antworten schreiben.
Einloggen ->
Noch nicht registriert? Hier können Sie Ihren kostenlosen Account anlegen: Neuer N-Liste Account
Zum Seitenanfang
© by 1zu160.net;