Ambi-Light 2: 16bit PWM, 5 RGB-Kanäle

4. Features des neuen Controllers

Mit den oben erwähnten Möglichkeiten der neuen MCU habe ich dem Steuergerät die folgenden Features spendiert.

4.1 Übersicht

  • 5 RGB-Kanäle, 16bit PWM, ~112 Hz Grundfrequenz, bis zu 2 A pro Kanal
  • 4-polige Westernstecker zur einfachen Montage
  • Serielle Schnittstelle 8N1, 57.6 kBit/s
  • PDI-Programmierschnittstelle
  • Grüne und rote LED (Empfang, Frame-Error)
  • 7,2837 MHz
  • Bis zu vier Kontroller „daisy-chainable“

4.2 Kaskadierung

Ja, ihr habt richtig gelesen. Man kann bis zu vier Kontroller hinter- oder übereinander montieren und sie mit 6-poligem Flachbandkabel verbinden. Dass dann natürlich nicht mehr jeder Kanal mit 2A belastet werden darf, versteht sich von selbst. So braucht man auch für 20 RGB-Kanäle nur eine einzige serielle Schnittstelle und 20 RGB-Kanäle sollten für jede Leinwand (oben, rechts, links, unten jeweils 5) mehr als ausreichen. Auch reicht ein Netzteil aus, da der Strom (+ und Masse) durch je zwei Flachbandleitungen geleitet wird.

Ein weiterer Vorteil ist, dass bei den „Slaves“ nicht alle Bauteile bestückt werden müssen, siehe Kapitel weiter hinten. Jeder Controller besitzt zwei Jumpermöglichkeiten, mit welchen die Kanalpositionen eingestellt werden können (0-14, 15-29, 30-44, 45-59). Zum Protokoll siehe nächstes Unterkapitel.

Auch ist bei 57,6 kBit und 50Hz Aktualisierungsrate mit 60 Bytes und der dem Timing der momentanen Firmware relativ Schluss. Würde man entweder die Aktualisierungsrate oder die Anzahl der Kanäle erhöhen, wäre die Pause zwischen Frames nicht mehr lang genug, um einen neuen Frame zu erkennen.

4.3 Protokoll

Ich habe mich dagegen entschieden, ein LTBL-Protokoll zu implementieren. Platz genug wäre noch in der MCU, vielleicht möchte sich das einer der geschätzen Leser antun. Statt dessen kommt eine modifizierte Version von MoMoLight zum Tragen. Normalerweise müßten bei MoMo-Light für einen Controller alle Farbwerte den Kanälen nach sortiert geschickt werden. Das würde bedeuten:

R01...R20 G01...G20 B01...B20

So müßte aber jeder Controller immer alle Datenwerte mitlesen und wäre unnötig beschäftigt. Besser ist es, wenn der Controller erst am vorgesehenen Index des Datenstroms beginnt, die Daten mitzulesen, und sich danach nicht mehr kümmert. Das modifizierte Protokoll lautet somit:

R01...R05 G01...G05 B01...B05 | R06...R10 G06...G10 B06...B10 |
R11...R15 G11...G15 B11...B15 | R16...R20 G16...G20 B16...B20

Jeder Controller ist somit für genau 15 Bytes aktiv.

Glücklicherweise kann man der Boblight-Software die Indizes der Kanäle vorgeben. Die 15-RGB-Kanal-Version der boblight.conf stelle ich hier zum Download bereit.

5. Hardware

Es folgt die Aufbaubeschreibung der Hardware. Bitte beachtet, dass die PCB-Layouts (Schaltplan, PCB und Ätzmasken) unter der Creative Commons Lizenz by-nc-sa stehen. Ihr dürft die Daten nicht kommerziell verwenden und müßt den Urheber angeben. Eine Weitergabe zu den gleichen Bedingungen ist gestattet.

5.1 PCB und Herstellung

Die Platine kann gut selbst hergestellt werden. Ich verwende dafür normale Klarsichtfolien, auf die ich die Platine (bzw. den kompletten Nutzen) 2x ausdrucke mit etwas Abstand. Dann wird eine Version knapp ausgeschnitten und auf die andere per Tesa-Film draufgeklebt. Am besten auf einer weißen Unterlage durchführen, dann sieht man die Ränder sehr gut. Arbeitet hier absolut präzise. Wenn der Photolack nur halb belichtet wird, wird die Platine nix.

Anmerkung: Die Platine oben ist nicht vollständig. Ich habe die Halterungslöcher der RJ11-Stecker abgeschnitten, damit die Sache viermal auf eine Europaplatine (16cm x 10cm) paßt. Deswegen hier links noch die vollständige Version. Die geht aber nur zweimal auf eine Europlatine, bedeutet mehr Abfall.

Hier könnt ihr beide Versionen in voller Auflösung downloaden. Die EAGLE-Files gibt es in dieser ZIP-Datei.

Legt nun die Folie in’s Belichtungsgerät, und zwar so, dass die Schrift von oben spiegelverkehrt ist. Schutzfolie von der Platine abziehen und 4:30 belichten (Isel Belichter mit Timer).

Nach dem Belichten muß der Lack mit Entwickler entfernt werden, ein halber Teelöffel in warmes Wasser reicht locker. Handschuhe nicht vergessen, NaOH ist ekelig zur Haut!

Zu guter Letzt muss die Platine geätzt werden. Fertig ist sie, wenn ihr mit der Taschenlampe gut durch die Zwischenräume leuchten könnt.

Belichtet nun die ganze Platine ohne Maske und löst den Lack von den Leiterbahnen (sonst wird’s Löten recht schwierig).

6. Bohren

Jetzt geht es ans Bohren: Die Proxxon-Teile mit Bohrständer leisten immer gute Arbeit, die Bohrer nehm ich von Bungard. Da gibt’s jeweils 10 in einer Packung, falls mal einer abnippelt. Unter keinen Umständen darf die Platine bewegt werden, sobald der Bohrer sich darin befindet. Schiebt die Platine eher locker ungefähr an die richtige Stelle, drückt den Bohrhebel und lasst den Bohrer sie sich selbst in die richtige Position ziehen. Sobald das geschehen ist, aber fest auf den Untergrund andrücken.

Als Bohrgrößen braucht ihr 0,8mm (0,7 wäre optimal, bricht aber extrem schnell ab) für die Quarz-Löcher, die RJ11 und die RS232 Buchsen. Für die Pfostenleisten werden 0,9 fällig, oder ihr bohrt jedes Loch mit einer Aale nach. Jetzt sollte das ganze wie hier links ausschauen.

7. Bestückung

Schaut am besten in die Eagle-Datei, wo welches Bauteil hinkommt. Ansonsten sollte es keine Schwierigkeiten geben, und wie immer gilt bei SMT:

  • ICs zuerst (MCU, IRF’s, MAX3232, V-Reg)
  • Einen Eckpin auf der Platine verzinnen, dann Bauteil darauf ausrichten. Sprich: Eine Hand lötet, die andere schiebt das Bauteil ggf. mit einer Pinzette hin bis es an allen Seiten exakt paßt. Dann die restlichen Pins anlöten.
  • Bei gepolten Kondensatoren gilt es aufzupassen: Die topfförmigen haben den schwarzen Strich bei MASSE, die gelben haben den braunen Strich bei PLUS!
  • Bei LEDs: Die Spitze der Markierung (Dreieck oder „T“) ist, anders als man meinen könnte, MASSE.
  • Weniger Zinn ist mehr: Kauft einen Zinn mit möglichst wenig Durchmesser.

Die Teile für RS232 (4 Kondensatoren, MAX3232, Buchse) müssen nur einmal bestückt werden.

Ursprünglich hatte ich auch vor, den V-Reg nur einmal zu bestücken, es hat sich aber gezeigt, dass der bei 60 mA und 12V Eingangsspannung schon so extrem heiß wird, dass ich deswegen empfehle, einen auf jeder Platine bestücken. Eigentlich müßte man noch die 3,3V Leitung der Durchschleifung auftrennen, es scheint aber bisher keine Probleme mit Querströmen zu geben, ich habe das deswegen erst einmal gelassen. Für die Zukunft sollte man aber einen größeren V-Reg einbauen, vielleicht einen der 1117er Reihe.

8. Weitere Bilder

Hier noch ein paar andere Fotos, unter anderem die Modifikationen an den LED-Leisten, sowie ein „Serviervorschlag“.

12 Kommentare zu “Ambi-Light 2: 16bit PWM, 5 RGB-Kanäle”

1.   Kommentar von Herman Oving
Erstellt am 22. März 2010 um 12:26 Uhr.

Hallo. Klasse gemacht. Wir überlegen ob wir die Daten nicht per PWM rausschicken, sondern als DMX. Der dmx receiver macht dann den PWM Teil, zB eine PAR oder moving head oder LED rgb light.
Ein Atmel mit dmx zu versehen ist nicht viel arbeit. Jedoch erst mal in dein Code einsteigen. Theoretisch brauche ich nur einen hex Wert zwischen 0 und 255 pro r,g oder b. Also 12 Kanäle( 4 * rgb) Mal sehen wo ich den am besten abgreife. Leider ist mein c nicht besonders gut. Bislang verwende ich nur assembler. Den PWM Teil werde ich dann weg lassen. Noch habe ich dein Code noch nicht mal detailliert angeschaut.
Vielen Dank und mal sehen ob das Projekt was wird.
Fabian & Herman Oving

2.   Kommentar von McSeven
Erstellt am 22. März 2010 um 14:59 Uhr.

Hi, Danke. Ich hab nur nicht genau verstanden, was ihr machen wollt? Soll es ein Seriell-zu-DMX-Konverter werden? Da schaut mal unter http://www.mikrocontroller.net, da gibt’s einiges zum Thema. Ziel dieses Projektes sollte ja genau die PWM-Ausgabe sein…

3.   Kommentar von hurra
Erstellt am 27. März 2010 um 15:12 Uhr.

Gibts den kompletten Quellcode auch nochmal zum Runterladen?

Danke

4.   Kommentar von McSeven
Erstellt am 27. März 2010 um 18:33 Uhr.

Hi, das versteh ich inhaltlich nicht. Auf Seite drei hast Du den gesamten Quelltext der Firmware. Mehr ist’s nicht. Und für die Sourcen von Boblight mußt Du auf seiner Seite schauen…

5.   Kommentar von hurra
Erstellt am 28. März 2010 um 13:39 Uhr.

c:/winavr-20100110/bin/../lib/gcc/avr/4.3.3/../../../../avr/lib/avrxmega2/crtx16a4.o:(.init9+0x0): undefined reference to `main‘

Was mache ich falsch?

6.   Kommentar von McSeven
Erstellt am 05. April 2010 um 12:42 Uhr.

alles klar, es war ein dummer Fehler beim Kopieren und Einfügen, ich habe die neueste und vollständige Version eingebaut. Sollte funktionieren… Danke für den Hinweis.

7.   Kommentar von hurra
Erstellt am 03. Mai 2010 um 16:39 Uhr.

Hallo nochmal.

Ich konnte das Projekt erfolgreich nachbauen! Funktioniert super.

Die Schaltung hat aber imho noch ein Problem: Die Sende- und Empfangsleitung zwischen MAX und dem COM-Anschluß sind gekreuzt.
Darum wird im aktuellen Schaltplan ein Nullmodemkabel zwischen PC und Platine benötigt. Bei der Verwendung eines USB-Serial-Adapters muss das gekreuzte Nullmodemkabel zusätzlich noch eingefügt werden.

Ich würde die Kreuzung auf der Platine entfernen und Stattdessen eine normales Modemkabel verwenden (siehe hier: http://www.mikrocontroller.net/articles/AVR-Tutorial:_UART)

Bei mir funktioniert das ganze mit dem USB-Serial-Wandler problemlos

Danke!

8.   Kommentar von McSeven
Erstellt am 03. Mai 2010 um 19:22 Uhr.

Sehr schön, freut mich, wenn es klappt. Wegen des UART haste Recht. Hintergrund ist, dass ich noch ein paar dieser Kabel mit 5m Länge daheim liegen hatte und dafür das Gerät entworfen habe. Es ist so aber tatsächlich keine saubere Umsetzung. Danke für den Hinweis.

9.   Kommentar von hurra
Erstellt am 04. Mai 2010 um 00:20 Uhr.

Das einzige, was mir negativ auffällt ist die große Verzögerung. Gerade beim Filmen mit schnellen Farbwechseln ist dies stark zu bemerken. Es sind vielleicht 0.4 Sekunden. Konntes du dieses Delay auch feststellen? Woran liegt das? An der boblight-Software (1.3)? Gibt’s Abhilfe?

10.   Kommentar von McSeven
Erstellt am 04. Mai 2010 um 09:22 Uhr.

Hm, das kann imo an mehreren Dingen liegen:
a) USB2Seriell macht Ärger -> mit reiner HW-Schnittstelle testen.
b) Parameter „proportional“ in der boblight.conf steuert die Farbübergänge. Je größer, desto sanfter.
c) Desktop-Komposition in Vista und 7 aus?

Ansonsten schau Dir das Video an, so tuts bei mir; ich glaube nicht, dass es da Verögerungen gibt. Ich hab auch schon jerry bruckheimer filme gesehen auf dem system, da „klebten“ die LEDs an dem Blitz am Anfang. Sollte also kein Systemfehler sein.

11.   Kommentar von hurra
Erstellt am 05. Mai 2010 um 13:12 Uhr.

Ich konnte das Problem wesentlich kleiner machen. Das von mir verwendete boblight-X11 kennt einen Parameter -t, mit dem die Abtastzeit eingestellt wird. Standard sind 0.5 Sekunden. Wenn man den Wert kleiner macht reagiert er viel schneller, jedoch braucht er dabei auch ziemlich viel CPU-Leistung.

Etwas Verzögerung bleibt zwar trotzdem noch, damit kann man aber durchaus leben.

Außerdem hoffe ich, dass dies bei der neuen Version von boblight besser wird. Leider kann ich die Entwicklerversion derzeit nicht testen, da boblight-X11 immer mit ner Fehlermeldunng abschmiert (Bug ist reported bei google-code)

12.   Kommentar von hurra
Erstellt am 27. Mai 2010 um 11:55 Uhr.

Nochmal Feedback.

Hab jetzt doch die neue Version aus dem Google-Code-Repository zum laufen bekommen. Mit dieser Version sind wesentlich kleinere Abtastzeiten möglich. Standardmäßig sind 0.1 Sekungen eingestellt, aber auch 0.05s gehen bei mir problemlos.

Damit ists jetzt endlich so flott, wie von mir erwartet 🙂

Danke!

Einen Kommentar hinterlassen