Kleiner P7.62 LED Screen aus kommerziellen 32x16 Kacheln

  • Hallo Forum!


    Nach langer Abstinenz melde ich mich mal wieder - meine Arbeit hatte mich leider fest eingespannt... :)


    Ich nutze mal die Gelegenheit, und zeige ein paar Bilder/Videos eines LED Screen cabinets das ich bereits letztes Jahr gebaut hatte.


    Ausgangspunkt sind kommerziell erhältliche Platinen mit LEDs, Treiber-ICs, Plastik-Rahmen und Gewindebuchsen.
    Die Treiber-ICs sind relativ "dumm", es handelt sich lediglich um 16-Kanal Konstantstromquellen. das (in diesem Fall 1:8) Multiplexing wird ebenso mittels Software-PWM vom Steuercontroller gemacht, wie das Dimmen der einzelnen Farben! Deshalb sitzt auf der Steuerplatine auch ein FPGA...


    Hier ein paar Fotos verschiedener Typen.







    Aus Alu-Profilen habe ich dann einen Rahmen für insg. 24 Module mit 7.62mm Pitch zusammengenietet/geschraubt. Steuerplatine dazu und 320W 5V-Netzteil -> Fertig! :D





    Die Auflösung des Cabinets beträgt nur 128x96, aber das reicht für erstaunlich detaillierten Content aus, solange man 5 Meter oder noch weiter entfernt steht! Am besten klappt aber natürlich Content mit wenigen Details - Zeichentrick-Serien kann man z.B. problemlos anschauen! Daher hier noch ein kleines Video:



    Falls Euch Details dazu interessieren schreibe ich gern noch mehr!


    Viele Grüße
    Andre


    P.S. Hui! Es gibt ja gar keine 150kB Bildgrößen-Limitierung mehr! Cool! :D

  • Sehr geil... hab die Teile ja auch gerade angesteuert... habs absichtlich ohne FPGA versucht, aber geht natürlich mit FPGA einiges mehr...
    Also ich hab ziemlich detaillierte Fragen:


    Welche Ansteuerfrequenz (CLK) fährst du? Welche Refreshraten schaffst du? Wie viel Panels hast du hintereinander gehangen (von der Ansteuerseite her gesehen)? Welche Farbtiefe ist es geworden? Wie bekommst du das Bildmaterial rein? Ist es ein FPGA für den ganzen Screen oder hast du welche angereiht?
    Musstest du die Reihen auch erst vollständig beschreiben, bevor du zur nächsten schaltest?


    Erzähl einfach mal alles... bin sehr interessiert... finde die China Module total verschärft :D


    Grüße


    Basti

  • Hi Basti!


    Wow, ich sehe Du hast Dich schon tief 'reingefuchst in die Materie! o.O
    Ja, diese Kacheln sind klasse! Ich überlege immer wieder, ob ich meinen Screen nicht vergrößern sollte...


    Ich habe mich da ungenau ausgedrückt, bzw. die folgende wichtige Info vergessen gehabt in meinem Post:
    Der Controller ist nicht von mir! Ich habe mit den Kacheln einen dbstar async. controller gekauft.


    Dieser versendet "Ethernet II" Pakete (siehe Wireshark Screenshot) an den Controller.



    Was die Ansteuerung der Kacheln angeht: Hier ein Screenshot der Controller-Software - evtl. kannst Du ja ein paar interessante DInge herauslesen?
    Es hängen je 4 Panels hintereinander (Je 32 Pixel Breit). 1/8 scan.


    Letztlich hängt also alles (6 Modulketten) an einem einzelnen FPGA (bzw. hinter 74xx245 Bustreibern) über die 16poligen Flachbandkabel.



    Viele Grüße
    Andre

  • Oh, okay...


    Aber danke für den Dialog... ist ja interessant... wie machen das die Chinesen? Wenn ich nach rechne, komm ich einfach nicht auf die 200 Hz die es an Refreshrate schaffen soll :-/


    20 MHz Clock / 4096 PWM Steps / 8 scanlines / (32 * 4) Bits in Line sind bei mir gerade mal 4,7 Hz und nicht 200 Hz..... Dabei ist es eigentlich egal ob die PWM machen oder Bit Angle Modulation... beim LSB ist der Wechsel am schnellsten... man bekommt die Bits aber nicht so schnell rein... 50 ns * 128 Bit um eine Line mit einem Wert zu zeichnen... so schaft man aber keine 12 Bit PWM in (1 / 200 Hz) Sekunden


    Kann sich wer zusammen reimen, wie das gehen soll?

  • Nun, eigentlich kann der FPGA relativ problemlos die ca. 200 Hz Refresh bei 20,8 MHz SCK (Serieller Daten-Clock) und 1/8 Scan erreichen, selbst bei 128 Bit pro Zeile.
    Nehmen wir mal an, man will 200 Hz Refresh haben, dann ergibt das bei 1/8 Scan 1600 Hz Zeilenfrequenz bzw. 625 µs Zeilen-Verweilzeit. Wenn wir 12 Bit BAM implementieren wollen, müssen wir diese Verweilzeit in 4095 Zeiteinheiten aufteilen und dann für die 12 BAM-Zeiten folgende Faktoren nehmen: 2048, 1024, 512, 256, 128, 64, 32, 16, 8, 4, 2, 1. Das entspricht folgenden BAM-Zeiten (in µs, aufgerundet): 312,6; 156,3; 78,1; 39,1; 19,5; 9,8; 4,9; 2,4; 1,2; 0,6; 0,3; 0,2. Insgesamt ergibt das wieder die 625 µs. Diese Zeiten werden vom FPGA via OE (Output Enable) jeweils für die ganze Zeile geschaltet. Nun braucht aber die Übertragung von 128 Bit bei 20,8 MHz rund 4,6 µs, also länger als die 5 niederwertigsten BAM-Zeiten. Das macht aber nichts, denn der FPGA (intern läuft er wohl mit einem vielfachen der SCK-Frequenz) steuert OE ja praktisch unabhängig vom Daten-Latch und damit von der Zeilenladezeit (Daten für die nächste BAM-Stufe oder Zeile). Es ergibt sich für die 5 niederwertigsten Bits einfach eine Totzeit, welche sich je Zeile aufsummiert und somit die maximal erreichbare Globalhelligkeit beeinflusst, nicht aber die Auflösung oder die Linearität. In diesem Beispiel wäre die Zeilenverweilzeit dann tatsächlich 643,3 µs statt 625 µs (die 5 kürzesten BAM-Zeiten durch 4,6 µs ersetzt), also 18,3 µs Totzeit pro Zeile. Das würde dann 1554 Hz Zeilenfrequenz oder 194 Hz Refresh ergeben. Wenn man genau 200 Hz haben will , dann muss der FPGA entsprechend alle BAM-Zeiten im Verhältnis etwas verkürzen, so dass die Totzeit im Verhältnis etwas zunimmt und die Gesamtsumme der Zeiten dann 625 µs ergibt. Die Gesamtsumme der BAM-Zeiten wäre dann natürlich etwas kleiner als 625 µs. Man kann sicherlich eine Gleichung aufstellen, um die dann erforderlichen (für 200 Hz Refresh inkl. Totzeit) BAM-Zeiten genau auszurechnen, aber das ist mir jetzt zu mühsam. Wichtig ist ja v.a. das Prinzip ;) .


    Gruss
    Neni

  • Aber OE schaltet doch alle 32 Pixel gleichermaßen... wie sieht das nun konkret aus, wenn ich in einer Zeile Pixel mit den Werten "2" und "1" von maximal 4095 habe?


    Wie kann ich da OE ansteuern, so das die einen Pixel 2 und die anderen eine 1 bekommen?


    Sorry, vielleicht steh ich nur auf dem Schlach... könntest du das noch mal etwas genauer erläutern?


    Danke


    Basti


    *edit* na klar... habs ;)
    Schick... gefällt mir... 12 Bit da geht so einiges!!!

  • OE schaltet ja nur für die Dauer der jeweiligen BAM-Stufe die gesamte Zeile ein (und aus). Die Werte der Bits (0 oder 1), welche in die Schieberegister entsprechend den Daten für die jeweilige Zeile und BAM-Stufe reingeschoben worden sind (während der vorhergehenden BAM-Periode) bestimmen dann ja, ob der entsprechende Pixel während der jeweiligen OE-Aktiv-Zeit ein oder aus ist. D.h. während einer BAM-Periode befinden sich in der Zeile nur die Daten für ein BAM-Bit, d.h. ob die Pixel-Daten an der Stelle des jeweiligen BAM-Bits dann eine 0 oder 1 stehen haben.


    Aber ich denke, du bist da ja noch selbst drauf gekommen ;) .


    Wichtig ist vielleicht auch noch zu sagen, dass das für eine Gesamtmatrix aus mehreren solchen Modulgruppen, wie Andre sie hat, nur deshalb mit 12 Bit BAM pro Farbe funktioniert, weil der FPGA einige serielle Datenstreams parallel an die Module ausgibt. Das wären in der Kofiguration von Andre jeweils 3 x 2 = 6 Streams pro Modulreihe (16 Zeilen zu 3 Farben bei 1/8 Scan). Bei 6 Modulreihen sind das dann 36 parallele Datenstreams. Das ist für einen entsprechend leistungsfähigen FPGA kein Problem, weil ja die entsprechende Logik eben quasi als Hardware implementiert wird und somit die Pixeldaten grösstenteils eben nicht sequentiell sondern parallel verarbeitet werden können.


    Gruss
    Neni

  • Ich bin der Meinung mit BAM und der OE Technik könnte ich es auch mit nem Cortex M4 schaffen. 3 Modulspalten mit 3 oder 4 Reihen mit einem Cortex ist möglich... Aktuell mach ich die PWM linear und da geht viel CPU und Speicher drauf...
    Ich glaub der FPGA hat aber noch deutlich mehr reserven... so weit ich weiß, kann der ja mindestens 8 Spalten parallel treiben und dann gehen wohl auch nur die PINs aus ;)


    Hab mich aber mit der BAM Modelierung noch nicht beschäftigt...
    Wenn mal Zeit ist, werde ich mich ran setzen...
    Die ersten PWM Stufen sollte man wohl direkt mit CLK reinschieben... bis sich etwas mehr Zeit ergibt und dann auf Timer getriggerte DMA Transfers umschalten...


    Grüße


    Basti