6. Hardware

Nun folgt eine Beschreibung des verwendeten Controllers. Die am „Selbstbau“-Markt erhältlichen Controller waren mir nicht gut genug; entweder zu viele Bauteile oder zu viel zum Bohren oder nicht genug Features, usw. Außerdem ist’s der Stolz des Ingenieurs, so etwas selbst zu bauen 🙂

6.1 Hohe Dynamik des Sehapparates

Zunächst etwas Theorie: Die Natur hat mit dem Auge ein extrem gutes Stück Biotechnik erschaffen. Nicht nur können wir Dinge scharf sehen, die sich direkt vor uns und sehr weit weg befinden, sondern haben wir auch einen riesigen Umfang an möglichen Helligkeitswerten – in der Nacht bei Sternen können wir noch immer Konturen (z.B. Waldweg/Bäume) erkennen und haben auch keine Probleme mit einer Yummi-Braut am Strand bei hellstem Sonnenschein.

In Lux ausgedrückt sind das 0,001 – 100 000 lx (Quelle), wie man unschwer erkennen kann, „sehr viel“. Unser Auge schafft diese Dynamik, indem es Signale logarithmisch codiert. Wir sind also am unteren Ende der Skala („dunkel“) sehr empfindlich, wohingegen wir nur noch wenig Unterschied zwischen Signalen im oberen Bereich („hell“) wahrnehmen.

Für den bilddarstellende Geräte im Allgemeinen und unserem Ambilight-Controller im Speziellen hat das nun eine Auswirkung (Stichwort Gamma-Korrektur): Wir müssen die Wechsel zwischen den Farben bei sehr dunklen Tönen sehr „weich“ hinbekommen, ansonsten sieht der Betrachter störendes Flackern.

6.2 Helligkeitsänderung von LEDs mittels PWM

LEDs sind stromgesteuerte Bauteile: Je mehr Elektronen durchgehen, desto mehr Photonen kommen raus. Es bestehen also grundsätzlich zwei Möglichkeiten der Helligkeitsänderung: Mittels Stromsteuerung oder mittels der Puls-Weiten-Modulation (PWM). Eine Stromsteuerung ist wegen der erforderlichen Regelschleife relativ aufwendig, es hat sich daher eingebürgert, das menschliche Auge durch schnelles Ein- und Ausschalten (eben PWM) der LEDs zu überlisten. Der Effekt ist der gleiche: Je geringer der sogenannte Duty-Cycle (also das Verhältnis von An- zu Aus-Zeit der LED), desto dunktler erscheint sie.

Im nächsten Kapitel gehe ich bei der Beschreibung der Firmware da noch näher drauf ein, für jetzt müssen wir uns nur merken, dass der Controller 3×3 PWM-Ausgänge bereitstellen muss (für drei Leisten â drei Farben) mit einer möglichst großen Anzahl an Schritten pro Duty-Cycle. Man sagt auch: eine möglichst große „Auflösung“ der PWM.

Auflösung (im Bild ist ein Schritt mit „t1“ bezeichnet): 256 Schritte (8bit PWM) sind da zu wenig. Die Erfahrung zeigt, dass auch 10bit (1024 Steps) noch kritisch sind, erst ab 12 Bit (4096 Schritte) erscheinen die Verläufe linear, weil dann der Unterschied zwischen den Duty-Cycles bei den kleinen Helligkeitsstufen (also 1/4096 an, 2/4096 an, 3 von 4096 an, usw.) fein genug ist, um dem Dynamikempfinden des Auges gerecht zu werden.

Frequenz (im Bild mit „T“ bezeichnet): Der zweite Parameter einer PWM ist ihre Frequenz, sprich wie oft pro Sekunde fange ich wieder mit dem ersten Schritt an. Durch Tests habe ich herausgefunden, dass die Frequenz mindestens 75 Hz betragen sollte; ab 70 Hz und drunter sieht man es flimmern bei hellen Farben.

6.3 MCU alleine oder mit dediziertem LED-Treiber?

Als letzte Designfrage stellt sich noch, ob wir unsere MCU nur zur Kommunikation mit dem PC benutzen und den PWM-Teil einem separaten Treiber überlassen, oder ob die MCU alles tut.

Ich habe lange gesucht. Ich habe unzälige Treiber ICs (der beste: TLC5943) gefunden für LEDs, die automatisch PWM mit herrlichem Spread-Spektrum erzeugen und schönen weiteren Features. Nur haben alle Treiber einen „Fehler“: Sie steuern ihre Kanäle mittels Stromsteuerung. Das ist aber nichts für die käuflichen LED-Leisten, die bereits Widerstände eingelötet haben und für Spannung-Steuerung (12V) auslegt sind.

Auch ist es mir dank der in den meisten Chips eingebauten Fehlerkontrolle (LED angeschlossen oder defekt) nicht gelungen, an den Ausgang eines solchen Kanals einen Low-Side MOSFET zu schalten. Die Treiber haben regelmäßig einen Fehlerzustand erkannt bzw. der MOSFET hatte nicht richtig geschlossen.

Eventuell ginge es mit einer konstanten Last und einem High-Side Switching, das wäre aber ein großer Design-Aufwand, der sich in Anbetracht der zu erwartenden Ergebnisse nicht rechtfertigen läßt.

6.4 Systembeschreibung des Controllers

Nachdem von den „bezahl“- und „überschaubaren“ MCU’s keine einzige mehr als 8 16Bit-Timer mit Compare-Output besitzt (Atmel und PIC), bleibt nur die Software-Lösung. Siehe nächstes Kapitel. Der Kontroller an sich ist sehr einfach gehalten und besteht aus einem Kommunikationsteil (RS232, FTDI USB), der MCU und den Lowside-Treibertufen (IRF-MOSFETs) für die LEDs, wie im Bild zu sehen.

Ich hab hauptsächlich SMD-Teile verwendet, die sind nämlich leichter zu bekommen und verurachen weniger Arbeit zum bohren, die Platine ist locker im Eigenbau machbar, auch die feinen FTDI-Beinchen waren gut zu ätzen. Hier der Controller fertig aufgebaut, Teilekosten ca. 20 EUR.

Die MCU (ATMega16) ist mit 14,7 Mhz (wegen USART-Frequenz) getaktet und erzeugt die neun benötigten Signale über eine Software-PWM; die Steuersignale werden dann einfach 1:1 an die Gates von neun MOSFETs übertragen und schalten so den Strom für die LED-Leisten ein und aus. Nachdem das eine ziemliche Laständerung auf der 12V-Leitung bewirkt, empfiehlt sich einweder ein sehr gutes, steiles LC-Tiefpass-Filter (Achtung bei den Spulen, müssen 2A aushalten) bei Verwendung eines PC-Netzteils oder ein stabilisiertes separates Netzteil, welches im Allgemeinen diese Filterfunktion bereitstellt.

Ein Wort zur benötigten Frequenz: gehen wir von einer PWM-Frequenz von 100Hz und einer 16-bit Auflösung (65536 Steps) aus, so kommen wir auf eine Frequenz von 100*65536= 6,55 MHz. Dafür gibt es bereits fertige Quarze. Leider trifft diese Annahme nur für Hardware-PWM (also ein MCU-Taktzyklus entspricht genau einem PWM-Step) zu, bei Software-PWM ist es komplizierter. Deswegen sei an dieser Stelle gesagt, takte die MCU so schnell wie möglich. Bei Atmel mit 16MHz Maximalfrequenz ist das bei Verwendung des USART eben 14,7456 MHz, damit keine Übertragungsfehler auftreten (USART-Symbolraten haben typischerweise 9k6, 19k2 oder 38k4 Symbole/Sekunde).

6.5 Dateien und Stückliste

Hier einmal die zum Ätzen und Nachbauen notwenigen Files.

• EAGLE Schematic: LED-Controller (LowSide) – EAGLE Schematic
• EAGLE Board: LED-Controller (LowSide) – EAGLE Board
• Bill of Materials: LED-Controller (LowSide) – Bill of Materials