OpenDCC - Command Station für DCC

OpenDCC - Eine Zentrale für DCC - FAQ und Change Log

FAQ - häufige Fragen

Was kostet OpenDCC?
Mut und Nerven ;-)
Im Ernst: die Platine kostet 21,90, die Bauteile etwa 30-40 Euro. Platinen lasse ich gelegentlich fertigen, bitte per mail anfragen.
Ich kann leider keine fertigen Zentralen bzw. Bausätze anbieten.
Norbert Martsch hat sich bereit erklärt, Stückliste und ev. Bausätze zusammen zu stellen. Bei ihm gibt es eine ladbare Bestellliste für reichelt.de.
Bei DCC-Versand gibt es einen Bausatz zu kaufen.
Wie viele Loks kann ich mit OpenDCC fahren?
Der integrierte Booster ist nur für 2-3 Loks ausgelegt, die Steuerlogik für max. 64 gleichzeitig fahrende Loks. Mehr ist für DCC wirklich nicht sinnvoll. Es können aber beliebig viele Loks an der Zentrale aufgerufen werden (das wird dynamisch verwaltet) - fahren tun die letzten 64. Natürlich ist diese Grenze im Sourcecode änderbar, wer will, kann auch 200 Loks fahren.
OpenDCC wäre ja ganz schön, aber ich wünsche mir einen Handregler!
Es gibt eine Erweiterung für Xpressnet-Handregler (z.B. Roco® Multimaus®). Dafür wird auch eine bessere CPU benötigt: Statt Atmega32 wird Atmega644P verwendet, wichtig ist der Suffix P, nur diese CPU hat die zweite serielle Schnittstelle. Atmega644-20PU paßt nicht, es muß Atmega644P-20PU sein.
Ich habe eine vorhandene OpenDCC Zentrale, wie kann ich diese für Handregler aufrüsten?
Mit Hilfe eines Xpressnet-Adapters
PC-Port: Kann ich mit der Option "USB+RS232 eingelötet" wahlweise eine der beiden PC-Schnittstellen durch einfaches Umjumpern nutzen?
Ja.
Kann ich auch mit p50x meine Multimaus (über den Xpressnet-Adapter) weiter verwenden?
Ja. Und man kann sogar die Lokdatenbank der Multimaus vom PC aus mit Hilfe des Configtools befüllen. Auch Funktionen der Multimaus F12 bis F20 werden unterstützt.
Wie kann ich meine Loks in den Handregler laden?
Die Roco® Multimaus® bietet die Auswahl der Loks per Namen an. Dies unterstützt OpenDCC mit einer Lok-Datenbank.
Welches Schnittstellenprotokoll muß ich am PC wählen?
Die verschiedenen Baugruppen einer Modellbahn-Steuerung kommunizieren mit Datenverbindungen miteinander. OpenDCC Z1 hat zwei solche Verbindungsmöglichkeiten:
- Schnittstelle zu Handreglern: Diese Schnittstelle wird mit Xpressnet betrieben und erfordert Atmega644P und die Erweiterungsplatine.
- Schnittstelle zum PC: Hier wird eine serielle Verbindung unterstützt (oder eine USB-Verbindung, auf der dann eine virtuelle serielle Verbindung aufgebaut wird). Auf dieser Verbindung sind zwei verschiedene logische Protokollemulationen möglich, das ist aber unabhängig von der Schnittstelle zum Handregler:
  Diese Emulation wird per geladener Software bestimmt und sowohl beim Atmega32 als auch beim Atmega644P mit [b]p50x[/b] vorbelegt. Man wählt also am PC entweder IB oder besser Tams EC. Wenn man an dieser Stelle eine Lenz-Emulation haben will, so muß man in config.h eine Variable ändern, neu übersetzen und die Box neu laden. Beide Emulationen lassen sich nicht zugleich laden.
Unterstützt OpenDCC Märklin®?
Nein. Braucht der "Marktführer" Unterstützung?
Ein Vermischen von DCC und MM würde die excellente Performance von OpenDCC beeinträchtigen.
(Im Module dccout.c ist allerdings eine bisher nicht getestete Implementierung des MM1 und MM2 Protokolls enthalten, diese wird aber nicht vom ORGANIZER angesteuert.)
Unterstützt OpenDCC BiDi (railcom®)?
Ja. Hierzu gibt es Konfigurationsvariablen:
Mit CV25=1 wird die Austastlücke erzeugt; Zudem sind die Befehle für CV-Lesen über BiDi implementiert. Der Rückweg ist dabei nicht in OpenDCC implementiert, sondern wird über ein externes System wie z.B. den GBM16 oder Tams RC erledigt.
Ich habe meine s88 Rückmelder angeschlossen, aber die Anzeige flackert. Was ist falsch?
Vermutlich ist in der Zentrale nicht die richtige Anzahl an Module je Strang eingestellt. Eine andere Ursache kann ein zu schnelles Lesetiming von OpenDCC sein - auch das ist per CV einstellbar. Alle Anbieter von S88-N Modulen sind verpflichtet, das Timing zu veröffentlichen. Bitte sprechen Sie den Anbieter darauf an.
Wie kann ich die Zahl der S88-Rückmeldemodule je Strang einstellen?
Entweder beim Übersetzen, oder durch Einstellen von Spezial-Optionen. Und es gibt auch spezielle IB-Befehle. Die Zuordnung ist wie folgt:
   S88-1 = X10 / X22, "left", von vorn gesehen
   S88-2 = X8 / X23, "middle"
   S88-3 = X9 / X24, "right", von vorn gesehen
Wie kann man Loks programmieren?
OpenDCC unterstützt normales Programmieren und Programmieren auf dem Hauptgleis. Zur leichteren Bedienung kann eines der folgenden Programme verwendet werden:
- P.F.u.Sch. Shareware (nur alte Version)
- rocrail Open Source
- Trainprogrammer
- DecoderProgrammer von Henning Voosen
- Railware
Wie kann ich zwischen Programmiergleis und Hauptgleis umschalten?
Man kann beide Ausgänge parallel schalten (auf Polarität achten - gleiche Polung verbinden) dann kann man auf einem Gleis sowohl programmieren als auch probefahren. Hierzu bitte M- und P- verbinden, zwischen M+ und P+ (Pins 2 und 4 von X5) einen Widerstand von 10 Ohm zwischenschalten. Das Gleis wird dann an M+ und M- angeschlossen. (Der Widerstand ist nur nötig, damit die Kurzschlußerkennung nicht verfrüht anspricht).
Achtung: nicht mit angeschlossener Anlage machen, das gibt dann ziemlich viele gleich programmierte Lokomotiven :-)
Warum ist OpenDCC beim Auslesen von CVs so viel schneller als meine bisherige Zentrale?
OpenDCC hat einen recht intelligenten Algorithmus zum CV lesen und fährt auch die Programmierbefehle mit dem Minimaltiming der NMRA. Fallweise muß das verlängert werden, s.u.
Ich kann die Lok programmieren und auslesen, aber die Werte sind falsch und es ist auch nichts in der Lok?
Offenbar ist die Zentrale auf Programmierung der internen CVs eingestellt. Da erfolgt normalerweise durch Tastendruck auf GO beim Einschalten. Wenn die (eigentlich nicht bestückten) Kondensatoren C37 und C38 vorhanden sind, dauert es beim Einschalten zu lange, bis die Leitung auf High geht und es wird fälschlicherweise ein Tastendruck angenommen. C37 und C38 entfernen!
Ich kann die Lok zwar programmieren aber nicht auslesen, was ist falsch?
Wenn beim Lesen Timeout kommt, dann erkennt OpenDCC den ACK-Puls von der Lok nicht. Bitte folgendes kontrollieren:
- Ist die Lok am Programmierausgang angeschlossen (Ausgang P)?
- Ist die Stromzuführung zur Lok absolut einwandfrei?
  (Grund: Der Quittungspuls für das Lesen wird durch eine Stromerhöhung von mind. 60mA gemacht - die Decoder erzeugen diese Stromerhöhung durch 6ms langes Einschalten des Motors. Dadurch bewegt sich die Lok auch ein wenig und kann fallweise Kontaktprobleme haben.)
- Ist die Lok mit einem Faulhabermotor ausgerüstet? Diese brauchen sehr wenig Strom, so dass die notwendige Stromerhöhung nicht zustande kommt. Hier kann eine Verkleinerung des Widerstandes R22 von 13k auf 12k die Empfindlichkeit erhöhen. Diese Empfindlichkeitserhöhung ist auch sinnvoll bei Spur N. Ansonsten muß in der Lok ein Lastwiderstand parallel zum Motor (während des Programmierens) eingebaut werden.
- Kann der Decoder die gewählte Programmierart?
  Hier kann es speziell bei älteren Decodern Probleme geben, diese können manchmal noch nicht 'DCC byteweise' oder Bitbefehle. Bitte bei solchen Decodern (z.B. Lenz LE200) auch darauf achten, dass das Hostprogramm entsprechend konfiguriert ist und 'Register'-Befehle absetzt.
- Hilft fallweise ein langsameres Lesetiming?
  Mittels zweier Sonderoptionen (18 und 19) kann die Zugriffsgeschwindigkeit von OpenDCC auf CV's reduziert werden. Ab Version V0.24.00 besteht zudem noch die Möglichkeit, extra Präambelbits zu erzeugen, kann ev. bei aktiviertem Railcom und alten Dekodern helfen.
- Ist die u.g. Hardwareänderung durchgeführt? (nur für alte Platinen)
Wie muss ich OpenDCC anschließen?
Auf der Seite Anlagenverdrahtung habe ich wichtige Hinweise und Schaltbilder für den Anschluß bereitgestellt.
Brauche ich die Optokoppler?
Hängt von der Applikation ab: OK1 ist ein allgemeiner Ausgang, OK2 ist ein allgemeiner Eingang. Es gibt bis jetzt zwei Anwendungen:
- OK2 wird für die echte Rückmeldung der Weichenlage verwendet.
- Beide OK werden bei externem Halt verwendet.
Wenn man das nicht will, kann man die OC problemlos weglassen.
Mit welchen Programmen funktioniert OpenDCC?
OpenDCC unterstützt Lenz und Intellibox bzw. Tams EC-Emulation. Dies ist weitgehend kompatibel, kann und will aber nicht alle Fälle abdecken. Z.B. sind Multitraktionsbefehle nicht vorhanden, da bisher kein PC-Progamm diese nutzt.

Da kommerzielle Softwarehersteller sich am Markt orientieren (da spielen Selbstbausysteme nur eine geringe Rolle), nehmen sie naturgemäß auch keine Rücksicht auf diese Systeme. Es kann daher sein, dass eine neue Version eines Steuerprogramms ev. neue Befehle verwendet, welche in OpenDCC (noch) nicht implementiert sind. Daher gelten die Tests logischerweise immer nur für den status quo der angesprochenen Software. Aus den erfolgten Tests ist auch keine Präferenz für eine bestimmte Steuersoftware abzuleiten.

Die Abneigung gegen ev. missliebige Zentralen geht sogar so weit, dass man sich explizit vorbehält, ohne nachvollziehbare Gründe nicht näher genannte Digitalsysteme zu blockieren (wer kann eigentlich als Käufer so eine AGB guten Gewissens unterschreiben?). Umgekehrt behalte ich mir vor, die Steuerung durch bestimmte Softwaresysteme zu unterbinden. Auch kann mein Support für eine bestimmte PC-Software wegen eventueller problematischer Lizenzbedingungen oder mangelnder Zusammenarbeit mit dem Programmanbieter eingestellt werden.

Bisher wurde OpenDCC mit folgenden Programmen erfolgreich getestet:
- srcpd und spdrs60 (Open Source)
- TrackOne (Open Source)
- Rocrail (Open Source)
- Traincontroller 5.8 (Support für TC 7.0 nur teilweise, wegen fehlender Informationen vom Programmanbieter) (Kommerziell)
- railware (Kommerziell)
Meine Loks beschleunigen und bremsen unter Traincontroller 8 sprunghaft!
Wenn über OpenDCC und das Protokoll p50x Rückmelder in Traincontroller eingelesen werden, kann es ab einer bestimmten Menge an Rückmeldern Probleme bei der internen Verarbeitung in Traincontroller geben. Als Folge werden Fahrbefehle nur verzögert an das Digitalsystem übermittelt. Das gilt auch, wenn 'Fahren' und 'Melden' auf zwei verschiedenen Digitalsystemen implementiert sind. TC8 kommt offenbar nicht mit schnellen Reaktionszeiten des Digitalsystems zurecht. Abhilfe schafft eine künstliche Verlangsamung der OpenDCC-Zentrale Z1.
Ich möchte den Code oder Teile davon für ein eigenes Projekt verwenden, was muß ich beachten?
OpenDCC ist keine freeware, sondern unterliegt einer Lizenz (gnu). Diese erlaubt die private Nutzung, bei kommerzieller Nutzung bzw. Weiterentwicklung sind die Lizenzbedingungen zu beachten. Source Code ist entweder auf dieser Seite oder unter sourceforge.net verfügbar. Wenn ein Passwort erforderlich ist, bitte ich dieses unter Angabe des Namens und der Adresse per mail zu erfragen.
Ich möchte nachbauen, habe aber ein bestimmtes Bauelement nicht?
- Frage zu IC7: Vorgabe: 74AC244N. Diesen hat Reichelt nicht, ist auch 74HC244 möglich?
  An dieser Stelle geht im Prinzip jeder 244er; AC habe wegen der brachialen Treiberleistung genommen, der HC ist aber auch nicht schlecht; um die Pegel möglichst in der Mitte zu treffen, sollte es ein HC oder AC (kein ACT oder HCT) sein.
- L6206N (Zweifacher H-Brücken-Treiber im PDIP24 Gehäuse) habe ich nicht.
  Der L6203 paßt nicht; Zur Not kann man den Booster mit L6203 extra aufbauen und nur die DCC-Leitung vom Prozessor adaptieren.
  Offenbar ist der L6206 nicht ganz leicht zu bekommen - fallweise per mail bei mir melden. (Ich habe einen kleinen Vorrat.)
Ich kann den Bootloader nicht laden.
Zuerst in ponyprog den richtigen Prozessor einstellen, dann das File laden. Der Bootloader beginnt erst bei Hex 7800, es schaut daher im ersten Moment so aus, als wenn nichts passiert wäre - aber einfach mal auf 7800 runterscrollen, dann sieht man den Bootloader.
Leider unterstützt ponyprog bis jetzt (Sept. 2008) den Atmega644P nicht. (Ich habe eine gepatchte Version von Ponyprog, welche den 644P unterstützt, bitte per mail anfragen).
- Setzen der Fuses mit avrdude:
     avrdude -c ponyser -p m644p -P /dev/ttyS0 -u -U lfuse:w:0xD7:m
     avrdude -c ponyser -p m644p -P /dev/ttyS0 -u -U hfuse:w:0x9C:m
     avrdude -c ponyser -p m644p -P /dev/ttyS0 -u -U efuse:w:0xFC:m
- Kontrollieren der Fuses mit avrdude:
     avrdude -c ponyser -p m644p -P /dev/ttyS0 -U lfuse:r:-:i
     avrdude -c ponyser -p m644p -P /dev/ttyS0 -U hfuse:r:-:i
     avrdude -c ponyser -p m644p -P /dev/ttyS0 -U efuse:r:-:i
- Dann den Bootloader einspielen (nur flash):
  avrdude -c ponyser -p avr911 -P /dev/ttyS0 -U flash:w:bootloader.hex:i
- Optional: OpenDCC einspielen (flash und eeprom):
  avrdude -c ponyser -p avr911 -P /dev/ttyS0 -U flash:w:OpenDCC_XP.hex:i -U eeprom:w:OpenDCC_XP.eep:i

Was muß ich bei AVRDUDE beachten?
AVRDUDE kann mit einem seriellen Ponyprog-Adapter zusammenarbeiten. Der auf lancos.com gezeichnete Adapter invertiert Reset. Sollte der verwendete Adapter die Resetleitung nicht invertieren, wie es z.B. der 'Notadapter' auf der OpenDCC-Platine macht, dann ist vorher folgende Änderung in avrdude.conf durchzuführen:

orginal:	programmer id = "ponyser"; desc = "design ponyprog serial, reset=!txd sck=rts mosi=dtr miso=cts"; type = serbb; reset = ~3; sck = 7; mosi = 4; miso = 8;
geändert:	programmer id = "ponyser2"; desc = "design ponyprog serial, reset=txd sck=rts mosi=dtr miso=cts"; type = serbb; reset = 3; sck = 7; mosi = 4; miso = 8;

Der Aufruf erfolgt dann natürlich mit "-c ponyser2" .

Ich erhalte die Fehlermeldung 'Closing tag not found! Opening tag <?xml> found, but not closing </?xml>.
Leider hat Atmel ab dem Studio 4.14 die partfiles nicht mehr kompatibel zum AVROSP gehalten. Also muß man bei neuem Studio entweder entweder AVROSP frisch installieren, die partfiles aus dem altem Studio für den Download entnehmen oder auf ein besseres Bootprogramm umsteigen, wie z.B. AvrOspII.
Mein S88 geht nicht, warum?
Vermutlich ist die Lötbrücke SJ2 auf der Unterseite der S88-Platine nicht geschlossen.
Mir gefällt der S88-Bus nicht, ich hätte lieber RS-Bus oder Loconet.
S88 ist leicht abspaltbar (die Adapterplatine weglassen und den #define Schalter S88_ENABLED ausschalten). Meine eigenen Rückmelder sind S88, daher habe ich kein anderes Protokoll implementiert - aber ein Entwurf für den RS-Bus geistert schon irgendwo bei mir rum. Zudem ist der S88 gar nicht so schecht, wie er oft gemacht wird: Mit OpenDCC ist er durchaus schnell und die Übertragungprobleme lassen sich lösen.
Die Kurzschlußüberwachung schaltet zu schnell ab, was kann ich tun?
Die Verdrahtung und der Ausgangsfilter belastet die Ausgangsstufe mit einer Kapazität. Daher zieht die Kurzschlußüberwachung prinzipbedingt bei jedem Polaritätswechsel kurz an.
Deshalb sind Sind R19 und R20 auf 2k2 geändert worden und zusätzlich wird in der Software (status.c) ein Filter gerechnet. Dieses Filter könnte man eventuell weniger aggressiv machen:
statt main_short_mean += 4; z.B. main_short_mean += 2; verwenden.
SHORT_TURNOFF_TIME ist die Zeitdauer, in der abgeschaltet wird; diese ist z.Z. auf 15ms eingestellt. (Ab V0.15 gibt es die CVs 34 und 35 für diese Einstellung).
Ein weitere Ursache können Servodekoder sein: Servos ziehen bei der Lageregelung (auch in der jeweiligen Endstellung) ziemlich kräftige Strompulse von bis 1,5A. Diese können die Kurzschlußsicherung zum Ansprechen bringen.
Bei mir funktioniert der Bootloader nicht, es gibt timeout!
Wenn sich der Bootloader normal einspielen ließ und anschließend die Verbindung zu Bootloader nicht klappt, könnte es auch an mangelnden Windows-Rechten liegen. Windows stellt sich an der seriellen Schnittstelle ohne Admin-Rechte bockig an. In diesem Fall als Administrator den Update durchführen.
Ich will mit dem Lenz-Protokoll steuern, geht das?
Die Entwicklung von OpenDCC startete mit dem Lenz Protokoll; Da aber dort u.a. die CV's und die maximal möglichen Adressen beschränkt waren, habe ich dann auf IB-Protokoll umgestellt. Alle Tests der letzten Zeit wurden mit dem IB-Protokoll gefahren.
Lenz ist nach wie vor vorhanden (und wird auch von manchen Anwendern benutzt) und kann per Compile-Switch wieder reaktiviert werden. Bitte hierzu per mail nachfragen (ab V0.14)
Wie kann ich PoM-Read machen?
Nach dem Absetzen eines PoM-read-Befehls muß die Antwort von einem Gleisbesetztmelder erfaßt werden und per Xpressnet an die Zentrale geliefert werden. Dort wird das entweder an den Handregler geschickt oder an den Host weitergeleitet.
In Xevent (0xC8) wird bei einem eintreffenden BiDi-CV-Ergebnis das Bit 5 (Maske 0x20) im Byte 3 gesetzt. Das Bit bleibt so lange stehen, bis XEvtPT gerufen wird. (Es schadet also nicht, wenn man vor dem PoM-Read einmal XEvtPT aufruft, um 'alte Leichen' wegzuräumen.)
Die Abfrage des Dateninhalts erfolgt dann mit XEvtPT, dort liegt wie sonst auch das Ergebnis vor. Intern merkt sich die Zentrale beim Ausführen eines beliebigen PoM-Befehls (via p50x Parser) ein Flag, den Zeitpunkt und die angefragte CV. Bei der XevtPT Abfrage wird das Flag und die Differenz (aktuelle Zeit - obiger Zeitpunkt) ausgewertet:
  a) ein Result für die CV liegt vor: es wird 0x02,0x00,DATA gemeldet.
  b) ein Result liegt nicht vor: es wird 0xF5 (=Busy) gemeldet.
  c) die Timeout ist abgelaufen: es wird 0x01,0xFE (=no ACK from Decoder) gemeldet.

Leider kennen die Hostprotokolle keinen 'Eigentümer' eines PoM-Befehls, die Antwort wird von der Zentrale ähnlich wie beim normalen Programmieren systemweit globalisiert. Wenn da also ein PoM von einem Handregler und dem PC parallel erfolgt, dann ist die Antwort nicht eindeutig. Vernünftig wird sich das erst in zukünftigen Protokollen lösen lassen.

Hinweis für Benutzer von Trainprogrammer der Firma Freiwald: Trainprogrammer muß als Schnittstellenprotokoll Tams EasyControl benutzen und damit Trainprogrammer PoM-Lesen aktiviert, muß in der Datei railroad.ini die Option
   [Connections]
   EnablePOMRead=1
gesetzt sein.
Die Dioden blinkern, was ist da kaputt?
Prog, Stop und Go gleichzeitig schnell blinkend bedeutet, dass die Software keine Daten (oder veraltete Daten)im EEPROM gefunden hat. Es wird nichts gestartet. Abhilfe: Abstecken, roten Knopf drücken, anstecken, Daten einspielen (mit update_opendcc_eeprom.bat).
Die Zentrale 'spinnt', (=schaltet ab, irrtümliche Kurzschlußerkennung, usw.), was ist die Ursache?
Hier hat sich bereits mehrmals das verwendete Netzteil als Ursache herausgestellt. Da gibt es offenbar Typen, welche Spikes und Dropouts am Ausgang haben. Dies irritiert fallweise die Kurzschlußerkennung bzw. die Spannungsüberwachung des Prozessors. Auch wurde mir schon ein Fall berichtet, wo das Netzteil keine vollständige Potentialtrennung hatte. Offenbar interpretieren manche Anbieter das CE-Zeichen als Abkürzung für China Export.
Ich brauche mehr/weniger Spannung, z.B. für LGB (24V).
Im Prinzip ist eine Änderung möglich, aber bitte folgende Dinge beachten:
- Kondensatoren / Dioden / Gleichrichter müssen dafür ausgelegt sein - die Kondensatoren müssen mind. 40V haben.
- Der L6206 kann bis 50V und bis 2,5A, aber die Strombegrenzung der H-Brücke ist hardwaremseitig auf 1,5A und die Abschaltroutine dahinter 'pingelig' ausgelegt. Hier muß man für LGB fallweise mehr Strom zulassen (siehe Datenblatt). Thermisch ist das normalerweise kein Problem.
- Die 5V für den Prozessor können noch mit dem 7805 erzeugt werden (ev. kühlen), jedoch für den S88 Kreis rate ich zu einem Schaltregler bzw. separater Versorgung.
- Ein Anlage mit mehrerer Loks oder Weichendekodern sollte immer über Booster versorgt werden: die Kondensatoren der Dekoder verursachen einen Stromspitze beim Einschalten, welche die Kurzschlußabschaltung ansprechen lassen kann.
- Ich rate von der Verwendung von alten PC-Netzteilen ab: dort funktioniert die 12V-Regelung oft nicht richtig, wenn die 5V nicht mit einer Mindestlast belegt sind.
Welcher Booster ist verwendbar?
Erst einmal muß man die Sicherheit beachten: Modellbahn muß gemäß VDE schutzgetrennt sein (die Zentrale ist über die PC-Verbindung geerdet), also muß der Booster die Schutztrennung mit einem Optokoppler gewährleisten.

Rein von der schaltungstechnischen Seite her ist folgendes zu betrachten:
Es gibt im Prinzip zwei verschiedene Boosterkonzepte: H-Brücke (so wie der OpenDCC-Booster) oder NF-Verstärker (so wie oft im MM-Umfeld verwendet).

H-Brücke ist recht simpel im Aufbau und billig, hat aber den Nachteil, dass das Gleis hinten gegen Masse der Zentrale 'tanzt'. Das ist nicht weiter schlimm, wenn optogekoppelte Rückmelder verwendet werden. Cutout-Erzeugung geht mit H-Brücke sehr einfach, da muß man nur beide Low-Quadranten gleichzeitig enablen.
NF-Verstärker ist mehr Aufwand, teueres Netzteil, fette Elkos, Schaltungsaufwand mit Levelshiftern und Brimborium. Hat aber den Vorteil, dass hinten eine Seite auf Masse der Zentrale liegt. Mit NF-Verstärkern ist auch die Cutout-Erzeugung mit mehr Aufwand verbunden. Damit lassen sich dann Rückmelder wunderbar billigst massebezogen bauen und man braucht keine weiteren Optokoppler mehr. Aber damit besteht auch die Gefahr, dass ein Teil des Gleisstromes über die Rückmelder abfließt und dort Störungen verursacht (Das hat dem S88 seinen schlechten Ruf eingebracht).

Wenn wirklich solche massebezogenen Booster verwendet werden sollen, dann würde ich in der Zentrale beim DCC Signal vom Prozessor andocken. Der Ausgang kann bis zu 10mA locker verkraften, d.h. bei üblichen 10k Eingangswiderstand lassen sich 10 Booster ansteuern. (Nochmal: Schutztrennung ist dann weg - die Anlage ist indirekt über den PC geerdet.)
Der Spannungsregler 7805 wird recht warm, was soll ich tun?
- Ein Kühlkörper hilft sehr viel, auch ein kleiner bringt schon was. Das Gehäuse sollte unbedingt belüftet sein.
- Schaltreglern ist klar der Vorzug zu geben. Es gibt neben dem auf der Platine bestückbaren Schaltregler von TI auch 7805-Ersatz Typen (R-7805). Ein PTH08080 geht bis 18V= Eingang und hat 86% Wirkungsgrad, ein 7805 hat nur 30%.
Was ist der Unterschied zwischen den Layoutversionen 1.3, 1.4 und 1.5?
Nahezu kein Unterschied, elektrisch ist alles beim alten geblieben. Ich habe wegen notorischer Unzuverlässigkeit den Leiterplattenhersteller gewechselt und mußte deshalb Fräsmarken ins Layout einbringen.
Wie kann ich ein Logging erzeugen?
Bei hartnäckigen Problemen brauche ich zur Analyse ein Logging der Schnittstelle, d.h. eine Mitschrift des Datenverkehrs vom PC zur Zentrale und zurück. Dies wird wie folgt erzeugt:
- Das entsprechende Programm (portmon.exe) kann von der Microsoft-Webseite geladen werden.
- Dieses muß man einfach *vor* der Modellbahnsoftware starten.
- Im Programm muß man folgende Einstellungen vornehmen:
  Auswahl des Ports, welcher überwacht werden soll (kann auch USB sein)
  Filter setzen (das ist der Trichter); bei Exclude: IOCTL_SERIAL_GET_COMMSTATUS mit dazu nehmen (dann wird das das Log kleiner)
  bei Options: Show Time und Show Hex dazu.
- Jetzt das Zielprogramm starten.
Was besser: OpenDCC oder DiCoStation?
Das ist natürlich schwer objektiv zu beantworten - jeder Meister lobt seinen Kleister!
Einfach zu vergleichen ist die Ausstattung: DiCo hat keinen Nothalttaster, keinen Booster, keinen Programmiergleisanschluß.
Zur Leistung: ich halte meinen Algorithmus für den Lokstack von DCC für das Optimum an Performance, was aus DCC herauszuholen ist, die Latenzzeiten sind geringer als bei SX! Und diese Performance bleibt auch bei vielen Loks und 128 Fahrstufen erhalten! Beim Protokoll P50x verursacht die die DiCo erhebliche CPU-Last auf dem Host, OpenDCC nicht. Die S88-Implementierung von OpenDCC ist deutlich flotter und störsicherer unterwegs.
Die DiCo kann Märklin Motorola, was ich nicht einbauen wollte. Die DiCo braucht zum Betrieb eine PC-Software (nur für Windows verfügbar), diese wird mittels einer Key-CD geschützt. Die CD wird laut Handbuch alle 15 Tage abgefragt.
Ich habe auf Windows 10 gewechselt, der USB-Treiber wird nicht erkannt. Was mache ich falsch?
Windows 10 benutzen :-)
Unter opendcc_usb.html sind mögliche Lösungen geschildert.
Wann muß ich SJ1, wann SJ4 schließen? SJ1 bleibt immer offen, SJ4 ist zu schließen, wenn man den extern Halt oder die Weichenrückmeldung nutzen will.

Märklin ist das eingetragene und geschützte Warenzeichen der Firma Gebr. Märklin & Cie. GmbH, Göppingen , Deutschland.
Intellibox ist das eingetragene und geschützte Warenzeichen der Fa. Uhlenbrock
DiCoStation ist das eingetragene und geschützte Warenzeichen von Littfinski Daten Technik
Xpressnet und railcom sind das eingetragene und geschützte Warenzeichen von Fa. Lenz