WS2801 (LED Strip) blinkt ab 34. LED

jntme · April 11, 2017 at 15:08

Hallo zusammen

Wir haben bei uns das Blinkenlights Kit, welches die WS2801 LED Pixel mitliefert (https://www.tinkerforge.com/de/doc/Hardware/Bricklets/LED_Strip.html#led-pixel).

Über Masterbrick und LED Strip Bricklet angesteuert, funktioniert das ganze bis zum 33 LED super, aber ab dort blinken alle LEDs, auch wenn das Signal eigentlich steady wäre.. Kann mir da jemand helfen?

Vielen Dank!

borg · April 12, 2017 at 13:13

Oh, das klingt so als wäre ein Pixel in einem der Bündel defekt.

Kannst du zum Testen versuchen an dem letzten Pixel der nicht funktioniert und an dem erste der funktioniert zu wackeln? Hinten an den Kabeln zupfen und zur Seite ziehen und so. Funktioniert es dann zwischendurch?

Zum testen könntet ihr das Bricklet auch an das Zweite Bündel anschließen, funktionieren dann die restlichen 200 LEDs wie erwartet?

jntme · April 12, 2017 at 13:27

Hi borg - merci für den Tipp.

Leider funktionierts immernoch nicht.

Inzwischen habe ich beinahe alles probiert.

Update:

Sämtliche LEDs ab einem bestimmten Punkt blinken – der Punkt ändert je nach Port des Masterbricks wo der LED Bricklet eingesteckt ist.

Master Brick LEDBricklet, Kabel und USB wurden getauscht.

Wir haben zwei verschiedene Netzteile und verschiedene PCs (Macbook und PC) probiert.

Wir testen mit BrickViewer und eigenen (mit Python geschriebenen) Programmen mit und ohne Callback.

die Firmwareversionen:

Master Brick 2.1: v2.4.3

LED Strip Bricklet: v2.0.6

Ich bin echt ratlos.

borg · April 12, 2017 at 13:46

Der Punkt ändert sich je nach Port des Master Bricks? Dann kann es ja kein Wackelkontakt in den Pixeln sein!

Was hast du im Brick Viewer genau eingestellt?

jntme · April 12, 2017 at 14:09

-> siehe Bild

Mit dieser Einstellung teste ich gerade, ich habe das Problem mit 200 Pixeln mit der LED Pixel Kette sowie mit WS2812B LED Steifen - an beiden Ketten beginnt der 114. Pixel zu blinken, bis 113 'steht' die Farbe, wie es sein sollte.

batti · April 12, 2017 at 20:23

Hallo jntme,

sehr eigenartig. Ich habe aktuell auch keine Idee.

Bei Anschluss an Port A ist es dass 114. Pixel. Wie sieht es bei Anschluss an den anderen Ports aus? (Ist da irgendein Muster zu erkennen?)

Das blinkende Pixel ist auch reproduzierbar? (Wenn du A,B,C,D getestet hast und gehst dann wieder zurück zu A).

jntme · April 18, 2017 at 13:15

Hi Leute

Jetzt funktionierts. Es scheint, als gäbs einen Fehler in der neusten Firmwareversion des Masterbricks (2.1). Wir haben von 2.4.3 zu 2.4.2 gedowngradet und jetzt funktionierts wie erwartet. Das LED-Bricklet ist nach wie vor auf dem neusten Firmware-Stand.

Sehr interessantes Verhalten - evt. kann das jmd. von Tinkerforge nachstellen.

Vielen Dank auf jedenfall für eure Hilfe!

borg · April 18, 2017 at 15:57

Oh? Das muss ich definitiv versuchen nachzustellen. Hab mir gerade die Codeänderungen durchgeguckt die es zwischen den Firmware Versionen gab und kann nichts relevantes finden .

Quantasy · April 29, 2017 at 12:26

Ich kann das bestätigen... Nach dem Update meiner Master-Bricks (2.1) auf 2.4.3 fingen die SK6812 (RGBW) an zu flackern.

Bin nun wieder auf 2.4.2 zurück und das Flackern hat aufgehört.

Das Ganze ist gut reproduzierbar...

Ich habe auch in einem Stack ein Master auf 2.4.3 und einen auf 2.4.2 gebracht.

Die LEDStrips am LEDStripBricklet (1.0) 2.0.6 flickern nur dort wo sie am Master mit 2.4.3 hängen.

Loetkolben · May 9, 2017 at 10:33

Hmmm.

Nur meine Info dazu: Habe hier einen Stack aus 2*Master 2.0 (2.4.3) mit 1 LEDStrip Bricklet (2.0.6) mit 13 WS2812 LEDs seit Wochen am laufen. Keine Auffaelligkeiten.

Der Loetkolben

Quantasy · June 24, 2017 at 22:43

Mal eine Frage zum Status: Macht ihr da noch was, oder sitzt ihr das Problem einfach aus?

Es ist immer noch so, dass die Master (v2.0 und v2.1) Firmware 2.4.0 die letzte Firmware ist, bei der das LED-Bricklet (v1.0 und v1.1) (Firmware 2.0.6) noch korrekt läuft.

Ab der Version und auch mit der aktuellen 2.4.4 Version

läuft die LED-Bricklet nicht korrekt:

Ich habe das soeben wieder bitter erfahren müssen:

150 LEDs 2801

Bei Firmware 2.0.6 an Port D:

Blau (der erste Kanal) geht durchwegs... aber es flickert manchmal die 81. LED

Grün/Rot (die zwei anderen Kanäle) gehen nur bis zur 30. LED

Sieht aus wie ein Wackelkontakt... oder ein paar kaputte 2801er...

ABER

Flashed man die 2.4.0 Firmware auf das Master dann geht alles genau so wie es soll.

Flashed man wieder die 2.4.4 Firmware drauf... Symptom wie oben beschrieben.

Bitte: Testet das bei Euch mal mit 100 LEDs!

Wichtig: Es nutzt nix, 50 dran zu hängen... und zu probieren. Auch dann nicht, wenn ihr einfach rein schreibt, es seien 200 dran, obwohl nur echte 50 angesteuert werden.

Der Fehler zeigt sich erst, wenn ihr echte 100 LEDs oder mehr ansteuert.

Es ist garantiert ein Tinkerforge Bug! Und sehr wahrscheinlich schreibt irgend was 'von links' ins Memory auf dem Master!

Falls euch zum Testen das Material fehlt (200 x 2801/2811/2812), kann ich euch auch gerne beliebige flickernde Setups (mit absolut frischem Master auf 2.4.4 geflashed und LEDBricklet 2.0.6) zur Verfügung stellen! Sagt was ihr braucht...

(Korrigiert... Master Brick Firmware 2.4.4 nicht 2.6.0)

Loetkolben · June 25, 2017 at 11:16

Nur mal eine Idee von einem Aussenstehenden:

Kann es sich (auch) um ein Problem in der Spannungsversorgung handeln? Warum:

Auch wenn ein Timing- bzw. Programmaenderung zwischen der 2.4.0 und der spaeteren FW stattgefunden hat, ist es vielleicht auch moeglich, dass es nur bei dir wegen unpassender Stromversorgung auftritt? Soll heissen: Das Timing ist trotz Aenderung immernoch innerhalb der Spezifikationen, aber durch was auch immer, zeigen sich bei dir nun ein Fehler.

Loesung waere, dass TF das Timing wieder wie in bis FW 2.4.0 einbaut oder du nochmals bei dir die HW ueberpruefst. (Elkos oder allgemeine Kapazitaeten, die das Signal unnoetigerweise verschleifen?)

Sind alle deine Streifen von gleichen Hersteller, bzw. mit LEDs vom gleichen Hersteller bestueckt?

Ich will die hier nichts schoenreden, sondern noch mal einen Gedanken zur Loesung beitragen. Ich gehe jetzt Glaskugel putzen.

Der Loetkolben

HerrB92 · June 25, 2017 at 13:50

Liebe Mitstreiter,

ich kann Quantasy's Vermutung bestätigen: Mit Master Brick Firmware V2.4.4 gibt es kreative Probleme mit dem LED Bricklet und signifikant vielen LEDs. Diese verschwinden mit Downgrade auf Firmware V2.4.2.

Getestet wurde mit dem aktuellsten Brick Viewer für Windows (Remote PC) und zum Schluss mit dem aktuellsten Brick Viewer für Linux (Raspberry PI). Das Verhalten war immer identisch. Ausgehend von einer LED wurde die Anzahl der LEDs im Brickviewer schrittweise erhöht.

Aufgetretene Effekte (lokaler Brickviewer auf dem Raspberry):

Mit 255,0,0 ergeben sich bis zur 33. LED blaue LEDs, ab der 34. LED blau blinkende LEDs bis zur 80. LED (dazwischen gibt es sogar einen Übergang zweier LED-Ketten-Abschnitte, d.h. es ist nicht abhängig von einer Kette), danach sind die LEDs wieder konstant blau.

D.h.:
1 - 33: blau, 34 - 80: blinkend blau, danach blau

Stellt man auf 255,255,255 bleiben die bisher blinkenden LEDs dunkel.
Bei 255,255,255 ergibt sich außerdem der Effekt, dass bis zur Anzahl von 5 LEDs alle LEDs weiß sind. Mit 6 LEDs wird die 5. LED grün und die 6. rot (d.h. die Aktivierung der Folge-LED beeinflusst den Vorgänger). Wird die Anzahl weiter gesteigert, tritt der Effekt nochmal wieder nach dem Dunkel-Fenster auf.

D.h.:
1 - 4: weiß, 5: grün, 6: rot, 7 - 33: weiß, 34 - 80: dunkel, 81 - 84: weiß, 85: grün, 86: rot, danach weiß

Info zu Farbschema: Die Einstellung Color 255,0,0 führt bei mir zu:

Linux/Raspberry [brockviewer bietet kein alternatives Mappping]: blau
Windows [Mapping RGB]: rot

Hardware (Testaufbau):

Master Brick V2.1, V2.4.2: Raspberry & LED-Bricklet mit 110 RGB LEDs (WS2801)
Master Brick V2.0, V2.4.4
Master Brick V2.0, V2.4.4

Die zusätzlichen Master Bricks werden (später) nur aufgrund der hohen Anzahl der LEDs benötigt. Ich habe sie zum Test noch nicht downgegradet, das war für das Ergebnis nicht erforderlich.

Mit Firmware V2.4.2 treten die Effekte nicht auf, mit V2.4.4 kommen sie reproduzierbar wieder.

Liebe Grüße,

HerrB92

P.S.: Nur für die Glaskugel: Die Spannungsversorgung kann ich ausschließen: Mehrfacheinspeisung mit einem Einbaunetzteil mit bis zu 10A. ;-)

Quantasy · June 25, 2017 at 15:17

Hallo HerrB92: Tolles Testsetup, danke für die Rückendeckung

Zu den Fragen von @Loetkolben: Stimmt, dazu habe ich ja gar nix geschrieben.

Es sind allesamt die 'Pixelbündel', welche ich von Tinkerforge bezogen habe.

Sie werden mit einer 100W/5V Quelle gespiesen. Jeweils Anfang- und Ende einer 50er Kette... genau so, wie es bei Tinkerforge in der Doku gezeichnet ist:

https://www.tinkerforge.com/de/doc/_images/Bricklets/bricklet_led_strip_pixel_wiring_1500.jpg

Die ganze Kette beginnt just nach dem LED-Bricklet, also keine lange Leitung für Clock und Data... und somit auch keine Kondensatoren dazwischen.

Das läuft absolut perfekt... bis Firmware 2.4.0. (Dass die 2.4.2 auch noch funzt wusste ich gar nicht.)

Es sieht nur im ersten Augenblick wie ein 'flackern' oder Wackelkontakt aus... Mit der Zeit merkt man aber, dass egal welchen LED-Strang man dran tut, das ganze sehr präzise reproduzierbar ist, also immer die genau gleichen LED-positionen flackern... Sofern das LED-Bricklet am gleichen Port bleibt.

Es ist wirklich fast sicher auszuschliessen, dass es ein externes Problem ist. Irgendwas schreibt ins Memory sobald das LED-Bricklet mehr als das übliche Memory (?240bytes?) benötigt.

Am Clock kann es nicht liegen, da auch 2811/2812er etc. betroffen sind.

Vielleicht nutzt das Master das restliche scheinbar ungebrauchte Memory... wenn da keine wieteren Bricklets dran hängen?

Es muss ein fieser Bug sein, der sich da eingeschlichen hat.

borg · June 25, 2017 at 22:26

Danke für die ausführlichen Tests! Ich werde morgen nochmal versuchen das nachzustellen, hoffentlich kann ich es reproduzieren .

borg · June 26, 2017 at 08:47

Oh, in der Tat. Das Problem ist sogar recht offensichtlich, warum auch immer ich das vorher nicht gesehen hab.

Das Problem ist, dass das LED Strip Bricklet den RAM von nicht-genutzten Bricklets mitnutzen kann.

Mit den neuen Co-Prozessor Bricklets gibt es folgende Vorgehensweise: Wir gucken erst ob ein EEPROM angeschlossen ist und dieses eine UID/device identifier beinhaltet (d.h. es ist ein altes Bricklet). Falls das nicht der Fall ist gehen wir davon aus des es sich um ein Co-Prozessor Bricklet handelt. In diesem Fall wird das ganze dann dynamisch gemacht.

Das LED Strip Bricklet guckt allerdings nur einmal ganz am Anfang welchen RAM es nutzen kann. Dadurch überschreibt der Code zum Handling der Co-Prozessor Bricklets dann die Daten des LED Strip Bricklets.

Soweit zum Problem, eine Lösung muss ich mir jetzt noch einfallen lassen .

borg · June 26, 2017 at 12:47

Die einzige Möglichkeit die ich sehe das zu fixen ist, die Erkennung wie viel RAM das LED Strip Bricklet verwenden kann auch dynamisch zu machen.

Das Timeout an der Stelle ist 2 Sekunden, d.h. wenn mehr als 80 RGB LEDs angesteuert werden sollen, muss jetzt nach dem ersten Enumerate erst 2 Sekunden gewartet werden.

Im Anhang ist eine Firmware die das implementiert, könnt ihr das einmal testen?

master-brick-v2.4.5-beta2.bin

HerrB92 · June 26, 2017 at 19:38

Hi Borg,

die gute Nachricht: Die LEDs funktionieren ohne funky Effekte. Die schlechte: Ab der 81. LED bleiben sie dunkel und reagieren gar nicht mehr (ich vermute, dass die Ermittlung des RAM über mehr als einen Master Brick nicht funktioniert).

Bei der Hardware noch eine Korrektur:

Master Brick V2.1, V2.4.5: Raspberry & C: LED-Bricklet mit 110 RGB LEDs (WS2801)
Master Brick V2.0, V2.4.5: B: Piezo Speaker
Master Brick V2.0, V2.4.5

Liebe Grüße,

HerrB92

borg · June 26, 2017 at 19:49

Oh man, ich befürchte das ich die falsche .bin hochgeladen hab. Ich bin mir sicher das ich es mit 240 LEDs getestet hab, allerdings hatte ich zwischendurch eine Version wo nur die ersten 80 funktioniert haben .

Ich komm jetzt von hier gerade nicht an den Sourcecode, ich lade direkt morgen früh das korrekte .bin hoch.

HerrB92 · June 26, 2017 at 20:20

Ok, danke, keine Hektik. Vor morgen Abend kann zumindest ich es ohnehin nicht testen...

By the way: Gibt es einen einfacheren Weg, als jedesmal den USB-Anschluss von Brick zu Brick zu wechseln und den jeweiligen Brick in den seriellen Modus zu versetzen, um die Firmware einzuspielen? ;-)

Gruß,

HerrB92

borg · June 26, 2017 at 20:26

Gibt es einen einfacheren Weg, als jedesmal den USB-Anschluss von Brick zu Brick zu wechseln und den jeweiligen Brick in den seriellen Modus zu versetzen, um die Firmware einzuspielen?

Leider nicht, der Bootloader-Modus ist Teil des Microcontrollers (sam3s) und wird nicht von uns gesteuert.

borg · June 27, 2017 at 07:57

So jetzt aber .

master-brick-v2.4.5-beta3.bin

HerrB92 · June 27, 2017 at 20:38

Success! 354 LEDs an zwei LED-Bricklets funktionieren, wie sie sollen. Wunnebar!

Hardware:

Master Brick V2.1, V2.4.5: Raspberry & C: LED-Bricklet mit 204 RGB LEDs (WS2801)
Master Brick V2.0, V2.4.5: B: Piezo Speaker
Master Brick V2.0, V2.4.5: A: LED-Bricklet mit 150 RGB LEDs

Case closed.

Liebe Grüße,

HerrB92

Anmelden

WS2801 (LED Strip) blinkt ab 34. LED

Recommended Posts

jntme

borg

jntme

borg

jntme

batti

jntme

borg

Quantasy

Loetkolben

Quantasy

Loetkolben

HerrB92

Quantasy

borg

borg

borg

HerrB92

borg

HerrB92

borg

borg

HerrB92

Join the conversation

Umsehen

Aktivitäten