Beiträge von Pesi

Das ist mir auch schon aufgefallen, habe dafür aber keine Admin-Rechte… müsste der Tristan sich drum kümmern. Würde diese Pinnwand einfach deaktivieren, das braucht ja wirklich keiner…

uaaah, Anleitungen bei YT, stundenlang jemandem beim frickeln zugucken, und irgendwann kommt der Schaltplan...

Des Rätsels Lösung ist ganz einfach: Der BT136 ist ein Triac - d.h., der wird einmal gezündet, und bleibt so lange an, wie Spannung anliegt.

Deswegen funktioniert das bei dem mit Wechselstrom auch, da kommt ja immer ne Nullstelle, wo der wieder gelöscht wird - bei Dir mit Gleichstrom aber nicht, da bleibt der eben an.

Du musst also nen MOSFET oder fetten Transistor nehmen. Z.B. sowas wie IRLZ34 oder IRLZ44 o.ä.

Das finde ich auch grenzwertig, dass man solche Videos überhaupt online stellen darf - der fummelt da auf diesem Sensor rum, und 5 mm daneben liegt an unisolierten Drähten die volle Netzspannung an...

verlinke doch mal so eine Anleitung… evtl. kann man die ja umbauen auf nen dicken MOSFET…

genau, einfach ein kleiner Brückengleichrichter (wenn es flimmern darf, reicht auch eine Diode), an den Ausgang parallel ein kleiner Kondi (würde mal 1 Mikrofarad probieren), und da dran dann die LED mit Vorwiderstand. Den halt entsprechend ausrechnen, erst mal mit nem größeren Wert probieren. Wenn‘s zu dunkel ist, dann den nächst kleineren probieren.

Durch das Gleichrichten und den Kondi erhöht sich die Spannung um den Faktor 1,44 - das dabei berücksichtigen…

Ich hab' den Fehler gefunden - hat gerade mal drei Minuten gedauert...

Es liegt tatsächlich an der Konfiguration des Players - ich hab' einfach mal ne tpm2-Datei mit weiß drin auf die Karte, tatsächlich bleiben die weißen Pixel dunkel...

noch mal in's Manual geguckt: Da ist standardmäßig RGB-LEDs eingestellt, aber auch der RGBWMODE = 1 - also weiß als 4. Kanal (den's bei RGB natürlich nicht gibt) umrechnen. _CONFIG_-Datei mit RGBWMODE = 0 auf die Karte, und schon geht's:

Das ist natürlich ungünstig - der technische Laie macht da halt erst mal seine tpm2-Dateien auf die Karte, und wundert sich (oder, je nach Animation/Programm vielleicht auch nicht), warum da kein weiß kommt.

Kann mir jetzt nur vorstellen, dass er bei Dir die _CONFIG_ nicht gelesen hat, evtl. ist da noch ".txt" hinten dran gestanden...?

Ich schreib' denen jetzt gleich mal, dass die das ändern sollen, also default-mäßig ne sinnvolle Kombination von LEDTYPE und RGBWMODE drin steht, damit das auch ohne config-Datei funktioniert - und dass die vielleicht auch mit .txt hinten dran eingelesen wird... die sind recht fix, meine gewünschte Änderung im Manual war hier auch schon in der gedruckten Version drin!

Ansonsten super Teil! - Sehr cool finde ich die Funktion, dass man verschiedene Dateien per Taster abrufen kann... ich baue gerade so eine 48 x 8-Pixel-Laufschrift (6 m x 1 m), da kommt das dann hin, und man kann einfach per Knopfdruck verschiedene Texte abrufen - einem Kumpel habe ich letztes WE LED-Stripes in seine alten Rasterleuchten eingebaut:

Da kommt dann auch so ein Teil hin, kann er per Knopfdruck verschiedene Animationen auswählen... für die paar Piepen fang' ich da echt nicht das selber basteln an...

P.S.: Die Daten dafür kommen dann natürlich von Jinx! - habe mal mit dem Hexeditor geguckt, da liegt das Problem nicht, weiß ist da weiß in der Datei...

Hier mal der Thread zur Vorgänger-Matrix, da ist das Prinzip auch schon so: RGB-Lichterketten-Matrix mit WS2801

Wenn Interesse an der SW besteht, kann ich die bei Gelegenheit mal hier rein stellen - ist aber Assembler…

Ah, noch was: Es könnte ja auch sein, dass der Controller da oben drin das aufteilt, und an 20 Ketten parallel ausgibt - mache ich bei meinen selbst gebauten Controllern auch so (Code ist irgendwo im Forum).

Z.B. hier:

Das sind auch nur 36 Ketten, die runter hängen, da geht auch keine Leitung wieder nach oben oder von Kette zu Kette…

EDIT: Ah, noch was: Bei dem Preis für das Dings braucht man eigentlich gar nicht mehr mit selbst basteln anzufangen…

Noch mal EDIT: Sorry, unkonzentriert! 🤪 - Du hattest ja geschrieben, dass Du ne andere Größe brauchst… und ja, da wird wohl genau so was drin sein (wie meine Controller), das eben an Kette 1 die Daten für LED 1-20 ausgibt, an Kette 2 die Daten für LED 21-40, usw.

Es gibt tatsächlich so LED-Ketten, bei denen die Adressen fest „einprogrammiert“ sind - siehe dazu diesen Thread hier: WS2812 (SK6812) LED in Reihe Probleme

Weiter runter scrollen, da kommt dann die Erklärung/Auflösung, wie das raus gefunden wurde…

Ich hatte mich damals gefragt, warum zur Hölle jemand sowas baut, aber hier wäre dann die Erklärung: Damit könnte man so einen Baum sternförmig verkabeln, und trotzdem alle LEDs einzeln ansprechen… bei den Verlinkten Ketten geht‘s halt nur von 1 bis 100, k.A., ob‘s da noch welche mit mehr Einzel-Adressen gibt…

Ah, nachdem ich nun den Thread noch mal gelesen habe (das Phänomen interessiert mich wirklich, in der Glotze kommt auch nix... ) bin ich noch verwirrter... Du schreibst oben (Post #4):

"Vom Config-Eintrag "LEDBITS" ist da keine Rede. Woher soll man das dann wissen? Einen Hellseher beauftragen?"

Hast aber am Samstag schon im Jinx!-Thread RE: Jinx! - LED Matrix Control ... und die nächste Matrix Software ... geschrieben:

"

Meine _CONFIG_ sieht so aus:

AUTOSTART=1

LEDCOUNT=256

BRIGHT=100

LEDTYPE=GRB

LEDBITS=8

RGBWMODE=2

SAVE

"

Wie bist Du denn da dann auf die LEDBITS gekommen, mit ner Glaskugel...?!

Ich kenn' mich da irgendwie langsam nicht mehr aus, was da nun Sache ist...?!?

Wir drehen uns hier irgendwie im Kreis...

Ich habe das so verstanden, dass der Mau eben genau *nicht* einen 4. Kanal braucht, weil er normale RGB-Pixel hat (WS2812B, auch wenn das *immer noch nicht wirklich bestätigt ist*) - also hilft es ihm auch nix, das mit diesem Tool umzurechnen. Und genau das, was das Tool macht, macht der Player ja intern (wenn er so eingestellt ist, was aber natürlich bei WS2812B nix bringt, weil die ja nur RGB.....)

Aber, trotzdem guter Hinweis: Der Mau könnte mal die von Jinx! ausgegebene Datei mit diesem Tool einlesen, und dann schauen, ob hier die Pixel richtig dargestellt werden.

Das (Zitat Mau) "Darin die Farben" verstehe ich nicht ganz: Sind die Farben so im GIF, oder in der .tp2-Datei...? - Wenn sie im GIF so sind, müssen sie nicht zwingend in der tpm2-Datei so sein, *falls* z.B. Jinx! da Probleme beim Umrechnen hat. Deswegen, wie gesagt, das Angebot, dass Du mal so ne tpm2-Datei hier rein stellst, und ich schaue mir (oder Du selbst kanst das ja auch machen) mit nem Hexeditor an, was da drin ist...

Ansonsten, wie gesagt, wenn Du schon so ne Unsumme für das Teil ausgegeben hast, doch einfach mal dem Support schreiben: info äd diamex bunkt de - die sind echt nett und schnell, habe denen gestern wegen eines Fehlers im Manual geschrieben, und paar Stunden drauf schon ne Antwort mit der Änderung bekommen...

Wie schon gesagt, evtl. hast Du ja einfach nen fehlerhaften Player bekommen, und dann bringt's natürlich nix, da Stunden weiter nach dem Problem zu forschen. Sowas habe ich in der Arbeit auch immer wieder, man sucht und wundert sich, warum läuft die Sch**e nicht wie sie soll, ist doch alles richtig konfiguriert - und am Ende stellt sich raus, dass schlicht und einfach das neue Gerät ab Werk defekt ist...

Weil, wie auch schon wiederholt gesagt, das kann nicht sein, dass das grundsätzlich nicht möglich ist, mit diesem Player weiß auszugeben. Da hätte man sicher schon diverse Male was dazu in diversen Foren etc. gelesen. Du bist jetzt tatsächlich hier im Forum (kannst gerne über die Suchfunktion nachprüfen) der Erste, der dieses Problem hat...

Ah, OK, Verwirrung... - oben hast Du den S3 (OHNE E) verlinkt, da hab' ich das Manual runter geladen, da gibt's diese Angaben mit LEDBITS usw. - Beim S3E haben sie wirklich die Keywords geändert.

Noch mal wegen der LEDs: Auf dem Foto kann man halt auch nicht erkennen, ob das nun wirklich WS2812B sind oder was anderes. Entweder Makro-Foto, auf dem man sieht, wie viele Chips da drin sind, oder, wie gesagt, Link zum Produkt...

Weil hier auch Verwirrung: Du schrobst ja von "versucht, die Farbe Weiß noch mit drei verschiedenen LEDs darzustellen, statt wie heute üblich, mit einer einzigen?" und im anderen Thread von "modernen Stripes" - hört sich für mich danach an, dass Du welche mit 4 Chips (also RGB und noch mal extra weiß) meinst - WS2812B haben nur RGB - aber ohne zu wissen, *was das denn nun genau ist*, wird man schlecht weiter kommen.

Wenn das normale WS2812B sind, dann kann es unmöglich sein, dass man die nicht mit diesem Player ansteuern kann. Da hätten ja schon x Kunden denen das um die Ohren gehauen und sich in div. Foren beschwert...

Vielleicht liegt der Fehler ja auch ganz woanders... also dass es in der tpm2-Datei schon falsch drin ist... wenn Du da mal eine machen kannst (oder mehrere) mit je einem Frame alle LEDs rot, alle grün, alle blau, alle weiß, dann könnte man sich das mal angucken, ob da die Farben richtig drin sind... wie sieht es denn aus, wenn Du eins der internen Programme des Players abspielst, ist denn da weiß mit dabei?

Ach, und, ich bleibe dabei: natürlich ist es *für Dich* billiger, nen Arduino zu kaufen und was drauf zu kloppen - Aber DU musst auch nix mit dem Verkauf von sowas verdienen. Der Hersteller schon. Und der bietet dafür dann auch Support. Das kannst Du auch noch probieren, einfach mal da zu fragen, was da nun los ist... vielleicht hast Du ja auch nur leider ein "Montagsgerät" bekommen... Ich wundere mich immer bisschen über diese Mentalität in deutschen Foren, dass man fertig für den technischen Laien verkaufte Komplettgeräte preislich mit was selbst zusammen geschustertem vergleicht. Und wenn man das dann da schon "teuer" kauft, dann nicht mal beim Hersteller fragt (der im Gegensatz zum Arduino-Chinesen auch nen deutschen AP hat), sondern in irgendnem Forum...

Wenn's mit dem Teil bei Dir gar nicht klappt, dann schick' es doch zurück, und bau das schnell selbst mit dem Arduino und dem SD-Reader... bevor Du noch mehr Zeit damit verschwendest, und dann hast Du auch noch 16,75 Euro gespart...

Nee, steht doch da (auf der von Mau verlinkten Seite) in der Beschreibung: "- Unterstützt RGB und RGBW-Leuchtdioden (z.B. SK6812)" - und im Manual https://www.led-genial.de/medi…nstiges/led-player_s3.pdf auch noch mal.

Zum Thema "dass dieser Player völlig veraltet ist, und versucht, die Farbe Weiß noch mit drei verschiedenen LEDs darzustellen, statt wie heute üblich, mit einer einzigen?" - das ist auch heute noch völlig üblich, auf einer Matrix weiß aus RGB gemischt darzustellen. Mir ist auch kein professionelles LED-Panel bekannt, das für weiß einen extra Chip drin hat. Das mit der 4. Farbe (weiß) bei "Digitalen LEDs" ist nur deswegen aufgekommen, damit man diese Stripes außer buntibunti auch für Beleuchtung einsetzen kann - auf ner Matrix für Bilder o.ä. ergibt das eigentlich keinen Sinn...

Was sind das nun genau für LEDs, haben die ne 4. Farbe (also extra weiß)...? - Du schreibst WS2812B, die haben aber immer nur RGB (siehe cdn-shop.adafruit.com/datasheets/WS2812B.pdf) - hast Du mal nen Link? - Die Chinesen verbauen oft was anderes, schreiben dann im Titel aber trotzdem "WS2812B", damit das in der Suche auftaucht, weil der Begriff einfach am bekanntesten ist.

Wenn es wirklich RGBW-LEDs sind, dann musst Du das dem Player auch sagen, damit er 4 Byte pro Pixel ausgibt. Das Manual (lohnt sich immer, so was zu lesen) wurde ja schon erwähnt, da findest Du die Angaben...

Tipp: Du schreibst im anderen Thread, Du hast eingestellt:

LEDBITS=8
RGBWMODE=2

Beide Werte gibt es lt. Manual nicht, LEDBITS muss 24 oder 32 (naa, klingelt was...? ) sein, und RGBWMODE 0 oder 1... LEDCOLORS dient dann wie gesagt nur dem Umsortieren der Farben, auch hier hilft es nix, einfach mal irgendwas rein zu schreiben (GRBW / RGBW ist kein gültiger Wert... auch LEDTYPE kommt in der Liste nicht vor, siehe S.9)

Ach, und zu "happigen Preis von 30 Ocken" (anderer Thread): Könntest _Du_ das billiger herstellen, und dann auch noch mit Gewinn verkaufen...?

Zum 2. Problem kann ich nix sagen, kenne diesen Player nicht… Evtl. hat es was mit diesem RGBWMODE=2 zu tun…? Dass der eben für RGBW-Pixel ist, also da dann das weiß nicht aus RGB gemischt wird, sondern auf dem 4. Kanal ausgegeben, wodurch dann RGB-Pixel natürlich schwarz bleiben…

Das 1. ist kein Bug, sondern logisch: Diese Angaben bewirken ja, dass Jinx! bzw. der Player die Farben umsortieren. Wenn Du nun bei beiden GRB einstellst, dann sortiert Jinx! die Farben um, so dass sie für Deine Matrix passen… der Player sortiert dann noch mal um, also passt es am Schluß wieder nicht mehr. Deswegen nur an einer Stelle umsortieren.

Ich mache das bei meinen selbstgebastelten Controllern immer so, dass der Controller umsortiert… dann kann ich in Jinx! Immer RGB einstellen, und muss nicht bei jeder Matrix/Stripe etc. überlegen, was ich da nun wieder einstellen muss… 😉

Das geht, und zwar mit Relais. Wenn ich das richtig verstehe, dass normal 2 so LED-Panels in Reihe an einer KSQ hängen, dann würde die Schaltung so aussehen:

Es leuchtet immer nur das/die Panel, bei dem/denen das Relais offen ist, das also nicht überbrückt ist. Hier im Beispiel Gruppe 1. Gruppe 2 und 3 sind für die KSQ "nicht vorhanden", weil sie ja überbrückt sind, also so, wie wenn die Leitung da direkt zurück gehen würde zur KSQ.

Was passieren kann:

- Alle Relais sind geschlossen, dann hast Du einen Kurzschluß an der KSQ - das ist normal aber nicht so schlimm, wenn es nicht gerade ein super-Billo-Schrottteil ist, macht der das nix, ist kurzschlußfest.

- Zwei oder alle Relais sind offen - dann hängen mehr als 2 Panels in Reihe an der KSQ. Dann fährt die die Spannung hoch, weil sie ja den Strom durchtreiben will. Wenn dann wieder nur 1 Panel aktiviert wird, bekommt das für einen kurzen Moment zu hohe Spannung, und kann defekt werden.

Verhindern kann man das mit der Ansteuer-Logik. Wie geht das überhaupt, über nen Arduino, oder RasPi oder so? - Ich würde da noch ein 4. Relais auf der Primär-Seite der KSQ anbringen. Dann die Programmierung so, dass erst die KSQ stromlos gemacht wird, kurz warten, die Einstellungen für die Panels ändern (also dass halt die leuchten, die dran sind), und dann wieder Strom ran an die KSQ...

Weil man ja manchmal was übersieht: Stimmen denn Net, Subnet und Universe (Bei den Artnet-Einstellungen....)? - Manche SW fangen hier bei 1 zu zählen an, manche bei 0 - hatte sowas auch schon mal mit Jinx! und vvvv, da lag's dann daran...

Ja, stell' den Code doch mal rein, ist bestimmt interessant.

Bei Ethernet ist es so, dass ein Datenframe (außer Du benutzt "Jumbo Frames", das muss der Switch aber können) max. ca. 1400irgendwas Bytes Nutzdaten übertragen kann. Ansonsten wird das Paket fragmentiert, das muss dann auch wieder Netzwerkkarte, Switch und Empfänger können...

Deswegen klar: (Zitat) "Alles als ein Block übertragen mit den 43200 Kanälen scheint aber nicht zu klappen." - so ein Riesenframe geht bestimmt nicht durch... - dafür gibt es eben diese Aufteilung auf mehrere Blocks, damit die Frames klein genug bleiben. Jinx! ist hier sehr komfortabel, mit der automatischen Aufteilung und patchen über ein Device. Prinzipiell sollte das auch möglich sein*, das z.B. bei Artnet auch automatisch so zu machen, also z.B. statt dass Du 10 Artnet-Devices patcht, gibt es nur eins, und die Ausgaberoutine teilt das selbst in versch. Universes auf...

*damit meine ich, man könnte das wohl so programmieren, hat Sven aber nicht gemacht, ist da bei Artnet halt auch nicht üblich...

Du kannst dann auch das

#define UDP_TX_PACKET_MAX_SIZE 50000

wieder runter setzen, weil das ist ja Verschwendung, so große Frames werden da nie ankommen...

Das (Zitat) "Um 1024 channels/block kommen die Daten interessanterweise am schnellsten durch (dauert ca. 3,5ms). Kürzere oder längere packets machen es langsamer."

kann ich mir auch so erklären: Wenn Jinx! die Daten auf mehr Blöcke aufteilen, und mehr Ethernet-Frames verschicken muss, dauert das natürlich länger, als wenn es nur "ein paar" Frames sind... dass es bei größeren Paketen langsamer wird, liegt dann wohl irgendwie an Netzwerkkarte/Switch, dass die evtl. irgendwie Probleme bekommen, wenn man mit der Framegröße an's Maximum geht...

(Zitat) "Damit Jinx! 1024 channels sendet, muss ich dort übrigens 1023 einstellen... hat mich ne Zeit gekostet, das zu checken." - 1024 lässt sich nicht durch drei teilen... - ich vermute, dass Jinx! nicht RGB eines Pixels über mehre Blöcke verteilen kann... deswegen 1023, das sind glatt durch drei dann 341 Pixel...

btw., ich habe noch nie ausgerechnet, wie viele Pixel man eigentlich über tpm2.net übertragen kann... - bei Frames mit 1023 Bytes, also je 341 Pixel, wären das dann (bei max. 255 Blöcken) 86.955 Pixel - also genug für den Teensy

Ach, guck' mal, gerade erst unter dem anderen Artikel entdeckt: https://www.amazon.de/dp/B088K1JH6X

Kostet bisschen mehr, die Alitove war so bei 24 Euro, aber wie gesagt, mit BTF auch gute Erfahrungen gemacht... natürlich alles ohne Garantie, ich weiß nicht, wie diese Matrix ist, und China-Zeug bestellen ist ja generell immer so'n bisschen wie Lotterie...

Ich habe gute Erfahrungen mit der hier gemacht: https://www.amazon.de/gp/product/B01JYLZWPI - so 10 Stück als "Türschilder" verbaut, die alle noch laufen. Aktuell aber leider nicht verfügbar. Kannst ja mal googlen, ob es von der Marke auf Ebay oder sonstwo was gibt.

Ansonsten habe ich auch gute Erfahrungen mit Produkten (hier Pixel-Ketten) von BTF-Lighting gemacht, aber k.A., ob die sowas haben... einfach mal bei Ebay schauen...

Ansonsten, k.A. wo Du das Ding her hast, aber evtl. halt einfach mal Pech mit nem Montagsprodukt gehabt, und wenn Du da noch eins bestellst, funktioniert es besser...(?)

Vorab: Bist Du wegen der Größe sicher, oder ist das ein Vertipper...? - ich kann in Jinx! maximal 480 Pixel in einer Dimension anlegen, also 12x1200 geht bei mir nicht...

Mich hat das interessiert, also ob Sven das richtig implementiert hat mit dem tpm2net - hat er!

Also von dem her ginge es, nur ein Output Device anlegen mit 43.200 Channels, z.B. auf 36 Blocks verteilt á 1.200 Byte, dann passt das gut in einen normalen Ethernet-Frame. Und dann einfach per "fast patch" alle Pixel in einem Rutsch patchen... ich hab' das mal mit 120 x 120 ausprobiert, und im Wireshark nachgeguckt: Jinx! teilt die Daten dann automatisch auf 36 Blöcke auf und zählt den Index hoch...

Ich kenn' mich mit Teensy nicht aus, programmiert man da in C...? - landet jeder empfangene Ethernet-Frame in einem Buffer...?

selbst habe ich früher Byte für Byte (bei "normalem" tpm2) empfangen und in Assembler ausgewertet, inzwischen habe ich auch eine tpm2.net-Empfangsroutine für Arduino/ESP8266 - die funktioniert im Prinzip so:

Ein Frame wurde empfangen und liegt im Buffer - dann parse ich den:

- ist das erste Byte 0x9C (Startbyte) und das zweite 0xDA (Frametyp: Daten)? - wenn nicht, Frame verwerfen
- Ansonsten Byte 3 (Hi-Byte) und 4 (Low-Byte) raus ziehen, daraus die Nutzdatenmenge errechnen
- Dann an der entsprechenden Stelle (Nutzdatenmenge+6) nachschauen, ob da das Blockende-Byte 0x36 steht - wenn nicht, Frame verwerfen
- Ansonsten ist der Frame gültig, Byte 7-n weiter verarbeiten.

Das ist jetzt die simple Version, ohne Aufteilung auf mehrere Blöcke. Die brauchst Du aber, also musst Du noch nachschauen:
- Byte 4: Paket (Block)nummer
- Byte 5: Gesamtzahl der Pakete (Blöcke)

und dann halt die Daten an die entsprechende Stelle (ausrechnen anhand Blocknummer und Framegröße) in deinem Arbeitspuffer schreiben. Das wäre die Luxus/ordentlich-Variante, die für (fast, die Blöcke müssen alle gleich groß sein) beliebige Werte funktioniert...

Was Du bei Dir vereinfachen kannst, wenn der Teensy fest ne Matrix mit 14.400 Pixeln bedienen soll, und die Aufteilung immer 36 Blöcke á 1.200 Byte ist:

- 9C, DA, Framegröße und Blockende-Byte gar nicht auswerten. Es schickt ja nur Jinx! auf den Teensy (davon gehe ich mal aus...), also muss das ein tpm2.net-Frame sein, und der wird schon passen (wenn nicht, flackert's/ruckelt's so und so...)
- nur die Block-Nummer auswerten, und die Bytes dann an die entsprechende Stelle in den Zwischenpuffer kopieren. Also Block 1 ist Byte 1 bis 1.200, Block 2 ist 1.201 bis 2.400, usw.
- Wenn Du Block 36 empfangen hast, ist das Bild komplett, ausgeben an die Matrix.

weiß nicht, ob Du das so auf Teensy umsetzen kannst...? - ich kann den Arduino-Code auch rein stellen bei Bedarf, aber der ist wie gesagt ohne Auswertung der Block-Nummer... das sollte aber noch easy rein zu machen sein...

mehr Infos auch auf http://www.tpm2.de

Für mich hört sich das an, als ob da (mindestens) eine LED kaputt ist. Ab der geht dann natürlich kein Signal weiter... Also insb., dass der Teil mal kurz aufgeleuchtet hat und dann nix mehr ging, klingt stark danach.

Kann auch ne schlechte Lötstelle sein, insb. wenn es so ne flexible Platine ist. Schau doch mal bei der esten LED, die NICHT leuchtet, ob da ein Pin ab ist oder sowas. Oder bei der davor, dass da das Signal schon nicht weiter geht.

Auch mal probieren: Auf die erste LED, die nicht leuchtet, sanft drauf drücken. Hatte ich auch schon mal, dass da drin ein Bonddraht ab war, durch leichtes Drücken auf die LED hat sie wieder kontaktiert...

Im Prinzip kannst Du dann diese defekte (und weitere, falls noch weiter hinten welche sind) LED dann austauschen... oder gleich ne komplette neue Matrix kaufen, soo viel kosten die ja nicht...

Interessante Zusatzinfo: Kann dann gut sein, dass Du wirklich ne Matrix mit WS2812B bekommen hast. Habe mich neulich mit nem Freund drüber unterhalten, der war früher auch hier im Forum aktiv, und hat seit Jahren nen eigenen LED-Shop. Er hat mir erzählt, dass die WS2812B wohl generell schlechte Qualität haben, und bei den meisten Matritzen/Stripes, die als "WS2812B" verkauft werden (weil die Bezeichnung bekannter ist), in Wirklichkeit SK6812 drauf sind, weil es da weniger Ausfälle gibt.

Was ich irgendwie auch bestätigen kann: Ich habe vor ziemlich genau 1 Jahr bei JLCPCB in China so Matrix-Platinen mit 39x15 Pixeln (WS2812B) für ein Projekt für nen Kunden anfertigen lassen. Da war bei der Hälfte der Platinen das selbe Problem, ein Teil blieb dunkel, wegen (von vornherein) defekter LEDs... als "Entschädigung" wurde mir dann ein Gutschein über 10 Euro bei der nächsten Bestellung angeboten...