DCC System nach NMRA-Definitionen

DCC System nach NMRA-Definitionen

Lange hat es gedauert, genauer gesagt etwa 20 Jahre, bis ich mich mit DCC näher befasst habe.

Ob es mir nun gefällt oder nicht, ich muss akzeptieren, dass dieses System weltweit wohl am
meisten verwendet wird und von immer mehr namhaften Hersteller als Basis genommen wird.
Der Modellbahner kommt kaum noch daran vorbei.

Von den digitalen Modellbahn-Systemen ist es mit Sicherheit das am besten dokumentierte.
In den zahlreichen NRMA-Dokumenten ist das Gleissignal beschrieben. Als "Quasi-Norm"
dienen die "empfohlenen Verfahren", die "RP's", recommanded practices, die teilweise auch
als Anleitungen verwendet werden können. Zudem befassen sich zahllose Internet-Seiten mit dem
Thema DCC, wovon ich nur die besonders informativen Seiten von Wolfgang Kufer auf www.opendcc.de
nennen will, weil er mir auch persönlich auf die Sprünge geholfen hat, beim Verstehen der teils
"kryptisch" formulierten NRMA-RP's. Dafür, auch von hier herzlichen Dank!

Erste "Gehversuche" mit DCC auf ATMEL Mega8 mit einem ESU-Lokpilot Basic (Nr. 52690)

Dieser Decoder erkennt lt. Beschreibung die Betriebsarten automatisch:

NMRA/DCC mit 14 / 28 / 128 Fahrstufen bei 2-stelligen Adressen.

In NEM 671 sind die DCC-Basics auf Deutsch zu lesen und der Aufbau des DCC-Basis-Datenpaketes
für die Steuerung von Geschwindigkeit und Richtung ist rasch begriffen, weil simpel:

DCC kennt 3 Signalarten für die Bit's:
     das 1-Bit                 ==   58 uSek. negativ und 58 uSek. positiv
     das 0-Bit                 == 116 uSek. negativ und 116 uSek. positiv
     das "lange" 0-Bit   == wie 0-bit mit bis zu 5ms Dauer (oder auch länger ?)

Ein DCC Datenpaket besteht aus:
    Synchronisationsbits            entweder 10 mal 1-Bit oder mehr als 20 1-Bit im Servicemode
    Datenbyte-Startkennung     1 mal 0-Bit
    Datenbyte(s)                         1 bis 4 Stück mit je 8 Bit
    Prüfbyte                                 das Ergebnis der EXOR-Verknüpfung der Datenbytes
    Paketstopbit                         1 mal 1-Bit

Der Decoder braucht seine Adresse und die Fahrinformation, also dieses Mindesttelegramm:

1111111111 0 0AAAAAAA 0 01DCSSSS 0 EEEEEEEE 1
    insgesamt 38 Bit, wobei die Dauer vom Inhalt abhängt.
In den 7 Bit AAAAAAA steht die binäre Adresse, MSB links, zuerst gesendet, LSB rechts,
   die vorlaufende 0 muss auch sein und natürlich das Start 0-Bit
Etwas eigenartig ist das Datenbyte. Der Kennung 01 folgt das Richtungsbit D und 5 Bit für die
   Geschwindigkeit. Weil ich keine Logik erkennen kann verwende ich ein Tabelle mit 32 Byte
    zum Umschlüsseln der 28 Geschwindigkeitsstufen und Stopbefehle.

unsigned char dcc_tab[ ] = {0,2,18,3,19,4,20,5,21,6,22,7,23,
                                                8,24,9,25,10,26,11,27,12,28,13,29,
                                                    14,30,15,31,31,31,31};

Das Prüfbyte ist das EXOR-Ergebnis von Adress- und Datenbyte-Verknüpfung.

Programmaufbau:

Als Zeitbasis für die Bitsequenzen verwende ich den Timer1 des Mega8, der mit Prescale 8 und
8 MHz Clock in Mikrosekunden zählt. Besonders einfach ist dies im MODE 4 == CLC was
Clear on Compare bedeutet. D.h. wenn der Timercounter1 den Wert von OCR1A (oder B)
erreicht, wird TCNT1 auf 0 gesetzt und ein Interrupt erzeugt, sofern freigegeben.

//***************************************************************************
//** Timer1 erzeugt die DCC-Gleisimpulse an PB3 und PB4 ****
//** Gleis auf negativ, Gl -, schaltet bitsend(), Gl +, hier         ****

#pragma interrupt_handler timer1_compa_isr:iv_TIM1_COMPA
void timer1_compa_isr(void)
{
    switch (dcc_stat)
    {

    case 1:
        PORTB &= ~16;     // PB4 PX1 aus, Gl +
        PORTB |= 8;         // PB3 PX0 ein
        dcc_stat = 2;
        break;

    case 2:                      // Bit gesendet
        dcc_stat = 3;
        break;

    default:
        break;
    }
}

//** DCC-Gleis wir hier auf Gl - geschaltet, Gl + im Timer1-Inter. *****
void bitsend (void)
{
PORTB &= ~8;         // PB3 PX0 aus, Gl -
PORTB |= 16;          // PB4 PX1 ein
dcc_stat = 1;
while( dcc_stat != 3) ; // warten bis gesendet
}

Mit diesen beiden Programm-Modulen wird das Gleissignal erzeugt. Fehlt noch das Setzen
von Timer1 vor dem Aufruf von bitsend(). Hier das Beispiel für die Synchronbits aus der
Main-Routine meines ersten Testprogrammes:

for (i = 0; i<10; i++) // Synch senden = 10 x 1-Bit
{
OCR1AL = 57;         // ergibt 58 Mikrosekunden, wegen 8 Takte Int.
bitsend();
}
OCR1AL = 115;      // 0-Bit senden mit 116 Mikrosekunden
bitsend();

Die Datenbytes sende ich so:

tes = 128;
for ( i = 0; i <8; i++)                             // Byte 1 senden
{
if (dcc_byte2 & tes) OCR1AL = 57;   // 1-Bit senden
else OCR1AL = 115;                         // 0-Bit senden
bitsend();
tes = tes >> 1;
}
OCR1AL = 115;                                 // 0-Bit senden
bitsend();

Fehlt noch das Prüfbyte und die Paket-Ende-Kennung:

dcc_pruef = dcc_byte1 ^ dcc_byte2; // Prüfbyte erstellen EXOR

tes = 128;
for ( i = 0; i <8; i++)                             // Prüf-Byte senden
{
if (dcc_pruef & tes) OCR1AL = 57;   // 1-Bit senden
else OCR1AL = 115;                           // 0-Bit senden
bitsend();
tes = tes >> 1;
}
OCR1AL = 57;                                     // 1-Bit senden
bitsend();                                             // DCC-Ende-Bit

Das Testprogramm wird mit dem Hyperterminal via RS232 des Mega8 bedient und
ist nicht ganz 300 Zeilen lang. Es sendet nacheinander drei DCC-Basispakete mit den
Adressen 3, 4 und 5. Bedient wird die Adresse 3, Standard für "frische" Decoder ab Fabrik.

Die Port-Bits passen zur Hardware meiner SX-PX-Mini-Zentrale, sodass die PX-Buchse
das DCC-Signal an den PX-Booster leitet, der diese auch klaglos umsetzt. ( Magnus Booster)
und die Testlok zum Fahren bringt. Vorwärts, Rückwärts, schneller und langsamer, samt SofortStop.

Zwischen den Paketen sende ich "etwas" verlängerte 0-Bit für mein Tec-Scope mit dem
Impulstrigger. Schließlich wollte ich meine ersten DCC-Gleissignale auch sehen.

Erste Erkenntnisse:

Die umgesetzte "NMRA-RP" aus NEM 671 funktioniert auf Anhieb problemlos.
Der Lok-Pilot tut das, was auf dem Beipack-Karton des 17€ Decoders steht.
Die oft kritisierte Lastabhängigkeit des DCC-Gleisprotokolls kann auch ein "Segen" sein,
denn mit wenigen Loks und dem Basis-Paket ist die Refresh-Rate höher als auf dem PX-Bus.
Der Programmaufwand für eine simple DCC-Fahrzentrale ist minimal.

Die Lust auf "Mehr DCC" steigt, die Neugier auf POM (programming on main) ist groß.

Winfried Steinhart, im April2009