Hallo zusammen, ich möchte einen WS2812B-Strip von 0 auf 100% aufdimmen. Eckdaten: -Arduino Nano -WS2812B Strip -Adafruit_Neopixel lib -es wird z.B. alle 500ms eine Funktion aufgerufen in welcher der Rot-Wert inkrementiert wird. Helligkeitswert steht durchgehende z.B. auf 255. Problem: Da ich somit für von 0 auf 100% nur die 256 Schritte des Rotwertes habe sind die erste "aufhellungen" relativ grob. Gibt es eine Möglichkeit diesen Verlauf flüssiger zu gestalten? Habe schon versucht den Helligkeitswert parallel über die gleiche weise zu inkrementieren und nun abwechselnd Rot bzw. Helligkeit zu inkrementieren. Somit hätte ich in Summe 512 Schritte. Hier passiert nun anfangs aber gar nichts, da die LEDs erst anspringen wenn Rot bzw. Helligkeit einen gewissen Wert erreicht haben. Danke!! Gruß Florian
Hallo, ich nutze die Funktion setBrightness gefolgt von der Funktion service aus der Library WS2812FX. Das funktioniert sehr harmonisch.
Florian schrieb: > Problem: Da ich somit für von 0 auf 100% nur die 256 Schritte des > Rotwertes habe sind die erste "aufhellungen" relativ grob. Gibt es eine > Möglichkeit diesen Verlauf flüssiger zu gestalten? Nicht wirklich. Die WS281x haben nunmal nur 8Bit PWM. Ich habe allerdings keine Ahnung, inwiefern die Addafruit-Lib wenigstens das tut, was unter dieser Randbedingung tatsächlich möglich wäre. Aber, selbst, wenn man alles tut, was möglich ist, wird's bei 8Bit-PWM niemals wirklich schön.
Hallo irgendwie habe es das Gefühl als wenn es kein Zufall ist das der TO eine fertige Arduino Bibliothek nutzt und die technisch durchaus sinnvollen Hinweise und "Lehrstunden" ihn nur begrenzt helfen werden. Viel mehr nehme ich an würde ihn ein Hinweis auf in diesen Punkt besser funktionierende Arduino Bibliotheken helfen, bzw. wie man die -Adafruit_Neopixel lib besser nutzen kann - soweit überhaupt möglich weil das eigentliche Dimmen und die hinterlegten Kennlinien bzw. Abstufungen ja für den Anwender "verborgen" sind und die Bibliothek sowieso recht mächtig ist. Wie geschrieben: Alles nur eine Vermutung aber die Art der Frage deutet schon darauf hin... Leider kann ich den TO nicht wirklich tiefgreifend helfen sondern nur die Empfehlung geben sich nach einer möglichst schlanken Bibliothek umzusehen die eben nicht alle RGB Streifen unterstützt die es seit "Beginn" bis zum heutigen Zeitpunkt gegeben hat, wo 100 + 1 Effekt schon vorgefertigt sind, und die auch für eine 10m² Leinwand ausreichend sind (ok. letzteres ist leicht übertrieben) Leider (manchmal auch zum Glück) sind insbesondere die Adafruit Bibliotheken auch möglichst einfachste Nutzung ausgelegt und ermöglichen alles Mögliche und Unmögliche in einen Rutsch - mit entsprechenden Fehlerpotential und Gefahr das man mit Seiteneffekten und den vorkauten leben muss. Man kann natürlich auch alles selbst von Null aus Programmieren - da sind (wären) die Links eine echte Hilfe - aber es hat ja wohl seinen Grund das Arduino als Idee mit seinen tausenden Bibliotheken für jedes Problem so beliebt sind. Realist
Moko schrieb: > https://www.mikrocontroller.net/articles/LED-Fading sollte jeder mal gelesen haben und das exel sheet geladen haben open office reicht auch
c-hater schrieb: > Nicht wirklich. Die WS281x haben nunmal nur 8Bit PWM. Das war auch meine Befürchtung. Wollte nur hier nochmal nachfragen ob es nicht einen Trick gibt dass man aus einer Kombination von Farb- und Helligkeitswert noch mehr Abstufungen bekommt. Der Link zum LED-Fading ist auch interessant nochmal zu lesen. Ist in ähnlicher Form schon berücksichtigt.
Ich bin nicht sicher, ob andere bereits sinngemäss das gleiche vorgeschlagen haben, daher formuliere ich meinen Vorschlag explizit aus: Wenn die Frequenz, mit der Du die LEDs aktualisierst, ausreichend hoch ist (=zu schnell für das menschliche Auge), könntest Du die 8 Hardware PWM-Bits des WS2812-LEDs um ein paar virtuelle Software-PWM-Bits erweitern. Stell Dir z.B. vor: Du kannst für den Rot-Wert nur die Werte 0-255 ausgeben, würdest aber gerne den Wert 2.5 ausgeben. Was Du dann machen kannst: Statt fest den Wert 2 oder 3 auszugeben, gibst Du immer abwechselnd 2 und 3 aus. Oder für den Wert 2.25: Du gibst dreimal den Wert 2 aus, dann einmal den Wert 3, dann wieder von vorne. Das ist vglw. leicht implementiert: Angenommen, Du möchtest statt der 8 Bits der WS2812-LEDs 10 Bit haben, und aktuell den Wert i = 937 ausgeben. Du lässt einen Counter j mitlaufen, der bei 0 startet, und nach jedem Frame per j = ((j + 1) % 4); erhöht wird, also immer von 0-3 hochzählt. Der 8-Bit-Wert, den Du tatsächlich ausgibst, ist ((i + j) >> 2)
Die WS2812-LED laufen mit 8 Bit PWM. Hier ist es extrem schwierig, gerade in den unteren Stufen flüssig zu faden. Wenn man noch die Anpassung an das menschliche Auge einbaut, kommen sogar noch wesentlich weniger vernünftige Schritte raus als die technisch möglichen 256 pro Farbe. Abhilfe: WS2815 - laufen mit 12V und haben eine 12-Bit-PWM. Hier ist flüssiges Faden in allen Bereichen möglich. Und das Beste: Die Dinger haben schon die Gammakorrektur (Anpassung an das menschliche Auge) eingebaut, so dass die RGB-Werte immer linear erscheinen. Eine Anpassung per Software ist hier gar nicht mehr notwendig.
Joachim S. schrieb: > Ich bin nicht sicher, ob andere bereits sinngemäss das gleiche > vorgeschlagen haben Ich z.B., vor etlichen Jahren (in den Annalen dieses Forums zu finden). Fazit: Funktioniert nicht. Es gibt nämlich noch eine weitere Beschränkung neben der PWM-Frequenz. Das ist Rate, mit der die Dinger Updates des Duty der PWM akzeptieren. Diese Rate ist wesentlich geringer als die Rate, mit der man die Information über (zumindest kurze) Ketten verschicken kann. Die Information kommt zwar an, landet aber effektiv im Nirvana. Nur das letzte Update vor der Akzeptanz wird tatsächlich wirksam. Sprich: das dir vorschwebende "Dithering" funktioniert einfach nicht.
c-hater schrieb: > Fazit: Funktioniert nicht. > > Es gibt nämlich noch eine weitere Beschränkung neben der PWM-Frequenz. > Das ist Rate, mit der die Dinger Updates des Duty der PWM akzeptieren. > > Diese Rate ist wesentlich geringer als die Rate, mit der man die > Information über (zumindest kurze) Ketten verschicken kann. Die > Information kommt zwar an, landet aber effektiv im Nirvana. Nur das > letzte Update vor der Akzeptanz wird tatsächlich wirksam. Danke, wieder was gelernt. Klingt auch logisch, die maximale effektive Update-Rate ist vermutlich halt die PWM-Frequenz der WS2812-LEDs. Und die scheint einer kurzen Google-Suche zufolge wohl üblicherweise bei nur 400Hz zu liegen. Wobei es offenbar auch neuere Modelle mit 2000Hz gibt, wo die Idee vielleicht mit Einschränkungen funktionieren könnte.
c-hater schrieb: > Es gibt nämlich noch eine weitere Beschränkung neben der PWM-Frequenz. > Das ist Rate, mit der die Dinger Updates des Duty der PWM akzeptieren. Interessant. Hat das nur mit der RES time von >50us zu tun oder ist kann das noch wesentlich mehr sein? (programmiere gerade einen 10x10x10 Cube mit 5mm LEDs rum, bei dem das noch interessant werden könnte)
Joachim S. schrieb: > Klingt auch logisch, die maximale effektive Update-Rate ist vermutlich > halt die PWM-Frequenz der WS2812-LEDs. Hmm ja, logisch. Da kann dann natürlich nicht mehr gehen. Was bedeutet "scan freq. not less than..." im folgenden Abschnitt des Datenblattes? "Each pixel of the three primary color can achieve 256 brightness display, completed 16777216 color full color display, and scan frequency not less than 400Hz/s"
:
Bearbeitet durch User
Joachim S. schrieb: > Klingt auch logisch, die maximale effektive Update-Rate ist vermutlich > halt die PWM-Frequenz der WS2812-LEDs. Das wäre sinnvoll, ja. Ich würde nach meinen Beobachtungen allerdings eher auf die Hälfte oder sogar nur ein Viertel der PWM-Frequenz tippen. Ist aber auch egal. Das eigentliche Problem ist, dass die PWM (und auch ihr Duty-Update) in keinster Weise mit der Kommunikation synchronisiert ist oder wird. DADURCH wird jeglicher Ansatz bezüglich eines Dithering torpediert. Es werden sich immer störende Aliasing-Effekte ergeben. Und zwar für jede einzelne LED andere. Und obendrein welche, die mit der LED-Temperatur variieren...
Das fadecandy-Platinchen von Adafruit, über das man solche LEDs vom Rechner aus per USB steuern kann, macht genau so ein Dithering. https://www.adafruit.com/product/1689 Ich hatte die schon im Einsatz, und in den untersten Stufen flackern die LEDs nur. Sobald aber ein permanentes Leuchten draus wird, sieht es eigentlich gut aus.
:
Bearbeitet durch User
c-hater schrieb: > Ist aber auch egal. Das eigentliche Problem ist, dass die PWM (und auch > ihr Duty-Update) in keinster Weise mit der Kommunikation synchronisiert > ist oder wird. ich hatte dir ja auch schon ein LESENSWERT spendiert c-hater schrieb: > Es gibt nämlich noch eine weitere Beschränkung neben der PWM-Frequenz. > Das ist Rate, mit der die Dinger Updates des Duty der PWM akzeptieren. > > Diese Rate ist wesentlich geringer als die Rate, mit der man die > Information über (zumindest kurze) Ketten verschicken kann. Die > Information kommt zwar an, landet aber effektiv im Nirvana. Nur das > letzte Update vor der Akzeptanz wird tatsächlich wirksam. > > Sprich: das dir vorschwebende "Dithering" funktioniert einfach nicht. das wird einfach zu gerne vergessen!
Rolf M. schrieb: > Das fadecandy-Platinchen von Adafruit, über das man solche LEDs vom > Rechner aus per USB steuern kann, macht genau so ein Dithering. > https://www.adafruit.com/product/1689 > Ich hatte die schon im Einsatz, und in den untersten Stufen flackern die > LEDs nur. Logisch, denn der Controller hat keine Möglichkeit, das Laden neuer PWM-Daten mit der PWM der LEDs zu synchronisieren. > Sobald aber ein permanentes Leuchten draus wird, sieht es > eigentlich gut aus. Man kann alles übertreiben. Oder einfach bei 8 Bit PWM mit Kennlinienkorrektur zufrieden sein.
Angehängte Dateien:
-
Leuchtturm.gif
23 MB
Hallo, ich habe vor ca. einem Jahr auch mein Projekt mit WS2812B gestartet. Da der erste Streifen (144 LED/m) zwischen den LEDs keine vernünftigen Kontaktflächen bot, habe ich da leider einige Stücke verbrannt (brauchte sieben Streifen mit 20 LED). Lange Rede kurzer Sinn, im Prinzip lief die Steuerung, nur halt nicht mit allen LED und das Ergebnis war von der Optik her ok. Dann habe ich einen anderen Streifen zerschnitten und alles neu gelötet. Das funktioniert jetzt technisch, wie es soll. Aber die LED kann man nicht mit niedrigen Werten dunkel betrieben, schon mit RGB=(2,2,2) sind die recht hell. Der alte Streifen würde hier erst bei RGB=(25,25,25) oder höher eine ähnliche Helligkeit erzeugen (Werte sind geschätzt, aber es ist ein deutlicher Unterschied). Insofern, wenn die LED gar nicht dunkel können, wird das mit dem Einblenden auch nichts. Ich habe damit ein Lauflicht für einen Leuchtturm gebaut. Ach ja, im angehängten GIF ist die max. Helligkeit bei 20 von 255... Evtl. beobachtet der TO auch einfach mal, wie ein langsames Einblenden von 0 auf 20 (quasi im Sekundentakt die Helligkeit um 1 erhöhen) aussieht. Gruß Nils
Nils W. schrieb: > Ach ja, im angehängten GIF ist die max. Helligkeit bei 20 von 255... > preview image for Leuchtturm.gif > Leuchtturm.gif > 23 MB Echt jetzt? Schon mal was von einem normalen Videoformat gehört? Der Quark lad ich nicht runter, auch wenn das heutzutage keinen juckt.
Thread beobachten
Seitenaufteilung abschalten
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.