Programmiergleis

Zur Programmierung von DCC Decodern gibt es aus historischen Gründen verschiedene Methoden. Seit Mitte der 1990'er Jahre verwendet man die CV Programmierung. Man unterscheidet die Programmiergleis Programmierung (service mode) und die Programmierung am Hauptgleis
POM.
[P]rogramming [O]n the [M]aintrack

Die Programmiergleis Methode baut auf der früher üblichen Register Methode auf und erlaubt das Ändern von Einstellungen ohne die Adresse des Decoders zu kennen. Die Zentralen senden solche Befehle nur auf einem Speziellen Ausgang aus. Das soll ein versehentliches Bearbeiten aller Decoder auf der Anlage verhindern. Einfache Zentralen sparen den speziellen Anschluß ein, mit der daraus folgenden Gefahr, daß man ungewollt alle angeschlossenen Decoder beschreibt. Eine weitere Eigenschaft des Programmiergleis Anschlusses ist, daß hier besonders sensible Überstromerkennung vorhanden ist. Damit soll erreicht werden, daß fehlverkabelte Decoder vor Schäden geschützt werden. Dieser Schutz kollidiert mit dem Problem der Ladeströme in Decodern. Die leeren Pufferkondensatoren sind von der Zentrale aus gesehen kaum von einem Kurzschluss zu unterscheiden. Nur mit aufwändiger Trendanalyse des Stromverlaufs kann man das erkennen. Solche aufwändige Einrichtungen findet man nur bei sehr wenigen Zentralen. In der Anfangszeit der DCC Norm haben viele Zentralen am Programmiergleis nur während des Programmierens Spannung angelegt. Wegen der Einschaltstromprobleme beim Laden von Pufferkondensatoren ist diese Methode eher unüblich geworden. Das hat auch den Vorteil, daß man sofort de gerade programmierten Werte überprüfen kann.

Das Programmiergleis dient im Wesentlichen dazu Decoder einzurichten. Die Befehle sind Adressenunabhängig. Das ermöglicht vor allem das Neusetzen von Adressen.

Am Programmiergleis gibt es die traditionelle Möglichkeit vom Decoder auch Ja / Nein Antworten zurück zu lesen. Eine Ja-Antwort wird vom Decoder durch das erzeugen eines höheren Strombedarfs er Zentrale mitgeteilt. Dazu werden vom Decoder Verbraucher eingeschaltet die diesen zusätzlichen Strom ziehen. Üblicherweise werden Lichtausgänge eingeschaltet und der Motor mehrfach kurz in beide Richtungen um das Modell nicht wegzufahren. Die Impulse sollen 6 mal hintereinander mit zumindest 60mA zusätzlichen Strom gesendet werden.
In der Praxis werten viele Zentralen nicht den Anstieg als solches aus sondern haben eine fixe Schwelle des Gleisstroms. Üblich sind hier Schwellwerte von 100-150mA.

Parallele Verbraucher in einem Modell wie Lämpchen oder Rauchentwickler können durchaus einen Ruhestrom oberhalb dieser fixen Schwellwerte ziehen. Dadurch können Zentralen die nur feste Schwellwerte benutzen und nicht die Veränderung auswerten die ServiceMode Impulse nicht lesen. Ein weiteres Problem stellen die Pufferkondensatoren in Lokomotiven dar. Das Laden der Kondensatoren zieht ebenfalls viel Strom die die Schwellwerte übersteigen. Umgekehrt können die Pufferkondensatoren den Strom für die Pulse liefern und die Zentrale kann die Quittierung deshalb nicht erkennen. Es gibt seit 2008 eine Norm die die Einschaltströme der Kondensatoren beschränkt. Weiters wird in dieser Norm gefordert, daß der Kondensator weggeschaltet werden soll wenn der Betrieb am Programmiergleis erkannt wird. Solche Einrichtungen auf Decodern sind sehr selten. Daher muß man, wenn es Ärger am Programmiergleis gibt, parallele Verbraucher oder Pufferkondensatoren wegschalten.

Programming Track

There are several methods available for programming DCC decoders. Currently the popular method is CV programming which was established mid 1990'es. There are two methods available service mode programming on a special programming track and
POM.
[P]rogramming [O]n the [M]aintrack
programming.
The service mode programming uses the old register method. The mail usage is to modify the address. Usually a central station has a special connector for the programming track. This avoids an accidental modification of all locos on the layout as the special service mode commands are only sent out to the programming track. Some cheap simple central stations share the programming track with the man track so that advantage is lost. Another feature s a more sensitive over current detection on the programming track. It should help to protect a faulty wired decoder. Frequently that more sensitive current protection collides with the inrush current of decoders especially if they have big buffer capacitors. Only a few premium produces can identify that inrush current. Some early central stations have no power at all on the track outside of programming commands. As this causes even more problems with buffers most central stations have always power on the programming track. This is also used to allow instant verification of the programmed commands.

The programming track is mainly used to set up a decoder. All commands have a special format and are not address specific. Therefore they are used to program the address in a decoder.

On the programming track there is also a traditional way to read data out of a decoder. The decoder can answer YES / NO to a question. A YES is sent by sending 6 pulses of higher current. The decoder does this using its output lines and turns it on. The motor is driven forward and backward to avoid a runoff of the loco. The pulses should be 6 times 60mA mode than the normal current. Many command stations do not detect the change. Instead the use a fixed threshold of 100-150mA.

Parallel loads like lamps or smoke generators can cause a current above the fixed limit. On models like this reading CV values is not possible. As mentioned before the inrush current of buffer capacitors might cause troubles. Bit the buffer could fill up the acknowledge pulses. So the central station could not see the ACKs. Since 2008 there is a norm regarding inrush current. It defines to turn off the buffer capacitor during service mode programming to secure the pulses for the central station. Even 2017 there are only a few decoders who have a special connection for buffer capacitors which follow that definition.
 

Quittierungs-Impulse

Die Quittierungsimpulse werden durch das Zuschalten von Verbrauchern erzeugt. Üblicherweise sind das Motor und Lämpchen. Für meinen Lichtschlangen Decoder habe ich einen eigenen Schaltkreis vorgesehen der über einen Transistor einen 100 Ohm Widerstand nach dem Gleichrichter einschaltet. Damit wird unabhängig von der Phasenlage des DCC Signals der Quittierungsstrom erzeigt. Die 6ms Pulslänge sind deutlich Länger als die typischen DCC Impulse. Zum Vergleich eine DCC 1 hat eine Halbwellenlänge von 56µS, eine 0 zumindest 100µS das ganze 1 Bit hat dann etwa 110µS und die 0 zumindest 220µS. Die Quittierungsimpulse dauern daher über mehrere Bits hinweg an.
Nachfolgend ein kurzer Code Ausschnitt der das Erzeugen eines ACK Impulses zeigt. Für die Quittierung, also die Antwort JA auf deine zuvor ausgesendete Frage an den Decoder sind 6 solcher Impulse hintereinander zusenden.

ACK Pulses

The confirmation ACK pulses are generated by engaging additional load like lamps or motor. On my light snake project I use a separate circuit which switches a 100 ohms resistor behind the decoder rectifier. This causes additional current independent of the DCC signal phase. The pulse length is 6ms. This is much longer than any typical DCC pulse. A DCC 1 uses a 56µS length for one half pulse. The 0 has a minimum length of 110µS this causes about 110µS length for a 1 and minimum 220µS for a 0. The ACK Pulses are therefore much longer than any DC Signal pulse.
Underneath there is a code snippet which shows the pulse generation. It generates one impulse. A YES answer requires 6 of those pulses.


// schreibe einen ACK Impuls
// zur Quittierung an die Zentrale wird über mehr Stromverbrauch ein Impuls
// an die Zentrale gesendet. Hinter dem ACK Pin befindet sich ein 100Ohm
// Widerstand um den Strom zu ziehen
void sendACKPulse(void)
{
  digitalWrite( ACKPin, HIGH );
  delay( 6 );  
  digitalWrite( ACKPin, LOW );
}
 

 
Die sehr langsame Übertragung der Quittierungsimpulse macht diese Methode ungeeignet um größere Datenmengen zu übertragen. Das führte dann zur Entwicklung von RailCom um schneller mehr Daten senden zu können.
The slow speed to ACK pulses does not allow to use it for sending bigger data amount. Therefore RailCom was developed to transfer date quicker..

 

Programmieren am Hauptgleis

Das Programmieren am Hauptgleis erfolgt unter Verwendung der aktuellen Adresse. Die Befehle am Gleis sind somit völlig unterschiedlich zu den ServiceMode Befehlen. Sinn der Einrichtung ist CVs während dem Betrieb zu verändern ohne das Modell auf das Programmiergleis bringen zu müssen.
Typische Anwendung ist das Einstellen von dynamischen Parametern wie Maximalgeschwindigkeit, Verzögerungszeiten udglm. Über CV19 kann man einfach Traktionen aufbauen und löschen. Nachteil der POM Programmierung war lange Zeit, daß das Schreiben der CVs im Blindflug erfolgen musste. Störungen in der Befehlsübertragung konnten technisch nicht erkannt werden. Ebenso war das Auslesen der Werte nicht möglich.
Erst durch RailCom entsteht eine Möglichkeit Informationen vom Decoder zur Zentrale zu senden. Die Technik dazu wurde Anfang der 2000'er Jahre von Lenz entwickelt, durch unnötige rechtliche Hürden hat sich die Technik kaum verbreitet. Lange Zeit unterstützten nur die Premium Hersteller die Technik. RailCom nutzt Pufferkondensatoren im Decoder um mit deren Energie kurze Stromimpulse absenden zu können.

Programming Track

Programming on the main track is always using the decoder address. The command on the track is totally different compared to the service mode command. The idea behind it is to allow quick and easy modification, without the need to put the loco back to the programming track.
Typical application is to set dynamic parameters link motor regulation or max speed. CV19 may be used to build a consist or delete it. A big disadvantage was for long time that there was no confirmation of the written values. If the command was disturbed there was no way to detect it. As well there was no way to read values back to the user.
RailCom now offers a path to transfer that data back to teh command station and the user. The technology was developed in the early 2000's by Lenz. Unfortunately they introduced some legal barriers which made it impossible for many companied to adopt it. For many years only premium manufacturers offered the technology. RailCom uses the energy in the buffer capacitors of the decoder to send little current spikes back to the command station.



 

(C) AMW 2017ff Visitors since 2017-07-01: Failed to execute CGI : Win32 Error Code = 2