Info zu grosse RGB LED Panel

[Matt]

Bei mir wird eher nur 25A auf 8 Panel, da AVR grottenlangsam in SPI Übertragung ist. Also max ca 1/4 Dutycycle (Rechnung haut wieder hin, 80-90A/4 = 20-22A)

Grüss
Matt

[Matt]

Das ist Plan, wie man es anschliessen wird.

rgb8bitpaneltpm2.txt

(6.01 KiB) 113-mal heruntergeladen

Diese Textdatei, bitte ins hex umbenennen und ins AVR 328p brennen.

Idealweise nihmt man Arduino Nano V3 (mit CH430 und Atmega328p drauf) und lötet auf 24Mhz Quarz um.
Dann spielt man HEX über ICSP auf Atmega auf.

Es spricht über TPM2 Potokoll , man sollte auf Kanal 1536 stellen ( ist eher Anzahl von überzutragene Byte) und Baudrate auf 500.000 stellen.




(Randnotiz: ich nutze nie Ardunio-Umgebung aber sehr gerne Arduino Board, ich löte niht für 2,5€ Atmega 328 mitsamt Quarz und ICSP Header zusammen)
(Randnotiz2: Aktuelle Code hat noch leichte Unzugänglichkeit mit leichte flimmern durch Interrupt verlangsamte Bitanglemodulation)

[Fritzler]

So langsam dämmerts mir was ich da fürn Projekt an Land gezerrt hab
Jedenfalls war ich heute in Dresden und hab mir die dort im Turmlabor gebunkerten 36 Panels abgeholt bevor die Ersties das mitnehmen können
Vielen Dank dafür an Ludwig und Hendrik!

Der Chinamann brachte die letzten Wochen auch gleich noch 200 Pfostenbuchsen vorbei von denen ich 180 crimpen muss.
4 Einzelbestellugen zu 50 Stück, weil bei ner 4fach Bestellung die Versandkosten explodierten.
Wenn ihr so wollt, dann bekommt ihrs eben so


Aber nun zum eigentlichen Fang:


Das Display soll aus 9x5 Panel bestehen, das macht 80x144Pixel, also fast 16:9
Es sind 2 Zeilen zu viel, egal.


So langsam erahnt man die Dimensionen, 172cm klingt so klein wenn mans ausrechnet.
Aufm Fußboden ausgelegt ist das RIESIG!
Achso: und 1m hoch!


@Matt
Der FPGA selbst ist super!
BlockRAM und LUTs bis zum Abwinken.
Er hat aber nur 32GPIO von der Platine runtergeführt, das wird etwas knapp, wenn ich LAN will.
(Pixeldatenempfang über Art-Net)
Dann brauch ich 36GPIO und nen DebugUart will ich eigentlich auchnoch für den SoftCPU Core.
Eigentlich könnte man ja auch die Serdes links nutzen zum Pixeldaten raushusten.
Nur hat die Platine nur 8 Links und ich brauch eben 15, ARGH!
Ich bin noch nicht Schlau geworden ob man die Serdes Links auch als GPIO nutzen kann.

[Matt]

Du nihmst halt 2te FPGA als Porterweiterung über serdes
Nicht kleckern sondern klotzen !


Ja, mir ist schon mit 4x2 Konfig ziemlich fett.

Zu Crimpzange für Pfostenbuchse wie in Bild, ich habe tatsächlich Zange dafür.


Achja, Martin aus Wellenkino hat gefilmt. Da wurde meine "Riesen" Display auf MakerFaire hingestellt .
http://www.wellenkino.de/makerfaire/2018/v3.mp4

[Fritzler]

Welche Wiederholfrequenz hasten jetz eigentlich?
Die Kameraaufnahme flimmert ja nicht.
Dafür haste abern kleinen Versatz von oberer Panelreihe zur Unteren.

Jow, türlich könnt man jetz 2 FPGA nehmen, dann wird aber die Synchro lustig.
Daher wirds wohl ne Zweichiplösung aus FPGA und nem STM32.
Verbunden über nen QSPI, dann reichen die GPIOs auf jedenfall.

Dabei hatte ich auch mal überlegt selber nen FPGA auf ne Platine zu löten, aber alles was es noch in TQFP gibt hat zu wenig BlockRAM.

Ne Crimpzange für Pfostenbuchen hab ich auch, die Kosten ja nix.

[Matt]

Auf Kamera fällt Flimmern nicht ganz auf, aber wenn man davor steht und es mit statische Bild angesteuert wird, dann fällt man es auf
(da es um 15% des Helligkeit durch UART Interrupt schwankt)
Ich hatte mal gemesst und es nicht notiert.
Ich denk mal: Es liegt um 65 FPS, der natürlich dank UART Interrupt zwischen 55 und 65 FPS pendelt. Es flimmert aber nicht wirklich wegen diese Wiederholungsrate. (BAM sei dank)

Versatz liegt an JINX!, der nicht synchron über 4 USB-UART Wandler sendet.
Klar, wie will ich 2x4 aufbauen, wenn EINE Atmega 328p schon mit 2 Panel an Anschlag läuft.
Erst recht mit nur 2kB RAM!

Serdes läuft soweit ich weiss mit sehr hohe Datenrate. und für eine GPIO zwecks Synchronisierung hat man immer übrig

[Fritzler]

Da kannste ja jetzt mehr Funktionen von jinx als ich.
Interessant, dass der über 4 UART raushusten kann.

Der 74ABT245 ist wohl auch nicht gut genug, dass er die Panels mit 22MHz takten kann.
Es gibt imemrnoch massigst Pixelfehler bei diesem Takt, HMPF.

Aufm Oszi erkennt man aber, dass er schon viel schneller ist als der HCT.
Man achte auf das Propagation Delay.

74ABT245:


74HCT245:


Aber sobald der gelbe Eingangspegel seine 3,3V erreicht hat flacht die Flange des Ausgangs ab.
3,3V -> 5V pegelwandeln und Bustreiben geht wohl eher nicht, doof.
Also mal Pegelwandeln und Bustreiben getrennt probieren?

[barclay66]

Hi,

probiere doch mal den TXB0108. Der kann +/-50mA treiben und braucht bei Vcc 3,3V/5V 5,2ns oder weniger zum Schalten (laut Dabla). Sollte reichen für 100MHz oder mehr...

Gruß
barclay66

[Fritzler]

Der TXB0108 ist genau das Gegenteil von dem was man haben will, der ist nämlich bidirektional und kann somit keine Leitungen treiben.

Die Bidiraktionalen müssen ja irgendwie erkennen wer grade treibt.
Daher geben dir nur einen kurzen Puls auf die Leitung bei einem Pegelwechsel und halten dann den Pegel über einen hochohmigen Widerstand.
Wenn der Pegel vom Pin und dem Ausgangsreiber über den Widerstand abweicht, dann bekommt die andere Richtung die Pulsbehandlung.

Bei langen Leitungen führt das dann zu einem wunderbaren oszillieren.
(Rat mal woher ich das weiß? )

Da gibts durchaus nen 74xyz245 mit 2 Spannungen zum Pegelwandeln, muss den erstmal wieder finden.

edit: 74LVC8T245, 74LVCC4245

[Matt]

ODER !

74ACT14 und so ähnlich als Treiber. Dann wird Problem mit abgeflachte Dach über 3,3V wegen Schmitttrigger umgegangen.

Ich weiss nicht genau, wie Treiber bei dir beschaltet und verwndet wird ist.

Lange Leitung und hohe Datenrate (da ist 25Mhz schon kritisch) ist schon mit Problem vorprogrammiert.
Da ist schon zwingend, deren Ende mit Terminator abschliessen, dann klingelt es nicht mehr.
Wenn ich Lust habe, dann kann ich herausfinden, was für Impedanz von Flachbandkabeln hat. Ich schätze mal 200 ohm.
(Nur wenn jeder zweite Leitung Masse ist und mit Daten/Takt/Latch/Enable in Rhythmus abwechselt)


Zu FPGA mit zu wenige GPIO, ich schlage dir vor: Ausgang mit ECL Schieberegister erweitert
Ich habe mehre ECL Schieberegister, der kann bis zu 250Mhz gehen.
MC100E141 kann bis 700Mhz schieben, da ist Lattice ECP3 schon längst am Taktkotzgrenze.


Grüss
Matt

[Fritzler]

74ACT245 war ja eh in Planung, Henry hatte mir dann aber die ABT mal gegeben.
Die ABT sind jedoch fixer als die ACT.

Also die 25MHz hab ich mir in Kopf gesetzt, weil die Schieberegister auf den Panels das als fmax haben.
Auf den Panels selber sind 74HC245 als Buffer eingesetzt. (Daher hatte ich ja zuerst den 74HCT245 probiert.)
Zudem wird auf den Panels garnix terminiert, auf keinem Signal und weder auf Aus- noch Eingängen.
Das muss also ohne gehen, weils nicht vorgesehen ist.

Richtig "geil" sieht das Taktsignal übrigens nach 2 Panels (=4 Platinen aus).
UARGHS:


Hier dann noch mit Daten dazu.
blau = CLK in 10 oder 20MHz (sihe Oszi Messungen)
gelb = Bits blau



Man sieht das Problem


So soll das Testbild aussehen:

So siehts aber bei 20MHz aus:


Der fliegende Aufbau:

[Matt]

schon klar,. mit 20cm lange Kabeln geht schon. Es wird aber schon (!)mit 50cm Kabeln ziemlich ekelhaft.

Das Pixelfehler, der verschluckt Takt und Pixeldaten. Auch wenn 25Mhz in Datenblatt geschrieben ist, low und high-Puls auch mit minimale Länge definiert.
Wenn Treiber wegen nur 3,3V Pegel zu kurze High-Pegel erzeugt. Da ist also Wurm drin.

[Fritzler]

Dann gehen wir doch mal den CLK Pfad bei 20MHz durch.

So siehts vor und hinter dem 74HCT245 auf der Lochrasterplatine aus:


gelb: 74HCT245 Ausgang vom Lochraster
blau: Ankunft an der Panel Platine


gelb: 74HCT245 Ausgang vom Lochraster
blau: 74HC245 Ausgang von LED Panel Platine


Was mir aufgefallen ist, dass nach jeder Panelplatine der CLK Impuls um 3ns länger wird.

Nach Platine1: 27ns
Nach Platine2: 30ns
Nach Platine3: 33ns
Nach Platine4: 35ns

Für mehr Takt müssten also wohl die 74HC245 auf der Panelplatine ersetzt werden gegen ACT.
Das wäre nen ziemlicher Aufwand, weil 4 ICs Pro Panel.

[Chefbastler]

Fritzler herzlich willkommen in der Welt des Voodoos.

In dem Frequenzbereich wird es langsam Spannend mit Masseführung und Signalleitungsführung und Signallaufzeit über die leitung(CLK, DATA leitungen sollten geleich lang sein), und bei längeren Leitungen spielt dann auch mal die terminierung schnell mal ne Rolle.

20Mhz hören sich nach wenig an, ist aber wenn es sich um Rechteck Signal handeln soll eher specktral mit 200Mhz anzusehen.

Ich fürchte eher dass die Panels im originalbetrieb eher mit 10Mhz liefen.

Der 74LVC541A Könnte da noch was bringen bei 20Mhz und entsprechender Leitungsführung:
https://assets.nexperia.com/documents/d ... VC541A.pdf

PS: Der Leitungstreiber IC auf deiner Lochrasterkarte würde sich über nen Kerko freuen. Der Elko da in der Ecke ist da bei den Frequenzen meist etwas ungeeigent da zu träge.

[Fritzler]

Der Kerko ist nur nicht zu sehen, der ist unter der Platine direkt an den Versorgungspins.

Der 74LVC541 geht nicht, weil er nur ne VCC von max. 3,6V hat.
Nur 5V tolerante Eingänge bringen ja nix wenn die Schieberegister ICs unbedingt 5V sehen wollen.

Da frag ich mich dann aber wirklich wie diese Panels in der original Videowall betrieben wurden.
So ist es ja nur möglich 2 Panels in Reihe zu schalten und das bei ner Wiederholfrequenz von maximal 90Hz.
Oder die haben noch viel früher angefangen am Output Enable rumzuspielen *kopfkratz*.
(Dann werden die Panels ja schonwieder etwas dunkler, aber dann spar ich mir Netzteilstrom)

Also mit 15MHz will ich die Teile durchaus noch prügeln, mal an der PLL spielen mit das mit dem SPI Taktteiler klappt.

[Chefbastler]

.

Der 74LVC541 geht nicht, weil er nur ne VCC von max. 3,6V hat.
Nur 5V tolerante Eingänge bringen ja nix wenn die Schieberegister ICs unbedingt 5V sehen wollen.

Meinte die LV Typen. Der rennt mit 5V und ist 3,3V Input tolerant.

Der LVC wäre immerhin noch mit Absolut maximum Rating VCC 6,5V angegeben und als "functional" wurde nur ne Mindestspannung angegeben. Die warscheinlichkeit das es funktioniert wäre warscheinlich hoch aber in einem Amtlichen Gerät würde ich das auch nicht machen.

Wobei diese die geschwindigkeit des ABT eigenlich auch nicht wirklich toppen.

[Fritzler]

Dafür gibts ja die LVC8T und LVCC

Jedenfalls, bei 15MHz ist auch schon schluss.
Panel 1 ist noch super und bei der oberen Hälfte von Panel 2 kommts zu ersten Fehlern.
Bei Panel3 ist dann ganz Schluss.

edit:
Selbst 3 Panel in Reihe bei 10 Mhz gehen nicht, shice.

[Bastelbruder]

Der Impuls wird immer breiter weil die Schaltschwelle nicht in der Mitte liegt. Das ist das ganze Geheimnis.

Mit 3 Volt auf 5 V-"kompatible" Eingänge ist ok, aber mit 5 V funktioniert das nicht so ideal. Ein Spannungsteiler aus 100 und 220 Ohm beseitigt das Problem und dämpft gleichzeitig die Überschwinger etwas ab damit nicht irgendwelche parasitären Dioden* sich unangenehm bemerkbar machen. Die durchschnittliche mehr-Stromaufnahme von 8 mA muß halt sin wenn die Chips nicht zueinander passen.

*Eine Parasitärdiode ist keine separate Diode sondern eher ein Stromspiegel, der eventuell denselben Strom nochmal von der gegenüberliegenden Spannungsquelle zieht. Und die Dinger sympatisieren miteinander über die ganze Chipfläche ...

[Fritzler]

Bastel, es geht doch in die andere Richtung.
Der sendende STM32/FPGA hat 3,3V IOs und die Panels wollen 5V.
Daher steckt da nen 74HCT245 zwischen, der 5V bekommt.
DER zieht die CLK Impulse nicht um 3ns in die Länge, sondern die 74HC245 auf den Panels. Diese bekommen aber 5VCC und 5VIO.

Ansonsten is das mit der Schaltschwelle ja einleuchtend.
Im FPGA werde ich den CLK wohl eher als 30/70 DC Impuls ausgeben, denn der CLk Impuls darf kürzer sein als die Hold Time am Dateneingang der Schieberegister.
Dann gehen vllt wieder 3 Panels in Reihe mit 60Hz oder 2 Panels in Reihe mit 90 oder 120Hz flimmerfrei.

Aber ich hab mich intern schon darauf eingestellt, dass ich wohl ne 4fach Verschachtelung bauen muss und jedes Panel bekommt seine eigene LAT und nOE Leitung.
Also jedes Panel bekommt Daten für sich und keine Reihenschaltung mehr.
Das bedeutet aber auch, dass das Display nurnoch 8x5 sein wird statt 9x5 Panels.
Weiterhin besteht es dann aus linker und rechter Hälfte, also 2 FPGA Boards brauchts, die werden dann von nem STM32 per QSPI gefüttert und gesynced.

[Fritzler]

AAAAHH! Nurnoch so ~2 Monate zum Treffen!

Da hab ich mich doch spontan entschlossen am Display weiterzumachen.
Jedenfalls sind die DMA Probleme jetzt weitgehend gelöst.

Der DMA sendet die Bits schön brav mit 14MHz auf die GPIO.
Es gab ja mal noch son flimmern, denn der Bitzähltimer hat beim stoppen gejittert.
Bitzähltimer?
Naja die DMA Ausgabe ist recht kompliziert gebaut, da die Panels ja nur Schieberegister sind und dadurch darf keine Taktflanke zu viel am Ende sein, sonst verrutscht das Bild.
Aber genau das kam ab und zu vor.
TIM1 des STM32 zählt die Zeit wie lange der DMA braucht um alle Bits auszugeben.
TIM8 erstellt eine PWM, das ist der Takt der Schiebregister und immer wenn TIM8 überläuft wird der DMA getriggert ein neues uint16-t auf die GPIO zu legen.
Damit das eigentlich nicht jittern kann läuft TIM8 im Gating Modus, also TIM8 läuft nur solange TIM1 läuft.
Das hatte aber trotzdem gejittert?! Da ist wohl das interne Eventsystem etwas zu träge, sobald TIM1 mit dem 4fachen Takt (durch den Prescaler eingestellt) von TIM8 läuft funktioniert das!

JAY!

Aber wie gehabt, dabei darf keiner weiter gleichzeitig auf den SRAM oder AHB1 zugreifen.
Selbst ein UART pollen -> RUMMS.
Daher liegt im SRAM1 exklusiv der Bitangle Buffer und in SRAM2 liegt der per SPI geholte Framebuffer. Der SPI DMA wird nur laufen, wenn grade keine GPIO Ausgabe erfolgt.
Das muss ich also intern noch verschränken.
Das Programm selbst läuft komplett aus dem Data CCM (Core Coupled Memory).
Das Linkerscript wird so langsam … unauf ... äh ... interessant.

Da die Panels nicht mit vollen 25MHz laufen (die SREG können das, aber die verbauten 74HC Bustreiber verzögern den CLK zu krass), kann ich nicht mehr 3 in Reihe packen, sondern immer nur eines betreiben.
Momentan sind 2 in Reihe und schaffen 60Hz Wiederholfrequenz, das flimmert aber noch leicht, also müssens 120Hz werden.
Ist aber kein Problem, weil ich ja noch die 3fach Verschachtelung habe.
Zudem veranstaltet meine Kamera bei den 120Hz keine Flimmerparty mehr bei den Aufnahmen.

Daher wird das Display gedrittelt, pro Drittel ein Controller (STM32F407).
Die Daten kommen von einem Zentralhirn per SPI über LVDS über Ethernetkabel.
Laut einer TI Appnote gehen da noch 200mbit über 5m CAT5, das ist mehr als genug.

Dazu muss ich aber mal gucken ob dann nicht das Zentrahirn überlastet ist wenn 3 SPI Slaves gleichzeitig per DMA bedient werden müssen und die Daten müssen ja auch noch reinkommen!

5*9 Panel zu16x16px und 60fps sind mal eben 2,1MByte/s!
Mal gucken wie ich diese Datenrate aus einem Linuxrechner rausgepopelt bekomme.
(wegen meinem mplayer Plugin).

Ein RasPI hätte einen SPI Ausgang, aber ob der FullHD Videos mit 60fps abspielen, downscalen und auf den SPI schieben kann?
Ich bezweifle es.

[Fritzler]

Hier der neue Testverhau.
Jetzt werden 2x3 Panel getestet und nicht mehr nur 1x2.
Um die Pixelverteilung über die Panelzeilen zu testen und um mal alle 3 Verschachtelungen gleichzeitig zu sehen.
Durch die Auftrennung der LAT/nOE Signale kann ich jede der 3 Panelspalten einzeln ansteuern.
Wenn also Spalte 0 grade keine Daten bekommt, kann ich zB Spalte 1 ansteuern.

So langsam merk ich wie groß und vor allem SCHWER das wird.
Die 6 Panel zusammen wiegen schon ordentlich was und nehmen gut Platz weg.

Trotz 4 Zusatzsignalen kann ich bei einem 16Pol Flachbandkabel bleiben, denn es sind genug NC vorhanden.
Glücklicherweise zusammen am unteren Rand (Pin 13-16).
Dafür muss ich zwischen 2 Panels am Flachbandkabel rumschnippeln:


Schlussendlich wird die Pegelwandlerplatine auch etwas größer:

[Fritzler]

Läuft! Würd ich ma sagen:
https://www.youtube.com/watch?v=eXhdq72zRSU
Ersteinmal nur per intern erzeugter Animation.

Also GPIO DMA mit 2xRGB und die ANsteuerung der 3 Panels pro Zeile.
Alles mit 120Hz, kein flimmern mehr auf der kamera und im Auge auch nicht!

Als nächstes dann mal noch ein STM32Disco Brett raukramen und das "Daten per SPI holen wenns zeitlich grade passt" implementieren.


Dazu hatte ich ja erstmal den BAM umgedreht mit ich Zeit habe.
Die kleinste Leuchtzeit kommt nun zuerst und wird dann immer größer.
Ansonsten will ich 60fps Video erreichen und habe 120HZ Wiederholrate.
Also 2 Wiederholungen pro Frame habe ich Zeit für alles.

Ersteinmal wird per SPI der neue Framebuffer in den Pausen gezogen (Das Bussystem des STM32 ist ja bekanntlich auf Vollanschlag).
Danach wird der neue BAM Buffer vom ARm kern im Core Coupled Mem berechnet und in der "Austastlücke" in den SRAM1 kopiert.

SPI Empfangen und berechnen könnt ich auch schachtelnw enn die Rechenzeit nicht hinkommt.

[Chefbastler]

Oha da in deinem Video sind ganz schön viele LEDs Defekt?
Lassen die sich austauschen?

[Fritzler]

Nö, das Projekt ist eben wortwörtlich Schrott!

Die LEDs sind in schwarzer Pampe vergossen wegen der Wetterfestigkeit.
Selbst wenn man die tauscht wird man nicht mehr haargenau dieselben bekommen und somit sieht man das auch wieder.
Auf einer der Platinen habe ich jetzt auch schon Reparaturarbeiten gesehen, da wurde eine leiterbahn mit einem Draht nachgezogen, der Subpixel geht aber.

Heute kam auch das von Xana gekaufte NT an und im Karton befand sich noch Qualitätsaal (die Beamerlüfter müssen jetz wohl weg ) Sowie LED LED LED, imemr gerne,

5V/200A, aber mit Steckkontakten zum reinschieben in einen Server?.
Daher mal aufgemacht und doch Schraubkontakte gefunden -> Perfekt!

Auch schön Modular aufgebaut.
der Deckel ist die PFC und der Boden das eigentliche NT.
Aus den Schalttrafos kommen Kupferschienen raus!

[Matt]

Also, meine Karton ist auch angekommt .

Ja, das ist Problem mit tote LED. (nahezu nur mechanische Schäden)
Und noch eins: an ihre Lötstelle (hinten) kommt man zur grösste Teil nicht ran. Grund: Treiber-Platine ist draufgelötet. Möchtest du mehr als 100 Lötstelle entlöten und Platine rausziehen ? Ich jedensfalls nicht.

Einzig was man machen kann: vorsichtig kaputte LED um Gehause befreit und helles SMD LED drauflöten. Um geringe bis keine Unterschiede zu erreichen, hat man nicht leicht. Daher: Scheiss drauf !.

Ich habe etwa 8 Stück Wahl 1A ( maximal 1 kaputte LED) und ist teils in 2x4er Panel verbaut.

Grüss
Matt

[Fritzler]

Ja, ich muss mal durchzählen ob ich mit deinen Panels jetzt 45+ Stück habe, sonst fehlt unten rechts eben was.
(Der Drucker is ja um einiges dicker als ich dachte! Ein 9er Band sieht darin so verloren aus)

Da ich eine Entlötlutsche habe mit Pumpe würde es sogar gehen die Treiberplatine runterzulöten, aber die is ja auch noch mit Pampe vollgeschmiert.
Nee issnich
Viele LEDs sind auch so abgerissen, dass da nicht mal genug Restdraht vorhanden wär zum SMD LED anlöten.

Ein NT bräuchte ich aber dennoch.
Ich hab jetzt: 200A+85A+60A = 345A
Aber 45 Panel zu 8,5A = 382A
Oder ich dimm nochn bissl.
(Wobei ich dem Chinaböller seine 60A nicht voll zutraue, das Ding wird bei 20A schon gut warm und der Lüfter will nich anlaufen)

Wenn alle Panel 12A ziehen is eh zu viel Strom (540A).
Aber durch das OutputEnable kitzeln, für die 12Bit an Graustufen, kann das Display garnicht mehr 100% an sein.
Ich hoffmal die Ausgangselkos der NTs federn das gut ab

[sukram]

Sag mal, kannst du daneben noch Handy oder Wlan nutzen? vei den Strömen scheint mir das ja ne Mords HF Schleuder zu werden

[Fritzler]

So, heute mal die SPI Übertragung eingebaut, welche in den GPIO DMA Lücken neue Daten holt.
Ersteinmal die Zeit gemessen zwischen 2 der Pulse: 600µs.
Davon hab ich 4 Slots, macht 2,8ms.
In diesen 2,8ms müssen 11520 Byte übertragen werden.
Das macht 38MHz SPI Takt, also APB/2 beim STM32 -> 42MHz SPI VOLLGAAAAAS.
Das funzt hier grade über Tüddeldraht mit Serienterminierung, später wird das ja LVDS.

Ein STM32F407 und STM32F429 DIscovery quasseln grade miteinander.
(Von Discoverys hab ich ne ganze Schublade voll!)

So sieht das dann aus:
blau ist der CLK des GPIO DMA und gelb der SPI CLK.
Genau in den Lücken wird empfangen (hier sinds noch weniger Daten, weil weniger Panel)


42MHz SPI mit nem 200MHz Oszi angesehen sind schon gut Sinusförmig:


Jedenfalls hab ich ein stabiles Bild ohne Pixelfehler.
Mal noch gucken wie ich wieder die mplayer Daten reingefüttert bekomme.

Störungen? Welche Störungen?
Also der Pixeltakt ist 14MHz, die zweite Oberwelle (28MHz) könnte CB Funker nerven.
(Soll ich bei der CPU PLL mal Spreadspectrum anmachen?)
Das ist aber nur Signal, die hohen LED Ströme werden seltener umgeschalten.
Nämlich nur wenn 256 Pixel übertragen wurden und in die SREG gelatcht werden.
Dann gibts aber echt böse Stromschwankungen.

WLAN/GSM wird das aber eher nicht stören.
Auf dem Ozi bekommt man aber nen ordentliches Rauschen:
(Die Bilder oben waren ohne aktive LED Panels)

[Bastelbruder]

Clock und Signal sehen da aber noch gut aus! Problematisch könnte das werden wenn die mehrfachen 3 ns hinzukommen.

Laß den Scheißeventilator* mal aus. Dann hast Du die Möglichkeit, EMV korrekt messen und qualifiziert verbessern zu können. Erst wenn da nichts mehr geht könnte Verwischung sinnvoll werden.

Das ist aber nur Signal, die hohen LED Ströme werden seltener umgeschalten.

Egal wie selten, wenn die Grundfrequenz aus dem Signaltakt abgeleitet wird, taucht exakt dieselbe Frequenz wieder auf. Plus "Subharmonische" mit Abstand und Energieanteil entsprechend ihrer zeitlichen Verteilung.

Siehe Postille 2018, erster Beitrag.

[ferdimh]

Wenn ich das sehe, bedarf es einer gewissen Serienterminierung an diesen Strippen. Evtl aber erstmal mit 470Ω direkt auf ein Koax und Oszi mit 50Ω-Eingang messen. Bezüglich rumgestöre sollte das Ganze eigentlich relativ harmlos sein - aktuelle EMV-Grenzwerte sind eh ein Witz, aber kein besonders guter.

[Fritzler]

Die Machbarkeitsstudie wäre jetzt ersteinmal fertig.
Bis auf 2 kleine Sachen:
Das Zentralhirn wirklich mal mit 3 42MBit SPI gleichzeitig stressen.
Überprüfen ob meine berechnete Rechenzeit der Funktionen Framebuffer->BAM wirklich so lange brauchen wie berechnet.

Das mplayer Plugin hält wieder her als Zuspieler, aber diesmal mit 3mbaud UART.
Ab und zu verschwindet dadurch mal ein Byte und das rotgetauchte Russkaja VIdeo wird blau
BREAK senden zum resync geht leider nicht, die Baudrate ändern durch den Linuxkernel und USB dauert zu lange.
Später wird ja per art-net UDP zugespielt, der ETH MAC des STM32 kann ja seine 100mbit und es verrutscht auch nix.

Durch die 120Hz sind die Videos jetzt auch ohne Augenkrebs genießbar.

Russkaja: https://www.youtube.com/watch?v=IcoESP6tbR8
Musik dazu: https://www.youtube.com/watch?v=BVWfqOSdzs4

Powerwolf: https://www.youtube.com/watch?v=c7HSDjX5fDU
Musik dazu: https://www.youtube.com/watch?v=GpxFUo7oxWM

Beim Fate AMV ist dann komischerweise kein Byte flöten gegangen:
https://www.youtube.com/watch?v=SMYH4SA2rXk
Original: https://www.youtube.com/watch?v=c8e7SYsh41Q

Es ist doch offensichtlich, dass es mehr Pixel braucht oder?

[Sir_Death]

geiles Projekt. - Weit jenseits dessen, was ich jemals programmieren werde können.

IIIGOOOOOOR MEEEEHR PIXEL!

[Fritzler]

Die 2 kleinen Sachen sind nun auch abgehakt.
Alle STM32 tun so als wäre der Bildschirm vollausbau schon fertig.

Dank Störungen wird aus einem 2 Kanal oszi ein 3 Kanal Oszi.
Wo der blaue Graph breiter wird findet die SPI Übertragung statt.
blau = high -> der CPU Kern berehcnet die BAM Buffer aus dem Framebuffer.
gelb = CLK Leitung der Bursts zu den Panels.

Es ist wunderbar zu sehen wie die SPI Übertragung zwischen den Bursts stattfindet und wenn alle 4 Teilübertragungen fertig sind darf die CPU rechnen.
Es wird grade so fertig bis zum nächsten SPI.
Nach einer SPI Übertragung wurd der Framebuffer vom SRAM zum CCM kopiert und der BAM Buffer vom CCM zum SRAM.
Bei 60fps hab ich also 1 Frame Verzögerung und bei 30fps 1/2 Frame.



Ansonsten hab ich mal mit den Platinen angefangen.
Zentralhirn und Panelsteuerung bekommen dasselbe Layout.
Es wird eben nur bestückt was gebraucht wird.

[Fritzler]

HMPF!
Das LVDS Zeuch is dann doch teurer als gedacht.
Die ganzen billigen LVDS ICs für 40 cent waren alle nicht auf Lager :/

[Fritzler]

Das wär dann das Layout.
Ist doch etwas voller geworden als gedacht.


Ethernet PHY Pinlayout und STM32 Layout passen so ganich zunander.
Aber bei dem STM32 Layout wo die MII Pins an 3 Seiten des µC rausgucken ist das kein Wunder
Muss man eben wieder ordentlich Schleifen in die Leiterbahnen weben.

[Fritzler]

Also ich kann ja aufm Fingertreff nicht die ganze Zeit lautlose Musikvideos und Fingerfilme abspielen.

Das LED Panel Display wird per Art-Net UDP ansteuerbar sein.
Es hat natürlich mehrere Universen und die 144x80px liegen hintereinander als (3x8Bit) RGB vor.

Art-Net ist einfacher als man denkt: https://en.wikipedia.org/wiki/Art-Net#Packet_format
UDP Socket aufmachen, reinhusten, fertig.

Will denn da jemand noch was coden?
Per JINX wirds auch ansprechbar sein, zB für Texte wann welcher Vortrag stattfindet.
(http://www.live-leds.de/)

[Fritzler]

BOAH NEE!
Jetz muss ich bei JINX 80 Artnetausgänge anlegen, weil er von selber nicht die DMX Universen hochzählt :/

[Fritzler]

Zu den Störungen:
Das 200A NT erweist sich als ne üble EMV Sau.

Osziausgang ohne Last:


15A Last:


30A Last mit homöopatischen 4700µF Ausgangselko vor die E-Last geklemmt:


Denn das NT besitzt nicht wirklich Ausgangselkos, die waren wohl im Cisco Switch selber verbaut.
Kann ich Matts Tüte 4700µ Elkos mal Anwenden

Was mich am NT etwas irritiert, dass es anfängt etwas elektrisch zu riechen wenn es "Last" bekommt (10/20/30A).
Aber nur leicht, aber es riecht nach warmer Elektronik.
Im Lerlauf verschiwindet das.
Ich hoffmal da riecht nur der Staub in dem Teil.
Oder durch die fehlenden Ausgangselko grille ich intern grade irgendeine TVS Diode?
Direkt aufmachen und Thermofühlen issnich, denn der Deckel ist die PFC und mit 450V 1500µ leg ich mich nicht an!

Jedenfalls hab ich mal noch ordentlich Kabel gecrimpt:




45 Datenkabel für die verbindung beider Panelhälften.
Dazu jeweils 45 Stromversorgungskabel in Plus und Minus als 1qmm für 8A.
Die muss ich alle noch anlöten x_X

[video6]

Wenn das fertig ist wird das stromtechnisch aber kein A++ Gerät

[Fritzler]

Ach wiesoooo?
Hat doch LEDs!

Man wird ja fast schon blind wenn 6 der Panels auf voll weiß gehen, was passiert dann erst bei 45 Panel?
Bzw da ich nicht genug Ampere habe wird das Display auf 90% gedimmt, aber das sollt immmrnoch sauhell sein.

Was nicht A++ sein kann war das Halogenlampendisplay als Gruppenprojekt:
http://www.fritzler-avr.de/HP/dasdisp.php

[Fritzler]

Heute mal eine der Aluleisten gebohrt und es passt.
Jedes Subpanel (jedes Panel besteht aus 2 Hälften), wird wohl noch 470µF bekommen wegen dem Ausgangselkolosen 200A NT.
Das sind dann 28.200µF, das sollt ja wohl reichen zum Glätten von dem Gelump auf den 5V.

Ich werd wohl doch keine Rohrschellen+Seilspanner nehmen, denn dann hängt das Display 15cm tiefer als es könnte.
Son 3,6mm breiter Kabelbinder von Reichelt soll 18 kp können, das sind 176N, also 17,6kg.
Es gibt 8 Aluprofile die aufgehangen werden, also 140kg Tragkraft.
Das reicht ja wohl?

Ziemlich groß wärs dann schonmal und das sind nur 2 von 9 Spalten.
Gute Musik als Größenvergleich.

[Hansele]

Sorry für diesen Kommentar...


GEILES TEIL!

(musste geschrien werden)

[Matt]

Bin gespannt, wie es am Ende dasteht.


Ich denk nach, ob ich meiner auch mitnehmen wird.

Grüss
Matt

[Fritzler]

Danke für die Blumen
@Matt, mach!
Für Infos einblenden sicher gut zu gebrauchen.

Heute hab ich mal die Stromkabel angelötet mit den zusätzlichen Elkos.
Dabei auch jedes Panel dann getestet. (ALso ich hab noch nicht alle durch)
Die Pixelfehler halten sich doch recht in Grenzen, die Testpanels für die Videos waren eigentlich mit die Schlimmsten.

Bei 7 Panel hatte ich leider abgerissene ICs, die auch Pads in Mitleidenschaft gezogen wurden.
Davon werden 3 irreperabel sein, denn dort sind Pads ab wo sich die Leiterbahn gleich zu nem Via hinschleicht.
Also hab ich jetzt trotz 50 vorrätigen Panel bei 45 Benötigten ein paar zu wenig.
Bei Anderen sind nur LED Pads ab, das könnt man Nachfädeln (ÖRGHS).
Da wärs einfacher die Platine zu tauschen.
AAABER! Bauteiltöter schickt mir noch 5 Panels.

[Fritzler]

Die Spielzeugmärkte Hellweg und Toom um die Ecke haben keine Euroboxen, sondern nur so Krimskramsboxen mit schiefen Wänden und ohne Traglast.
Also muss man extra nach Schweineöde.

Aber es passt wie geplant, zu sehen sind 3 Spalten von 9.
Da kommt dann noch ne zweite Ebene drauf sowie eine Eurobox mit 20er statt 40er Höhe.
Der freie Platz ist für Kabel, Schrauben, Platinen und Zeuchs.

[Fritzler]

Nach dem alle Aluprofile fertig gebohrt sind kann ich mal ein Displaydrittel (=eine Displayeinheit) aufbauen.
Unten kommen dann die dicken Strippen des NT ran und oben die Kabelstrapse um es ans Querrohr des Zelts zu befestigen.

Hier ist jetzt zu sehen wie ich das meinte, dass die Aluprofile zum Verschrauben und für die Stromverteilung sind.
Diese Displayeinheit wird dann auch von einem Subcontroller gesteuert.

[Fritzler]

Die Platinen sind da!

Aufpassen beim Bestellen bei Elecrow, denn "Hongkong DHL" = DHL Express.
Das sind die mit der assigen Abzock äh Kapitalbereitstellungsgebühr.
Zum Glück hab ich ich die 5€ Marke (ab wann die EUst. eingezogen wird) knapp verfehlt.
$26.46 -> 23,63€ -> davon 19% EUst = 4,49€

Fedex "Express" brauch noch etwas.

[Fritzler]

Da hab ich heute mal 2 Platinen bestückt, einen Sklaven und das Zentralhirn.
Der EthernetPHY baut eine Verbindung auf und die Daten LED blinkt bei Broadcasts, der funzt also.


Natürlich hab ichs geschafft mit 80A eine leiterbahn zu grillen.
Beim steifen cat6 pimf LAN Kabel reinstecken fürs LVDS ist die eine Platine auf die andere gerutscht und der 5V Kontakt ist auf das GND potenzierte Schirmblech der LAN Buchse raufgekrochen.
*stink*
Nunja, Draht drüberlöten und weitermachen, die Platine hatte 5V und GND=5V, da kann nix kaputt gehen. War ja kein Potenzial vorhanden.


Was mich etwas verdutzt ist, dass die 120R Serienterminierungswiderstände Ärger machen.
Diese sitzen am STM32 zum LVDS Treiber und am LVDS Receiver wenns zum STM32 soll.
Also am Slave sieht man Bitfehler auf dem Panel, wenn ich den Widerstand berühr siehts so aus wies soll.
Überbrücke ich ihn, dann auch, also 0R reingelötet.

Beim LVDS Receiver wird der benötigt, der haut Taktflanken raus die für 400MHz Signale reichen.

HF *grusel*

[Fritzler]

Was zum Teufel?

Alle Serienterminierungen sind jetzt auf 0R gelötet.
Der obere Ausgang: kein flimmern
Der mittlere Ausgang: kein flimmern
Der untere Ausgang: flimmert wie die anderen vorher und war vorm Umlöten stabil.

[Sir_Death]

Darf ich mal raten? - Laufzeiten und damit Reflexionen am Kabel?