Hallo,

ich habe in einem anderen Thread angekündigt, ein DCC Weichendecoder entwickeln zu wollen (dieser und folgende Beiträge).

Dass es die zahlreich zu kaufen gibt, ist mir klar. Ich mache das aus Spaß am Entwickeln und Programmieren. Es geht auch nicht um's Geld sparen, zumindest nicht in erster Linie.

Am Ende des Projekts möchte ich einen Weichendecoder im "Inselbetrieb" haben - Decoder versorgt sich mit Energie und Steuersignalen einzig aus dem Gleis alleine.

Stand ist jetzt, dass ich mir einen Optokoppler ONsemi H11L1M besorgt habe und - zusammen mit Bauteilen, die ich schon hier hatte, zu einer Schaltung zusammengelötet habe:

Die Schaltung mit Arduino Uno kann ich gleichzeitig an die Zentrale und an den PC anschließen (der Arduino wird über USB-Kabel vom PC stromversorgt, und mit Hilfe des Bootloaders geflasht).
Die LEDs dienen als Ersatz für die "Leistungsstufe" der Weichenmagnete. Es geht erstmal nur ums Decodieren des DCC-Signals, die LEDs dienen zur "Erfolgskontrolle".
Ich habe auch einen Schalter eingelötet, da mein Decoder auch eine Adresslernfunktion haben soll, die mit diesem Schalter gestartet wird.

Für das Erkennen von Nullen und Einsen habe ich folgenden Ansatz:
Eine Art Zustandsautomat mit drei Zuständen,
1) "Grundzustand",
2) "0er Halbwelle erkannt, warte auf zweite Halbwelle",
3) "1er Halbwelle erkannt, warte auf zweite Halbwelle".

Zeitmessung mit abwärts zählendem Timer, dessen "Startwert" bei Betreten eines Zustands stets dem Zustand entsprechenden Wert gesetzt wird (z.B Zustand 2: auf 64us). Tritt bei 0 der Zähler-Unterlauf auf, kam die nachfolgende Signalflanke zu spät und mein Automat fällt in den Grundzustand zurück. Wird in Zustand 2/3 ein erfolgreiches Bit erkannt, wird dies dem Rest des Programms signalisiert, und der Automat fällt wieder in den Zustand 1 zurück.
Die Zustandsänderungen werden durch Interrupts, ausgelöst durch den Opto einerseits, und dem Timer-Unterlauf andererseits, verwirklicht.

Ich habe eine erste Programm-Version bereits in Arduino-C implementiert, scheint soweit auch prinzipiell zu funktionieren. Allerdings glaube ich, dass die micros() Funktion, mit der ich die Zeitmessung implementiert habe, zu unpräzise ist. Zugriff auf Timer-Interrupts habe ich in Arduino-C auch nicht. Damit werde ich nicht weit kommen (habe ich auch nicht wirklich erwartet). Mit Standard-C, der avr-libc und einer geeigneten Toolchain abseits von der Arduino-IDE muss ich noch beschäftigen.

Das Erkennen des relevanten DCC-Befehls stelle ich mir ungefähr so vor:
- Im Speicher ist der relevante DCC-Befehl einfach nur als Bitmuster hinterlegt.
- Warten bis genügend 1en hintereinander empfangen wurden, sodass die Bedingung für die Präambel erfüllt ist.
- Warten auf die 0, die die Präambel abschließt.
- Dann die nachfolgenden Bits zählen, bis die Anzahl der des hinterlegten Bitmusters entspricht.
- Empfangenes Bitmuster mit dem hinterlegten vergleichen.
- Wenn Übereinstimmung: Nutzlast des Befehls extrahieren, entsprechende Aktion ausführen.
- XOR-Byte? Müsste noch mal schauen, ob es reicht, es als Muster zu hinterlegen, oder ob man es stets neu berechnen muss.

Ich habe mir die relevanten Standards der NMRA mal angesehen.
Zu S-9.1 Electrical Standards... Kapitel "One Bit Timing", hätte ich Fragen:
- die Bedingungen für das Eins-Bit sind klar formuliert: eine empfangene Halbwelle zwischen 52 und 64 us, zweite Halbwelle darf sich von erster höchstens um 6 us unterscheiden.
- die Bedingungen für das Null-Bit habe ich nicht so richtig verstanden: die zwei Halbwellen sollen (normalerweise(?)) gleich lang sein, sie dürfen zwischen 90 und 10000 us lang sein, sollen aber zusammen nicht länger, als 12000 us sein? Wieso darf eine 0-Halbwelle 10000us lang sein, beide zusammen nur 12000us? Das widerspricht sich doch? Was ist mit "Stretched-0-Bit" gemeint?

Mich treibt noch eine andere Sorge um: In der finalen Schaltung möchte ich einen wesentlich kleineren Atmel AVR, als den 328 im Arduino Uno einsetzen, und zwar mit internem Taktgeber. Da wäre wohl höchstens 1MHz zu erwarten, was hieße, dass im Extremfall 1MHz * 52us = 52 Takte zur Verfügung stünden, um den aktuellen Interrupt abzuarbeiten, bis die nächste Signalflanke (heißt: Interrupt) kommt. Da wäre ich gespannt, ob das reicht. Eventuell muss ich mit Assembler an die Sache ran...

Danke im Voraus und Gruß, Philipp

Hallo FlippsThRd,
wenn du den Decoder komplett aus der Gleisspannung versorgen willst (Energie und Daten) benötigst du keinen Optokoppler.
Neben der Auswertung des DCC Signals incl Railcom Cut müssen auch die weiteren Signale auf der PowerLine (mfx, MM, Selektriks) erkannt und zumindest ignorriert werden. Oder soll der Decoder nur in einer reinen DCC Welt funktionieren?
Ein funktionierender DCC Weichendecoder mit Anlernfunktion passt in 1024 FlashWords, 128byte EEProm und 64 byte SRAM. Dabei arbeitet er mit 1MHz Befehlszyklen.
Ein 328 ist Kanonen auf Spatzen.
Volker

Hallo Volker,

schon klar, der Opto und der Arduino sind auch nur zum bequemen Testen/Programmieren.
So kann ich das gleichzeitig am PC und an der DCC-Zentrale angeschlossen lassen, ohne dass es gefährlich wird.

Nur DCC. RailCom könnte allerdings später dazukommen. Meine LoPis können das ja.

Ich denke, ich ignoriere RailCom der Einfachheit halber vorerst mal, und kümmer mich erst drum, wenn ich es auch wirklich einsetzen will.

Wo kann ich mich über RailCom schlau machen? Das ist ja, glaube ich, nicht in der NMRA, oder NEM definiert?

Hast du mit C oder mit Assembler programmiert?

Gruß, Philipp

Hallo Phillip,
RailCom ist eine Norm: RCN-218
Nur nicht vom Morop sondern von RailCommunity – Verband der Hersteller Digitaler Modellbahnprodukte e.V.
Erfinder ist Lenz, der auch ein Patent darauf ein Patent erteilt bekam (2005).
Volker

Hi Philipp,

bzgl. Dekodierung des DCC Signals musst du das Rad ja nicht neu erfinden (außer du willst es). Es gibt die NRMA DCC Library, die hier auch in einem anderen Projekt genutzt wird. Ich habe mir meinen Dekodier-Routine selbst geschrieben, da auf meinem Attiny nicht genügend Platz ist (und ich es auch selbermachen wollte) Kannst ja mal schauen, mein Code ist auch bei github verfügbar. Hier der Thread zu meinem Funktionsdekoder

VG, Markus

Zitat von FlippsThRd im Beitrag #1

---

Mich treibt noch eine andere Sorge um: In der finalen Schaltung möchte ich einen wesentlich kleineren Atmel AVR, als den 328 im Arduino Uno einsetzen, und zwar mit internem Taktgeber. Da wäre wohl höchstens 1MHz zu erwarten, was hieße, dass im Extremfall 1MHz * 52us = 52 Takte zur Verfügung stünden, um den aktuellen Interrupt abzuarbeiten, bis die nächste Signalflanke (heißt: Interrupt) kommt. Da wäre ich gespannt, ob das reicht. Eventuell muss ich mit Assembler an die Sache ran...

---

Hallo Markus,

Zitat von Homer Jay im Beitrag #6

---

1 MHz halte ich für nicht machbar.

---

Hi,

danke für die Links, ich schau mal rein.

Mein Wissen über verfügbare Mikrocontroller ist ein wenig oberflächlich. Ich dachte immer, interne Taktgeber gehen so bis 1MHz. Aber wenn auch ATTinys schon bis 20MHz gehen, dann waren meine Sorgen ja unbegründet.
Denn mit 1MHz betreiben möchte ich natürlich nicht :-).

Es ist nämlich auch meine Hoffnung, die Decoder so klein zu bauen, dass ich sie auf der Unterseite meiner Roco-Weichen einbauen/verstecken kann. Das wird generell schon schwierig werden (die Weichenantriebe selbst nehmen schon den größten Teil ein), aber wenn ich auch noch einen externen Oszi, wie z.B. mein Arduino ihn hat, vorsehen müsste, wäre es in jedem Fall unmöglich.

Ich meinte Prozessortakt. Mein Gedankengang war, dass ich die Interrupt-Handler im Extremfall in 1MHz * 52us = 52 Taktzyklen unterbringen müsste, was mir auch unmöglich erscheint.

Vielleicht irre ich mich ja, aber dass die Abarbeitung eines Befehls 4 Takte benötigt, war doch immer nur eine Sache der PICs? Einer der größten Selling Points der Atmel AVR Architektur war/ist ja, dass durch geschicktes Hardware-Design die meisten Befehle in nur einem Takt abgearbeitet werden können.

Hallo Phillip,
das was du vorhast gibt es schon. Nennt sich Weichei Decoder und funktioniert mit einem Pic 12F629. Der taktet intern mit max 8MHz.
Volker

Hallo Volker,

ja, weiß ich. Darüber haben wir ja im anderen Thread (erstellt vom Kollegen RBL) geredet :-)

Gruß, Philipp

Ich glaube ich verstehe, was du meintest:
der PIC taktet mit 8MHz, und braucht 4 Takte pro Befehl, was ihn effektiv zum 2MHz Prozessor macht? Also maximal 100 Instruktionen pro Interrupt?

Dann wurde der wohl in Assembler programmiert, damit das hinhaut.

Gruß, Philipp

Wieviele Takte die CPU für einen Befehl braucht steht im Datenblatt.

Bei einem Mega 328 sind es zwischen 1 und 4, wobei die Zahl der Befehle die 3 oder 4 Takte brauchen sehr klein ist, die überwiegende Mehrheit braucht 1 oder 2 Takte.

Hi,

laut RCN 211 soll eine DCC-Zentrale mindestens 17 Synchron-Bits senden, die Decoder hingegen dürfen 10 Synchron-Bits als gültig anerkennen.

Warum ist das so?