Der Bau eines LED Matrix Displays fällt eindeutig unter die Kategorie "muss man mal gemacht haben". Das Photonenbanner fing mit eine paar LEDs an, wurde dann aber doch größer als ursprünglich geplant. - 96 Spalten, 24 Zeilen - 2304 LEDs - ATMega 644 @ 20Mhz - 2MByte extra SPI Flash Speicher - C Programm mit diversen Echtzeiteffekten - C# Programm zur Steuerung über SER - PHP web-frontend zum Texten und Pixeln Vieleicht findet hier jemand ein paar interessante Ideen: Projektbeschreibung: http://www.crafted.de/photonenbanner.php Video vom Bau: http://www.youtube.com/watch?v=LWY_jnurgo0 Video 2304 Echtzeitdemo: http://www.youtube.com/watch?v=XgEYBqEIDEY
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 ...
> > 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? Das Display läuft ohne PC. Der PC kommt nur ins Spiel um neue Bilder zu programmieren oder um Daten aus dem Netz ranzuhohlen. Die Echtzeitdemo enthält bis auf die Zeichen und "the real party is outside" keine Bilder oder Animationen. Das wird alles in Echtzeit vom ATMega644 berechnet. Dabei werden 2 Arrays (framebuffer) genutzt. Der eine wird angezeigt, der andere neu berechnet. 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. Über SER und mit der Hilfe des MC läßt sich der externe Speicher im laufenden Betrieb programmieren. Teilweise sind die Bilder aber auch direkt im ProgMem hardcoded. > > Im Speziellen würde mich die Generation der Animation bei 1:23 > interessieren. Die "Plasmabalken" werden über PWM gemacht. Für jede der 16 Spalten läßt sich über einen 8-Bit Timer ein eigenes PWM Signal erzeugen. Das gleiche PWM Signal gilt aber immer für die entsprechende Spalte aller 6 Pannels. Das sieht man in diesem Effekt aber nicht, da die Sinuswelle genau so eingestellt ist, das Spalte=m+n*16 (m=0,..,15 - n=0,...,5) sowieso die gleiche Helligkeit haben. Der Photonenbanner ist aber eigentlich nicht für PWM gebaut. Dafür braucht man eine ganz andere Schaltung. > > 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/Spa... das ist > schon hart =) Wir haben die Matrix aller 6 Pannels an einem einzigen Tag gelötet, und das mit Mitgliedern, die noch nie einen Lötkolben in der Hand gehalten haben. Bis auf 2-3 Lötstellen ist bis jetzt - nach mehreren Transporten - alles heile geblieben.
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?
Hi, sehr interessant: 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. Wenn ich nun an die fliegenden Sterne denke, wie sieht da die Schnittstelle aus (Softwareschnittstelle)? Lasst ihr einen Punkt auf einer Geraden wandern? Wie macht Ihr die Drehung von Bildern, gibt es eine Bild-dreh-funktion um den Mittelpunkt der Matrix? 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? 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... T.
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! :)
> > 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.
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? Schade nur dass einige LEDs etwas dunkler sind. (oder liegt das an der Aufnahme?) 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.
(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
Vlad Tepesch schrieb: > (erstaunter) schrieb: >> Der Wahnsinn! Da hat jemand Ahnung von Mathe und kann programmieren! > Das gehört bei den meisten Anwendungen irgendwie zusammen, oder? Jain. Polarkoordinaten und Vektorrotation braucht man (zum Glück) nicht zwangsläufig um einen µC zu programmieren, das hier ist schon Mathe auf einem etwas höheren Level. (Ich muss zugeben meine Mathekenntnisse sind ziemlich eingerostet. :-( ) > (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 Ja... > (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 Genau, eben deshalb kann man sich den Traffic sparen. Einige Bilder kann man ruhig in groß zur Verfügung stellen, aber bitte als Extralink und nicht beim Klick auf die kleinen Vorschaubilder.
(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!
> 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. Man hätte auch vorher einfach den ersten Absatz von http://www.dse-faq.elektronik-kompendium.de/dse-faq.htm#F.8.2 lesen können und sich den Fehler gespart.
Mit Verlaub, im Gegensatz zu dieser LED-Anzeige: http://www.youtube.com/watch?v=7dVJcqFkJzI ist das hier eine ziemlich müde Geschichte.
MaWin schrieb: >> 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. > > Man hätte auch vorher einfach den ersten Absatz von > http://www.dse-faq.elektronik-kompendium.de/dse-faq.htm#F.8.2 > lesen können und sich den Fehler gespart. Der große MaWin weiß und kann natürlich alles besser. :-( Irgendwie klingt das ziemlich arrogant. Lenchen schrieb: > Mit Verlaub, im Gegensatz zu dieser LED-Anzeige: > > http://www.youtube.com/watch?v=7dVJcqFkJzI > > ist das hier eine ziemlich müde Geschichte. Ich sehe da die schlechte Laune erzeugende Fresse von irgendeinem dieser TV-Hampelmänner, was hat das mit dem Thema zu tun?
sepp schrieb: > was hat das mit dem Thema zu tun? Es geht doch hier um ein LED Matrix Display und die dazugehörigen Rechenalgorithmen, oder?
Ist zwar off topic, aber mich interessiert der Song, der im Hintergrund läuft. :-)
Super Projekt. Bin immer fasziniert was man heut zu Tage noch so selbst zusammen bauen kann. Echt Spitze. Ist der Quellcode schon veröffentlich? Würde mich brennend Interessieren ;)
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.