Benutzer:Mobafreund/C-Digitalsystem, Conrad Digital
C-Digitalsystem oder kurz "C-Digital" ist der Name für eine digitale Mehrzugsteuerung für Modelleisenbahnen, die von dem Ingenieurbüro Techniklabor Grünwald Mitte der 1990er Jahre entwickelt wurde. Das System wurde erstmals 1998 unter dem Namen "Conrad Digital" der Öffentlichkeit vorgestellt und durch den Elektronik-Versandhändler Conrad Electronic SE in den Vertrieb gebracht. Im Jahr 2004 wurde das System wieder aus dem Programm genommen.
Das C-Digitalsystem ist ein echtes Gleichstrom-Digitalsystem, welches den C-Digital-Bus mit dem gleichnamigen C-Digital-Protokoll zum Informationsaustausch mit Decodern und anderer Peripherie nutzt. Dieser C-Digital-Bus basiert auf einem digital amplitudenmodulierten Signal, das auf eine reine Gleichspannung zwischen 11 Volt und 16 Volt im On-Off Keying (OOK) Verfahren aufmoduliert ist. Bei dem C-Digital-Bus sind die "Langsamfahrt" und der fahrrichtungsabhängige "Halt" als digitale Informationsbits in das Protokoll integriert. So lässt sich ein automatisches Halten vor Signalen ohne zusätzlichen Aufwand an elektronischen Baugruppen in eine Anlage einbringen und zu einer realistischen Blockstreckensteuerung ausbauen. [1]
Funktionsprinzip
[Bearbeiten | Quelltext bearbeiten]Entstehungsgeschichte
[Bearbeiten | Quelltext bearbeiten]Der Uhrsprung des Systems liegt in einer in den 1980er Jahren entwickelten frequenz-gesteuerten Mehrzugsteuerung. Mit dem Anspruch eine digitale Mehrzugsteuerung mit Automatikfahrt-Möglichkeit und einfach zu integrierendem Blockstreckenbetrieb zu haben, wurde Mitte der 1990er Jahre die digitale Mehrzugsteuerung "Conrad Digital" von dem Ingenieurbüro Techniklabor Grünwald[1] entwickelt. Um dem Anspruch gerecht zu werden wurde ein eigener Datenbus (C-Digital-Bus), und im Zuge dessen auch ein eigenes Protokoll (C-Digital-Protokoll) ins Leben gerufen. Da die Datenübertragung zu den Decodern mit dem C-Digital-Bus technisch anders funktioniert als bspw. bei Digitalsystemen wie "Märklin Digital" oder DCC Digitalsystemen, war das "Conrad Digital" System (und ist auch das weiterentwickelte "C-Digitalsystem") zu diesen inkompatibel.[2][3][4]
Das System entstand zu einer Zeit, in der es noch kaum herstellerübergreifende Normen zu digitalen Mehrzugsteuerungen gab. So hat man sich bei der Entwicklung von "Conrad Digital" an keinen externen Vorgaben orientiert. Maßgebend waren die folgenden 10 wichtigsten Punkten:
- adressgesteuerter Mehrzugbetrieb
- Integration einer Blockstreckensteuerung mit überschaubarem Aufwand
- automatisches originalgetreues Bremsen und Wiederanfahren vor roten Signalen
- auf der ganzen Anlage uneingeschränkter Zugriff auf alle mit Decodern ausgerüsteten Fahrzeuge (Fahrbetrieb und Programmierung)
- Handsteuergeräte mit Haptik
- Anbindung an einen PC über ein entsprechendes Interface
- zur Umrüstung von Gleich- und Wechselstromsystemen (2-Leiter- und 3-Leitersystemen)
- modulares, erweiterbares System über Booster und mehrere Fahrgeräte
- Möglichkeit Systemkomponenten in Form von Bausätzen zum Selbstbau
- ausschließliche Verwendung von standard Elektronikbauteilen (keine speziell angefertigten Microchips)[5]
Im Jahr 1998 wurde das System schließlich unter dem Namen "Conrad Digital" als neue digitale Mehrzugsteuerung der Firma Conrad Electronics SE der Öffentlichkeit vorgestellt[5]. Die Fertigung der verschiedenen Systemkomponenten übernahm der Elektronik-Dienstleister H-Tronic. Nach 6 Jahren stellte die Firma Conrad Electronics SE 2004 den Vertrieb ein und lies den Service auslaufen. Seitdem übernimmt das Ingenieurbüro Techniklabor Grünwald den Service und führt das System unter dem Namen "C-Digital" bzw. "C-Digitalsystem" fort.
So entstanden seit 2012 Neu- und Weiterentwicklungen wie das PC-Interface mit der zugehörigen Software CDC[6] (C-Digital Control), neue Lokdecoder mit verschiedenen Schnittstellen nach NMRA-Norm aber auch eine Adressraumerweiterung und ein vergrößerter Umfang bei Decoder-Zusatzfunktionen.
Aufgrund der Inkompatibilität zu anderen digitalen Modelleisenbahnsteuerungen ist der Verbreitungsgrad und Marktanteil sehr gering, trotz vieler technologischer Vorteile. Das DCC-Protokoll hatte sich in den 1990er Jahren bereits stärker etabliert und wurde von der NMRA als Norm anerkannt, woraufhin eine Reihe an Digitalformaten (Fleischmann FMZ, Zimo Digital, ...) ausstarben. Das "C-Digital" System hat aufgrund seiner technischen Besonderheiten lediglich als Nieschenprodukt überlebt, weshalb Neuerungen aktuell nur in Kleinserien hergestellt werden.
C-Digital Zentrale (CDZ) / Booster
[Bearbeiten | Quelltext bearbeiten]Zentrale
[Bearbeiten | Quelltext bearbeiten]Die Zentraleinheit, kurz "Zentrale", bildet das Gehirn des Systems. An ihr werden mit Diodensteckverbindern die Handsteuergeräte, ggf. ein PC-Interface und ein Funk-Interface über einen I²C-Bus als Slaves an die Zentrale (Master) angebunden. Außerdem erzeugt sie das C-Digital-Bus Signal, das auf drei unterschiedlichen Leitungen ausgegeben wird. Eine STR-Leitung (Strecke) die Betriebsdaten ohne Halteinformation enthält, eine UZ- (Uhrzeigersinn) und eine GUZ-Leitung (Gegenuhrzeigersinn), die neben den Betriebsdaten je eine Halteinformationen für jede Fahrrichtung enthalten und eine Masse-/COM-Leitung als Bezugspotential. Die Zentrale ist als reine "Black-Box-Zentrale" konzipiert und verfügt neben der Start- und Reset-Taste über keine weiteren interaktiven Bedienelemente. Neben einem Stromanschluss gibt es noch einen 9-poligen Sub-D Anschluss zur Verbindung mit einem Booster. Als Stromversorgung wird ein Netztrafo mit 18 Volt AC und 50 Watt Leistung empfohlen. Sollte im Fall von größeren Anlagen mehr Leistung benötigt werden, so ist ein Booster oder sind mehrere Booster vorzusehen, deren Stromversorgung jeweils über eigene Netztrafos erfolgen muss.
Booster
[Bearbeiten | Quelltext bearbeiten]
Handsteuergeräte
[Bearbeiten | Quelltext bearbeiten]HRX20 / HRX20 Funk
[Bearbeiten | Quelltext bearbeiten]
Digital Control ("Walk-Arround-Control")
[Bearbeiten | Quelltext bearbeiten]
C-Digital-Protokolle
[Bearbeiten | Quelltext bearbeiten]Ursprüngliches Protokoll
[Bearbeiten | Quelltext bearbeiten]Ein Datensatz des ursprünglichen Protokolls besteht aus zwei aufeinanderfolgenden Doppel-Bytes (16 Bit) mit je einem Zusatzbit (Z-Bit) als Ergänzung. Wobei das zweite Doppel-Byte mit dem zweiten Z-Bit eins zu eins die gleichen Informationen wie das erste Doppel-Byte mit Z-Bit enthält und nur zur Datensicherheit dient. Zur Synchronisation muss vor jeder Datenübertragung ein Start-Bit gesendet werden, damit die Decoder erkennen können, wo ein Datensatz beginnt.
In den 16 Bit reinen Informationsgehalts werden nach den Mode-Bits (2 Bit) 64 (6 Bit) Empfänger-/Decoderadressen unterschieden auf die im Fahrbetrieb entweder 32 Fahrstufen (5 Bit) mit der Fahrrichtung (1 Bit) oder vier Massensimulationsstufen (2 Bit), drei Zusatzfunktionen (3 Bit) und ein Automatikfahrt-Bit (1 Bit) gesendet werden. Welche Information auf die Decoderadresse folgt, entscheiden die Mode-Bits (Fahren mit Geschwindigkeit oder mit Zusatzfunktionen oder Programmierparameter). Unabhängig von den Mode-Bits, folgt in den letzten beiden Bits des Doppel-Bytes immer die Information über Signalhalt in Fahrrichtung rechts oder links nach dem Broadcast-Prinzip.
Aus dem Adressraum von eigentlich 64 Decoderadressen (6 Bit), sind die Adressen '0', '62' (neutral) und '63' (Nothalt) ausgenommen. So bleiben 61 Adressen zur freien Vergabe.
Das Z-Bit dient zur Unterscheidung von Fahrzeugdecodern mit anderen Decodern, die zur Steuerung von Peripherie gedacht sind.
Die Programmierung von Decodern erfolgt ausschließlich über Codes (Programmierparameter), wobei ein Code meistens mehrere Einstellungen programmiert.
Informationsgehalt ursprüngliches Protokoll | |
---|---|
Adressraum | 61 + (62 (neutral), 63 (Nothalt)) |
Fahrstufen | 32 (Fahrstufe 0 bis 31) |
Funktionen | 2 + Rangierfahrt |
Massensimulationsstufen | 4 |
Halteinformationen | 4 |
Erweiterungen
[Bearbeiten | Quelltext bearbeiten]Da das erweiterte Protokoll strukturell unverändert ist, ist es vollständig kompatibel zu dem ursprünglichen Protokoll. Auch die reine Anzahl an Bits (34) je einer Sendung entspricht der des ursprünglichen Protokolls. Die Erweiterungen werden nur von Decodern des Typs "56x", "56 LGB", "57x" und "NZ47" erkannt und ausgewertet.
Neben den Erweiterungen ist hier die halbduplexe Kommunikation mit den Decodern integriert. Damit ist es Decodern möglich, auf der selben Trägerfrequenz Informationen auf den Datenbus zu geben. Diese sogenannte Rückmeldung muss von der Zentrale eingeleitet werden. Das vorhanden sein eines Decoders mit seiner spezifischen Adresse, wird von diesem immer mit dem sogenannten Acknowledge-Bit (ACK-Bit) bestätigt, sobald dieser einen Datensatz für seine Adresse empfängt.
Ab diesem Protokoll ist die Programmierung eines Decoders über einen Code (Programmierparameter) und einen Wert eingepflegt. Es gibt nur noch vereinzelt Codes, die ohne einen Wert Einstellungen vornehmen, so z.B. die Decoder Resets oder die Bremsweglängen für das automatische Anhalten.
Informationsgehalt ursprüngliches Protokoll (erweitert) | |
---|---|
Adressraum | 99 + (62 (neutral), 63 (Nothalt)) |
Fahrstufen | 32 (Fahrstufe 0 bis 31) |
Funktionen | 4 |
Massensimulationsstufen | 4 |
Halteinformationen | 4 |
Neues Protokoll
[Bearbeiten | Quelltext bearbeiten]Da beim neuen Protokoll die Struktur zum Ursprünglichen nur geringfügig anders ist, ist dieses auch vollständig kompatibel zu dem ursprünglichen Protokoll und dessen Erweiterung. Es wird nur von Decodern ab Decoder-Typ "58x" ausgewertet und beinhaltet auch die halbduplexe Kommunikation mit den Decodern, wodurch die Decoder in der Lage sind auf Anfrage der Zentrale Informationen rückzumelden. Dies kann im laufenden Betrieb ohne Einschränkungen überall auf der Analge erfolgen. Das vorhanden sein eines Decoders mit seiner spezifischen Adresse, wird von diesem immer mit dem sogenannten Acknowledge-Bit (ACK-Bit) bestätigt, sobald dieser einen Datensatz für seine Adresse empfängt.
Die minimale Länge eines Datensatzes liegt bei 34 Bits, die maximale aktuell bei 47 Bits. Da ein spezifisches Datenpaket aus 13 Bit besteht, kann der minimale Datensatz in 13 Bit Schritten - als Anhang bezeichnet - verlängert werden. Begrenzt wird dieser nur von der maximalen Dauer von 100 ms, die eine komplette Sendung benötigen darf. Für die ursprüngliche Baudrate von 1.546 Bd des C-Digital-Bus bedeutet das eine maximale Datensatzlänge von etwa 64 Bits. Bei höheren Baudraten skaliert sich dieser Wert entsprechend.
Die Datensicherheit wird hier durch eine Prüfsumme (Checksum), auch "Prüfinfo" genannt, sichergestellt, die aus einer XOR-Verknüpfung der Adress- plus Mode-Bits (13 Bit) mit dem Anhang (13 Bit) besteht. Die per Broadcast versendete Halteinformation ist, wie ursprünglich, durch reines Wiederholen abgesichert. Eine Korrektur eines fehlerhaften Datensatzes findet nicht statt. Fehlerhafte Datensätze werden verworfen.
Informationsgehalt neues Protokoll | |
---|---|
Adressraum | 1022 + (0 (neutral), 1023 (Nothalt)) |
Fahrstufen | 32 (Fahrstufe 0 bis 31) |
Funktionen | 14 |
Massensimulations-/
Bremsstufen |
8 |
Halteinformationen | 4 |
C-Digital-Bus
[Bearbeiten | Quelltext bearbeiten]Allgemein:
[Bearbeiten | Quelltext bearbeiten]Der C-Digital-Bus ist der Datenbus der am Gleis liegt und zum Informationsaustausch zwischen der Zentrale und den Decodern dient. Dabei handelt es sich um ein digital amplitudenmoduliertes Signal mit der Trägerfrequenz 450 kHz, das auf eine reine Gleichspannung zwischen 11 Volt und 16 Volt im On-Off Keying (OOK) Verfahren (Amplitudenumtastung) aufmoduliert ist. Diese Technik erlaubt es auf unterschiedlichen Trägerfrequenzen unterschiedliche Protokolle mit unterschiedlichen Informationen simultan zu betreiben. Aktuell (2019) wird nur eine Trägerfrequenz bei 450 kHz genutzt.
Die Gleichspannung zwischen 11 und 16 Volt dient der Eneregieversorgung der Empfängerbausteine (Decoder). Der Informationsaustausch erfolgt über das aufmodulierte Datensignal, dessen Amplitude bei etwa 400 mV (< 3% Gleisspannung) liegt. Die bisherige Baudrate beträgt 1.546 Bd, woraus sich ein reiner Datendurchsatz von 840 Bit/s ergibt. Eine logische Eins oder Null ergibt sich aus der Länge des High-Pegels im Datensignal. So entspricht die Länge eines 200 μs High-Pegels gefolgt von einem 400 μs Low-Pegel einer '0', 400 μs eines High-Pegels gefolgt von 200 μs eines Low-Pegels einer '1' und ein 800 bis 1400 μs langer Hig-Pegel einem Startimpuls. Die Bus-Geschwindigkeit kann bei gleicher Metrik verändert werden. So ergibt sich rein rechnerisch bei doppelter oder vierfacher Busgeschwindigkeit ein Datendurchsatz von 1.680 Bit/s oder 3.360 Bit/s (3,36 kBit/s = 0,42 kByte/s).
Ab Decoder Typ 57x spielen die konkreten Zeiten für ein Eins- oder Null-Bit nur eine untergeordnete Rolle. Die Decoder orientieren sich automatisch an den empfangenen Zeiten der unterschiedlichen Bits. Wichtig ist, dass die Metrik des Protokolls eingehalten wird. Auf diese Weise ist es möglich die Übertragungsgeschwindigkeit im laufenden Betrieb zu ändern, da sich die Decoder automatisch darauf einstellen. So ist auch die erhöhte Übertragungsgeschwindigkeit mit einem 100 μs High-Pegel gefolgt von einem 50 μs Low-Pegel zur Übertragung einer logischen '1' und entsprechend ein 50 μs High-Pegel gefolgt von einem 100 μs Low-Pegel zur Übertragung einer logischen '0' möglich. Dadurch ergibt sich eine Symbolrate von 5.714 Bd, wobei der reine Datendurchsatz, bezogen auf einen Datensatz mit 18 Bit, bei 3.101 Bit/s liegt.
Die Bus-Geschwindigkeit ist ähnlich dem Selectrix-Bus praktisch immer konstant und nicht wie bei Märklins mfx oder dem DCC Protokoll von der Aktivität auf dem Bus abhängig. Bei Vollauslastung mit 61 aktiven Decoderadressen und einem Datensatz eines Decoders aus 18 Bit pro Empfang, erfolgt mit einem Datendurchsatz von 840 Bit/s spätestens alle 1,3 Sekunden eine Aktualisierung der Steuerungsinformationen aller Decoder. Da die Zentrale die gesendeten Datensätze priorisiert, je nachdem ob eine Änderung im Datensatz vorhanden ist (bspw. durch eine Änderung der Geschwindigkeit oder einer Funktion), dauert es nur dann 1,3 Sekunden, wenn bei allen 61 Decoderadressen nahezu zeitgleich eine Änderung an den Steuerdaten vorzunehmen ist. Da das allerdings schon aus der beschränkten Anzahl gleichzeitig verwendbarer Handsteuergeräte (zur aktiven Änderung von Steuerdaten für alle möglichen Lokadressen) unrealistisch ist, können nur maximal 14 Adressen gleichzeitig adressiert sein (2 Decoderadressen simultan pro maximal 7 Handsteuergeräte = 14 Adressen). Damit ist spätestens nach 1/3tel Sekunde ein Datensatz aktualisiert, was dem Bus Echtzeitfähigkeiten verleiht. Die per Broadcast versendete Halteinformation ist von Aktualisierungs-Latenzen ausgenommen.
Stärken:
[Bearbeiten | Quelltext bearbeiten]- Der Bus kann neben einer unidirektionalen simplexen Datenübertragung auch eine bidirektionale halb- und vollduplexe Datenübertragung bewerkstelligen. Für eine vollduplexe Datenübertragung werden für die unterschiedlichen Übertragungsrichtungen allerdings zwei verschiedene Trägerfrequenzen benötigt.
- Der Bus erlaubt einen uneingeschränkten Einsatz auf der kompletten Anlage, auch über abgetrennte Halte-, Brems- oder Langsamfahrabschnitte hinweg.
- Das Einrichten von Langsamfahr- oder Brems/Halteabschnitten unterliegt grundsätzlich keinerlei Zwängen.
- Für eine automatische Signalhalt- oder Langsamfahrterkennung wird außer dem Fahrzeugdecoder in der Lok keine weitere Hardware am Gleisabschnitt benötigt.
- Es spielt im Betrieb keine Rolle, ob sich der Informationsgehalt (die Bitfolge) zwischen zwei Abschnitten unterscheidet. Dies hat zur Folge, dass ein Decoder bspw. auch in einem Halteabschnitt vollständig bedienbar bleibt und auch programmiert werden kann.
Schwächen:
[Bearbeiten | Quelltext bearbeiten]- Die Decoder müssen über eine entsprechende Empfangsschaltung zur Demodulation das Bussignals verfügen.
- Um das Datensignal nicht kurzzuschließen, muss beim Betreiben von kapazitiven Elementen (z.B. Pufferkondensatoren) am Bus eine Spule zum Entkoppeln des HF-Signals vorgesehen werden.
- Der C-Digital-Bus ist inkompatibel zu anderen Digitalprotokollen wie mfx, DCC, Märklin Motorola, Selectrix, FMZ, ...
Computer Interface
[Bearbeiten | Quelltext bearbeiten]Decoder für Triebfahrzeuge
[Bearbeiten | Quelltext bearbeiten]Grundsätzlich sind die verschiedenen Decoder (Informationsempfänger) für Triebfahrzeuge zu deren internen Steuerung gedacht. Sie übernehmen die Steuerung/Regelung der Motoren und können das Spitzenlicht und weitere Zusatzfunktionen schalten. Dabei lassen sich verschiedene Funktionalitäten per Programmierung im Decoder einstellen. Jeder Deocder ist auf eine spezifische Adresse (Lokadresse, Fahrzeugadresse) programmiert, unter der man diesem gezielt Steuer- oder Programmierbefehle senden kann. Welchen Funktionsumfang und technische Leistungsdaten ein Decoder mitbringt, ist vom verwendeten Decodertyp abhängig.[7]
Decoder 56x
[Bearbeiten | Quelltext bearbeiten]Dieser Decodertyp war der erste C-Digital Decoder mit einer Motor Lastregelung (Lastregelausgleich). Diese sorgt dafür, dass der Decoder automatisch die Energiezufuhr zum Motor der benötigten Leistung anpasst. So wird die Energiezufuhr bspw. bei einer Bergfahrt erhöht und bei einer Talfahrt reduziert. Aber auch die Langsamfahreigenschaften werden dadurch verbessert, weil ein städiges Nachregeln der Ist- an die Soll-Geschwindigkeit geschieht[8]. Weiterhin wurde bei diesen Decodern erstmalig das Programmieren über "Codes" mit einem dazugehörigen "Wert" eingeführt, wodurch sich die Anzahl an Konfigurationsoptionen im Vergleich zu älteren Decodern deutlich steigern lies.[9]
Neben den zwei Motorausgängen gibt es zwei Ausgänge für die Spitzenbeleuchtung und drei zusätzliche Funktionsausgänge, wobei einer unverstärkt erfolgt. Diesen Decoder gibt es in Ausführung für folgende Schnittstellen: 6-polig (NEM 651), 8-polig (NEM 652), 21MTC (NEM 660), PluX16 (NEM 658)[9]
Profi/Eco Decoder
[Bearbeiten | Quelltext bearbeiten]
Decoder für Großspuren (Spur G, Spur 0, Spur 1)
[Bearbeiten | Quelltext bearbeiten]
Einzelnachweise
[Bearbeiten | Quelltext bearbeiten]- ↑ a b C-Digital Systembeschreibung (pdf). In: www.c-digitalsystem.de/Dokus. Dipl. Ing. Univ. Achim Grünwald, 12. Februar 2015, abgerufen am 1. Juni 2019.
- ↑ Benutzerhandbuch (pdf). In: www.c-digitalsystem.de/Dokus. Dipl. Ing. Univ. Achim Grünwald, 2018, abgerufen am 3. Juni 2019.
- ↑ Digital Command Control. In: Wikipedia - die freie Enzyklopädie. Wikimedia Foundation Inc., abgerufen am 3. Juni 2019.
- ↑ Märklin Digital. In: Wikipedia - die freie Enzyklopädie. Wikimedia Foundation Inc., abgerufen am 3. Juni 2019.
- ↑ a b Benutzerhandbuch Zentrale. In: Conrad Electronic Download Center. Abgerufen am 1. Juni 2019.
- ↑ Handbuch PC-Software CDC (pdf). Dipl. Ing. Univ. Achim Grünwald, abgerufen am 3. Juni 2019.
- ↑ Modellbahndecoder. In: Wikipedia. 31. Mai 2018 (wikipedia.org [abgerufen am 4. Juni 2019]).
- ↑ Wie arbeitet die Lastregelung? In: www.der-moba.de. Abgerufen am 3. Juni 2019.
- ↑ a b Decoder 56. In: www.c-digitalsystem.de/Decoder_56. Abgerufen am 3. Juni 2019.
Weblinks
[Bearbeiten | Quelltext bearbeiten]- C-Digital Steuerung
- Handbuch C-Digital
- C-Digital Leistungsübersicht pdf-Datei
- Modelleisenbahnsteuerung
- Normen europäischer Modellbahnen
- NEM (Normen europäischer Modellbahnen) auf der Internetseite der MIBA
- https://modellbahn.mahrer.net/technisches/zentralen/186/Techniklabor+Gr%C3%BCnwald+C-Digital/
- https://modellbahn.mahrer.net/technisches/zentralen/41/Conrad+Conrad-Digital/
- http://www.hpw-modellbahn.de/digitalsysteme/digitalsysteme08.htm
- Digital Command Control (DCC)
- Selectrix
- Märklin Digital
- Lastregelung bei Modellbahndecodern auf der Internetseite www.der-moba.de/