DCC Lichteffekt Dekoder

Motivation

Lichteffekte auf der Modelleisenbahn wecken das Interesse der Besucher nicht erst seit sie so intensiv im Miniatur Wunderland in Hamburg eingesetzt werden. Es gehört einfach zum guten Ton sämtliche Häuser, Autos, Straßenlampen usw. mit blinkenden Lichtern auszustatten – strahlende und begeisterte Kinder bestätigen dies immer wieder an unseren Ausstellungen! Obwohl die Lichttechnik auf einer Modellbahn so viel zum Gesamteindruck beiträgt, haben die Hersteller dies noch nicht erkannt und entsprechend Produkte entwickelt und ihn ihr Angebot aufgenommen. Folglich gibt es nicht sonderlich viele Produkte in diesem Bereich zu kaufen. Existierende Produkte beschränken sich zumeist nur auf die Ansteuerung von Lichtsignalen oder anderen einfachen Blinkeffekten. Im Bereich der Eigenbauprojekte gibt es zwar eine größere Auswahl, doch sind diese meist nicht zu Ende gedachtet und/oder entwickelt oder erfüllen schlicht nicht die Wünsche, die wir als Verein haben.

Die Motivation einen eigenen Lichteffekt-Decoder zu entwickeln, entstand im Rahmen des Neubauprojektes ‚Gleis 3‘ bei den Eisenbahnfreunden Bietigheim-Bissingen e.V im Jahr 2010. Bei der Planung dieser neuen Vereinsanlage wird auf Zuverlässigkeit, modernste Technik, aber auch auf etablierte Standards gesetzt – die Anlage soll schließlich auch noch in 10 oder 20 Jahren betrieben werden können, wenn Hersteller Produkte abkündigen oder diverse Zubehörteile nicht mehr nachgekauft werden können, sofern etwas kaputt geht. Daher werden nun aktuelle Produkte, die gemäß etablierten Standards entwickelt wurden, verbaut. So haben wir später auch einmal die Möglichkeit den Hersteller zu wechseln, ohne befürchten zu müssen zu viel umbauen oder verändern zu müssen, dass die Anlage wieder läuft, falls denn eine der oben genannten Situationen eintritt.

Ein solcher Standard stellt das DCC-Protokoll der standardisierenden NMRA Arbeitsgruppe dar. Dieser existiert bereits seit über 15 Jahren und ist sehr verbreitet in der Modellbahnwelt, vor allem in den USA. Wir haben uns zum Ziel gesetzt diesen Standard überall dort einzusetzen, wo es sinnvoll, als auch möglich ist. Neben der Ansteuerung der Fahrzeuge, als auch der Weichen usw. gehören für uns eben auch die Lichter und Effekte hierzu, die später einmal Verwendung finden sollen. D.h. unser eigener Lichteffekt-Decoder soll das DCC-Protokoll verstehen und so seine Befehle entgegen nehmen. Dies hat auch den Vorteil, dass der Decoder durch andere Standardkomponenten ersetzt/ergänzt werden kann (sofern denn irgendwann welche auf den Markt kommen).

Andere bekannte Projekte:

Pro/Contra Bewertung entspricht meinen Vorstellungen bzw. meinem Eindruck!

Projekt Pro Contra
MoBaLiSt
(seit 2011)
  • mehr Leistung je Ausgang steht zur Verfügung
  • Ansteuerung über BiDiB ist standardisiert, also keine Bastellösung
  • günstig
  • PC-Software ist nicht flexibel genug
  • zu groß zum Einbau in Gebäude
  • Software nicht Open-Source
  • kein DCC-Anschluss
OpenDCC LightControl
(seit 2012?)
  • vollständig Open-Source
  • sehr tolle und ausgereifte Hardware
  • Ansteuerung über BiDiB ist standardisiert, also keine Bastellösung
  • DCC-Anschluss vorhanden
  • zu groß zum Einbau in Gebäude
  • zu teuer und überdimensioniert
  • zu wenige Makros können definiert werden (Hauptanwendung von uns)
  • Fokus liegt vermutlich eher bei statischer Beleuchtung und weniger in der Flexibilität alles machen zu können (nur eine Vermutung)
Steffen A. Mork
(seit ?)
  • CAN-Kommunikation sehr zuverlässig, aber nicht von uns gewünscht
  • vollständig Open-Source
  • nicht fertig (Projekt tot?)
  • kein DCC-Anschluss
  • keine Servo-Anschlüsse
Light@Night
(seit ?)
  • fertiges, kommerzielles Produkt mit PC-Software
  • viele fertige Effekte vorhanden
  • viel zu alte Technik (LPT/Parallelport)
  • viel zu groß zum Einbau in Gebäude
  • kein DCC-Anschluss
  • zu teuer
  • geschlossenes, nicht erweiterbares System
BLM 10 von Lauer Systeme
(seit 2011)
  • zufallsgesteuerte Gebäude-Lichtsteuerung
  • nur automatische Gebäude-Lichtsteuerung, sonst keine anderen Funktionen
  • kein DCC-Anschluss
  • keine Servo-Anschlüsse
  • nicht programmierbar
  • geschlossenes, nicht erweiterbares System
Lichtsteuerung von Michael Floessel
(seit 2012)
  • einfacher, kleiner Aufbau
  • günstig
  • automatische Haussteuerung bereits vorhanden
  • Schaltplan Open-Source
  • keine Konfiguration möglich
  • kein DCC-Anschluss
  • keine Servo-Anschlüsse
  • Aktivierung nur über Taster
  • Software nicht Open-Source
TAMS Light Computer
(seit ?)
  • günstig (aber wieder teuer bei den wenigen Optionen)
  • kompakte Bauform
  • kommerzielles Produkt
  • keine Konfiguration möglich
  • kein DCC-Anschluss
  • keine Servo-Anschlüsse
  • nur via Taster/Schalter steuerbar
  • geschlossenes, nicht erweiterbares System
TrainModules
(seit ?)
  • DCC-Anschluss
  • günstig
  • kommerzielles Produkt
  • nur für Signalansteuerung gedacht
  • geschlossenes, nicht erweiterbares System
  • keine Servo-Anschlüsse
  • zu große Bauform für Einbau in Gebäude

Rahmenbedingungen

Für die Eigenentwicklung wurden diverse Rahmenbedingungen festgelegt, sodass ein klares Ziel fest steht und nicht unnötige oder nur selten benötigte Funktionen umgesetzt werden. Folgend eine Liste der wesentlichen Punkte:

  • Ausgangspunkt sollen andere Eigenbauprojekte aus dem Internet sein. Das Rad soll nicht neu erfunden werden – d.h. andere Projekte als Basis verwenden und dann weiter Ausbauen. Ggf. aber manche Teile überarbeiten und neu erstellen.
  • Kleine Bauform des Decoders bei viel Funktionalität. Einbau sollte in möglichst jedem Modellhaus möglich sein. Dies macht SMD-Technik unerlässlich für die Elektronik.
  • Preisgünstig in der Herstellung (Materialkosten) und einfach Auf- und Einzubauen (Zeitaufwand). Der Einbau soll auch von nicht Elektronik-versierten Personen möglich sein.
  • Verwendung des DCC-Protokolls gemäß NMRA-Spezifikation zur Steuerung des Decoder. Alternativ soll dieser auch klassisch über Taster und Schalter gesteuert werden können (für unsere alte und analoge Clubanlage) bzw. automatisch Effekte starten, sobald Spannung anliegt.
  • Gute, vollständige und freie Dokumentation aller Komponenten. Dies beinhaltet auch das Veröffentlichen der Schaltpläne, des Layout, als auch der Software für den vereins-internen Gebrauch.
  • Einfache Programmierung und Konfiguration des Decoder über einen beliebigen PC oder Laptop. Dabei soll die Adresse des Decoders, als auch die Abläufe und Animationen frei definierbar sein. Eine grafische Konfiguration wird bevorzugt.
  • Der Decoder soll über zwei Varianten mit Strom und DCC-Signal versorgt werden können:
    1. Strom und DCC-Signal auf einer Leitung wie auch für Loks auf dem Gleis (Anschluss direkt über eine Zentrale/Booster; benötigt bei entsprechender Anzahl LEDs erhebliche Anzahl an Boostern)
    2. Strom und DCC-Signal getrennt (diese Variante entlastet den Geldbeutel indem nicht so viele teure und leistungsstarke Booster für das DCC-Signal benötigt werden; Stromversorgung kann über günstige Notebook-Netzteile erfolgen)
  • Für die Lichtausgabe sollen ausschließlich LEDs Verwendung finden, da diese wenig Strom verbrauchen, eine geringe bis kaum Abwärme haben, günstig zu beschaffen sind und lange Laufzeiten im Vergleich zu Glühlampen o.ä. haben.
  • Pro Ausgang am Decoder sollen möglichst viele LEDs angeschlossen werden können, egal welche Farbe die LED hat (relevant, da die Spannung für jede LED-Farbe anders sein kann)
  • Optional Ansteuerung von Modellbau-Servos über den Decoder für Bewegungsanimationen.
  • Optional Ausgabe von beliebigen DCC-Signalen zur Ansteuerung von DC-Car Fahrzeugen z.B. Stoppstelle, Blinker an/aus, Fahrlicht an/aus, Fahrstufe 1-28 usw.
  • Optional, um Kosten einzusparen, soll es möglich sein mehrere Decoder zu kaskadieren. D.h. es wird nur ein Mikrocontroller benötigt, wenn mehr LED Ausgänge genutzt werden sollen.

Aktueller Funktionsumfang

Generell:

  • fünf DCC Adressen von eins bis 16384 können konfiguriert werden, auf welche reagiert werden soll. Dies ermöglicht z.B. eine Individualsteuerung mit je einer Adresse pro Dekoder, als auch eine Gruppierung von mehreren Dekodern um eventuell ganze Anlagenteile auf Tag/Nachtbetrieb umzustellen.
  • DCC Funktionen bzw. Funktionstasten von F0 bis F28 (Frontlicht wird als Funktionstaste F0 betrachtet)
  • DCC Accessory-Decoder-Befehle als Alternative zu den Funktionstasten (Weichen- bzw. Schaltartikeldekoder)
  • 16 LED-Ausgänge, jeweils bis 100mA belastbar; Spannung je nach Stromversorgung (typisch 12V-18V)
  • 10 zusätzliche Ein- und Ausgänge für Erweiterungen oder analoge Steuerung über Taster/Schalter
  • viele vordefinierte Lichteffekte (siehe unten)
  • Eingänge und Funktionen frei mit Ausgängen und Animationen konfigurierbar
  • zwei Modellbau-Servo können angeschlossen werden
  • keine Konfiguration via CV-Werte oder lange Parameterlisten, Decoder kann keine Hauptgleisprogrammierung bzw. Service-Mode (Acknowledge wird nicht unterstützt)
  • Konfiguration via RS232 bzw. serieller Schnittstelle am PC über grafische Oberfläche, welche überwiegend mit der Maus bedient wird. FTDI basierte USB zu TTL Seriell-Konverter ohne Pegelwandler werden bevorzugt.
  • auf bis zu 32 LED-Ausgänge erweiterbar (in Konzept und Platine vorgesehen, Software noch in Arbeit)
  • Verwendung der Standard DCC-Pakete, keine eigene Lösung oder Veränderungen am Protokoll nötig zur Ansteuerung. Daher Standard DCC-Zentralen und Booster einsetzbar
  • ausreichend Spielraum für eigene Erweiterungen vorhanden

Lichteffekte und Animationen:

  • 10 Blinkfolgen von Einsatzfahrzeugen (Polizei, Feuerwehr, Krankenwagen) gemäß ECE-Norm
  • Sodium Gasdrucklampen Simulation (Einschalten/Ausschalten)
  • 9 Neonlampen/Leuchtstoffröhren Starts werden simuliert
  • 2 defekte Neonlampen/Leuchtstoffröhren Simulationen mit Flackern/Aussetzern
  • 2 Simulationen für beliebige defekte Leuchtelemente
  • Auf- und Abdimmen von Ausgängen in 0.5, 1 und 60 Sekunden
  • Permanent an oder aus
  • Simulation von Verkehrssicherungsanhänger (VSA) zur Sicherung von Baustellen auf der Autobahn
  • Gaslampen Simulation (Einschalten)
  • Simulation von Gasdrucklampe
  • Schweißlicht
  • Lagerfeuer Simulation
  • Beacon-Lights von US-Zügen
  • Blinken von gelbem Licht für Verkehrsampeln
  • Blinken für Bahnübergänge (Andreaskreuze)
  • und noch viel mehr selbst definierbar!

Umsetzung

Version 0.1 – Steckbrett-Aufbau

Die erste Version des Decoder entstand als Testaufbau auf einem Steckbrett, um überhaupt die Machbarkeit zu demonstrieren. Darüber hinaus wurde in dieser Phase experimentell ermittelt welche Komponenten verwendet werden können bzw. zum Einsatz kommen müssen. Basis für den Aufbau war sowohl aus Hardware, als auch Software-Sicht das opendcc Projekt von Wolfgang Kufer. Während dieser Entwicklung gab es diverse Grundsatzentscheidungen sowie Erkenntnisse, die hier kurz aufgeführt sind:

  • Die Ansteuerung der LED erfolgt über einen speziellen Treiber, welcher speziell hierfür vom Hersteller entwickelt wurde. Der Mikrocontroller gibt Dimm-Aufgaben an den Treiber ab, um Rechenkapazitäten für andere Dinge frei zu haben
  • Das DCC-Signal wird via Optokoppler galvanisch getrennt. Störungen auf dem Gleis bzw. in der Dekoder-Elektronik können sich gegenseitig nicht beeinflussen z.B. im Falle von Kurzschlüssen oder Überspannung
  • Der Mikrocontroller wurde festgelegt auf einen 8-Bit Typ der Firma Atmel

IMG_4015

Anhand dem Steckbrettaufbau konnte man bereits die wichtigsten Funktionen des Decoder implementieren und testen. Alle für uns relevanten und gewünschten Funktionen konnten simpel umgesetzt werden und funktionierten! Getestet wurde mit einer MultiMaus von Rocco, mit welcher einzelne Funktionen für die ‚Lok‘ mit der Adresse eins aktiviert und deaktiviert wurden. Der Decoder hat diese DCC-Signale erfolgreich ausgewertet, in Lichteffekte bzw. Animationen umgesetzt und diese über den LED-Treiber ausgegeben. Infolgedessen konnte mit der Entwicklung fortgefahren werden, indem der Steckbrettaufbau auf eine Platine gebannt wurde.

Version 1.0 – defekte Platine

Die erste richtige Platine sollte lediglich den Steckbrettaufbau mit diversen zusätzlichen Funktionen darstellen. Die Entwicklung lief gut, aber schnell wurde klar, dass ein doppelseitiges Layout aufgrund der kleinen Fläche nötig war. Nachdem das Routen der Leiterbahnen abgeschlossen war, wurden die benötigten Teile beschafft und die Platine zur Fertigung freigegeben. Bis hierhin war auch bereits die Größe der Platine definiert bzw. gefunden: 50x25mm.
Als alle Teile beschafft waren, wurde die erste Platine bestückt und versucht diese in Betrieb zu nehmen. Leider war dies nicht möglich, da es permanent einen Kurzschluss gab. Der Grund hierfür wurde auch nach längerer Recherche und vielen Testmessungen nicht gefunden. Infolgedessen wurde das Layout und der Schaltplan nochmals überarbeitet, woraus dann die Version 2.0 entstand. Die übrigen Platinen landeten in Ablage M (Mülleimer).

Folgende Funktionen/Eigenschaften hatte diese Version:

  • eigene Spannungsversorgung, da vorher über USB via ISP-Programmer gespeist
  • externes EEPROM um Einstellungen und Effekte darin speichern zu können
  • Die Taktversorgung erfolgt über einen Quarzoszillator, um zwei Kondensatoren einsparen zu können
  • Die JTAG-Schnittstelle zum Debuggen während der Entwicklung wurde herausgeführt
  • Die ISP-Schnittstelle wurde zum Programmieren herausgeführt

Version 2.0 – erste funktionierende Platine

Aufgrund der fehlerhaften Version 1.0 entstand die nächste Version 2.0, welche dann auch endlich in Betrieb genommen werden konnte. Es stellte sich zwar heraus, das stets noch Fehler existierten, aber diese waren nicht so kritisch, sodass diese erst später in Version 2.1 behoben wurden. Die eigentliche DCC-Funktionalität sowie Ausgabe an die LEDs funktionierte einwandfrei. Folgende Veränderungen gab es für die Version 2.1:

  • zwei Servo Anschlüsse kamen hinzu
  • der Dekoder war nun kaskadierbar d.h. man konnte theoretisch mehrere LED-Treiber mit einem Mikrocontroller verbinden (theoretisch, da die Software hierfür nicht angepasst wurde)
  • Die Kaskadierung erfolgte über spezielle Expansion-Stecker beidseitig am Rand der Platine
  • v-USB wurde auf der Platine vorgesehen und integriert, jedoch nie in Betrieb genommen (sollte ursprünglich für die PC-Konfiguration Verwendung finden)
  • zusätzliche Ein- und Ausgänge für weitere Funktionen bzw. Taster/Schalter wurden berücksichtigt
  • Die Frequenz für den Mikrocontroller wurde erhöht, um den Mehrumfang der Software bewältigen zu können
  • Die JTAG-Schnittstelle wurde wieder entfernt, da diese nie genutzt wurde und nur Platz auf der Platine verschwendet hat
  • Der Regler zur Stromversorgung wurde abermals mit einem anderen und platzsparenden Typen ersetzt

IMG_4001

Die Platinen- und Schaltplan-Version 2.0 war die erste, mit welcher so richtig viel im Bereich der Software für den Mikrocontroller entwickelt werden konnte. Überarbeitet bzw. neu erstellt wurden:

  • Eigener Scheduler um Events bzw. zeitgesteuerte Funktionen zu verwalten und ausführen zu können
  • Abstraktion der Mikrocontroller-Funktionalität um einfacher Änderungen vornehmen zu können
  • Bibliothek mit Grund-Animationen wurde zum Testen erstellt
  • System zum Dimmen von LED wurde überarbeitet und vereinfacht
  • Überarbeitet wurden unter anderem auch sämtliche DCC relevanten Sende- und Empfangsroutinen für mehr Zuverlässigkeit und schnellere Verarbeitung (komplett von Grund auf neu entwickelt)

Version 2.1 – Fehlerbereinigt

Wie es der Fehlerteufel so will, haben sich auch wieder in der Version 2.0 neue Fehler eingeschlichen. Auch dieses Mal waren diese nicht gravierend, sodass die Software weiter entwickelt werden konnte. Software lässt sich nun einmal leichter anpassen, ändern und Fehler beheben, als das in Hardware möglich wäre.

Für die nächste Version wurden folgende Veränderungen vorgenommen:

  • der Port am Mikrocontroller, welcher für v-USB genutzt werden sollte war leider falsch gewählt. Andere Funktionen haben die benötigten Pins bereits belegt.
  • Der gekaufte Quarzoszillator war leider nur für 3,3 Volt geeignet und wurde beim Betrieb an 5 Volt etwas warm. Dies lag daran, da das Datenblatt und das angebotene Teil im Webshop einmal nicht direkt von mir abgeglichen wurde. Ein normaler Quarz lag noch bereit – mit diesem funktionierte dann wieder alles.
  • Die Modellbau-Servo funktionierten zwar an den bereits gewählten Ausgangs-Pins des Mikrocontroller, doch war der dahinter genutzte Timer nicht hoch genug aufgelöst. Eine Umbelegung auf einen anderen Timer mit höherer Auflösung war nötig.

Version 3.0 – überarbeitete Version

Die nächste Generation des Lichteffekt-Decoder sollte noch kleiner und kompakter werden. Hierzu wurden einige Veränderungen vorgenommen, welche im folgenden aufgeführt sind:

  • Der verwendete Mikrocontroller ist in einer noch kleineren Gehäuseform verfügbar. Diese wird nun verwendet. Dadurch kann die Platine in der Größe auf 25x32mm schrumpfen.
  • Sämtliche anderen Komponenten werden nun ebenfalls in der kleinsten verfügbaren Größe verbaut, welche noch per Hand gelötet werden kann
  • Das externe EEPROM für zusätzliche Konfigurationsdaten entfällt, da nicht genutzt
  • v-USB wurde entfernt, da eigentlich überhaupt nicht benötigt und Lizenz-Probleme mit USB.org hierdurch entstanden wären (eigene Vendor-ID)
  • Der Expansion-Stecker, als auch der ISP-Anschluss wurde durch einfache Lötpads ersetzt um weiter Platz auf der Platine sparen zu können
    • Die Mikrocontroller-Programmierung erfolgt ab sofort via gefederten Prüfspitzen (so genannte Pogo-Pins) in einer speziellen Vorrichtung
    • Expansion-Platinen werden mit kurzen Flachbandkabeln miteinander verlötet und verbunden

IMG_4006

Für die Version 3.0 wurde auch mit der Entwicklung der PC-Software zur Konfiguration der Effekte und Zuordnungen begonnen. Konfiguriert wird über eine serielle Schnittstelle (RS232/UART) und einem Programm, welches in Java geschrieben wurde. Nur über diese Software ist die Konfiguration möglich, da für das Programmieren via DCC zu wenig Bandbreite zur Verfügung steht, kein geeigneter Programmiermodus wie für CV-Werte existiert und DCC eigentlich nur ein unidirektionales Protokoll ist. D.h. das Auslesen der Konfiguration wäre nicht schnell genug möglich für eine angenehme Programmierung. Die Integration von DCC-ACK bzw. Railcom wurde erötert, aber wieder verworfen. Im Grunde genommen werden viele Lichteffekt-Dekoder auf einem DCC-Bus angeschlossen und mit Daten versorgt. Railcom/DCC-ACK funktioniert aber nur wenn ein Dekoder auf einem separaten DCC-Bus bzw. Abschnitt angeschlossen ist. Eine entsprechende Arbitrierungslogik fehlt schlichtweg – sämtliche Dekoder würden gleichzeitig Antworten und sich ihre Antworten gegenseitig überlagern. Eine Zentrale wäre nicht in der Lage die Daten sinnvoll auszuwerten (eventuell wird dieses Problem mit Railcom Plus einmal gelöst!?).

Version 4.0 – Servo Stromversorgung

Die zwei Servo-Anschlüsse waren zwar bereits seit der frühen Phase der Version 2.0 vorgesehen und auf dem Layout integriert, jedoch wurden diese nie getestet. Das ist ein grober Schnitzer, lag aber primär daran, dass die Software nie so weit fortgeschritten war, dass etwas anderes – hier die Servo – getestet werden konnten.

Zeichnung

Daher folgende Änderungen:

  • Alternative Spannungsversorgung für die Modellbau-Servo mit mehr Strom (je nach Bestückung 500mA oder 1A). Der bis dato verwendete Linearregler stellte schlicht zu wenig Strom zur Verfügung.
  • Um den Stromverbrauch zu optimieren wurden zwei MOSFET nachgerüstet, um die Servos bei Bedarf an- und abschalten zu können.
  • Der Quarz wurde durch einen Resonator ersetzt.
  • Diverse unnötige Bauteile wurden entfernt, andere durch kleinere Bauformen ersetzt.
  • Der Optokoppler für die galvanische Trennung des DCC Signal wurde Aufgrund einer Diskussion mit einem namhaften Hardware-Hersteller im Modellbahnsektor entfernt, da dieser im Prinzip nicht nötig sei, verhältnismäßig viel kostet und Platz auf der Platine wegnimmt. Eine Ersatzschaltung zum Schutz des Mikrocontroller-Pin wurde auch gleich von derselben Person vorgeschlagen und integriert.
  • Diverse Layoutänderungen wodurch die Gesamtgröße auf 20x25mm geschrumpft werden konnte. Bedingt dadurch musste auf eine 4-lagige Platine gewechselt werden (günstig in China zu beschaffen).
  • Die Herausführung der Lötanschlüsse erfolgt nun immer über Pinheader im 2,54mm Raster. Diese wurden gemäß der Funktion möglichst passend angeordnet, um die Herausführung mit Steckern zu ermöglichen.
  • Ein GPIO-Header für die Erweiterung mit RS485/BiDiB bzw. die Programmierung via RS232/UART wurde entsprechend vorgesehen.
  • Diverse Lötpads wurden für die Erweiterung auf 32 anstatt 16 LED-Ausgängen vorgesehen.
  • Ein Breakout-Board zur Entwicklung und Effekt-Programmierung wurde entwickelt. Dieses führt sämtliche Anschlüsse steckbar heraus: Servos, ISP, GPIO, LEDs, Stromversorgung sowie DCC

IMG_5477

Version 5.0 – die Vision

Die nächste Generation des Decoder soll noch umfangreicher ausfallen. Ziel ist die Verwendung eines Cortex-M0 oder Cortex-M3 als Prozessor mit bis zu 50Mhz. Des Weiteren sind folgende Features angedacht. Geplant bzw. in Arbeit ist hiervon jedoch noch nichts:

  • 3,3V anstatt 5V für den Controller und LED-Treiber
  • Verwendung von Bluetooth 4.0 Low Energy Funkmodulen zur Kommunikation via einem Mesh-Netzwerk. Dadurch optional Wegfall von DCC für die Ansteuerung der Effekte bzw. Programming-over-Air.
  • Verwendung von kompakten Steckverbindern aus der Handy/Smartphone-Sparte um nicht mehr löten zu müssen bei Dekoderwechsel o.ä. Dadurch wird eine Art kompakte Breakout-Platine für die Anschlüsse benötigt.

Konfigurations-Software

Sämtliche Einstellungen und Effekte des Lichtdekoder werden über eine mehrsprachige und Java-basierte Software erledigt. Durch den Einsatz von Java kann diese unter jedem heute üblichen Betriebssystem verwendet werden. Die Kommunikation mit dem Lichtdekoder erfolgt über eine serielle Verbindung (bevorzugt über einen USB/TTL-RS232 Wandler von FTDI), welche um eine eigene Flusssteuerung sowie Erkennung für Übertragungsfehler erweitert wurde. Darüber hinaus ist eine vollständig verschlüsselte Übertragung ohne fest kodierte Schlüssel vorgesehen, damit auch Firmware übertragen bzw. aktualisierte werden kann. Ein eigener Bootloader, der dies ermöglicht ist in der Mikrocontroller-Firmware bereits integriert.

Folgend noch ein paar Beispielbilder dieser Software:

screen1

screen3

screen2