THEMA: DCC. CV1 per POM

CV 1 per POM zu ändern ist halt nur solala, wenn bei der Übertragung was schief geht ist danach erstmal Schluss mit POM. Zentralen für Anfänger verbieten es daher, zentrale für eher Profis wie die DR5000 oder D&H programmer, lassen es zu.

Hallo,

und es kommt auch auf den Decoder an.
Ich würde, wenn ich ein Decoder wäre, keine Adressänderung per PO zulassen.
Mach da mal einen Fehler, dann geht's sofort los: wie heißt denn das Teil jetzt.

meint ho

Hallo Frank,
eigentlich sagt der Standard, dass das nicht gehen soll, um zu verhindern, dass man versehentlich die Adresse ändert und die Lok unkontrolliert rumfährt. Manche Zentralen unterbinden das auch aktiv und werfen einen Fehler, wenn man das versucht. In der Regel ist es aber auch decoderseitig gesperrt, d.h. die übernehmen die Adressänderung einfach nicht. Bei D&H-Decodern ist das aber nicht so, dort kann man die Adresse auch per POM setzen. Bei anderen Herstellern ist mir das nicht bekannt.

Viele Grüße
Carsten

Folks!
CV1 sollte sich per POM gar nicht beschreiben lassen. Das ist eine MUß Bestimmung. Wenn das geht haben sowohl Decoder Hersteller als auch Zentralenhersteller geschlampt.

CV17/18 kann man per POM beschreiben wobei es da auch viel Diskussion gab. Es wird im Zuge der RailCom Anmeldung auch darüber diskutiert wie man das macht, insbesondere wenn was schief geht wie man auch der Kasperei wider raus kommt.

Zum Nachlesen die Normen auf deutsch: http://vhdm.de/index.php?option=com_content&am...;id=49&Itemid=61
-AH-

Hallo,


Wieso sollte man einerseits CV1 (kurze Adresse) nicht über POM ändern dürfen wenn anderseits Änderung von CV17/18 (lange Adresse) über POM gestattet ist? Änderung des CV29 über POM ist auch gestattet, und auch über diese Weise ist Änderung der Lok-Adresse (kurz auf lang bzw lang auf kurz) möglich....

Nur so eine Frage...

Grüße aus NL,
Bert

Hallo

ganz einfach, die aktive Adresse sollte nicht über POM geändert werden können.
Siehe auch AH's Antwort.

meint ho

Hello!
Simpel und einfach weil viele Leute inklusive mir ohne Bezahlung seit vielen Jahren an den Normen arbeiten, unbezahlt Reisespesen fressen und ziemlich viel Zeit aufwenden dafür. Alleine schon deshalb ist es das mindeste von jedem der DCC Decoder oder Zentralen baut verlangen zu dürfen die Norm zu lesen, zu verinnerlichen, ganz gut ist es wenn man versucht das zu verstehen was da steht, zugegebenermaßen nicht in allen Fällen immer ganz leicht und dann sich auch dran zu halten. Alleine das reicht als Antwort.

Inhaltlich will ich ergänzen, daß man damit verhindert, daß jemand eine Lok umnietet aber dann nicht weiß welche Adresse das Ding hat. Wenn man nur POM hätte, kann man eine falsch geschriebene Adresse danach nicht mehr ändern, weil man die Unbekannte Adresse ja nicht weiß.  Daß man CV17/18 via POM ändern darf ist selbstverständlich inkonsistent / inkonsequent. Das Gleiche bei Zubehördekodern ist noch weit mehr Chaos.

Daher wird jetzt eine Lösung ausgearbeitet wie man das Lokanmelden machen kann. Wie man doch noch eine Möglichkeit hat via POM unbekannte Decoder zu finden. Da hat man via RC zumindest die Möglichkeit was zurück zu lesen. Aber das ist ein noch ungelegtes Ei.
-AH-

Und wenn man nur POM hat, dann kann man die Adresse gar nicht ändern. Auch nicht sinnvoll.
Ein Programmiergleis wäre dann also immer nötig.
Zum Glück gibt es Railcom, da sieht man die Änderung

In welcher RCN steht, dass CV1 nicht per POM geändert werden darf?
Habe nichts gefunden.

Was ich nicht verstehe, Du schreibst, dass viel Zeit für die Normierung aufgewendet wird, warum sind dann solche offensichtlichen Inkonsistenzen nicht behoben?

Grüße
Stephan

Hallo Heinrich und Arnold,

Vielleicht sollte ich meine Frage anders verfassen...

Wo sollte der Kontrolle liegen ob eine aktuelle Adresse tatsächlich über POM geändert wird?

In der Zentrale geht das nicht, denn (ohne RailCom Fähigkeit der Decoder) ist es die Zentrale unmöglich CV29 Bit 5 zu kontrollieren... Wenn Bit 5 = 0 sollte CV1 verweigert werden, mit CV29 Bit 5 = 1 dürfen CV17/18 nicht geändert werden. Wenn nur CV29 geändert wird, darf Bit 5 nicht geändert werden, die anderen Bits aber schon...

Die Verweigerung sollte also mMn nicht in der Zentrale gemacht werden aber in der Decoder.

Das es Normen dazu geben sollte ist mir klar und ist auch nicht mein Beschwerden, nur wer (Decoder oder Zentrale) in diesem Fall die Normen nicht beachtet ist die Frage: nur der Decoder weiß ob tatsächlich über eine einzelne CV-Änderung seine Adresse geändert wird.

Meint in NL,
Bert

Weil man rückwärtskompatibel bleiben muß. Es gibt sehr viele Missverständnisse in den NMRA Variante der Normen die aus British English und den diversen Varianten von AmericanEnglish entstanden sind. Alleine die Verwendung von shall und will ist nur verständlich wenn man den Autor kennt, also weiß wer den Entwurf geschrieben hat. Die RCNs sind da bereinigt aber man darf die Historie nicht vergessen.

Zentralen die nur POM können sind aber keine DCC Zentralen. Es gibt etliche die nur einen Schienenausgang haben. Wenn da ServiceMode Programmiert wird werden alle am Gleis befindlichen Decoder umgenietet gutes Beispiel dafür sind die Einsteigerzentralen bei Roco.


@9 da kommt was gänzlich anderes, benutzt zwar die heutigen Mechanismen es braucht aber neue Vereinbarungen...
-AH-

Hallo,

so viel Diskussion wollte ich gar nicht auslösen; und meine Frage, ob ihr das mit euren Kombinationen (welchen?) Zentrale/Decoder könnt, ist noch nicht beantwortet.

Ich hatte noch nicht gesagt, dass es sich um einen Tran-Decoder handelt.

Mir gefällt es zumindest, eine "verlorene" Lok kommt halt aufs Programmiergleis und wird dort gelesen/korrigiert.

Viele Grüße
Frank

Die RailCommunity in Ehren, ich bin sogar der größte Fan davon, aber auch die dürfen mal ruhig ein wenig auf dem Teppich bleiben. Wenn man die RCN streng auslegt, dann darf wahrscheinlich inzwischen keine Zentrale mehr das Wort "DCC" verwenden. Ich sag nur "RailCom-Chaos". ACK, NACK, nein doch nicht NACK sondern ein zweites ACK, aber nein, jetzt gibt es doch wieder eine ganz neues NACK. Arnold, Du weisst von was ich rede. Wer bitte soll so einen unglaublichen Mist denn  implementieren??? Die RailCommunity verändert da tatsächlich viel zum positiven, weiter so. Aber kaum eine Zentrale kann das alles zur Zeit umsetzen.

Wenn die WLANmaus also das Ändern von CV1 per POM erlaubt, und der Decoder das akzeptiert, und ein paar Anwender sich freuen, dann soll es halt so sein. Die "Streber"-Decode dürfens ja gerne verweigern. Es gibt sicher wichtigere Themen, wo man auf strikte Einhaltung der Normen pochen kann.



Kann man schon verlangen. Sicher schön, wenn man auf der Seite der Schreiber sitzt und teilweise nicht mal wirtschaftlich denken muss. Nur in realistischer Zeit umsetzbar und testbar ist das alles schon lange nicht mehr. Mein ernstgemeinter Tipp: schmeisst zuerst mal den ganzen unnötigen rückwärtskompatiblen Müll raus, so nen Dreck wie 14/28 Fahrstufen, Registerprogrammierung und was sich der alte Lenz vor Urzeiten sonst  noch ausgedacht hat. Und gebt dann dem Kind endlich einen neuen Namen anstelle von "DCC". Das Wort DCC steht ja auch auf den Krempl aus den 90ern drauf, und der hat mit den Neuerungen in den RCNs auch nichts mehr zu tun. Vom Ballast erleichtert würde das endlich wieder lesbar und sogar ohne jahrelange Entwicklungszeiten umsetzbar. Macht endlich einen klaren Schnitt. Dann würde sich sogar der Anwender wieder auskennen, was zum Beispiel per RailCom definitiv zusammenspielt und was nicht.
Und bevor jetzt jemand losmeckert: Es ist auch dem Anwender zumutbar, auf unbedingte Rückwärtskomptibilität zu verzichten. Der Schritt ist überfällig. Ich habe selber an die 120 digitalsierte Loks, davon zwei mit Uraltdecodern. Ja, es ist zumutbar, dass ich die beiden gegen modernere Decoder tausche.

VG
Gerhard

@12 An dem RailCom Chaos kannst aber die RailCommuniuty nicht beschuldigen, die durften lange Zeit nix normen weil ein Patent digenen stand. Es gab da jemanden in Gießen der meinte das das besonders lustig ist wenn man die Hersteller in 2 Lager Freunde und Feinde aufteilt.

Lenz sind die alten Normen nicht anzulasten das hat er zwar wesentlich beeinflusst, genormt hat das die NMRA.

Völlig klar es wird früher oder später etwas nach DCC kommen müssen. Da aber viele Modellbahner mit großem Unverständnis reagieren wenn ein Modell aus den 50'ern mit aktueller Technik Schwierigkeiten macht zusammenzuarbeiten, gibt's halt wenig Verständnis wenn das mit "fast neuen Sachen" aus den späten 1980'ern so wäre. Einfach mal nachlesen was es für Ärger mit Decodern gibt die von der RailCom Lücke verwirrt werden. Diese Lücke ist aber sogar mit den DCC Vorläufernormen kompatibel, das MUß jeder Decoder aushalten! Allein die Decoderhersteller kümmert das wenig. Der Modellbahner meint aber die "Neuerung" verursacht den Fehler. Daher ist der Fortschritt so langsam, weil man versucht den Modellbahnern möglichst wenig Ärger zu bereiten.
-AH-

@13

Ich habe ja gesagt, dass die RailCommunity viel zum Positivem verändert. Die Kritik geht nur in Richtung der mitgeschleppten Altlasten.

WIMRE hat zuerst  Lenz das Übertragungsformat entwickelt, welches erst 1993 von der NMRA zum digitalen Standardformat erklärt worden ist. Lenz' Handschrift bezüglich Bit-Knauserei ist unübersehbar, darum ist auch fast alles doppelt und bei den Fahrstufen oder Decoderprogammierung sogar mehrfach vohanden, weil der erste Wurf wohl völlig unzureichend war. Nur gut, dass Lenz inzwischen mehr mit der Spur 0 beschäftigt ist.

Wegen der RailCom-Lücke. Das Thema kenn ich aus erster Hand. Einerseits ja: die nicht kompatiblen Decoder sollten die kurzen Unterbrechung aushalten. (Dass auch ein Weichendecoder mit Unterbrechungen rechnen soll, ist nicht unbedingt auf dem ersten Blick selbsterklärend. Hast Du übrigens gewusst, dass beim Roco 42624 nicht die CPU sondern nur der Infrarotsensor in der RailCom-Lücke ausgefallen ist? Kannst Dir ja vorstellen wie "lustig" es war, dafür in so einem alten und langsamen Microcontroller den Workaround in Assembler einzubauen.)
Anderseits ist und bleibt RailCom aus elektrischer Sicht eine ziemliche Kack-Techologie, die Lenz mit fragwürdigen Methoden (Patent nein/ja/vielleicht) zur Norm gepusht hat, nur mehr getoppt vom RailCom+ Schlingerkurs. Derjenige, welcher sich die 4/8-Codierung überlegt hat, hat definitv wenig Ahnung von Übertragungstechnik (CRC, PDO, SDO, ...), Bandbreite wird unnötig verschenkt. Die ungewöhnliche Baudrate von ausgerechnet 250 kBit/s schränkt die verwendbaren Microcontroller ein. Wahrscheinlich versteht meine Kritik aber nur derjenige, der das mal selber tatsächlich implementieren musste. Am geduldigen Papier schaut RailCom ja noch irgendwie Ok aus, in der Praxis vergeht einem dann ziemlich schnell das Lachen.
Ich kann Digitrax jedenfalls gut verstehen, der bereits ein besseres und nachrüstbares(!) Transpondigsystem hatte, dass er RailCom verweigert.

VG
Gerhard

Hallo zusammen,

interessante Diskussion!

Ich implementiere ebenfalls Eigenbau Decoder seit einigen Jahren incl. Railcom mit dem vollen Programm. Ich kann Gerhard Verdruss nachempfinden. Unscharfe Spezifikationen, endloses Bit-gepfriemel, wiederkehrenden Änderungen von Änderungen sind zermürbend. Das hier diskutierte CV1 POM Problem war mir bislang unbekannt. Obwohl ich gefühlte 100x die RCNs gelesen habe ist mir nirgends aufgefallen das CV1 POM verboten sein soll (wo genau steht das?).

Das Abschneiden von alten Zöpfen halte ich ebenfalls für dringend notwendig.

MfG,
Frank

Hallo zusammen,

mal ne ganz blöde Frage zu dem Thema der Änderung der Adresse per POM: Ich habe bei D&H die Erfahrung gemacht, dass sich auf einem Progammiergleis gar keine Adressen ändern lassen, wenn ein Fahrzeug mehr als einen Decoder hat (habe ich bei elektrisch verbundenen Triebwagen mit dem Funktionsdecoder). Die Zentrale gibt sofort einen Fehler aus.
Ich muss das doch über POM machen, oder gibt es da einen anderen Trick? Daher bin ich heil froh, dass es bei meiner Decoder(D&H)-Zentralen(DaisyII)-Kombination geht. Wäre es so gesperrt, wie ihr es beschrieben habt, wäre es ja unmöglich bei solch einen Fahrzeug die Adresse zu ändern.

Eine ergänzende Frage: Gibt es eigentlch irgenwo eine Hilfe, wie ich mir aus den CV 17/18 die Adresse zusammenrechne?

Viele Grüße

Dirk

Sorry, Leute - aber ich kann überhaupt nicht verstehen, wieso man jemals auf die Idee kommen kann, eine Lok via POM zu programmieren oder sie programmieren zu wollen - unabhängig davon, welche CV-Werte man ändern möchte.

Ich selbst war in der Software-Entwicklung tätig und möchte die beiden Anschlüsse Main-Track und Prog-Track der Test- und der Produktionsmaschine in meinem Beruf gleichsetzen. Wäre einer meiner Berufskollegen jemals auf die Idee gekommen, Änderungen im Programm oder in deren Abläufen direkt auf der Produktionsmaschine vorzunehmen, der hätte instantan seine 7 Sachen zusammen packen können und sich um einen anderen Job bemühen müssen.

Und genauso handhabe ich es hier auf meiner Modellbahn. Ganz gleich, was die Norm darüber aussagt (danke an Arnold Hübsch an dieser Stelle für sein Engagement) und genauso egal, was die Hersteller sich darüber hinaus haben einfallen lassen - für mich ist die Anlage zum Programmieren tabu. Denn nur so kann ich mir zu 100% sicher sein, dass ausschließlich jene Lok von den Änderungen betroffen sein kann, die zum Zeitpunkt am Programmiergleis steht.

Herby

Herby, das liegt halt einfach daran, dass die Modellbahn keine Produktionsmaschine ist und kein Schaden in der Produktion entstehen kann, wenn etwas beim Programmieren schief geht. Die Programmierung via POM ist äußerst sinnvoll, um schwierigen Motörchen Manieren bei zu bringen. Das geht nur während der Fahrt, außer du hast zu viel Zeit. Soll ja vorkommen.

Gruß an den Rest,
Kolomna

Hallo Herby,

an erkläre mir bitte, wie ich die Programmierung an einem Fahrzeug (meist Triebwagengespann) ändern kann, dass über einen Fahr- und einen Funktionsdekoder verfügt. Zumindest bei meiner Decoder-Zentralen-Kombination kommt da auf dem Programmiergleis nur einer Fehlermeldung.

Es ist nicht so, dass ich es nicht auch lieber so machen würde, ich wüsste nur momentan nicht wie. Also wenn Du die Lösung hast, gerne nur her damit

Gar keine Möglichkeit sehe ich für das änden der CV19 für das Bilden einer Doppeltraktion. Da geht es ja gerade darum, das Fahrzeug nicht vom Gleis zu nehmen.

Viele Grüße

Dirk

Hallo Dirk,

mir hat dieser Link oft geholfen, vor allem bei den langen Adressen.


https://www.opendcc.de/info/decoder/dcc_cv.html

Gruss,
Gerd

Super, Danke für den Link Gerd!

Das ist genau das was ich suche

Dirk

@Herby: zb Lautstärke ändern ist über POM überaus sinnvoll, detto Min/max Geschwindigkeit und andere Feineinstellungen wie Dimmwerte für die LEDs.

Du willst ja auch nicht die Stereoanlage neu starten müssen, nur wenns ein wenig lauter oder leiser werden soll.

Der Vergleich mit der Produktionsmaschine hinkt gewaltig. Äpfel und Birnen. ( OT: Ich habe übrigens selber schon an Produktionsanlagen für einen Weltmarktführer in der Glas-Branche mitgebaut mit weit über 6000 Parametern pro Artikel, mit mehreren verschiedenen Artikel gleichzeitig in der Anlage. Diese Parameter werden allesamt zur Laufzeit verändert sobald das Werkzeug den entsprechenden RFID-Leser passiert. Stichwort "Rezept". Reduktion der Umrüstzeiten. Dazu kommen noch die Kompensationsparameter pro eingelegtem Werkzeug, welches jedes einzelne vorher auf einem eigenen Prüfstand auf Abweichungen und Toleranzen vermessen worden ist. Anders wäre die geforderte Bearbeitungsgenauigkeit von <10 Micron überhaupt nicht erreichbar gewesen. Hätte da jemand erzählt "zur Laufzeit bloss nix ändern", der hätte das Bewerbungsgespräch nicht überstanden und erst gar keine 7 Sachen auspacken können. )

vg
Gerhard

@ Dirk #19

Irgendwie hab ich die Problematik nicht verstanden. Warum genau geht das nicht am Prog-Gleis, aber am Main-Gleis schon?

Herby

@ Gerhard #24

Bequem mag es sein, ob es sinnvoll ist, halte ich persönlich für strittig. Ich habe zuletzt die Dimmwerte für meine Loks sehr wohl perfekt am Prog-Gleis eingestellt.

Gut, für mich selbst war es sogar so bequemer, weil ich das alles über den PC erledige und ich mir mein Prog-Gleis direkt vor die Tastatur platzieren kann. So sehe ich unmittelbar, was ich mache. Ansonsten müsste ich mich mitunter verrenken, um zu sehen, wie hell die LEDs sind ...

Und ähnlich wird es wohl mit der Lautstärke vom Sound sein, auch das kann ich am Prog-Gleis genauso abschätzen. Und wenn das Prog-Gleis lange genug ist, kann ich auch die Geschwindigkeit gut einstellen.

Wie eingangs gesagt: es mag bequemer sein, die Lok zum Programmieren nicht von der Anlage nehmen zu müssen - aber _ich_ werde es dort nicht tun.

Herby

Hallo zusammen

Ich habe schon oft eine Lok zusammen mit einem Steuerwagen aufs Programmiergleis gesetzt und eine gemeinsame Adresse eingegeben.Hat immer funktioniert.Dabei brauche ich die Fahrzeuge nicht einmal vom Gleis zu nehmen weil ich ein Bahnhofsgleis komplett vom Rest der Anlage trennen kann.So kann ich anschl. gleich die eingebenen Werte testen.(Fahre mit Multi/Wlanmaus und z21).
Für mich kommt deshalb POM garnicht in Frage.

Gruß  Udo

Hallo zusammen,



Beim Programmieren auf dem Prog-Gleis liest und gibt die Daisy II immer vorher den bestehenden Wert aus. Vermutlich klappt das nicht, wenn sie auf einmal zwei Rückmeldungen bekommt. Zumindest gibt es eine Fehlermeldung. Wenn ich trotzdem den Wert ändere, hat das keine Auswirkung auf den Decoder.

Beim Pom wird die CV ja nur überschrieben und nicht ausgelesen. Da die Zentrale einfach Fire and Forget ins Gleis haut und alle Decoder mit der gleichen Adresse das aufnehmen, geht das da.

(So ist zumindest meine These, warum das geht)

Viele Grüße

Dirk

@ Dirk

Was machten und machen die Modellbahner seit gefühlt ewigen Zeiten, wenn sie eine Lok mit Spannung versorgen wollten und eine andere nicht? Genau: Sie teilen das Gleisstück in mehrere getrennte Spannungsbereiche auf. Sprich: Es ist meiner Meinung nach nicht wirklich viel sooo viel Aufwand, eine Trennstelle am Programmiergleis vorzunehmen und diesen Bereich, beispielsweise mit einem simplen Schalter, ein- und auszuschalten, je nach Situation. Dann kann die eine Lok/der eine Wagen eben stromlos geschaltet werden, während der andere programmiert wird und vice versa. Notfalls ginge das sogar mit einem Küchentuch aus Papier oder einem Taschentuch, welches man zwischen Achsen und Gleis legt. Einfach seine Fantasie walten lassen.

Wie ich oben schon schrieb: bequemer mag das Main-Gleis sein, in meinen Augen sicherer ist aber das Prog-Gleis. Und ich glaube nicht, dass es einen Fall gibt, der grundsätzlich _nicht_ am Programmiergleis lösbar wäre.

Herby

Hilft Dir aber nicht bei elektrisch verbundenen Fahrzeugen...

Vielleicht bin ich da auch ein Einzelfall, für die es sich nicht lohnt, etwas anders zu machen, aber zumindest habe ich mehrmals den Anwendungsfall, dass ich zwei Decoder gleichzeitig ändern will - ggf. auch die Adressen. Aber da es ja bei mir über POM zu klappen scheint und ich von Gerd den hifreichen Link bekommen habe, ist das Thema ja auch nun erledigt

Viele Grüße

Dirk

PS: edit:
: Trennen/Verbinungen von Doppeltarktionen mit VC19? Es geht zwar am Programiergleis, aber wenn ich im Betrieb zwei Fahrzeuege kuppeln und Trennen möchte, muss es ja auf dem Gleis sein

@ Dirk

Klar, das ist Streiten um des Kaisers Bart, wie man bei uns so schön sagt. Sollte ich doch irgendwann mal einen Fall haben, wo ich die Programmierung _nicht_ am Programmiergleis schaffe, dann würde ich eher den Main-Ausgang an das Programmiergleis hängen, um dennoch sicher sein zu können, dass nur die eine Lok oder das eine Gespann betroffen sein kann. Aber ich neige ja allgemein dazu, übervorsichtig zu sein.

Herby

Hallo,

auch wenn manche das Feature, CV1 über POM programmieren, nicht gutheißen:

Mir ist noch ein Anwendungsfall untergekommen: Da ich demnächst mehrere (viele) Loks mit Decoder gleichen Typs mit einer gleichen Geschwindigkeitskennlinie versehen möchte, könnte ich allen temporär die gleiche Adresse geben und sie somit gleichzeitig programmieren, am Ende die Adresse zurückstellen. Das geht mit CV-Programmierung nicht.

Viele Grüße
Frank

Bei POM am Hauptgleis wird ein Befehl an den Decoder geschrieben der über die Adresse angesprochen wird. Wenn man jetzt in einer CV was Ändert hat man das Problem es ist unbestimmt wann diese Änderung aktiv wird. Nehmen wir an sofort. Wenn man also CV17/18/29 ändern muß um von einer kurzen zu einer langen Adresse zu kommen an welche Adresse sendet man die 2. CV und 3. CV Änderung? Man könnte vereinbaren es müssen alle 3 beschrieben werden, erst dann ändert sich die Adresse oder es dauert zumindest 10 Sekunden. Was aber wenn beim Programmieren die Lok wegen Verschmutzungen in der Mitte der Sequens stromlos wird?

Bei ServiceMode also Programmiergleis Programmierung sind die Kommandos am Gleis völlig anders. Vor allem sind die Befehle ohne einer Adresse. Also etwa so: egal welche Adresse Du lieber Decoder jetzt hast Du schreibst in CV17/18/29 die folgenden Werte. Darin liegt der große Unterschied.

Ohne Zweifel kann man mit POM vieles leichter erledigen nur ohne funktionierendem RailCom ist es immer Blindflug. Gemessen an den Fragen dieses Threads ist wohl mehr als klar daß es viele der hier Fragenden völlig überfordert. Daher bitte noch etwas Geduld, wenn Lokanmeldeverfahren genormt sind wird's einfacher.
-AH-

Ich habe es schon in den RP gelesen, finde es aber nicht mehr. Wenn jemand mit besserer Übersicht als ich hier nochmal schreiben würde wo in den RP und in den RCN das denn genau steht wär ich dankbar.

Grüße,
Harald.

PS: Übersetzungen sind immer so eine Sache. Ich finde es etwas problematisch, wenn man eine bekannte Definition aus den RP ("6ms +/- 1ms" [RP 9.2.3 Zeile 48]) dann in der deutschen Variante anders beschreibt ("eine Zeitspanne von 5 bis 7 ms" [RCN216 Seite 4]) weil der deutsche Text dann keinen Wert, der erstrebt werden soll, mehr beinhaltet. Aber Lenz gefällt das wahrscheinlich, weil da der Puls traditionell nur 5ms lang ist. Nach der RP ist das grenzwertig, nach der RCN OK. Am besten wär es, wenn es nur eine Variante in Englisch gäbe. Bei den RFC (Definition der Standards fürs Internet) brauchen wir ja auch nicht noch eine deutsche (französische? russische? chinesische?) Variante.