LED Matrix Display Photonenbanner 96x24 Atmel

Stefan Wendt schrieb:
> Der Bau eines LED Matrix Displays fällt eindeutig unter die Kategorie
> "muss man mal gemacht haben".

Nicht schlecht ...

Stefan Wendt schrieb:
> Video 2304 Echtzeitdemo:
> http://www.youtube.com/watch?v=XgEYBqEIDEY

Darf ich fragen wie du die Animationen gespeichert hast? Sind das 
Einzelbilder die du vom PC zum MEGA überträgst oder sind das Shift- bzw. 
relative-Ausdrücke auf einem Array?

Im Speziellen würde mich die Generation der Animation bei 1:23 
interessieren.

Einige Anregungen für spätere Projekte möchte ich dir dennoch mit auf 
den Weg geben:

1. Viel Lötzinn != gut 
http://www.crafted.de/tutorials/photonenbanner/SpaltenFETs.JPG das ist 
schon hart =)

2. Gerade wenn PWM im Spiel ist - Lochraster ist nichts für hohe 
Frequenzen. Das Ding entwickelt sich zur unschönen EMV Schleuder. Wenn 
schon keine PCB, dann evtl. Streifenraster und hin und wieder eine Bahn 
auf GND legen. Nur so als Denkanstoß.

Trotzdem ein gelungenes Projekt ...

Stefan Wendt schrieb:
> Das Photonenbanner fing mit eine paar LEDs an, wurde dann aber
> doch größer als ursprünglich geplant.

ist das das Ding von der Revision aus der Real Wild Compo?

Kompliment, tolle Animationen!

Stefan Wendt schrieb:
> Die Animationen, die im Howto Video zu sehen sind, wurden auf dem PC
> gepixelt, und in eine raw Datei konvertiert. Teilweise liegen die
> Animationen in dem externen Flashspeicher.

Womit gepixelt, womit ins passende Format gebracht? PCX oder XPM? ;)

Ist die Animation "hardcoded", oder speicherst du eine Art Drehbuch, ne 
Bitmap hier, ne Bitmap da, dazwischen Anweisungen zu Effekten (Zoom, 
Drehen, Überblenden usw.)? Erzähl mal! :)

hallo?

>
> ich würde gern wissen wie man das softwaretechnisch aufbaut. Mein
> Vorgehen besteht meist darin die LED Matrix im Prozessor abzubilden,
> z.B. je ein bit für eine LED.

Ja. Das ist hier auch der Fall. Jede LED wird im FrameBuffer durch ein 
Bit angesprochen.

> Wenn ich nun an die fliegenden Sterne
> denke, wie sieht da die Schnittstelle aus (Softwareschnittstelle)? Lasst
> ihr einen Punkt auf einer Geraden wandern?

Die Sterne sind als Polarkoordinaten im RAM. Jeweils zwei Bytes für 
einen Stern. Erst der Winkel (Wert 0-255), dann der Z-Wert (Wert 0-255). 
Es handelt sich um eine Array aus Zufallswerten, die am Anfang aus dem 
ProgMem gelesen werden. Die Werte werden jeweils mit einem zPlus und 
winkelPlus addiert um die Sterne zu bewegen. Dann werden die Daten in 
eine X und Y Koordinate umgrechnet (siehe 
http://de.wikipedia.org/wiki/Polarkoordinaten ). Dabei geht zSumme als 
zusätzlicher Faktor mit in die Berechnung ein, um die Sterne, die sich 
"weiter Hinten" befinden, dichter ans Zentrum zu setzen.

xStrich = (x * zSumme) / 256

Ein großer Teil der Sterne wird nicht angezeigt, da sie sich ausserhalb 
des Sichtfensters befinden. Der eigentlich Trick ist es die 
Wertebereiche so zu wählen, das es beim Rechnen nicht zum Überlauf 
kommt. Oder aber das der Überlauf gezielt genutzt wird. Viele 
Berechnungen benötigen 16Bit Werte, aber man sollte so viel wie möglich 
mit 8Bit Werten machen.

> Wie macht Ihr die Drehung von
> Bildern, gibt es eine Bild-dreh-funktion um den Mittelpunkt der Matrix?
>

Vektorrotation ( http://de.wikipedia.org/wiki/Drehmatrix ). Es werden 3 
Vektoren im 2D Raum definiert. A=LinkeObereEcke, B=RechteObereEcke, 
C=LinkeUntereEcke. Diese 3 Punkte können über die Drehmatix in einen
anderen Raum umgerechnet werden. Alle Punkte der 2D Fläche lassen sich 
über diese 3 Punkte berechnen.

AB=A-B
deltaAB=AB/anzahlXPunkte;
AC=A-C
deltaAC=AC/anzahlYPunkte;

P=A + x*deltaAB + y*deltaAC

Durch 2 verschachtelte Schleifen kann die Multiplikation umgangen 
werden.

> Wie funktionieren die größer-kleiner Effekte - ist ein Buchstábe mit
> maximal möglicher Auflösung abgespeichert und wird dann linear kleiner
> gerechnet und das dann auch noch in Verbindung mit dem dreh Effekt?
>

Die Zoomeffekte benutzen GFX, die in etwa so groß sind wie die 
physikalische Auflösung des Photonenbanner. Mit der ABC 3Punkt Methode 
kann auch das Zooming betrieben werden, indem ein Z Wert als 
zusätzlicher Faktor benutzt wird.

> Wie schafft man es bei so viel rechnerei das das Bild nicht ruckelt bei
> 20MHz? Ihr habt nur "pasive" also nicht speichernde Elemente - der
> Prozessor muss doch ständig das Bild am "leben" erhalten...
>

Das Videomaterial läuft nur mit ca. 25 Hz. Der Photonenbanner läuft mit 
150 Hz. Dadurch ist ein sehr großer Teil der Spritzigkeit beim Abfilmen 
auf der Strecke geblieben. In Wirklichkeit sieht die 2304 Demo sehr viel 
flüssiger aus.

Die Latches halten das Signal und sind notwendig um die große Anzahl von 
LEDs anzusteuern. Der yC arbeitet zwar "immer mal wieder" um die Latches 
mit Daten zu versorgen. 288Bytes * 150Hz ist nicht wirklich viel bei 
20Mhz. Da bleibt noch genügent Platz für die Echtzeiteffekte.

Tom M. schrieb:
> Kompliment, tolle Animationen!
>
> Stefan Wendt schrieb:
>> Die Animationen, die im Howto Video zu sehen sind, wurden auf dem PC
>> gepixelt, und in eine raw Datei konvertiert. Teilweise liegen die
>> Animationen in dem externen Flashspeicher.
>
> Womit gepixelt, womit ins passende Format gebracht? PCX oder XPM? ;)

Hauptsächlich mit GIMP als PNG oder GIF gespeichert. Dann mit einem 
kleinen selbstgebauten PHP Skript in echtes RAW konvertiert. Im 
allgemeinen werden Bilder Zeile für Zeile gespeichert. Das 
Photonenbanner arbeitet aber alles Spalte für Spalte ab. Deshalb ist 
auch der Speicher so organisiert.  Die ursprügliche Bitmap muss also 
noch rotiert und gespiegelt werden. All das macht mein kleines 
Konvertierungsscript. PHP als Kommandozeileninterpreter macht es einem 
sehr einfach verschiedene Bildertypen zu laden und zu manipulieren.

>
> Ist die Animation "hardcoded", oder speicherst du eine Art Drehbuch, ne
> Bitmap hier, ne Bitmap da, dazwischen Anweisungen zu Effekten (Zoom,
> Drehen, Überblenden usw.)? Erzähl mal! :)

In der 2304 Demo sind überhaupt keine Animationen, dort wird alles in 
Echtzeit berechnet. Die grobe Steuerung erfolgt durch eine 
Storyboard(Drehbuch/Playlist). Diese Bytefolge definiert welcher Effekt 
zu welcher Zeit abläuft. Verzögerungen und Überblendungen werden 
Teilweise aus dem Storyboard gesteuert.

Die Animationen (also alles was per Hand gepixelt wurde) sind Bild für 
Bild im externen Flashspeicher abgelegt. Die Bilder (einige 100 pro 
Animation) werden einfach in den FrameBuffer kopiert und dann ein wird 
für einige msec gewartet.

Es stehen ca. 50 verschiedene Befehle zur Verfügung, die vom Storyboard 
aus getriggert werden können. Den Befehlen follgen teilweise weitere 
Argumente, die z.B. ansagen wie lange gewartet werden soll, wie schnell 
eine Animation abgespielt werden soll, oder welches Logo in den 
FrameBuffer geladen werden soll.

Die Ausführung des Storyboards kann durch das C# Kontrollprogramm 
angehalten werden. Das Storyboard kann dann neu in den yC geschrieben 
werden. Dadurch kann das Photonnenbanner auf Veranstaltungen zur 
Laufzeit angepasst werden, ohne den Atmel Progammieradapter.

(erstaunter) schrieb:
> Der Wahnsinn! Da hat jemand Ahnung von Mathe und kann programmieren!
Das gehört bei den meisten Anwendungen irgendwie zusammen, oder?

> Wie
> viele Stunden stecken in der Entwicklung von diesem Ding? Wie viele LOCs
> hat das Ganze? Open Source?

Das storyboardzeug hört sich sehr durchdacht an.
Ist das modular und hardwareunabhängig gebaut?


(erstaunter) schrieb:
> Schade nur dass einige LEDs etwas dunkler sind. (oder liegt das an der
> Aufnahme?)
Ist mir auch aufgefallen.
Schade eigentlich bei so viel Arbeit - hier hätte man vorselektieren 
müssen

(erstaunter) schrieb:
> Ach so, die Bilder auf der Projektseite könnten etwas verkleinert
> werden, sinnvoll wäre es die volle Größe wenn überhaupt nochmal extra zu
> verlinken. Spart Traffic und Ladezeit.

vor allem sind sie teilweise ziemlich verrauscht oder unscharf, so dass 
man die Auflösung locker vierteln kann, ohne Informationsverlust

(erstaunter) schrieb:
> Der Wahnsinn! Da hat jemand Ahnung von Mathe und kann programmieren! Wie
> viele Stunden stecken in der Entwicklung von diesem Ding? Wie viele LOCs
> hat das Ganze? Open Source?
>

Es sind ca. 6500 LOC. Davon sind ca. 30% Binärdaten im C Format.
Der Sourcecode wird im Laufe des Jahres veröffentlicht. Im Momment 
genügt er noch nicht meinen eigenen estetischen Anforderungen.

> Schade nur dass einige LEDs etwas dunkler sind. (oder liegt das an der
> Aufnahme?)
>

Das ist zwar ein Problem der LEDs, aber nicht der 
Helligkeitsunterschiede der LEDs. Subjektiv lassen sich zwischen den 
LEDs keine Helligkeitsunterschiede feststellen! Der erste 1000er Sack, 
den wir aus China bestellt haben, hatte eine grandiose Streuung bei der 
Wellenlänge (siehe Foto auf crafted.de). Es war alles dabei von gelb bis 
orange. Die haben wir in einem Prototyp verbaut.

Die Helligkeitsunterschiede im Video kommen durch die follgenden 
Faktoren:
- LEDs haben einen Öffnungswinkel von nur ca. 20Grad.
- Die LEDs sitzen nicht alle im rechten Winkel zu Oberfläche.
- Die Kammera war nur ca. 4m vom Photonenbanner entfernt aufgebaut.

LEDs mit 20Grad Öffnungswinkel sind eigentlich die falsche Wahl für ein 
Matrix Display. Wenn das Auge sich im Lichtkegel befindet, dann ist der 
Lichtstrom sehr viel größer. Nach 10Grad zu jeder Seite schreitet man 
langsam aus dem Lichtkegel heraus und der Lichtstrom der einzellnen LEDs 
sinkt stark ab. Das passiert nicht für alle LEDs gleichzeitig. Wer in 
einem bestimmten Winkel zum Photonenbanner steht nimmt die LEDs in 
teilweise sehr stark unterschiedlicher Helligkeit wahr. So ist das auch 
mit der Kammera und dem Video. Die Kammera befindet sich schon 
ausserhalb des Lichtkegels der LEDs am Rand. Durch die extrem weit 
geschlossene Blende der Kammera verstärkt sich dieser Effekt noch.

Normalerweise sollte man diffuse LEDs benutzen, einen Diffusor vor das 
Display schrauben oder aber gleich LEDs mit einem viel größeren 
Abstrahlwinkel benutzen.

Im Nachherein muss man sagen, das die LEDs zwar billig waren. Das ist 
aber am falschen Ende gespart wenn man die Arbeitskosten in betracht 
zieht! Lieber ein paar 100€ für die richtigen LEDs ausgeben.

Unbedingt vorher mal 100 Stück in einen großflächigen Prototyp einbauen 
um die Streuung und den subjektiven Eindruck aus verschiedenen 
Richtungen zu testen. Auch das Trägermaterial sollte man vorher mit den 
LEDs testen!

Die Tracks für die beiden Videos kommen von
Stefan H. von

http://www.kreativhuette.de/