WS2812B manche LEDs zeigen falsche Farben

Hast du GND vom Controller und den LEDs verbunden?

Vermutlich sind die betroffenen LEDs defekt. WS2812 sind nicht gerade 
für ihre zuverlässigkeit bekannt.

Hi,

ich habe jetzt auch mal eine LED getauscht, keine Änderung...

ebenso ist natürlich der Controller mit GND verbunden :)

versuche gerade noch einen ESP8266 (reicht mir aber von der Leistung 
vermutlich nicht aus... werden am ende, einige tausend LEDs

ingo schrieb:
> ebenso ist natürlich der Controller mit GND verbunden :)

Der Controller und die LEDs müssen aber eine gemeine Masse haben.

Guest schrieb:
> WS2812 sind nicht gerade für ihre zuverlässigkeit bekannt

Billige Ausrede für das eigene Unvermögen bei Handhabung und 
Beschaltung.

phul schrieb:
> Billige Ausrede für das eigene Unvermögen bei Handhabung und
> Beschaltung.

Wenn du das sagst, du musst es ja wissen als absoluter Profie. Dann frag 
ich mich ob die gefühlt 1000 Leute die hier im Formum schon probleme 
hatten alle zu dumm sind eine scheiß LED zu benutzen. Was will man da 
bitte groß falsch machen?

ich hab jetzt erstmal einen Streifen mit 144LEDs WS2812B hingehangen <- 
die sehen exakt gleich aus, haben auch 4 Pins und einen Kondensator pro 
LED.

hier habe ich das selbe Problem, d.h. ich mach irgendwas mit dem ESP23 
falsch.
Ich programmiere mit der ARDUINO IDE und das "ESP32 DEV MODULE" 
ausgewählt. Firefrog ist genau das gleiche in grün.

mit dem ESP2866 habe ich gerade noch USB-Probleme, hier wird der CH340 
Treiber nicht erkannt (hier also noch keine Infos)



PS. das mit der Masse... jaja, Grundsätzlich geht der Controller ja, ich 
kann ja jede erdenkliche Farbe auf 135 LEDs schreiben, nur ein paar 
zeigen was anderes an.

Das mit der Stromversorgung ist ganz einfach.
Ich habe ein 5V - 20A Netzteil, welches sowohl den Controller, alsauch 
die LEDs versorgt.

Aber auch wenn ich nur über USB vom PC versorge (was ja gut reicht um 
mal 10 LEDs auf voller Helligkeit zu betreiben) habe ich den selben 
Fehler.

Guest schrieb:
> Was will man da bitte groß falsch machen?

Ne Menge, ist eben nicht nur eine "scheiß LED" sondern ein IC. Wenn die 
Tatsache, dass viele Leute Probleme damit haben bedeutet, dass das 
Bauteil unzuverlässig ist, dann ist auch jeder Transistor und jeder 
555-Timer "unzuverlässig".

Guest schrieb:
> Wenn du das sagst, du musst es ja wissen als absoluter Profie

Auch ich hatte und habe meine Probleme damit, aber ich akzeptiere, dass 
das an mir liegt und nicht am Bauteil und habe daher wenigstens eine 
Chance den Fehler zu finden und zu beseitigen.

Wenn mich das zu einem Profi macht, bitte.

phul schrieb:
> ne Menge, ist eben nicht nur eine "scheiß LED" sondern ein IC

Wow du brauchst einen Ablockkondensator und das wars. Sinnigerweise 
etwas ESD und Überspannungsschutz am Anfang des Streifens. Dass die 
WS2812 sehr empfindlich gegenüber Temperatur sind und auch gerne mal die 
Bonddrähte kaputt gehen ist halt eine Tatsache. Ich benutze diese LEDs 
relativ viel und bin mittlerweile mit sonst gleicher Beschaltung auf 
sk6812 gewechselt. Von denen ist mir noch keine einzige kaputt gegangen, 
während die WS2812 reihenweise ohne Grund kaputt gegangen sind.

Hi,

naja, es kann nicht am GND liegen, wenn ich mit einer komplett anderen 
LED-Kette das selbe Problem habe...

SOOOO:
ESP8266 läuft und das auch Fehlerfrei. D.h. es liegt am Controller.

Aber hat noch nie jemand mit einem ESP32, WS2812B mit der Adafruit 
Library betrieben? <- das glaub ich kaum...

Ich habe jetzt 3 Versuchsaufbaus <- immer das selbe Program:

1

#include <Adafruit_NeoPixel.h>

2

3

#include <Adafruit_NeoPixel.h>

4

#ifdef __AVR__

5

  #include <avr/power.h>

6

#endif

7

8

9

#define PIN  13 //am ESP8266 ist es D4

10

#define PIX  140

11

#define DELAYVAL 5

12

13

Adafruit_NeoPixel pixels = Adafruit_NeoPixel(PIX, PIN, NEO_GRB + NEO_KHZ800);

14

15

16

void setup() {

17

  #if defined(__AVR_ATtiny85__) && (F_CPU == 16000000)

18

    clock_prescale_set(clock_div_1);

19

  #endif

20

21

  Serial.begin(115200);

22

  Serial.println(13);

23

24

  pixels.begin(); 

25

}

26

27

void loop() {

28

    pixels.clear();

29

30

  for(int i=0; i<PIX; i++) {

31

    Serial.println(i);

32

    pixels.setPixelColor(i, pixels.Color(0, 150, 0));

33

    pixels.show();

34

    delay(DELAYVAL);

35

    pixels.setPixelColor(i, pixels.Color(0, 0, 0));

36

    pixels.show();

37

  }

38

39

40

}

1. ESP32 (der erste), mit meinen zusammengelöteten LED Strecken
2. ESP32 (ein neuer), mit einem vorhandenen 1m Streifen (mit 144 LEDs)
3. ESP8266, mit sowohl meinem selbst gelöteten als auch mit dem 
LED-Streifen...

ESP32 arbeitet nicht wie er soll.

gemacht habe ich:
ich habe an allen 3 Controllern einen Stecker gelötet welcher mit PIN13 
/ bzw. D4 verbunden, sowie VIN / 5V und GND.

PS. evtl. machen diejenigen dich sich streiten wollen wer jetzt mehr 
recht hat einen eigenen Thread auf??? Das wäre mega lieb von euch.

ingo schrieb:
> ESP32 arbeitet nicht wie er soll.

Evtl. hierzu eine genauere Definition:
Die LEDs werden wie gewünscht angezeigt, allerdings werden bei ein paar 
wenigen noch andere Farben angezeigt, wenn dann nun die Grüne LED kommt, 
kommt es zu einem Mix (z.B. aus Grün und Blau und es wird Türkis 
angezeigt)

NEO_KHZ800 & NEO_KHZ400 ändern im übrigen auch nichts...

ingo schrieb:
> Auch 100NF zwischen DI und GND bringen nichts.

Der DIN einer WS2812B ist ein DATENEINGANG, der nominell mit 800kHz 
läuft.
Was willst du da mit 100nF.

Nimm den Jörg ernst.
Die Leitungsführung kann hier eine ganz entscheidende Rolle spielen.

Zeige mal Fotos, wo man die Stromversorgungs-Leitungen vom Netzteil zum 
ES und dem LED Streifen sehen kann. Und zwar die ganzen Leitungen bitte, 
nicht nur die Lötstellen und Stecker.

Dann wären noch die technischen Daten des Netzteils von Interesse, am 
Besten das Datenblatt.

Hast Du mal mit dem Oszilloskop die Signale kontrolliert? Ich kenne die 
verwendeten Bibliotheken nicht, aber könnte es sein, dass ein Interrupt 
- z.B. von der seriellen Kommunikation- das Timing der LEDs 
durcheinanderbringt?

Ich habe gerade mal in den Quelltext der Adafruit_NeoPixel Bibliothek 
geschaut. Da wird das Timing mit blockierenden Warteschleifen erzeugt. 
Das ist schon ein grobes No-Go. Wer das Programmiert hat, kann nur ein 
sehr naiver Anfänger gewesen sein:

1

for(...) 

2

{

3

    ...

4

    // Bit high duration

5

    while(((c = _getCycleCount()) - startTime) < period); // Wait for bit start

6

    GPIO_REG_WRITE(GPIO_OUT_W1TS_ADDRESS, pinMask);       // Set high

7

    startTime = c;                                        // Save start time

8

    while(((c = _getCycleCount()) - startTime) < t);      // Wait high duration

9

    GPIO_REG_WRITE(GPIO_OUT_W1TC_ADDRESS, pinMask);       // Set low

10

    ...

11

  }

12

  while((_getCycleCount() - startTime) < period); // Wait for last bit

13

}

Zwei Probleme sehe ich hier:

1) Wie Mike schon richtig vermutete, werden Interrupts diesen Ablauf 
unterbrechen und damit das Timing versauen.
2) Wenn man zwischen den Ausgaben nicht genug Zeit für die Behandlung 
der WLAN Kommunikation durch die Kern-Firmware reserviert, wird der Chip 
abstürzen.

Ich sehe nur bei dem 2-Kern Modellen des ESP32 eine Chance, dass das so 
funktionieren kann. Es gibt aber eine andere Bibliothek, die das Signal 
mit Hilfe von DMA und der I²S Schnittstelle erzeugt. Das scheint mir ein 
besseres Konzept zu sein.

Hier beschreibt einer das Problem im Detail und beleuchtet 
unterschiedliche Lösungsansätze: 
http://marc.merlins.org/perso/arduino/post_2017-04-03_Arduino-328P-Uno-Teensy3_1-ESP8266-ESP32-IR-and-Neopixels.html

Unabhängig davon empfehle ich trotzdem, die Stromversorgung zu prüfen. 
Diese ist sowohl bei ESP Modulen als auch bei LED-Streifen generell ein 
problematisches Thema (außer für erfahrene alte Hasen). Wenn schon die 
Stromversorgung schlecht ist, kann die Software das nicht mehr retten.

Stefan ⛄ F. schrieb:
> Da wird das Timing mit blockierenden Warteschleifen erzeugt.
> Das ist schon ein grobes No-Go. Wer das Programmiert hat, kann nur ein
> sehr naiver Anfänger gewesen sein:
Unfug.
Wie will man sonst das Timing einhalten?
(ok, es mag noch andere Möglichkeiten geben, aber die sind ungleich 
aufwändiger)


Bei den WSxxxx und ESP kommt das Problem hinzu, dass die 3,3V des 
Datenausgangs nicht für die WS reichen müssen.
Schaut man sich die Pegel im WS Datenblatt an, sind die 3,3V schon mehr 
als grenzwertig.

Arduino Fanboy D. schrieb:
> Unfug. Wie will man sonst das Timing einhalten?

Habe ich geschrieben: Indem man DMA und I²S kombiniert verwendet.

Sind die Streifen zufällig über den ESP versorgt? also Netzteil an ESP 
und von ESP an die Streifen?

Damit hatte ich des öfteren Probleme.

Letztlich sieht meine Verkabelung immer so aus das Streifen wie ESP mit 
Extra Leitung (der Streifen dicker) versorgt werden und vom Controller 
nur der Datapin zum Streifen geht.

ingo schrieb:
> Evtl. hierzu eine genauere Definition:
> Die LEDs werden wie gewünscht angezeigt, allerdings werden bei ein paar
> wenigen noch andere Farben angezeigt, wenn dann nun die Grüne LED kommt,
> kommt es zu einem Mix (z.B. aus Grün und Blau und es wird Türkis
> angezeigt)

Immer an der gleichen Stelle oder willkürlich?

Frank M. schrieb:
> Bei den WS2812-Streifen fällt über die gesamte Strecke wegen der dünnen
> Leiterbahnen die Spannung ab. Schon nach einem Meter ist die anfängliche
> Spannung von 5V (nachmessen!) weiter unter 5V abgefallen.
>
> Abhilfe: Die 5V alle 50cm neu einspeisen.

meine SK6812 RGBW sind in Einheiten zu 50cm, 1m und 1.5m im Treppenhaus 
angebracht und jeweils am Anfang und Ende eingespeist (ab 1m Länge) und 
funktionieren so erst problemfrei.

Der Spannungsfall über den Streifen hinweg ist in der Tat nicht zu 
unterschätzen. Auch die Zuleitung spielt da noch mit.

Sind im Treppenhaus ins UG die kompletten 5m auf RGB Weiß 
(255,255,255,0) zieht der Streifen (SK6812 RGBW 60LED/m) gute 11A. Bei 
voller Helligkeit des weißen Chips (0,0,0,255) sind es immerhin 8,4A.

Hi,

die Spannungsversorgung ist mit 1qmm an dem Stecker welcher auch die 
LEDs versorgt, die 5V, GND und Datenleitung geht dann direkt in den ESP.

Das mit den 3.3V (und das es knapp wird) habe ich in einem anderen Forum 
auch schon gelesen, also habe ich noch (am ESP32) einen Pegelshifter von 
3.3 auf 5V eingebaut.

Aber nur nochmal zur Erklärung:
am ESP8266 funktioniert alles PERFEKT ohne falschfarbige LEDs, ohne 
blinken ohne alles (sowohl am Teststreifen, alsauch an meinem 
Versuchsaufbau).
am ESP32 funktioniert es nicht. Also muss es am Controller oder am Pegel 
liegen und NICHT an der Spannungsversorgung, ausreichend Strom oder an 
den Lötstellen.

ebenso habe ich ja 2 ESP32 mit 2 komplett unterschiedlichen Kabeln, 
Netzteilen und WS2812B Strecken aufgebaut, sollte es an Strom, 
Wackelkontakt oder Lötstelle liegen, hätte man nicht exakt den selben 
Fehler: die 13. LED leutet ein wenig Rot, die 33. LED Grün, 46. Grün, 
und die 65. leicht blau (alle flackern etwas)... (es sind noch ein paar 
mehr).

bezüglich des Timings / Delay...
> euch ist schon klar, dass dies hier "Testcode" ist!?

Zum testen ob die Hardware funktioniert verwende ich Minimalistischen 
Code.

und zur Stromversorgung. der Teststreifen hat 1m und nur eine 
Versorgung, mein Eigenbau wird alle 60cm versorgt und hat bereits nach 
13 LEDs ein Problem <- tut aber nichts zur Sache, weil es ja mit dem 
ESP8266 perfekt funktioniert.

Frank M. schrieb:
> Bei den WS2812-Streifen fällt über die gesamte Strecke wegen der dünnen
> Leiterbahnen die Spannung ab. Schon nach einem Meter ist die anfängliche
> Spannung von 5V (nachmessen!) weiter unter 5V abgefallen.

Dann ist der Streifen falsch angeschlossen.
Um allen LEDs eine gleiche Betriebsspannung zur Verfügung zu stellen, 
müssen Gnd und DIN am einen Ende des Streifens angeschlossen sein und 
die 5V am anderen.

ingo schrieb:
> Aber nur nochmal zur Erklärung:
> am ESP8266 funktioniert alles PERFEKT ohne falschfarbige LEDs, ohne
> blinken ohne alles (sowohl am Teststreifen, alsauch an meinem
> Versuchsaufbau).
> am ESP32 funktioniert es nicht.

Dann hast du ein Problem mit den Tasks, die sonst noch so auf dem ESP32 
laufen. Hast du dir das Signal mal mit einem LA genau angesehen?

Joachim B. schrieb:
> Wie ist der maximale Highpegel aus einem ESP32?

Du meinst sicher den minimal zugesicherten HIGH Pegel.

und nochmal (einfach weil ich's erst 3 Mal geschrieben habe)

die LEDs sind nicht kaputt, weil ich 1. schon eine getauscht habe, und 
2. eine ganz andere Teststrecke mit dem selben Problem habe.

aber das mit den Tasks ist ein guter Hinweis, das schau mal ich mir Mal 
an...

ach Leute... das mit dem Strom ist doch völlig egal, wenn ich 2 oder 3 
grüne LEDs betreibe.

@Jörg R.

> Tschüss und viel Erfolg bei der weiteren Fehlersuche.
Dankeschön :) - und danke für die Mühe.

@Rest:
Ich habe nun mal alle LEDs angeschlossen, interessanterweise hat sich 
ein "Muster" Herauskristallisiert. (siehe Anhang)

Du hast um Hilfe gebeten, weil du den Fehler nicht alleine finden 
konntest. Ich denke, dass kluge Menschen nicht an ungesicherten Annahmen 
festhalten, sondern sich vergewissern. Ausserdem nehmen kluge Menschen 
Ratschläge an.

Wenn bei dir alles in Ordnung wäre, würde es funktionieren. Da sind wir 
uns doch einig, oder nicht?

ingo schrieb:
> siehe Anhang

Abblockkondensatoren für jede einzelne WS2812 sind auf dem LED-Streifen 
drauf?

@Marc V.:
habe ich schon gemacht, ändert nichts, zeigt das ganze in langsamer an, 
auch das Flickern der "Muster" ist genau gleich nur langsamer (nicht 
verschoben oder besser).

@Wolfgang:
ja, die Kondensatoren sind vorhanden...


im Anhang mit einem ESP8266 <- der Stripe und die Spannungsversorgung 
ist in Ordnung (meiner Meinung).
Ich habe noch einen 2. ESP32 mit einem Pegelshift, da sieht das Muster 
genau gleich aus wie bei einem ESP32 ohne Pegelshift.

1

[...] ist ein Interrupt-Problem. Hat aber nichts mit dem Pin zu tun.

2

3

Nutze einfach die aktuelle FastLED-Lib. Die macht die Ausgabe über die RMT-Hardware (Remote Control des ESP32). Die benutze ich auch.

4

https://github.com/FastLED/FastLED

https://forum.arduino.cc/index.php?topic=632122.0


Würde auch zu
Beitrag "Re: WS2812B manche LEDs zeigen falsche Farben"

passen...