PWM-Signal verstärken

Du hast das Symptom falsch gedeutet. Die erste LED "verstärkt" das 
Signal bereits auf 5V. Du hast sehr wahrscheinlich dein Netzteil oder 
die Leitungen überfordert. Ab einer gewissen Länge muss man 
zwischendurch zusätzlich Stromversorgung einspeisen.

Develeon64 schrieb:
> wie kann ich das PWM-Signal
> überhaupt entsprechend auf 5V verstärken?

Siehe Beitrag "Re: Esp8266 mit ca. 13 m ws2812b"

Achim M. schrieb:
> Nicht unbedingt,

Bei ihm schon, denn ein kurzer LED Streifen funktioniert ja. Also hat er 
die 3,3V kompatible Version.

Develeon64 schrieb:
> Das funktioniert auch soweit ziemlich gut, solange das Band kurz genug
> ist.

Develeon64 schrieb:
> Da ich gelesen habe, dass das Band das PWM-Signal mit 5V erwartet, das
> Pi das Signal aber nur mit 3,3V raushaut, gehe ich davon aus, dass diese
> 3,3V über die entsprechende Länge dann einfach zu schwach werden.

Setze als Pegelwandler ein 74HCTxx Gatter deiner Wahl dazwischen.

Stefan ⛄ F. schrieb:
> Bei ihm schon, denn ein kurzer LED Streifen funktioniert ja. Also hat er
> die 3,3V kompatible Version.

Gibt es dazu auch ein Datenblatt, dass das garantiert oder ist das 
einfach nur Glück?

Teo D. schrieb:
> Ab V4/5 is das Reset-Signal wirklich 50µs lang. Mehr weiß ich nich mehr.

Dein Wissen täuscht dich, zumindest wenn man den Datenblätter glaubt. 
Die sagen ganz etwas anderes.

Sowohl die WS2812B-V4 als auch die WS2812B-V5 verlangen nach einer 
Reset-Zeit von mindestens 280µs.

Als minimaler High-Pegel des Eingangssignal ist für die V4 ein Wert von 
0.7*VDD @ VDD=4.5～5.5V garantiert, was dann bei 5V einen spezifizierten 
Mindestwert von 3.5V ergibt. Damit ist diese Version nicht 3.3V 
kompatibel.

Die WS2812B-V5 ist lt. Datenblatt 3.3V kompatibel. Für diesen Typ ist 
ein minimaler High-Pegel des Eingangssignals von nur 2.7V erforderlich.

Stefan ⛄ F. schrieb:
> Bei ihm schon, denn ein kurzer LED Streifen funktioniert ja. Also hat er
> die 3,3V kompatible Version.

Das ist ein Fehlschluss.
Für die 5V-Version ist NICHT garantiert, dass sie unterhalb von 3.5V ein 
Signal nicht als High-Pegel erkennt. Vielmehr ist garantiert, dass bei 
einem Pegel von 0.7*VDD das Signal sicher als High erkannt wird. 
Darunter gibt es eine Grauzone, wo's noch funktionieren KANN oder auch 
nicht.

Leon D. schrieb:
> Dort hielt das Band für ca. 2-3 Meter, bevor es dann auf der gesamten
> Länge anfing zu flackern.

Flackern. Hmm. Ein Schaltnetzteil schaltet wegen Überlastung ab (hicup) 
und nach kurzer Zeit wieder ein ?

Leon D. schrieb:
> Mit dem neuen Netzteil auf seiner ganzen Länge von 5 Metern der Rolle.

So so, du hast also nach Fehlfunktion das Netzteil gewechselt, dann ging 
es plötzlich.

Leon D. schrieb:
> Jetzt sind es insgesamt 6 Meter, plus die Kabel"brücke", und
> interessanterweise funktioniert es jetzt nur noch auf den ersten 4
> Metern, statt wie vor der Brücke 5. Außerdem ist der Unterschied zum
> ersten Mal, dass es dann nicht auf der gesamten Länge anfängt zu
> flackern, sondern nur exakt der zweite Teil.

Das hat jetzt natürlich BESTIMMT nichts mit der Stromversorgung und 
deren schlechter Verdrahtung (nicht nur plus, sondern auch auf Masse 
fliesst Strom) zu tun.

Leon D. schrieb:
> Wie ich bereits berichtete, lief das Band zunächst auf etwa 2-3 Meter
> stabil.

> Jetzt sind es insgesamt 6 Meter... und
> interessanterweise funktioniert es jetzt nur noch auf
> den ersten 4 Metern.

Wenn der Signalpegel aus dem Mikrocontroller dein Problem wäre, würde 
gar keine LED richtig arbeiten. Jede LED liefert an ihrem Ausgang 5V 
Pegel zur jeweils nächsten LED.

Wie viele LED pro Meter hat dein LED-Streifen? Die gibt es in 
unterschiedlichen Ausführungen.

Leon D. schrieb:
> Außerdem speisen wir alle ~1,5 Meter neuen Strom ein.
Es wäre einfach mal interessant zu sehen, wie du das gelöst hast. Ein 
Foto wäre hilfreich.
Weil: Nicht nur die VCC-Leitung sondern auch die GND-Leitung müssen 
verstärkt werden und das mit einem Draht, der einiges mehr als 1.5mm² an 
Querschnitt hat. Und gerne auch öfters neu einspeisen ...

> Mit dem neuen Netzteil ...
Kann durchaus sein, die Netzteile haben eben nicht exakt 5.000V. Hat das 
neue 200mV mehr oder weniger als das alte, kann das den Effekt u.U. 
schon erklären.

Develeon64 schrieb:
> Da ich gelesen habe, dass das Band das PWM-Signal mit 5V erwartet, das
> Pi das Signal aber nur mit 3,3V raushaut, gehe ich davon aus, dass diese
> 3,3V über die entsprechende Länge dann einfach zu schwach werden.
Ja, üblicherweise wollen die WS2812 ein 5V-Signal. Wie schon gesagt 
wurde, wenn es mit einem 3.3V-Signal auch geht, ist das Zufall und du 
hattest Glück. Das kann dich aber schnell verlassen, schon bei anderen 
Temperaturen.
Die allereinfachste Abhilfe ist die Versorgung der ersten LED mit 
weniger Spannung; man nimmt gerne eine Si-Diode von VCC der zweiten LED 
zu VCC der ersten und speist die 5V erst an der zweiten LED ein. Somit 
sieht die erste nur 4.3V und die 70% VCC für den Signalpegel sind 
erfüllt. Die erste LED leuchtet trotzdem, vielleicht nur etwas dunkler. 
Ob es auffällt?

Ein weiterer Punkt ist die Signalintegrität des Datensignal. Du hast 
offenbar längere Leitungen zwischen den Abschnitten, da kann das 
Datensignal schon verfälscht werden. Ich würde als erstes am Pi-Ausgang 
und am Ausgang jedes Teilstreifens einen Serien-R mit 30-50Ω einbauen. 
Und natürlich das Datensignal schön parallel zur GND-Leitung führen.

Wolfgang schrieb:
> Für die 5V-Version ist NICHT garantiert, dass sie unterhalb von 3.5V ein Signal 
nicht als High-Pegel erkennt.

Das kommt wie gesagt auf die Revision des Chips an. In der aktuellen 
Diskussion geht es allerdings nicht um Garantien. Ein paar Meter 
funktionieren, und erst dahinter tritt das Problem auf. Dort wo das 
Problem auftritt, haben die Signale 5V. Da helfen deine Bemerkungen dem 
TO nicht, egal wie richtig sie sind.

Nachtrag:
Hast du auch mal das Timing des Datensignal nachgemessen? Der Pegel wird 
durch jede LED regeneriert, das Timing jedoch nicht. Und wenn es anfangs 
bereits grenzwertig war, kann es durchaus sein, dass sich das auch nach 
hinten verschlechtert.

By the way: Ich möchte nochmal daran erinnern, dass ich weiter oben auf 
den anderen Thread verlinkt habe wo ich einen Pegelwandler mit 1 
Transistor und die korrekte Leitungsführung der Stromversorgung 
beschrieb.

Stefan ⛄ F. schrieb:
> Siehe Beitrag "Re: Esp8266 mit ca. 13 m ws2812b"

Man darf das natürlich ignorieren und noch ein paar Ehrenrunden drehen. 
Nur darf man sich dann nicht darüber wundern oder gar beklagen, wenn es 
nicht zufriedenstellend funktioniert.

Stefan ⛄ F. schrieb:
> Das kommt wie gesagt auf die Revision des Chips an.

Nein, auch den älteren Chip-Revisionen mit U_IH min = 0.7*VDD  ist es 
nicht verboten, ein 3.3V Signal noch zu verstehen.

Stefan ⛄ F. schrieb:
> Ein paar Meter
> funktionieren, und erst dahinter tritt das Problem auf. Dort wo das
> Problem auftritt, haben die Signale 5V.

Schon ein Spannungsabfall von 100mV auf der Gnd-Leitung kann darüber 
entscheiden, ob es gerade noch so geht oder eben nicht. Und der 
Spannungsabfall auch für die 1.LED kann sich ändern, wenn die Kette 
länger wird.
Bisher kennt keiner die Verdrahtung.

Wolfgang schrieb:
> Schon ein Spannungsabfall von 100mV auf der Gnd-Leitung kann darüber
> entscheiden, ob es gerade noch so geht oder eben nicht. Und der
> Spannungsabfall auch für die 1.LED kann sich ändern, wenn die Kette
> länger wird.

Deswegen habe ich einen Pegelwandler empfohlen. Der wird aber nicht das 
vom TO gemeldete Problem lösen. Also lass uns mal auf die Frage des TO 
konzentrieren!

Wenn ich mit einem gebrochenen Bein und Schuppen auf dem Kopf ins 
Krankenhaus komme behandelt man auch zuerst das Bein, nicht die 
Schuppen.

Falk B. schrieb:
> Nö. man macht erstmal einen C****A Test! Sicher ist Sicher! ;-)

Selbst wenn der positiv ausfällt wird man trotzdem erst das Bein 
behandeln. Die Infektion wird man wahrscheinlich gar nicht behandeln 
sondern aussitzen.

Falk B. schrieb:
> ACH! Aber 5min vorher noch lauthals verkünden, daß man so eine LED mit
> 3,3V ansteuern darf . . . Mann O Mann! Such dir nen guten Therapeuten!

Was man darf, steht in den Absolute Maximum Ratings, was garantiert 
funktioniert, steht in den Electrical Characteristics.
Alles andere kann, aber muss nicht funktionieren.

Das solltest du doch wohl wissen - ist doch nicht das erste Datenblatt, 
dass dir vor die Nase kommt.

Stefan ⛄ F. schrieb:

> Deswegen habe ich einen Pegelwandler empfohlen. Der wird aber nicht das
> vom TO gemeldete Problem lösen.

Da wäre ich nicht so sicher. Der Einwurf von HildeK bezüglich des Timing 
ist nicht von der Hand zu weisen und könnte tatsächlich ebenfalls zu den 
beschriebenen Symptomen führen. Ohne selber am konkreten Objekt zu 
messen, würde ich das also keinesfalls pauschal ausschließen.

Aber klar: wahrscheinlicher ist schon eine unzureichende Versorgung, 
insbesondere eine unzureichende Masseführung.

Leon D. schrieb:

> Ich habe eine kleine Zeichnung der Verdrahtung angehängt, wie sie auch
> real vorliegt. Das ist besser, als Worte.

Jepp. Die Versorgung ist definitiv Mist. Es liegt ganz sicher daran.

c-hater schrieb:
> Die Versorgung ist definitiv Mist

Der erste grobe Fehler besteht schon darin, dass Signal und Versorgung 
durch eine gemeinsame GND Leitung laufen. Der Spannungsabfall auf der 
GND Leitung versaut dir das Signal.

Schau dir meine Zeichnung (und Erklärung) an auf die ich bereits 2x 
verwiesen habe. Dort steht, wie man es richtig macht.

Falk B. schrieb:
> Ein 5V Pegelwandler hinter dem Raspberry Pi ist sehr zu empfehlen.

Solange nicht klar ist, welche Revision der WS2812 in der Kette verbaut 
ist, ist völlig unklar, ob der nominelle Signalpegel das Problem ist.
Schaden kann es natürlich nicht.

Leon D. schrieb:
> Also, wenn ihr mehr Informationen zu etwas braucht, bin ich derjenige,
> der euch diese liefern kann. Fragt mich einfach :)

Ich hatte ein Foto vom Aufbau angefragt.

Und in der Zeichnung sind keine Leitungslängen eingetragen, nur die 
Stripe-Längen.

Läuft die Datenleitung wirklich so alleine vom zweiten zum vierten 
Strang? Man sollte die Masse hier mitführen.

Über die verwendeten Kabelquerschnitte der Versorgung hast du auch 
nichts gesagt (oder ich habe es übersehen, dann sorry).

c-hater schrieb:
> Der Einwurf von HildeK bezüglich des Timing
> ist nicht von der Hand zu weisen und könnte tatsächlich ebenfalls
> zu den beschriebenen Symptomen führen

Vermutlich meinst du diesen Einwurf:

HildeK schrieb:
> Ein weiterer Punkt ist die Signalintegrität des Datensignal. Du hast
> offenbar längere Leitungen zwischen den Abschnitten, da kann das
> Datensignal schon verfälscht werden.

Jede einzelne LED bereitet nicht nur die Signalpegel auf, sondern auch 
das Timing. Zwischen den LEDs sind laut Datenblatt bis zu 5 Meter Kabel 
ohne weitere Maßnahmen verwendbar. Ich denke, wenn man deutlich darunter 
bleibt und am Anfang der Leitung einen 100Ω Widerstand gegen Reflexionen 
einbaut, ist man auf der sicheren Seite.

Natürlich vorausgesetzt, die Stromversorgung ist in Ordnung.

Stefan ⛄ F. schrieb:
> Jede einzelne LED bereitet nicht nur die Signalpegel auf, sondern auch
> das Timing.

Den Signalpegel ja, aber das Timing? Nach welchen Vorgaben denn, es gibt 
ja keinen Takt? Wenn die Flanken verschliffen bzw. langsamer ansteigen, 
dann wird die nächste LED eben bei ihrer Schwelle schalten und so ist 
ein Verfälschen der Puls- und Pausendauern denkbar.
Oder haben die LEDs einen Taktrückgewinnung drin und machen wieder neues 
korrektes Timing? Kann ich mir nicht vorstellen.

HildeK schrieb:
> Den Signalpegel ja, aber das Timing?

Ja auch das Timing steht so im Datenblatt und auf einigen Webseiten. Das 
Signal wird mit Takt abgetastet und verzögert aufbereitet wieder 
ausgegeben.

HildeK schrieb:
> Nach welchen Vorgaben denn, es gibt ja keinen Takt?

Es gibt einen internen R/C Oszillator.

"It internal include intelligent digital port data latch and signal 
reshaping amplification drive circuit. Also include a precision internal 
oscillator"

und "After transmission for each pixel, the signal to reduce 24bit. 
pixel adopt auto reshaping transmit technology, making the pixel cascade 
number is not limited the signal transmission, only depend on the speed"

https://www.tme.eu/Document/64e8d425b90f84990264129a9679149c/WS2812B-V5.pdf

"One of the first observations was that the delay between the leading 
edge of the input pulse and the leading edge of the output pulse, 
T_delay_in_out, was constant regardless of the timing of the input 
pulse."

"An interesting observation is that the timing values for both LEDs are 
multiples of a smaller number, ~208 ns for the WS2812B and ~166 ns of 
the WS2812. It appears that the internal controller circuit is actually 
a clocked design – possibly realized by a small state machine."

https://cpldcpu.wordpress.com/2014/01/14/light_ws2812-library-v2-0-part-i-understanding-the-ws2812/#

Leider ist das Datenblatt immer noch so scheiße, dass man einige Details 
nur durch Experimentieren heraus finden kann.

Danke, Stefan F., für das Zusammentrage dieser Infos.
Aus dem Datenblatt alleine mag ich das nicht ableiten (Reshaping könnte 
auch nur die Regeneration der Pegel heißen), aber offenbar hat dieser 
Tim in seinem Blog sich das genauer angeschaut.

Trotzdem, wenn das Datensignal am Eingang schon grenzwertig war, dann 
kann auch die zeitliche Aufbereitung nicht alles lösen; schließlich muss 
das Ganze kausal bleiben. Dann könnten die im Blog ermittelten Grenzen 
verletzt worden sein.

1

A “0” can be encoded with a pulse as short as 62.5 ns, but should not be longer than ~500 ns (maximum on WS2812).

2

A “1” can be encoded with pulses almost as long as the total cycle time, but it should not be shorter than ~625 ns (minimum on WS2812B).

Recht hast du natürlich mit den Aussagen, dass die Stromversorgung und 
-verteilung sowie ggf. Reflexionen des Datensignals die Hauptprobleme 
sein dürften für den TO.

HildeK schrieb:
> Trotzdem, wenn das Datensignal am Eingang schon grenzwertig war, dann
> kann auch die zeitliche Aufbereitung nicht alles lösen;

Klar. Ich wollte nur ein paar zusätzliche Infos liefern über die ich 
heute morgen gestolpert bin als ich herausfinden wollte wie lange die 
Pausen zwischen den Impulsen mindestens sein müssen und maximal  sein 
dürfen. Die maximal Angaben im Datenblatt fand ich nämlich ziemlich 
unplausibel.

Dietrich L. schrieb:
> Nur dann könnte man schätzen, ob das Timing schon am Beginn der Kette
> knapp ist

Die Tatsache dass die ersten drei Meter tadellos funktionieren sagt mir, 
dass es mit hoher Wahrscheinlichkeit OK sein wird.

Dietrich L. schrieb:
> Nach der nächsten Stufe kann es aber verändert knapp auf der
> "schlechten" Seite liegen und dann nicht mehr stabil funktionieren.

Nein, das kann nicht sein, weil auch das Timing von jeder einzelnen LED 
aufbereitet wird. Wenn das Timing nicht in Ordnung wäre, würden die 
ersten 3 Meter auch nicht funktionieren.

Lies doch mal die Seite auf die ich verlinkt habe.
https://cpldcpu.wordpress.com/2014/01/14/light_ws2812-library-v2-0-part-i-understanding-the-ws2812/#

Jens G. schrieb:
> Vielleicht ist es ja ein TTL-Raspberry

Man kann die Ausgänge die Raspberry Pi auf ungefähr 4 Volt hochziehen, 
liegt damit aber außerhalb seiner Spezifikation.

Stefan ⛄ F. schrieb:

> Nein, das kann nicht sein, weil auch das Timing von jeder einzelnen LED
> aufbereitet wird. Wenn das Timing nicht in Ordnung wäre, würden die
> ersten 3 Meter auch nicht funktionieren.

Um das so sicher behaupten zu können, müßte man die NICHT 
dokumentierte Funktionsweise der Aufbereitung kennen.

Es könnte natürlich sein, dass du sie ausgemessen hast. Würde ich aber 
bezweifeln. Jemandem wie S. Landolt hingegen würde ich eine derartige 
Behauptung ziemlich unbesehen abkaufen. Aber auch nicht völlig 
unkritisch, denn selbst der vergißt bei seinen Bemühungen gelegentlich, 
auch die Grenzen abzuklopfen und kommt deshalb gelegentlich zu falschen 
Schlüssen.

Ich sehe das immer so: Was würde ICH machen, um die Funktion der 
Hardware möglichst billich umzusetzen. Wo würde ich sparen, wo wären 
dementsprechend die Schwachstellen. Wenn man das durchdenkt, weiss man 
schon recht gut, was genau man messen muss, wenn was nicht dokumentiert 
ist...

Dietrich L. schrieb:
> Aber ich gehe mal vom physikalischem Verständniss bei einer serielle
> Datenübertragung Typ "daisy chain" aus: jede Stufe kann zusätzliche
> Timingfehler bewirken, sodass nach x Stufen die Summer aller Fehler die
> Toleranzschwelle des nächsten Empfängers überschreitet.

Genau das ist hier nicht der Fall.

Die LEDs erkennen die Länge des Impulses am Eingang. Es gibt nur eine 
ganz simple Unterscheidung: kurz=0 und lang=1.

Am Ausgang geben sie ein neu erzeugtes Signal aus: kurz=1 Takt, lang=2 
Takte. Also liefert jede LED ein Signal mit perfektem Timing.

c-hater schrieb:
> Um das so sicher behaupten zu können, müßte man die NICHT
> dokumentierte Funktionsweise der Aufbereitung kennen.

Auch für dich gilt: Lies was auf der Seite 
https://cpldcpu.wordpress.com/2014/01/14/light_ws2812-library-v2-0-part-i-understanding-the-ws2812/# 
steht, denn genau dies hat der Mensch untersucht und dokumentiert.

Stefan ⛄ F. schrieb:
> kurz=1 Takt, lang=2

Sorry, sollte heissen:

kurz=2 Takte, lang=4 Takte

Stefan ⛄ F. schrieb:

> Am Ausgang geben sie ein neu erzeugtes Signal aus: kurz=1 Takt, lang=2
> Takte. Also liefert jede LED ein Signal mit perfektem Timing.

Jetzt ist es vollkommen klar: du bist dir der Implikationen des Problems 
überhaupt nicht bewusst. Tipp: entwerfe eine eigene Statemachine mit der 
Aufgabe, das WS2811-Protokoll bestmöglich zu recyclen (unter dem 
Umstand, selber nur einen nicht allzu hoch über dem Protokolltakt 
liegenden Systemtakt zu haben)...

Dann werden dir die Probleme wohl bewusst werden (das wiederum traue ich 
dir schon zu).

Nein c-hater, ich denke du hast die Lage nicht verstanden. Jede einzelne 
LED bereitet das Signal so auf, dass an ihrem Ausgang ein perfektes 0 
oder 1 Bit heraus kommt. Genau das steht so im Datenblatt der WS2812 und 
der Tim hat es in seinem Blog durch Messungen bestätigt.

Zum Vergleich: Nimm einen PC mit einem Programm dass die Daten con COM1 
nach COM2 durch reicht. Du kannst beliebig viele PC's miteinander 
verketten. Solange der erste PC die Eingabe richtig erkannt hat, werden 
alle Computer die Daten perfekt aufbereitet weiter reichen. Die Kette 
kann beliebig lang werden.

c-hater schrieb:
> entwerfe eine eigene Statemachine mit der
> Aufgabe, das WS2811-Protokoll bestmöglich zu recyclen

Leis noch mal die Seite. Genau das hat er dort beschrieben. Seine WS2812 
hat offenbar einen Taktgeber mit 208 ns. Wenn das Eingangssignal kürzer 
als 3 Takte ist wird es als 0 Bit gewertet. Wenn es länger als 3 Takte 
ist wird es als 1 Bit gewertet.

Ausgangsseitig wird das kurze Bit mit 2 Takten ausgegeben und das lange 
Bit mit 4 Takten. Beides ist ist der nächsten LED wieder eindeutig mit 3 
Takten vergleichbar.

Stefan ⛄ F. schrieb:

> Nein c-hater, ich denke du hast die Lage nicht verstanden. Jede einzelne
> LED bereitet das Signal so auf, dass an ihrem Ausgang ein perfektes 0
> oder 1 Bit heraus kommt.

Du hast es nicht verstanden: Das Problem ist: inwiefern kann sie das?

Doch natürlich bestenfalls mit der Auflösung ihres eigenen Taktes! Und 
der ist SCHEISSE. Relativ gering bezüglich des Protokolltaktes und 
obendrein nicht besonders stabil. RC-Oszi halt.

c-hater schrieb:
> Doch natürlich bestenfalls mit der Auflösung ihres eigenen Taktes! Und
> der ist SCHEISSE.

Ist er nicht. Nochmal zum mitmeißeln:

Am Eingang wird ein Impuls als kurz (0) gewertet wenn er weniger als 3 
Takte lang ist. Ansonsten ist es ein langer (1) Impuls.

Am Ausgang hat ein kurzer Impuls 2 Takte und ein langer Impuls 4 Takte.

Selbst wenn ein R/C Oszillator 20% Abweichung zur vorherigen LED hätte, 
könnte er das Signal immer noch einwandfrei erkennen und weiter geben.

Der nächste der behauptet, die LED's würde das Signal ohne neuen Takt 
durch reichen und Fehler aufaddieren möge das bitte mit Messprotokollen 
belegen!

Stefan ⛄ F. schrieb:

> Ist er nicht. Nochmal zum mitmeißeln:

Du bist wirklich zum Scheißen zu blöd, selbst mit freundlicher 
Nachhilfe.

Tip: Jedes einzelne WS28xx-Teil hat seinen eigenen Takt, der in keinster 
Weise mit dem seiner Nachbarn synchronisiert ist. Begreifst du es (mit 
dieser schon etwas unfreundlicheren Nachhilfe) endlich?

Bin gespannt...

Lieber c-hater, wenn dir die Argumente ausgehen beleidigst du. Muss das 
sein?

Ich habe meine Annahmen mit dem Datenblatt und Verweisen auf Tims 
Messprotokolle belegt.

Du hast deine anderen Vermutungen hingegen nicht belegt. Du hast auch 
weder zu meinen noch zu den Aussagen von Tim einen Widerspruch im 
Datenblatt aufgezeigt.

c-hater schrieb:
> Jedes einzelne WS28xx-Teil hat seinen eigenen Takt, der in keinster
> Weise mit dem seiner Nachbarn synchronisiert ist.

Na und? Das tut nichts zur Sache, außer dass die Abweichung der 
Taktfrequenzen in gewissen Grenzen bleiben muss, die sehr leicht 
einzuhalten sind, wie ich aufzeigte.

Das ganze Internet basiert übrigens auch auf asynchroner Taktung. Nach 
deiner Logik kann das Internet nicht funktionieren, tut es aber.

Stefanus hat schon recht: jede LED bereitet das Signal so auf, dass die 
folgende es sicher erkennen kann - die Toleranzen des eigenen und 
nächsten Taktgenerators sind im Timing berücksichtigt.

Das einzig kumulierende ist die Verzögerung der steigenden Flanke - jede 
LED erhöht sie um einen konstanten Wert.  Ich sehe aber nicht, wie das 
zu einem Fehler führen kann.

Falk schrieb:
> Das könnte man messen, indem man die Eingangspulse verändert und dabei
> die Ausgangspulse beobachtet.

Genau das hat der ja in dem verlinkten Artikel gemacht.

Extra für dich c-hater:

Nehmen wir mal an, die erste LED hätte 208 ns Takte, dann ist deren 
Schwelle zwischen 0 und 1 Bits genau 624 ns.

Nun speise die Lichterkette mit dem schlechtesten Signal dass weit 
außerhalb der Spezifikation ist dennoch so gerade eben erkannt wird:

0 Bits mit 623 ns Länge  (das DB erlaubt 250 ... 550)
1 Bits mit 625 ns Länge  (das DB erlaubt 650 ... 950)

Dann wird diese erste LED (wie beim TO) korrekt aufleuchten. An ihrem 
Ausgang kommt folgendes Timing heraus:

0 Bits mit 416 ns Länge  (das DB erlaubt 250 ... 550)
1 Bits mit 832 ns Länge  (das DB erlaubt 650 ... 950)

Das Signal wurde durch die erste LED erheblich verbessert. Da ist kein 
Fehler, der sich aufaddiert hat.

Nun stellen wir uns einfach mal vor, die nächste LED hätte einen 20% 
langsameren Takt von 250 ns. Die Schwelle ist dann 750 ns.

416 ns ist viel kürzer als 750 ns, also eindeutig ein 0 Bit.
832 ns ist deutlich länger als 750 ns, also eindeutig ein 1 Bit.

Sie liefert an ihrem Ausgang das aufbereitete Signal:

0 Bits mit 500 ns Länge  (das DB erlaubt 250 ... 550)
1 Bits mit 1000 ns Länge (das DB erlaubt 650 ... 950) Hoppla, diese LED 
erfüllt nicht mehr die Spec, sie funktioniert trotzdem!

Nun stellen wir uns vor, die nächste LED hätte einen 25% schnelleren 
Takt (relativ zu der davor), also 188 ns. Die Schwelle ist dann 564 ns.

500 ns ist kürzer als 564 ns, also eindeutig ein 0 Bit.
1000 ns ist viel länger als 564 ns, also eindeutig ein 1 Bit.

Sie liefert an ihrem Ausgang das aufbereitete Signal:

0 Bits mit 376 ns Länge (das DB erlaubt 250 ... 550)
1 Bits mit 752 ns Länge (das DB erlaubt 650 ... 950)

Obwohl ich in diesem Szenario eine LED verwendet habe, die sogar 
außerhalb der Spec liegt, funktioniert die LED Kette noch und liefert an 
ihrem Ausgang ein taldelloses Signal für weitere WS2812 Leuchtdioden.

Ich beziehe mich hier auf dieses Datenblatt: 
http://www.world-semi.com/solution/details-140-4.html

foobar schrieb:
> Das einzig kumulierende ist die Verzögerung der steigenden
> Flanke - jede LED erhöht sie um einen konstanten Wert.

Entsprechend dem Satz im Datenblatt "the pixel cascade
number is not limited the signal transmission, only depend on the speed"

Dietrich L. schrieb:
> Aber ich gehe mal vom physikalischem Verständniss bei einer serielle
> Datenübertragung Typ "daisy chain" aus: jede Stufe kann zusätzliche
> Timingfehler bewirken, sodass nach x Stufen die Summer aller Fehler die
> Toleranzschwelle des nächsten Empfängers überschreitet.

Nicht, wenn das Signal beim Einlesen auf einen Taktgenerator 
synchronisiert wird und damit auch die Flankenlagen regeneriert werden.

Mir ist da übrigens eine Unstimmigkeit aufgefallen bei T1H aufgefallen. 
Ich habe im Netz erheblich unterschiedliche Angaben gefunden, siehe 
angehängte Screenshots.

Nun hat der Tim ermittelt, dass seine WS2812B mindestens 625 ns 
benötigt, was im Rahmen der damals aktuellen Dokumentation liegt.

Aber im Datenblatt v5 steht 580 ns, das ist weit von den bisherigen 
Angaben entfernt. Es gibt ein Migrations-Dokument das scheinbar alle 
Unterschiede zwischen v5 und vorherigen Versionen auflistet. Von einem 
geänderten Timing steht darin aber nichts.

Kann es sein, dass im Datenblatt v5 ein Zahlendreher passiert ist: 580 
versus 850? Was meint ihr dazu?

Ich würde das ja gerne selbst ausmessen, aber mir fehlt das nötige 
Equipment, und ich habe auch nur die älteren Versionen des Chips 
vorliegen.

Hast du meinen obigen Vermerk zum möglichen Zahlendreher gesehen? Wenn 
es kein Zahlendreher ist, muss sich die Abtastmethode bei der Version 5 
fundamental geändert haben.