zwei Fragen zu MAtrix mit LED-Streifen; Spannungsversorgung, Datenleitung

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.

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 ?

Welche?

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

Wilhelm M. schrieb:
> Welche?

>> und vor allem alle 5 LEDs einen Abblockkondensator 100nF.

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.

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...

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.

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 ;)

@ 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.

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.

Aber nicht bei eine primären Fremdlicht Quelle die dauert ihre 
Helligkeit und Farbe wechselt. Man erkennt doch was fg

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 ..

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.