Hallo, wie der Titel schon sagt, habe ich zwei Fragen zu einer Matrix mit LED-Streifen (WS2812). 1) Spannungsversorgung die LED-Streifen werden ja mit 5V betrieben. Die LEDs sind aber doch in reihe geschaltet oder? Addiert sich dann die Spannung der einzelnen LEDs nicht? (also müsste ich nicht eigentlich bei 10LEDs in Reihe 50V bereitstellen?) Die einzelnen Reihen würde ich dann trotzdem mit neuer Spannung versorgen. 2) Datenleitung Wie macht ihr das mit der Datenleitung? Diese geht ja auch von LED zu LED. Aber in der ersten REihe von der letzten LED, ist es dann besser zur zweiten Reihe zur ersten LED? oder ebenfalls zur letzten LED und dann über die anderen LEDs zurück zur ersten LED? [reihe,spalte] [0,0]-[0,1]-[0,2]-[0,3]-[0,4]-[0,5]-[0,6]-[0,7]-[0,8]-[0,9] - ?[1,0]-[1,1]... ?[1,9]-[1,8]... Bei zweitere möglichkeit müsste ich in der Software ja dann jede spalte spiegeln. Bei erster Variante müsse ich die Datenleitung jedesmal zunächst an der ganzen reihe vorbeiziehen. Markus
Markus schrieb: > Die LEDs sind aber doch in reihe geschaltet oder? Nein > Wie macht ihr das mit der Datenleitung? Datenleitung geht an den Eingang der Kette. Davon gibt es nur einen
[1] nein, parallel [2] Du legts die erste Reihe von links nach rechts, die zweite von rechts nach links, etc. - je kürzer die Datenleitung, desto besser. ---[0,0]-[0,1]-[0,2]-[0,3]-[0,4]-[0,5]-\ | /-[1,5]-[1,4]-[1,3]-[1,2]-[1,1]-[1,0]-/ | \-[2,0]-[2,1]-[2,2]-[2,3]-[2,4]-[2,5] Wenn's viele sind, evtl. die 5V-Versorgung nochmal zwischendrin mit dicken Leitungen einbringen - aber das weißt Du ja schon ;-) ("Die einzelnen Reihen würde ich dann trotzdem mit neuer Spannung versorgen.")
Ja, das "Spiegeln" machst Du in SW. Wichtig sind kurze Leitungen, und vor allem alle 5 LEDs einen Abblockkondensator 100nF. So kannst Du bist zu 200 LEDs kaskadieren.
Dauergast schrieb: > [1] nein, parallel Ahso, dann passt das mit der Spannung. Dauergast schrieb: > Wenn's viele sind, evtl. die 5V-Versorgung nochmal zwischendrin mit > dicken Leitungen einbringen - aber das weißt Du ja schon ;-) ("Die > einzelnen Reihen würde ich dann trotzdem mit neuer Spannung versorgen.") Ich wollte eine 10x10 Matrix machen und wie erwähnt jede Zeile einzeln mit Spannung versorgen Wilhelm M. schrieb: > Ja, das "Spiegeln" machst Du in SW. Ok. Wilhelm M. schrieb: > Wichtig sind kurze Leitungen, und vor allem alle 5 LEDs einen > Abblockkondensator 100nF Das wusste ich nicht, werde ich aber berücksichtigen.
Wilhelm M. schrieb: > Wichtig sind kurze Leitungen, und vor allem alle 5 LEDs einen > Abblockkondensator 100nF. So kannst Du bist zu 200 LEDs kaskadieren. Wo hast du diese Weisheit her ?
Hallo, die WS-Strips kann man so benutzen, wie sie sind. Einspeisung GND/Vcc bei einer 10x10 Matrix jede Zeile an einem Ende parallel, 10 Stück sind max. 600mA, also etwas dickeren Draht für die Spannung. Einspeisung dann in der Mitte bei Zeile 5 oder 6 oder in der Mitte dazwischen. Netzteil entsprechend min. 6A, besser 8A. Datenverbindung kann auch durcjaus 1m oder mehr sein, man kann die Zeilen also auch "richtig" rum verschalten. Wichtig: in DataIn der ersten LED einen 330Ohm Reihenwiderstand direkt an der LED UND GND von der Steuerschaltung direkt vom GND bei der ersten LED nehmen. Wenn der µC aus dem gleichen Netzteil versorgt werden soll, +5V vom Netzteil holen, GND NUR von der ersten LED. Ein AVR hat mit Schwankungen der Betriebsspannung bei verschiedener Helligkeit kein Problem, die GND-Verschiebung dadurch am an der ersten LED mit den Daten sorgt aber dafür, daß die erste LED früher oder später stirbt... Deshalb muß GND der ersten LED wirklich auf GND des AVR liegen! Hier sind zur Zeit 120 LED als Stripe, Einspeisung 1x in der Mitte, ein ESP mit 3,3V-Regler am Anfang, GND, +5V und Dta direkt vom Stripeanfang. Nezteil 12V 8A, Zuleitung 2x 0,75 Litze ca. 2m. Damit gibe es keinerlei Probleme. Gruß aus Berlin Michael
Ich hatte angenommen (falsch gelesen), dass es sich dabei um einzelne bedrahtete WS2812b handelt. Bei denen habe ich schon viel Schwierigkeiten gehabt, falls das Abblocken fehlte. Bei Led-Streifen kann das anders sein. Bei den einzelnen LEDs hab ich das (glaube ich) auch im Datenblatt gelesen ... bin aber nicht sicher mehr.
Michael U. schrieb: > Ein AVR hat mit Schwankungen der Betriebsspannung bei verschiedener > Helligkeit kein Problem, die GND-Verschiebung dadurch am an der ersten > LED mit den Daten sorgt aber dafür, daß die erste LED früher oder später > stirbt... Ja, ist mir auch schon passiert. Aber 150 Ohm in die Datenleitung und es ist Ruhe. ______ AVR ---|______|---- WS281x Din 150 E P.S. Komischerweise geht die erste WS281x meistens nicht ganz kaputt, nur die Daten werden nicht mehr durchgeschoben, man kann diese LED dann durchaus als einzelne LED verwenden...
Wilhelm M. schrieb: > bedrahtete WS2812b handelt. Bei denen habe ich schon viel > Schwierigkeiten gehabt, falls das Abblocken fehlte. Bei Led-Streifen > kann das anders sein. Bei Led-Streifen hat jede WS281x einen eigenen Kondensator.
Nochmal der Nachfrage zum Widerstand in der Datenleitung. Wozu ? Der Treiber in der LEDs ist wie ein normales Logik Gatter zu betrachten. Der ist auch 3.3V Tolerant. Die Kapazitive Last von Din 15pF erzeugt laut Daten einen Strom von 1µA. Keine Gefahr für AVR oder LED Treiber. Das mit der Masse ist teilweise verständlich das man die Versorgung der LEDs weit vorne am NT abgreift. Das was hier wahrscheinlich zur Diskussion steht ist der angenommene Unterschied zwischen Masse AVR und LED. Der ist auch nicht vorhanden wenn man die AVR Masse vorne vom NT holt. Auf die Idee diese an der LED abzugreifen wird ja wohl keiner kommen ? Ging es darum ?
Marco H. schrieb: > Wozu ? Der Treiber in der LEDs ist wie ein normales Logik Gatter zu > betrachten. Der ist auch 3.3V Tolerant. Die Kapazitive Last von Din > 15pF erzeugt laut Daten einen Strom von 1µA. Keine Gefahr für AVR oder > LED Treiber. Haben schon viele so oder ähnlich gedacht... *********** IMMER *************** Masse AVR <===> Masse erste WS281x. *** Funktioniert ohne Probleme *** 150 Ohm in die Datenleitung. Einschaltreihenfolge beliebig. *** Wenn man starsinnig ist *** Kein Widerstand zwischen AVR und WS281x WS281x zuerst einschalten !!!
Marc V. schrieb: > Bei Led-Streifen hat jede WS281x einen eigenen Kondensator. und so gehört sich das ja auch - wie bei jeder Digitalschaltung: ein Abblockkondensator jeweils direkt an jeden Chip. Nur jeden 5 oder so ist Murks! Ein (oder besser mehrere verteilt) größerer Elko zusätzlich an der 5V-Versorgung der LEDs ist auch zu empfehlen, natürlich zusätzlich zu den 100n pro LED.
Aus dem Grunde würde ich den Widerstand nicht verwenden. Er aus dem Grund bei einen Kurzschluss von Di zu Masse mir die GIO oder Pegelwandler nicht zu zerstören. Ich denke das die LEDs er davon gestorben sind.. Ich lassen alle Datensignale über Logikgatter oder Bustreiber laufen. Die setzen den Pegel von 3.3V auf 5V und verhindern das 5V auf die 3.3V PIO kommen könnten. Größer Längen kann mit dem einen RS485 Treiber überbrücken, das funktioniert zuverlässig mit einen 75176. Irgend eine Firma kaum da auch schon drauf.
Der Widerstand hat schon seine Berechtigung! Hier mal eine kleine Veranschaulichung, welches Signal der Daten-Eingangspin der LED sieht bei einem ca. 1 Meter langen Verbindungskabel zwischen µC und LED. 1: ohne Widerstand (vergleiche das Signal mit den "absolute Maximum Ratings" für die Spannung am Pin im Datenblatt!) 2: Widerstand am µC-Ausgang 3: Widerstand an der LED.
Thomas E. schrieb: > einem ca. 1 Meter langen Verbindungskabel Kleine Korrektur: die Simulation entspricht wohl eher einem ca. 60 cm langem Kabel - habe oben den Verkürzungsfaktor außer acht gelassen...
Danke ! Das hat aber weniger mit Masse Problemen zu tun. Ich habe jetzt 330Ohm drin. 4 Linien über Artnet, zumindest ist die Hardware jetzt etwas stabiler als auf den Reißbrett ;).
Wenn das jemand nach bauen will anbei die Lochmaster Datei. Aber nichts für den wirklich produktiven Einsatz. Sicherung fehlt die ist bei mir extern. Passt auf einen Arduino Due oder gleichwertiges Belegtes Board und nutzt die Ausgänge PWMML0..3 die anderen 4 sind nicht auf der Leiste. Man könnte 8 Ausgänge mit dem PWM Controller realisieren.
:
Bearbeitet durch User
Bei mir ist es wie bei Dauergast beschrieben. 9 Gruppen je 4 * 60 LEDs (Snake) Spannungsversorgung von MC ist von erster LED (Gruppe) abgegriffen. Da ich immer invertiert über SPI die Daten erzeuge habe ich noch einen Pegelwandler an jeder Gruppe. 3.3v ist dann auch möglich.
Marco H. schrieb: > Er aus dem Grund bei einen Kurzschluss von Di zu Masse mir die GIO oder > Pegelwandler nicht zu zerstören. Ich denke das die LEDs er davon > gestorben sind.. Denken kann man sich vieles - ob das auch stimmt ist eine andere Sache. Bei einem Kurzschluss und 4.7V am Ausgang ergibt das mit 150 Ohm 31mA Strom für uC. Davon stirbt kein AVR. Und für WS281x kann es gar kein Kurzschluss am Din geben, da es Eingänge sind. Es kann aber sehr wohl unerlaubte Spannungsspitzen geben. > Danke ! Das hat aber weniger mit Masse Problemen zu tun. Ich habe jetzt > 330Ohm drin. Man kann es auch übertreiben...
:
Bearbeitet durch User
Wenn ein Widerstand drin ist, bei 31mA ist die Chance gegeben das sie überlebt, das kommt auf die PIO an. Ohne sinkt die Chance und es steigt die für Rauchzeichen. Beim basteln sind Unfälle keine Seltenheit. Ein Kurzschluss am Streifen hat böse folgen. Auch wenn die 5V auf die 3.3V PIO geraten. thomas_fr läuft das ganze mit dem auf dem Board vorhanden Mega8 ? welchen ArtnetCode verwendet du ? Ich habe fast alles neu Programmiert und mich an die Artnet Norm gehalten. Also alle Spezifikationen sind vorhanden. Merging, Clear merge, LTP/HTP. Das Treiben von 170 LEDs per DMA geht Technisch mit einer Framrate von 200HZ. Den Bandwitch Test mit 255 Universen hat die Node ohne Paket loss überstanden. Allerdings muss der Buffer vom W5500 vergrößert werden. Die Ausgabe per PWM hat allerdings seinen Preis. Diese ist ein speicher mordendes Monster. Ich will das noch überarbeiten in dem ich die Werte stückweise berechne und diese per next Pointer an die DMA Ausgabe dran hänge. So das der Framebuffer speicher deutlich verkleinert werden kann. Nun auch mal ein Video. Bandwitch Test 25ms ein Paket und ein zweiter Controller im merge Mode HTP, der ebenfalls alle 25ms seine Pakete sendet. Ohne dropouts .. Das so mit der Kamera festzuhalten ist immer schwierig, in Wirklichkeit setzt es nicht aus.
:
Bearbeitet durch User
@ Marco H. Auf dem Board ist ein ATxmega8E5. (W5500->MC->WS2812 geht über DMA) Das ganze wird über ein eigenes Protokoll (UDP) gesteuert. (100Hz) Im Protokoll ist ein Zeitstempel damit kann die Ausgabe zu den WS2812 Phasensynchronisiert werden. (Jitter 50µs) Ein selbst entwickeltes PC-Programm wandelt eine interne BitMap in die 9 Datenströme um. (Gammakorrektur jede Gruppe für sich) Die BitMap kann von verschiedenen Datenquellen versorgt werden Matrix3,jinx (ArtNet) VLC-Player (DLL) GDI+ Zeichenfunktionen
Interessant.. in sofern das man eine Madrix DVI zu einer DMX machen kann ;) Ja klar durch den Zeitstempel kann man berechnen wann die Ausgabe erfolgen muss. Das Paket muss vor dieser Zeit vorliegen. Ich habe mich schon gewundert was über dem Madrix läuft. Warum nicht Artnet direkt und diese Lösung mit richtig viel Randarbeit? Ich will noch hinzufügen. Der Bandwitch Test lauft folgend ab. Alle 25ms wird ein Paket an der Abfolge Rot->Grün->Blau gesendet. Das für jedes Universum. Bei mehreren Universen werden die Paket direkt hinter einander versendet -> 255 in diesem Beispiel. Das geht so schnell das aus dem Rot,Grün,Blau weißer Strobe Effekt entsteht. Der zweite Controller sendet einen Plasma Effekt. Das mischt sich nach der HTP Regel(höherer Wert). Was einen klar sein muss ist das man mit 25MHZ SPI nicht in der Lage ist den gesamten Datenverkehr mit 100MBit über den W5500 auszuwerten. Der Trick besteht darin den Buffer des W5500 so groß zu machen das dass was man haben haben will nicht untergeht. Bei 3 Universen ist mit 2k Feierabend das vierte ArtDmx Paket ist bei UDP verloren da es der W5500 nicht mehr aufnehmen kann. Das mit dem ws2812 ist nur ein Nebenprodukt des Artnets. Ich brauchte etwas um zu sehen was passiert. So eine schnöde DMX Lampe wäre zu einfach gewesen ;)
:
Bearbeitet durch User
@ Marco H. wie schon geschrieben die WS Daten werden über SPI erzeugt. 8 SPI Bits = 2 WS Bits 800kHz * 4 SPI Bits = 3,2 MHz SPI Takt Ein DMA Transfer umfasst 12 Bytes = 3 WS Bytes (GRB eine LED) Sobald als möglich werden die nächste 12 Bytes berechnet und die Daten für die nächste LED über DMA ausgegeben. Das ganze funktioniert ohne Verzug. Es wird dafür ca. 20% CPU Leistung benötigt dafür kaum Speicher. Ein kompletter Transfer umfasst 240 LEDs.
@ Marco H. dein Projekt ist sehr interessant für was treibst du den Aufwand. 200Hz vs. 100Hz wird man kaum unterscheiden können. Es war von mir nie geplant den MC ArtNet tauglich zu machen. Es ging mir mehr um die Machbarkeit an sich. (MC, PC-Programm)
Die 200Hz kommen nur zu Stande wenn man die Ausgabe kontinuierlich betreibt. Dies ist ja fix durch das Datenformat gegeben. Bei dir hängen ja auch mehr LEDs im Strang. Mit DMX gehen ja bloß 170 LEDs. Das mit dem LEDs war wie gesagt nur Spielerei. Vor einen halben Jahr brachte mir ein Kollege den WS2812 Kram an. Darunter die Node vom Radig und einen aus Israel mit zig AVRs drin. Beide liefen nicht so recht. Von Radig flog regelmäßig aus der Device Liste von e:cue. Da offenbar dieser aufgrund der vielen Pakete es nicht packte auf Polls zu regieren bzw. auf diese in 2-3sec zu Antworten. So flog dieser wieder raus und er bekam keine Daten mehr. Strobe etc. war auch ziemlich mit Dropouts belegt. Manchmal flackern LEDs an einer gewissen stelle. Vermutlich weil irrend wo Daten speicher überschreiben wurden oder so. Das Problem hatte ich aber auch... Die ganze Thematik Artnet ist dort sehr einfach ausgelegt. Man muss ihm auch nicht sauer sein. Das ist auch auch gar nicht das Ziel seiner Kunden und wer möchte kann dies ja vervollständigen. Ich brauch eben eine Artnet Implementierung die sich an den Standard hält und die LEDs dienen nur als Ausgabe. Die Ansteuerung mit dem PWM Controller habe ich damals aus Interesse Programmiert. Der Kollege spendete mir seine Schnipsel :) DMX In hatte ich damals mit eingebaut und die Probleme das der Sam3x das FrameError nicht setzte. Mit SPI fällt weniger Ballast an. Das könnte man auch über die Usart des SAM3x so machen. Ich fand aber gefallen am PWM Controller und dessen Fähigkeiten per DMA das Tastverhältnis zu steuern. Jedes der einzelnen von den 24bits benötige ein 1byte großen Wert für das Tastverhältnis. Hinzu kommt mindestens 2 Reset Bits. Die sind nötig damit der Controller nicht die PWM weiter mit den letzten Wert ausgibt. Wenn man mehrere Channels nutzt müssen die Werte hintereinander angeordnet werden. Die Sache wird dann im sync Modus mit channel 0 aktiviert. Das Prinzip mit dem stückchenweise berechnen wollte ich auch aufgreifen. Die Frage die ich mir stelle ob es mir gelingt die Sachen schnelle zu berechnen wie der DMA Controller und dessen Zeiger am Ende angekommen ist. Um so kürzen die Stücke um so mehr speicher kann ich sparen. Denn das ist ja nicht das einige was noch mit laufen soll. HTTP muss ja auch noch bedient werden. Ehrlich gesagt liegt die Verlockung nahe die Node auf 8 Ports zu erweitern. Allerdings steht im Standard des jede Node seine eigene MAC besitzt. Das müsste ich erst mal prüfen wie sich der W5500 mit z.bsp Multicast IP/MAC verhält.
:
Bearbeitet durch User
Marco H. schrieb: > Jedes der einzelnen von den 24bits benötige ein 1byte großen Wert für > das Tastverhältnis. Hinzu kommt mindestens 2 Reset Bits. Die sind nötig > damit der Controller nicht die PWM weiter mit den letzten Wert ausgibt. Wie schon mehrmals erwähnt: Man kann es unnötig kompliziert machen oder man macht es so schnell und so einfach wie gerade nötig. Soviel ich da aus dem Video gesehen habe, sind es bei dir gerade mal 4 * 30 = 120 LEDs. Wenn ich das richtig gerechnet habe, sind aber bei dir dafür satte 3600 Bytes nötig. Und ausser chaotischem Blitzen habe ich da nicht viel gesehen. Da würde ich an deiner Stelle bestimmt nicht mit solchen Sprüchen um sich herumwerfen... Beim anderen Video (von Thomas F.) wird die ganze Arbeit von MADRIX geleistet - aber es ist logisch so und ergibt einen Sinn - die Flammen und die fallenden Rechtecke sind ganz nett. Und was du da mit ArtNet und DMX willst, ist mir erst recht nicht klar. Beim DMX sind etwa 44 Hz die obere Grenze. Solltest du von DMX nach ArtNet umwandeln, sieht es sogar noch schlimmer aus. Und ArtNet ist (meiner Meinung nach) nicht Echtzeitfähig, da sind die 200Hz nur Theorie und reines Wunschdenken, ausser vielleicht in einem Hausnetz und dann auch exclusive... Da habe ich mit ungefähr 3mal soviel LEDs wie du (340, um genau zu sein), Bitbanging, SD-Card mit fertigen Sequenzen und Programmauswahl per WiFi/Bluetooth etwas viel besseres, oder ? Bei 100Hz beträgt die CPU-Auslastung etwas mehr als 90%, bei 80Hz sind es etwa 75%. Mag sich nach viel Arbeit für die CPU anhören, aber das ergibt bei 100Hz alle 10ms eine Ruhezeit von etwa 1ms. Und was man noch alles in 1ms abarbeiten kann... Das alles schafft eine M328P spielend, von der Codegrösse her würde sogar M168 reichen, aber die hat nicht genügend RAM. Und mit Parallelausgabe könnte die M328P wahrscheinlich 8mal so viele LEDs schaffen (2720 LEDs) ohne übermässig ins Schwitzen zu geraten- wenn da nicht die SD-Card wäre - mit 1bit SPI kommt die M328P nicht über 300KB/s. Aber selbst wenn die M328P schwitzt - soll die ruhig, dazu sind die Dinger da...
Denkst du man mal über deine Antwort nach oder willst du nur Stimmung in manche Thread bringen ? Du Schlaumeier es ist ein Test der Frame pro Strang umfasst 170 LEDs = 1 Universum 510 Cannels (512). Mein Tisch hat nur eine endliche Größe und ich packe mir nicht aus Spaß 4 Rollen a 55€ auf den Tisch. Wenn es um die LEDs gar nicht geht... "Da habe ich mit ungefähr 3mal soviel LEDs wie du (340, um genau zu sein)" 4x 170 sind bei mir 680 ( 2048 channels im DMX)... Die Blitze sind nicht chaotisch sondern fortlaufend und ohne Aussetzer. Genau darum geht, wenn ein Frame verloren geht würde man dies optisch sofort bemerken. Normgerecht kann der Code mit mehreren IPs umgehen. Wenn ein zweiter Controller ArtDmx Pakete sendet wird das per HTP/LTP zusammengerechnet. Mach dir mal Gedanken darüber wie du die Sache synchronisierst wenn du nicht weißt wann wer was sendet und in welche Reihenfolge es kommt. Ein dritter Controller wird ignoriert, bis du ein cannelMerge sendest. Dann werden die Pakete des zweiten ignoriert bis wieder ein 3 Controller ins Spiel kommt oder der zweite 10sec keine Artdmx pakete sendet. So steht das in der Norm, hält sich nur keiner dran. Ob 50 oder 200HZ es entsteht kein Unterschied in der CPU Last da die Ausgabe per DMA erfolgt. Es steht da "Technisch" bei dem Video erfolgte die Ausgabe noch Paket gebunden. Kam ein Paket an wurde es berechnet und dann ausgeben. Das mache ich mittlerweile anders. Ich habe den Buffer des W5500 vergrößert und leere ihn in einen rutsch. Das hat den Vorteil das ich den Brust mit einmal auswerte und somit nur alle 35ms ein Frame erzeuge. Das ist aber auch nicht ideal besser wäre es eine feste Framerate ein zu richten und die optional mit dem Artsync Paketen zu synchronisieren. Das über den PWM Controller auszugeben hat technische Ursachen um verwendeten Sam3x. Dort kann man zwar auch auf die PIO per DMA zugreifen aber nur ganz weit vorne und nicht über Masken. Ich würde damit 32 Pins Platt machen und 32 Pins zu suchen die nicht mit irrend etwas belegt sind ist bei einer Arduino Hardware unmöglich. Das ist aber nicht teil des Codes, ich wollte portierbar und universell gestalten. Was man mit den Daten macht ist nicht Teil des Artnetcodes. Noch etwas "Echtzeitfähig" dann müsstest du den Ws2812 weglassen denn dieser ist nicht für Video Wände geeignet. Die vermeintlichen Geheimnisse haben wir in einen anderen Thread schon geklärt. 44 Bilder in der Sekunde reichen aus um flüssige Bilder zu erzeugen. Wenn man sich Gedanken um die Synchronisierung macht ist das für die meisten Anwendungen ausreichend.
:
Bearbeitet durch User
Marco H. schrieb: > 20161103_200153.mp4 thomas_fr schrieb: > P1020422.JPG > P1020423.JPG > P1020425.JPG Was ist eigentlich mit der Photokultur in diesem Lande passiert. Früher (tm) hätte man sich gar nicht getraut, derart technisch saumäßige Produkte überhaupt aus dem Photolabor zu lassen, sondern hätte sie direkt in die runde Ablage befördert. Anpassung von Belichtungszeit (Sensoraussteuerung, ausgebrannte Highlights) oder vernünftige Bildschärfe als (persönliche) technische Mindestanforderung vor einer Veröffentlichen scheinen völlig aus der Mode gekommen zu sein, und das in Zeiten, wo man unmittelbar nach Aufzeichnung das Ergebnis technisch bewerten kann. Marco H. schrieb: > Das so mit der Kamera festzuhalten ist immer > schwierig, in Wirklichkeit setzt es nicht aus. Da fehlen wohl eher ein paar phototechnische Grundlagen. Man muss mit seinen Werkzeugen auch umgehen können ;-( Übt mal ein bisschen mit der Kameratechnik. Mit den LEDs klappt es doch auch. Schönen Sonntag
Aber nicht bei eine primären Fremdlicht Quelle die dauert ihre Helligkeit und Farbe wechselt. Man erkennt doch was fg
> Noch etwas "Echtzeitfähig" dann müsstest du den Ws2812 weglassen denn > dieser ist nicht für Video Wände geeignet Diese Aussage ist zu pauschal: https://www.youtube.com/watch?v=8FiTcabQz1k (ab 1:25)
Noch eine Frage an thomas_fr. Wie synchronisierst du die Uhren der Nodes ? Wenn du einen Zeitstempel mit sendest müssen doch auch die Uhren der einzelne Nodes synchron gehalten werden. Ähnlich PTP ..
Marco H. schrieb: > Aber nicht bei eine primären Fremdlicht Quelle die dauert ihre > Helligkeit und Farbe wechselt. Man erkennt doch was > <Räusper> Viel mehr aber auch nicht ... Deine Kamera ist bei den leuchtenden LEDs, die eigenlich das Hauptobjekt darstellen, in allen Farbkanälen hoffnungslos übersteuert. Was neben drastischer Verkürzung der Belichtungszeit hilft, um die Spitzenlichter abzuschwächen, ist eine Verteilung des LED-Lichtes auf eine größere Fläche (Diffusor in etwas Abstand vor den LEDS, indirekte Beleuchtung einer weißen Fläche). Das reduziert dann die Dynamik im Bild. Die Hintergrundbeleuchtung kann man anheben, damit der dann nicht kohlpechrabenschwarz wird. Guck dir mal das RGB-Histogramm deiner Aufzeichnung an ;-)
Vidiantis schrieb: >> Noch etwas "Echtzeitfähig" dann müsstest du den Ws2812 weglassen denn >> dieser ist nicht für Video Wände geeignet > > Diese Aussage ist zu pauschal: > > https://www.youtube.com/watch?v=8FiTcabQz1k (ab 1:25) genau das ist es eben doch nicht. Wenn man weiß wie der ws2811 Treiber funktioniert. Man hat keine Kontrolle darüber wann der PWM wert an der LED wirksam wird. das hat jemand mit einer Kamera mit hoher Framerate eindrucksvoll bewiesen ! Das ganze läuft völlig unkontrolliert ab und damit ungeeignet für ein Video Bild.
Hallo, Thomas E. schrieb: > Der Widerstand hat schon seine Berechtigung! Hier mal eine kleine > Veranschaulichung, welches Signal der Daten-Eingangspin der LED sieht > bei einem ca. 1 Meter langen Verbindungskabel zwischen µC und LED. > 1: ohne Widerstand (vergleiche das Signal mit den "absolute Maximum > Ratings" für die Spannung am Pin im Datenblatt!) > 2: Widerstand am µC-Ausgang > 3: Widerstand an der LED. nun nimm noch folgendes mit rein (ich bin kein Simulationskünstler...): 1m WS2812-Stripe mit 60 LEDs. Netzteil am rechten Ende. 1. LED am linken Ende. LED im schnellen An-Aus-Wechsel mit voll weiß, also 60mA pro LED. Sind bei 60 LED 3,6A. Wie reagiert das Signal an der ersten LED, Daten gegen ihren GND? 2m Stripe. Speisung in der Mitte. AVR bekommt Spannung von selben Netzteil. Zuleitung zum Netzteil LED 1m 0,75. Zuleitung zum AVR sollte bei seinem Betriebsstrom keine Rolle spielen. Daten vom AVR wieder zur ersten LED. Was sieht diese zwischen DataIn und ihrem GND bei vollem Lastsprung? Für mich erscheint die Lösung, mit 3,3V für AVR/ESP per LowDrop-Regler zu erzeugen und die Betriebsspannung genau von dieser ersten LED zu holen, die mit den saubersten Potenzialverhältnissen zu sein. Das ändert sich aber wieder, wenn der AVR noch ein anderes GND-Potezieal bekommt (USB, LAN, ??). Bei WLAN mit ESP8266 escheint es mir praktisch. Gruß aus Berlin Michael
Michael U. schrieb: > zu erzeugen und die Betriebsspannung genau von dieser ersten LED zu > holen, die mit den saubersten Potenzialverhältnissen zu sein. Wie denn sonst ? Data von AVR an die erste LED, GND von AVR an die letzte LED ? Ausserdem wird die Betriebsspannung für AVR nicht von der ersten LED geholt, sondern von deinem Netzteil.
Michael U. schrieb: > nun nimm noch folgendes mit rein (ich bin kein Simulationskünstler...): > > 1m WS2812-Stripe mit 60 LEDs. Netzteil am rechten Ende. 1. LED am linken > Ende. LED im schnellen An-Aus-Wechsel mit voll weiß, also 60mA pro LED. > Sind bei 60 LED 3,6A. Wie reagiert das Signal an der ersten LED, Daten > gegen ihren GND? Um die Stromversorgung und die ggf. dabei auftretenden Verschiebungen des Bezugspotentials ging es in der Darstellung doch gar nicht (das ist eine völlig andere Baustelle!), sondern um den Zweck von Serienwiderständen in längeren Signalleitungen. Das betrifft nicht nur die Verbindung zwischen Mikrocontroller und erster LED, sondern auch die Verbindungen der LEDs untereinander, sofern da eine gewisse Leitungslänge dazwischenliegt. Wenn man denkt, bei einer langen Leitung brauche man einen "kräftigen" Treiber, um die Kapazität des Kabels zu überwinden (vielleicht gar noch mehrere Ausgänge parallel schaltet, damit der Ausgang schöne, steile Flanken schafft...), liegt man falsch und sieht sich ggf. eher mal mit einer defekten ersten LED konfrontiert.
Betreff Video Qualität. Meine einfache Kamera schafft es nicht besser. sorry Vidiantis schrieb: >> Noch etwas "Echtzeitfähig" dann müsstest du den Ws2812 weglassen denn >> dieser ist nicht für Video Wände geeignet > > Diese Aussage ist zu pauschal: > > https://www.youtube.com/watch?v=8FiTcabQz1k (ab 1:25) Sehe ich auch so, siehe Film. Marco H. schrieb: > Noch eine Frage an thomas_fr. > > Wie synchronisierst du die Uhren der Nodes ? > > Wenn du einen Zeitstempel mit sendest müssen doch auch die Uhren der > einzelne Nodes synchron gehalten werden. Ähnlich PTP .. Es wird nicht mit verteilten Uhren gearbeitet. Es wird beim senden jedes Frames zu den Nodes die vergangene Zeit zum 10ms Ereignis hinterlegt. Der Node sendet immer Verzögert die Daten zu den LEDs. z.B. 500µs (Verzögerung) - (30µs) Zeitstempel = Start Daten bei 470µs. Es wird davon ausgegangen das die Laufzeit der Telegramme zu den einzelnen Nodes gleich ist. Michael U. schrieb: > Das ändert sich aber wieder, wenn der AVR noch ein anderes GND-Potezieal > bekommt (USB, LAN, ??). Bei WLAN mit ESP8266 escheint es mir praktisch. Bei USB stimme ich dir zu. Ethernet ist an sich Potentialfrei. (Gleichstrom) Man kann auch UTP Kabel benutzen.
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.