Moin Gemeinde,
@Jendris: ESU Lokprogrammer ist wie der Name schon sagt nur für ESU und ESU-Kompatible Dekoder. Oligluck testet meinen Servodecoder an seinen Zentralen und ist, ohne vorgreifen zu wollen, hoffentlich mit im Boot.
Ich kann jetzt nur für mich sprechen, gebe aber mal einen kleinen Überblick über die Normen so das es auch der Laie versteht:
Eigentlich gibt es zwei Normen die es zu einer großen Verbreitung geschafft haben.
- DCC-Protokoll nach NMRA-Norm. Damit dürften die meisten in diesem Forum fahren.
- MM-Protokoll. Die Märkliner (außer mir) dürften meistens das Motorola Protokoll fahren.
(DCC= DigitalCommandControl, MM= Maerklin Motorola)
Da ich mich auf DCC eingeschossen habe, hier ein kleiner Exkurs zu den verschiedenen Telegrammen und der Decodierung innerhalb DCC. Diese Erläuterungen sind nicht vollständig aber garantiert frei von verwirrenden technischen Details. Betrachten wir hier also nur die sogenannten "Baselines" wie es in der NMRA beschrieben ist. Im Detail ist es etwas komplizierter. Also Railcom und POM und CV, Broadcasts usw., usw. vergessen wir erst einmal.
DCC überträgt die Daten über das Gleis, soweit klar. Die Daten werden in Pakete verpackt. Die Pakete bestehen aus einer Reihe von "1en" und "0en" und sind jeweils 38 bis 42 Bit lang. Jede "1" und jede "0" nennt man Bit. Die Position jedes Bits innerhalb der 42Bit bestimmt seine Funktion. Diese Funktion ist im DCC-Standard festgelegt. Jedes Paket hat einen Empfänger an den es gerichtet ist. DCC unterscheidet jetzt grob 2 Arten von Empfängern. Zum einen sind das ganz klar die Lokomotiven (Mobile Decoder), und zum Anderen die Zubehörartikel (Stationary Decoder), also Weichen, Signale usw. Dabei reden wir jetzt nicht über die Funktionsmöglichkeiten des Dekoders als solches. Dazu später mehr.
Jeder Dekoder, ob Lok oder Zubehör, hört jedes Datenpaket mit und unterscheidet zuerst einmal grob ob es sich um ein Datenpaket für Zubehör oder Lok handelt. Pakete die nicht zur eigenen Gruppe gehören werden einfach ignoriert.
Das ist wichtig, da sich der Inhalt der Datenpakete nämlich stark unterscheidet. Bleiben wir jetzt also mal bei einem Zubehördekoder für Weichen und Signale. Also das Ding mit den 4 Doppelspulenausgängen. So ein Dekoder hat deshalb 4 Ausgänge, weil das Standardprotokoll nicht mehr Weichen usw. pro Adresse vorsieht. Wenn ich dieses Basispaket jetzt in meinem Dekoder per Software zerlege habe ich eine Dekoderadresse mit den 4 Ports und jeder Port hat einen Ausgang Rot und Grün. Wie gesagt, wir reden nur vom Standard. Mit diesen Informationen kann ich jetzt auf einfache Weise einen Dekoder bauen und programmieren.
Im Dekoder passiert folgendes:
Zuerst einmal wird über eine geignete elektronische Schaltung aus dem Gleissignal der Datenstrom so umgewandelt, das man das an den Eingang des Microcontrollers legen kann. Das Gleis hat so um die 16 bis 20 Volt Wechselspannung der Prozessor darf aber nur 5V oder 3,3V Gleichspannung an seinem Eingang haben. (Tut mir Leid aber ACler und DCler sind technisch immer ACler!) Was jetzt passiert ist softwareseitig zu erledigen. D.h. der kleine Tausendfüßler auf dem Dekoder hat ein Programm im Bauch welches die Information aus dem Gleis verdauen kann. (Ich versuche es so Laienhaft wie möglich zu erklären. Sollte ich übertreiben seht es mir nach.) Die Informationen werden dabei im ersten Programmteil an einen Empfänger geschickt (Receiver) der extrahiert aus dem Gleissignal die Nullen und Einsen und schiebt sie so lange in einen Zwischenspeicher bis das Paket vollständig empfangen wurde. Da die Pakete natürlich hintereinander kommen und der Receiver nicht weis was gerade dran ist (Lok oder Zubehör) filtert er alle Pakete aus die nicht für seine Gruppe bestimmt sind. Da der Receiver mitten drin anfängt die Pakete abzuhören, muß er noch wissen, wann ein neues Paket anfängt. Dazu erfolgt vor jedem neuen Paket, egal ob Lok oder Zubehör, eine Art "Achtungspfiff" welchen die Zentrale aussendet.
Hat der Receiver jetzt ein vollständiges Paket erhalten meldet er es an einen zweiten Programmteil den Entschlüssler (Decoder) weiter. (Bitte nicht mit dem Begriff Dekoder als Baustein verwechseln.) Dieser Programmteil ermittelt jetzt aus den Daten des Zwischenspeichers die Dekoderadresse. Stimmt die Dekoderadresse mit der im Microcontroller hinterlegten Adresse überein ist das Paket beim richtigen Empfänger gelandet und kann weiter bearbeitet werden.
Jetzt werden aus dem Paket noch die Daten für die Ports 1 bis 4 und Rot und Grün geholt.
Bis hierhin geschieht das bei allen Zubehördekodern gleich, egal was der Dekoder weiter machen soll. Ich kann jetzt im Dekoder eine Servoroutine ablegen und anhand der Port und ROT/GRÜN-Information einen Servo bewegen, oder Sinalbilder ausgeben, oder einen Mann fotografieren lassen usw.usw. Die oben beschriebene Software kann natürlich auf diversen Microcontrollern abgelegt werden. Ich verwende Microchip PIC-Microcontroller, der Andreas ein Arduinoboard. Letztendlich ist es egal welche Hardware darunter liegt. Es sei noch dazu gesagt, dass je nach Leistungsfähigkeit der verwendeten Microcontroller auch noch die erweiterten Funktionen des DCC-Protokolls ausgeschöpft werden können u.A. CV-Programmierung, POM, Railcom usw.
Ich sehe uns im momentanen Stadium auch genau hier. DCC können wir dekodieren. Und ich habe mal einen Servo dahinter getackert.
Das alles ist auch
vollständig für Interessierte nachzulesen. (Englisch)
Zum Abschluß meines Exkurses möchte ich noch Jendris Frage beantworten. Da die Multimaus eine Kleine und Feine, wenn auch einfache DCC-Zentrale ist, kann man damit natürlich auch die Zubehördekoder ansteuern. Somit also auch unsere Selbstbauprojekte. Und wenn Du das oben liest denke ich, dass auch von Dir Vorschläge kommen werden. Wie Du siehst steck ich auch ganz schön tief im Thema.
Ich hoffe das ist für jeden informativ und jeder weis jetzt wo wir stehen.
Bis dahin