nachdem das in dem Beitrag "[Mitbestellung] SMD5050 RGB-LED mit integriertem 8-bit PWM Controller" nicht mehr so richtig weiter geht ( Bestellung ), habe ich mir diese Woche selbst welche in China bestellt. Die RGB-LED's sind schon unterwegs und werden in der nächsten Woche bei mir sein. Ich habe gleich eine größere Menge bestellt, um auf einen guten Preis zu kommen. Der Preis bewegt sich zwischen 0,25 EUR und 0,30 EUR pro Stück. Den genauen Preis gebe ich hier bekannt, wenn alle Gebühren, die noch so anfallen, bezahlt sind. Wer also Interesse an den Teilen hat, der kann sich über PN bei mir melden. Gruss Steffen p.s. ein Datenblatt habe ich leider auch nicht bekommen.
die SMD5050-RGB-LED mit WS2811 sind heute bei mir eingetroffen. Wer also noch was braucht, kann sich ja bei mir per PN melden. Der Preis pro LED liegt bei 0,28 EUR pro Stück. Alle, die mich bis jetzt angeschrieben haben, bekommen noch eine MAIL. Gruss Steffen
Hi Steffen, ich nehme an du hast ebenfalls noch kein Datenblatt. Wärst du bereit die Quelle zu nennen? Ralf
Hallo Ralf, bestellt habe ich die RGB-LED's hier: http://www.scottled.com/ Ein Datenblatt habe ich bei denen auch nicht bekommen. Ich habe da auch mal telefonisch versucht, aber leider hat das auch nichts gebracht. Die Rollen waren in Vakuumbeutel mit den entsprechenden Hinweisen, aber kein Label oder sowas. Gruss Steffen
Hi Steffen, bei Scott hatte ich auch gesucht, aber offenbar war ich zu doof (oder die führen die LEDs noch nicht auf der Seite bzw. wenn dann gut versteckt). Danke für die Info, dann hab ich mal einen Ansatzpunkt. Ich hab aus der vorangegangenen Bestellung ein paar LEDs, die werd ich jetzt verbasteln und dann würd ich mich nochmal melden :) Falls du doch noch ein DB von Scott bekommst kannst es ja mal posten. Ralf
@ hanz: den Preis musst Du anfragen und verhandeln. Schreibe mir eine PN und ich schicke Dir die Kontaktdaten. Gruss Steffen
Hi, da es mit den Dyco LEDs und der Bestellung irgendwie so garnicht weitergeht und diese hier obendrein noch günstiger sind, werde ich mich wohl an einer Bestellung hier beteiligen... Wäre super wenn das demnächst klappen würde... Grüße Markus
@Steffen: Hab grad nochmal bei Scott geguckt, kann es sein dass die LEDs bei denen nicht auf der Website sind? Ralf
Ich würde gerne so ca. 100 Stück nehmen. Wäre es möglich, mich per E-Mail anzuschreiben? electronicsnstuff ät hotmail (punkt) com Danke und Gruss
@Ralf: richtig, die wirst Du auf deren Homepage nicht finden. Ich hatte die direkt da mal angefragt. Ich werde in der nächsten Woche noch mal welche bestellen. Derzeit habe ich keine mehr. @Electronics'nStuff: ich melde mich bei Dir, wenn ich wieder welche habe. Gruss Steffen
ich bekomme in der nächsten Woche noch eine Lieferung der RGB-LED's mit WS2811 Chip. Wer also noch Interesse hat, kann sich bei mir melden. Der Preis von 0,28 EUR/Stück bleibt wie schon im 2.TH angegeben. Gruss Steffen
Hi Steffen, wo liegen denn etwa die Versandkosten? Ralf
@Ralf: der Versand liegt bei 1,65 EUR im Luftpolsterumschlag. Gruss Steffen
Oh - ich vergaß Bescheid zu geben: meine 350 Stück sind gut und wohlbehalten angekommen ;) Danke nochmal dafür! Jetzt muss ich blos noch die Software von synchron nach asynchron umstricken. (WS2801 <-> WS2811) Stichwort: processing.org, Paintyourdragon, P9813, Cygwin usw. gerade die Cygwin Installation war echt Neuland. Hab doch von Linux bisher keine Ahnung :( Dafür ist proccesing.org ja echt einfach und mit erstaunlichen Möglichkeiten! https://github.com/PaintYourDragon/p9813 http://www.youtube.com/watch?v=hBmQG1qDvog&feature=plcp Gruß Axelr.
die LEDs sind schon am Sonntag in Deutschland eingetroffen, aber die Abwicklung durch das Zollamt dauert dieses mal etwas länger. Ich Denke, das die LEDs am Mittwoch bei mir sind. Gruss Steffen
die LEDs sind heute bei mir eingetroffen. Leider hatte ich mit dem Zollamt einige Meinungsverschiedenheiten, so das ich die erst heute in Empfang nehmen konnte. Wer also noch was braucht, der kann sich gerne bei mir melden. Gruss Steffen p.s.: über PN oder mcu (ät) shotech (p) de .
Hallo zusammen, kann mal bitte jemand einen Link posten, damit ein Newbie sich einlesen kann, worum es hier geht ? Das Thema RGB-LED interssiert mich brennend. Bislang kannte ich nur die Lichterketten, die per RGB PWM mit MOSFETs entsprechende Farben generieren. Wo liegen die Anwendungsgmöglichkeiten dieser LEDs? Offenbar kann ich durch "Bit-Schieben" Farbmuster in verketteten RGB-LEDS erzeugen ?? Vielen Dank!
> Wo liegen die Anwendungsgmöglichkeiten dieser LEDs? Offenbar kann ich > durch "Bit-Schieben" Farbmuster in verketteten RGB-LEDS erzeugen ?? Die Anwendungsmöglichkeiten dieser LEDs liegen genau dort, wo auch die "normalen" RGB-LEDs ohne integrierten Controller ihre Anwendung finden. Der Vorteil ist eben, dass durch den integrierten Controller die wahnsinnig aufwändigen Matrix-/Multiplexer-Schaltungen entfallen und Platzbedarf sowie Komplexität des Layouts reduziert werden. Ausserdem erlaubt es der integrierte Controller wesentlich mehr LEDs zu verwenden, als es in einer Matrix-/Multiplex-Schaltung möglich wäre (klar, mit x Lagen der Leiterplatte und genug Geld geht alles). Durch den geringeren Platzbedarf ergeben sich je nachdem weitere Anwendungsgebiete. Ich denke, dass in nächster Zeit das eine oder andere Projekt mit diesen LEDs hier vorgestellt werden wird. Ansonsten findest du generell zu RGBs haufenweise Videos auf YT etc. Ralf
...auch für kleine Projekte ist der Aufwand schon geriner. Aleine um ein bisschen "Leuchtkram" zu basteln reichen ein paar dieser LEDs, ein bisschen "Hühnerfutter" in Form von Widerständen und Stützkondensatoren und ein kleiner µC, z.B. ein ATtiny45 reicht schon aus umd viele Leds anzusprechen. Mit den herkömmlichen Wegen ist das wesentlich aufwändiger, da benötigt man Treiber (Transistoren/FETs oder ICs), viele Ausgänge am µC, eben evtl. Multiplexlogik, Schieberegister etc... Die LEDs sind also quasi "Plug & Play" :-) Einzg die serielle Ansteuerung ist ein bisschen tricky bzw. zeitkritisch, aber auch das funktioniert mittlerweile gut. Aufpassen muss man nur bei der Stromaufnahme. Da die LEDs ja nicht gemultiplext werden, kommen da schnell einige Ampere zustande, wenn alle LEDs auf maximum weiß geschaltet sind. Wenn ich Zeit habe, mache ich vlt. mal 'ne Seite im Wiki zu den LEDs. Grüße Markus
Vielleicht kann mir jemand der WS2811-Cracks hier kurz Nachhilfe geben. Sehe ich das folgende richtig? 1 Zyklus je Bit dauert 2,5µS, je Chip werden 24 Bit benötigt, also 1 Zyklus je Chip 60µS. Wenn ich mehr Chips ansprechen möchte, schiebe ich die Daten hintereinander (mit exakten Timing) in den 1. Chip rein, der kassiert die ersten 24 Bit für seine eigenen LEDs und leitet nur die Folgebits an den nächsten Chip weiter, der kassiert auch seine 24 Bit und leitet nur die Folgebits weiter etc etc etc. Werden die Daten in die LED-Treiber sofort nach den 24 Bit übernommen oder erst mit dem Reset, der länger als 50µS dauern muss? Bei z.B. 100 Chips kommen da ja ganz schöne Zeiten zusammen, da man immer alle Chips mit Daten versorgen muss. Zudem muss das Timing bei steigender Chip-Zahl immer genauer werden oder synchronisiert sich der Chip für jedes Bit mit der steigenden Flanke neu? Das Durchschleifen eines Resets durch z.B. 100 Chips dauert ja auch geradezu "ewig". Wie mache ich denn z.B. eine Helligkeitsregelung bei höheren Chipmengen, PWM würde dann ja zu ziemlichem Flimmern/Flackern führen.
> Vielleicht kann mir jemand der WS2811-Cracks hier kurz Nachhilfe geben Ich versuch mal zu cracken... > 1 Zyklus je Bit dauert 2,5µS, je Chip werden 24 Bit benötigt, also 1 > Zyklus je Chip 60µS. Nope. 800kHz Übertragung = 1.25µs pro Bit, aufgeteilt in 1:4 H/L für ein Low und 4:1 H/L für ein High. Das heisst 0.25µs / 1.00µs High/Low Puls für ein Low-Bit oder umgekehrt für ein High-Bit. > Wenn ich mehr Chips ansprechen möchte, schiebe ich die Daten > hintereinander (mit exakten Timing) in den 1. Chip rein... Korrekt. Jeder Chip übernimmt die ersten 24 Bits die er bekommt, die restlichen leitet er weiter. > Werden die Daten in die LED-Treiber sofort nach den 24 Bit übernommen > oder erst mit dem Reset, der länger als 50µS dauern muss? Mit dem Reset. > Bei z.B. 100 Chips kommen da ja ganz schöne Zeiten zusammen, da man > immer alle Chips mit Daten versorgen muss. Muss man nicht. Daten einmal reingepustet und die Chips behalten die Werte... > Zudem muss das Timing bei steigender Chip-Zahl immer genauer werden oder > synchronisiert sich der Chip für jedes Bit mit der steigenden Flanke > neu? Soweit ich weiss ist ein interner Oszillator drin, also ganz exakt muss es nicht sein, siehe +- 150ns Toleranz im Datenblatt. > Das Durchschleifen eines Resets durch z.B. 100 Chips dauert ja auch > geradezu "ewig". Nein, es dauert nicht ewig. Wenn man davon ausgeht, dass ein Chip sich die jeweils ersten 24-Bit krallt und die nächsten weiterreicht, dann wird er auch den Reset sofort weiterleiten und demzufolge wird auch ein Reset über 1000 LEDs auch nicht mehr wie die 50µs dauern. Fraglich wie man das nun beweist ;) > Wie mache ich denn z.B. eine Helligkeitsregelung bei höheren Chipmengen, > PWM würde dann ja zu ziemlichem Flimmern/Flackern führen. Du brauchst kein PWM, das macht der Chip doch schon. Wenn du mit Helligkeit der Farben spielen willst, dann solltest du eine HSV-RGB-Funktion implementieren. Da gibst du dann keine RGB-Werte an, sondern Helligkeit, Farbton und Sättigung. Es gibt diverse Beispielfunktionen im Forum (SuFu benutzen). Ralf
PS: >> Zudem muss das Timing bei steigender Chip-Zahl immer genauer werden oder >> synchronisiert sich der Chip für jedes Bit mit der steigenden Flanke >> neu? > Soweit ich weiss ist ein interner Oszillator drin, also ganz exakt muss > es nicht sein, siehe +- 150ns Toleranz im Datenblatt. Die eigentliche Antwort ist: Ja, er synchronisiert sich auf die steigende Flanke des Datensignals, der interne Oszillator ist quasi das "Gegenstück". Ralf
> Fraglich wie man das nun beweist ;)
mit einem 2-Kanal-Oszi oder einem LA ???
Hi, das die LEDs die Daten erst nach dem Reset übernehmen ist mir neu, konnte ich im ws2812pre Datenblatt auch nicht finden. Dort steht, dass ein "Pixel" nach dem Empfang von 24 Bit die Daten in seinen internen Latch übernimmt und danach DIN -> DOUT weiterleitet, inklusive "reshaping". Nach meiner Auffassung heisst das, er würde danach sofort mit den neuen Daten arbeiten. Aber nehmen wir mal 512 LEDs. Wir müssen also 512 x 24 Bits = 12288 Bits übertragen. Bei 800 kbit/s ergeben sich 12288 / 800000 = 15,4 ms für eine komplette Übertragung. Die Anzahl der kaskadierbaren LEDs ist lt. Datenblatt nicht begrenzt, nur in der Praxis durch die Framerate die man erzielen möchte. Grüße Markus
> das die LEDs die Daten erst nach dem Reset übernehmen ist mir neu, > konnte ich im ws2812pre Datenblatt auch nicht finden. Dafür ist das Resetsignal da. Nach gegenwärtigem Kenntnisstand handelt es sich bei den WS2812-LEDs um RGB-LEDs mit integriertem WS2811-Controller. Nimmt man dessen Datenblatt, welches ein kleines bisschen detaillierter beschrieben ist ebenfalls hinzu, so steht dort (nach meiner Auffassung), dass die Daten erst übernommen werden, wenn das Resetsignal übermittelt wurde... > Dort steht, dass ein "Pixel" nach dem Empfang von 24 Bit die Daten in > seinen internen Latch übernimmt und danach DIN -> DOUT weiterleitet, > inklusive "reshaping". Korrekt. Meine Vermutung ist eben, dass der Chip, wenn keine High-Flanke zum erwarteten Zeitpunkt erfolgt davon ausgeht, dass ein Resetsignal erfolgt, welches direkt weitergeleitet wird. Müsste man halt eben wirklich mal ausmessen, mit einem LA oder einem Oszi. > Nach meiner Auffassung heisst das, er würde danach sofort mit den neuen > Daten arbeiten. Wie gesagt, das WS2811(!)-DB sagt da etwas anderes aus. > Die Anzahl der kaskadierbaren LEDs ist lt. Datenblatt nicht begrenzt, > nur in der Praxis durch die Framerate die man erzielen möchte. Das DB sagt für beide Chips (WS2811 und WS2812) eine "transmission delay time" von 300ns aus, daher vermute ich, dass abgesehen davon keine zusätzlichen Verzögerungen zu erwarten sind. Im Endeffekt bedeutet das 33.3k-LEDs pro Sekunde. Ralf
Hi, ja stimmt, im WS2811 Datenblatt steht: "All chip synchronous send the received data to each segment when the DIN port input a reset signal" Genau dieser Satz fehlt komischerweise im WS2812 Datenblatt... Entweder ist das eine abgespeckte Version von dem Chip, oder sie haben es einfach vergessen beim cut & paste :-) Man könnte es ja einfach testen, indem man einen endlosen Datenstrom schickt. Dann dürften nach dieser Theorie die Daten NIE übernommen werden. Werde ich nachher mal ausprobieren, auch das Delay von der 1. bis zur letzten LED... probiere sowieso gerade mit sonem Strip rum. Grüße Markus
Hiho, hier meine Erkenntnisse (außer das jetzt 2013 ist :-) 1. Die Daten werden tatsächlich erst beim Resetimpuls übernommen, wenn man kontinuierlich Daten ohne Resetimpuls schickt, werden diese nie übernommen. 2. Die Verzögerung für das Resetsignal beträgt bei einem Strip mit 240 LEDs von der ersten bis zur letzten ca. 45µs, also ca. 190ns pro LED. Grüße Markus
> 1. Die Daten werden tatsächlich erst beim Resetimpuls übernommen, wenn > man kontinuierlich Daten ohne Resetimpuls schickt, werden diese nie > übernommen. Geht auch nicht anders, irgendwie muss man dem Controller ja sagen, dass er jetzt die Daten übernehmen soll. Wenn er die Daten sofort beim Erhalt übernehmen würde, dann könnte man wahrscheinlich keine Panels aufbauen, das würde wohl flackern etc. > 2. Die Verzögerung für das Resetsignal beträgt bei einem Strip mit 240 > LEDs von der ersten bis zur letzten ca. 45µs, also ca. 190ns pro LED. Das passt zur TransmissionDelayTime Din->Dout aus dem Datenblatt mit max.300ns. Konntest du rausfinden, wie genau die 50µs für das Reset-Signal sein müssen? Ralf Ralf
Hallo, ich hätte auch Interesse an LEDs (150 Stück dürften erst einmal genügen). Sind so viele noch zu haben oder gibt es wieder eine Bestellung?
@ Christian H. : sind noch einige über. Schicke mir einfach eine PN. Gruss Steffen
Hallo, Kann es sein das meine Mails im Spam Filter untergehen? Grüsse
@ Dominic : habe Dir gerade ne MAIL geschickt. Gruss Steffen
hey ihr bastler, hab anfang jahr angefangen mit den ws2811 zu arbeiten. schon cool die dinger. was das timing angeht: die chips sind sehr sehr tolerant. wichtig ist einzig, dass die high-time für ein bit stimmt. also nach meiner erfahrung geht alles von 100-300ns high als 0 durch und von 400-800 als 1 (kann auch etwas abweichen davon aber so ungefähr in dem rahmen). die low time kann dann auch gut mal 1000-3000ns sein, das macht gar nix, einfach nicht zu lange, da ab 50mikros der latch aktiv wird und die datenreihe von vorne beginnt. wie lange genau die minimum latch zeit ist weiss ich nicht, aber es wird eh schwierig ein neues frame bereitzustellen in weniger als 50mikros, vielleicht mit multicore und double buffer? das timing kann man gut in software implementieren, habs zum testen auf einem arduino gemacht und (etwas schneller) auf einem STM32F0. man bekommt (bei deaktivierten interrupts!) etwa mit 15ms für ein frame (in meinem fall 435 LEDs) aus. wenn mans jetzt schlau macht, kann man auch gleich mehrere GPIOs verwenden und alle gleich takten. das wird dann pro bit etwas langsamer aber dafür kann man die LED kolonne an 4 stellen gleichzeitig speisen. hab das mal provisorisch programmiert und es funktioniert, aber nur als test, das ganze panel hab ich so noch nie angesteuert da mir die 15ms mehr als ausreichen im moment. hier gibts noch ein video vom resultat, für video ists zu langsam aber so animationen kriegt man schon gut hin: http://www.youtube.com/watch?v=F7fd7MILKFU
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.