THEMA: DCC Datenpaket

Address Data Byte   XOR   Instruction Data Byte

Aus der NMRA Standard S-9.2 ( http://www.dcc.info/standards_rps/s92.html ):


"Error Detection Data Byte = EEEEEEEE  The error detection data byte is a data byte used to detect the presence of transmission errors. The contents of the Error Detection Data Byte shall be the bitwise exclusive OR of the contents of the Address Data Byte and the Instruction Data Byte in the packet concerned.  (e.g. the exclusive OR of bit 0 of the address data byte and bit 0 of the instruction data byte will be placed in bit 0 of the error detection data byte...)  Digital Decoders  receiving a Baseline Packet shall compare the received error detection data byte with the bitwise exclusive OR of the received address and instruction data bytes and ignore the contents of the packet if this comparison is not identical."

>Folgt unmittelbar nach dem "Packet End Bit" ein neues Datenpacket oder gibt es eine Pause?

Soweit ich mich erinnern kann - lang ist's her: es gibt zwischen zwei Datenpakete keine Pause. Die Decoder sollten ja ununterbrochen mit Spannung versorgt bleiben. Allerdings gilt für zwei Datenpakete, welche an die gleichen Decoderadresse gerichtet sind:
"Care must be taken to ensure that two packets with identical addresses are not are not transmitted within 5 milliseconds of each other for addresses in the range between 112-127 as older decoders may interpret these packets as service mode packets (see RP-9.2.3)." (Fußnote 11 aus oben genannten Dokument)

Man kann in so einem Fall z.B. ein "Idle-Paket" einschieben.

Noch mehr Klugscheiss meinerseits:

In http://www.dcc.info/standards_rps/drafts/PFC%20S-92.pdf gibt es allerdings eine rot markierte Erweiterung des in Beitrag 2 zitierten Absatzes:

"Power may also be removed from the rails between
the Packet End Bit and the Preamble of the next packet to allow for alternative command control formats."

Würde ich so interpretieren: ein DCC-Decoder sollte mit so einer Pause zurecht kommen. Aber das ist scheinbar noch ein "draft".

#1
Mich irritierte etwas die Bezeichnung "Error detection ...".
Dieses Byte bezieht sich also nur auf Datenübertragung zum Decoder, ist also ein Kontrollbyte.
Irgendwie kam ich an die Info, das hier Fehlerzustände des Decoders ausgelesen werden könnten, was mir aber sehr unsinnig erschien.

#2

Die Sache mit den aufeinanderfolgenden Packeten an die gleiche Adresse ist auch logisch.

#2 + 3
Wenn ich das richtig deute, ist eine Pause nötig damit das "Packet end Bit" nicht als ein Bit des "Präambel Bytes" ausgewertet wird.

Na gut Gerhard,
das waren doch sehr gute Tips von dir.

Hab vielen Dank,

Günter

Hallo Günter,

Fehlercodes werden in CV30 gespeichert soferne der jeweilige Decoder das unterstützt.

Grüße, Peter W.

Hi Peter,
das mag sein,
aber um solche Feinheiten ging es mir nicht.

Gruß,
Günter

Hallo Günter,

schau mal auf
http://bahn-in-haan.de/_decoder.html
dort ist, wie ich finde, die Sache schön erklärt - sogar ich habs begriffen
Meiner Meinung nach, darf das "1"-Bit mit der das Checksummen-Byte abgeschlossen wird durchaus auch zum Header-Byte mit zugezählt werden.

Gruss
Raimond

Moin zusammen,
vielleicht hilft dem Einem oder Anderen ja auch dieser Link :

DCC Track Sniffer:
http://www.digitoys-systems.com/ShowDCC_e.htm
"ShowDCC Track Packet Analyzer" ist ein tolles, kostenloses Programm, um am Computer zu sehen, was an DCC - Befehlen über's Gleis geht. Die Hardware ist denkbar einfach, es werden 3 Widerstände, 2 Dioden und ein Mikrofonstecker benötigt.

Der Text stammt nicht von mir, ob das Programm also wirklich so toll ist,
lasse ich mal dahingestellt.

Das ganze sieht dann so aus :

http://www.digitoys-systems.com/_borders/ShowDCC.gif

Ob es euch bei eurer Grundlagenforschung hilft wage ich mal zu bezweifeln,
ist aber vielleicht ganz interessant, wenn man selber mal einen Schalt oder Weichendecoder bauen will.

Gruss Dirk
Bei dem sich die 1 ½ Arbeitstage bis zu seinem Urlaub ziehen wie Kaugummi. :-[

Moinsens Dirk,

die Software ist so schlecht nicht und recht sinvoll zum Testen von Decodern und ihrem Verhalten.

Raimund,
du hast schon recht, nur an anderer Stelle stand was von einer Pause (die aber im µS - Bereich liegt). Ich hatte gestern noch die Möglichkeit, mit einem Speicher-Oszilloskop mir mal ein Telegramm anzusehen und eine echte Pause konnte ich auch nicht erkennen.

Dirk, wünsche dir noch einen ruhigen Urlaub und wenn du Fragen zu EAGLE hast, kannst du mich anmailen.

Gruß,
Günter

@Dirk,

also ich würde da UNBEDINGT einen Optokoppler einbauen. Sollte z.B. über ein Interface eine weitere Verbindung zwischen PC und DCC System bestehen, raucht es mitunter.

Grüße, Peter W.

#4
>Wenn ich das richtig deute, ist eine Pause nötig damit das "Packet end Bit" nicht als ein Bit des "Präambel Bytes" ausgewertet wird.

Doch, es ist durchaus erlaubt, keine Pause einzufügen:

In http://www.dcc.info/standards_rps/s92.html#_ftn3 steht:
"The Packet End Bit may count as one of the  preamble bits of the subsequent packet if there are no inter-packet bits."

Ich persönlich würde das ganze so interpretieren: diese Pause ist optional und ein Decoder sollte sowohl mit als auch ohne Pause zwischen  "Packet End Bit" und neues Datenpacket zurecht kommen.

Folgende NMRA DCC Normierungen sind besonders lesenswert:

DCC Standard S-9.1 (Signalbeschreibung)
http://dcc.info/standards_rps/s91.html

DCC Standard S-9.1 (Baseline Paket Format, da werden die hier gestellten Fragen m.E. recht gut erklärt, auch die Fussnoten sind aufschlussreich)
http://dcc.info/standards_rps/s92.html

Recommended Practice RP-9.2.1 (Extended Paket Format, alles was für die moderneren Decode wissenswert ist: 128 Fahrstufen, Mehrfachtraktion, ...)
http://dcc.info/standards_rps/rp921.html

Verzeichnis
http://dcc.info/standards_rps/

@Günter
> die Software ist so schlecht nicht und recht sinvoll zum Testen von Decodern und ihrem Verhalten.

Genau das meinte ich ja auch damit.
Wollte damit auch nur sagen, das ich selber ( noch ) nicht getestet habe.

>Dirk, wünsche dir noch einen ruhigen Urlaub und wenn du Fragen zu EAGLE hast, kannst du mich anmailen.

Ja, danke !
Ich werde garantiert darauf zurückkommen.
Das Buch zu Eagel habe ich mir gekauft und werde es mir im Url.
mal zu Gemühte führen.
Also freue dich, das ich am Wohnwaagen kein I-Net habe
und genieße die drei Wochen Ruhe vor mir und meinen
Anfängerfragen.   

@Peter
Danke für den Tipp !

Durch das DCC Wdec Selbstbauprojekt bin ich in der Tat etwas neugierig geworden.
Wenn mal Zeit ist wollte ich mich mal näher mit AVR’s und deren Programmierung
befassen.
Möchte doch wenigstens ansatzweise verstehen was ich da gebaut habe.
Falls ich da diesen DCC Sniffer einsetze, könntest du oder einer der Anderen Freaks
mir bei der Schaltung des Optokopplers helfen ?
Bin was Elektronik, entwerfen von Schaltungen und Auswahl der Bauelemente ein
echter DAU.  
Hoffe das ändert sich im laufe der Zeit.

Guss Dirk

Dirk,
ich habe vor einiger Zeit mal ein Optokoppler-Interface gebaut welches recht schnell ist und mit low Cost Optokopplern auskommt.
Für DCC reicht es allemal.
Bei Bedarf bitte melden.

Günter