NeoPixel- oder FastLed Library - Welche ist schneller?

International Deutsch
1

Ich steuere eine LED Streifen mit 61 Leds an (WS2812B).
Den LED Streifen steuere ich bisher mit HSV Farbwerten an.
Meine Frage ist nun, welche Libraray auf einem Nano schneller ist?
Die NeoPixel. oder die FastLed Library?
Gibt es dazu vielleicht Vergleiche?

Für mich ist es wichtig, die Farbe (nicht Sättigung oder Helligkeit) so schnell wie möglich zu ändern? Ich habe nur 2 fixe Farbwerte (on und off) die ich so latenzfrei wie möglich anzeigen möchte.

Noch eine Frage:
Ist die Steuereung per RGB schneller oder per HSV?
Bisher komme ich mit HSV Werten besser klar.

Gucky.

2

So groß ist der Aufwand, um den Sketch mit beiden Libs aufzubauen und selbst zu vergleichen nun auch noch.

Gruß Tommy

1 Like
3

Da das Timing Protokoll der WS2812B eher die Bremse ist, wirst du keinen sichtbaren Unterschied der beiden Bibliotheken erkennen.

Da die Daten in RGB, je 8 Bit, zur WS2812B übertragen werden, braucht es keine Umrechnung, wenn du die Farbwerte, als RGB der Bibliothek übergibst. Ob das einen sichtbaren Effekt hat, musst du beurteilen.

4

Bei 61 Pixel wirst Du kaum einen Unterschied feststellen.
Und Du hast den Flaschenhals DIN (Ich mein 800kB/Sec.)
Da hilft keine der beiden Libs um schneller zu sein.
Bei meinem Tetris
6 mal 256 Pixel setze ich die NeoPixel ein. Das heißt aber nicht das diese Schneller ist. Nur brauchbarer für meinen Einsatz.
Die 1536 Pixel sind so in 6 Blöcke aufgeteilt, was dann das Optische etwas schneller macht.

5

Es geht mir nicht um einen SICHTBAREN Effekt, sondern eher um einen messbaren/spürbaren. Das Auge des Menschen ist träge und SICHTBAR macht das sicher keinen Unterschied, da gebe ich Dir Recht.

Aber:
Wenn Du eine Saite (Musikinstrument) anschlägst und die dazugehörige LED eben langsamer oder schneller regiert, merkst Du das sehr deutlich und daher fragte ich, ob das was "Tommy" andeutete, schon mal jemand gemacht hat, bzw. ob jemand Erfahrungwerte damit hat. Daher auch die Frage nach "RGB vs. HSV".
HSV ist in dem Fall für mich einfacher, aber wenn RGB schneller wäre, baue ich das Script ggf. entsprechend um.
Warum das Rad neu erfinden, wenn damit jemand evtl. schon Erfahrungen gesammelt hat?
Ich dachte zudem, dass genau das u.A. auch der Sinn eines Forums ist, sich auszutauschen.

Gucky.

1 Like
6

Du wirst keinen Unterschied visuell erkennen. Wenn doch dann liegt es an deinen Code Unterschieden.

Wie schon vorgeschlagen - mach dir zwei Testsketche wenn du noch keine Praeferenz fuer eine der beiden Libs hast.

7

Wie gesagt, RGB ist schneller, da dies nicht erst umgerechnet werden muss. Sind aber nur paar Takte.

Die WS2812B erwarten die Daten (High und Low) in einer gewissen zeitlichen Abfolge. Die Daten erzeugen beide Bibliotheken gleich, da vom Hersteller WorldSemi so vorgeschrieben. Das ist eine Bremse die du nicht beeinflussen kannst.

Andere programmierbare LEDs lassen sich schneller beschreiben, da man die Clock selber vorgeben kann.

Ich vermute aber die größte Bremse ist wohl eher dein Sketch. Da lässt sich die meiste Zeit rausholen, unabhängig der beiden Bibliotheken.

Hast du den einen „fühlbaren“ zeitlichen Versatz?

8

Moin @gucky_87 ,

zum generellen Timing siehe u.a. einmal hier

https://learn.adafruit.com/adafruit-neopixel-uberguide/advanced-coding

Bei 100 LEDs wäre die theoretische Update-Rate 328 mal pro Sekunde. Selbst bei einem (eher unwahrscheinlichen) Faktor 10 schlechter, wären das immer noch ca. 33 Hz, wenn man kontinuierlich updaten würde.

Oder anders ausgedrückt: Eine Änderung würde dann maximal 1/33 Sekunden = ca. 30 ms benötigen. Bei 61 statt 100 LEDs wären es also 0,61 * 30 ms = 18 ms.

Auf der o.a. Adafruit-Seite wird FastLED als Alternative zur Adafruit Neopixel Library aufgeführt, aber - wie schon oben gepostet wurde - ist mit Sicherheit Dein Code für die Update-Zeit wesentlich relevanter als die Library.

Dort wäre eine Optimierung anzusetzen, wenn diese erforderlich sein sollte.

Gruß (bitte auch an Perry, Atlan und Bully :wink: )
ec2021

9

Ich will/muss auch VISUELL keinen Unterschied erkenen.
Schlag mal eine Taste auf dem Klavier an. Du hörst SOFORT einen Ton. Lolo.
Nun schlage sie nochmal an und denk Dir das KLavier "laggt". Duc drückst, hörst den Ton aber erst 10ms später. Seheh wirst Du das nict´ht, aber spüren.
Ich hoffe, ich habs das ein wenig verständlich erklärt?

"Paar Takte" x 61 sind aber auch ein "paar Takte". Das macht das ganze wiederum langsamer. Ich MUSS immer alle 61 Werte "dürchzählen" und aktualisieren.

Das ist schonmal eine sehr aussagekräftige Aussage, mit der ich was anfangen kann, denn das wusste ich bisher noch nicht. Danke.

Gucky.

10

Um das mal zu Visualisieren
Hier die FastLED wo 1536 Pixel in Reihe angesteuert werden.

Das ist in eines der Beispiele bei FastLED.
Und hier in diesem ab 0:42 Min der Helle Streifen von Links nach Rechts

Das ist nichts mehr als 2 mal 32 Pixel mit einer Farbe beschreiben und dann mit Farbe 0 wieder beschreiben.
Das ist eine For Next mit keinerlei Pause drinnen. Und der UC ist nicht für diese Geschwindigkeit verantwortlich (ESP32 Wroom 250MHz)
Pausenzeiten sind nur wenn so ein Stein nach unten fällt. Hier sind das 800 mSec. bevor dieser Stein eine Reihe tiefer dargestellt wird.
Und bei dem Zusammenfallen der Reihen sind das 100 mSec Pause

Und es werden nur 256 Pixel gesteuert im zweiten Video. Und der Pixel 0 (DIn) ist auf der rechten Seite der 32x8 Matrix
Ich hoffe Du kannst da was erkennen
Leider hatte ich keine Aufnahme mit dem Versuch auf 1536 Pixel mit dem Teris gemacht.
Da kann man dann schon einen Unterschied erkennen und der Flaschenhals wird sichtbar.

11

Akustische und visuelle Latenz sind beim Menschen tatsächlich deutlich unterschiedlich.

Diese liegt beim Gehör durchschnittlich bei ca. 10 ms, beim Auge bei ca. 100 ms.

Dabei spielt der Abstand zwischen Quelle und Sensor beim Schall natürlich auch noch eine deutlich größere Rolle als beim Licht. Bei 3 m Abstand zu einer Quelle braucht der Schall schon ca. 10 ms.

Theoretisch müsste man noch die Zeit zwischen Auslösen und der ersten ausreichend hörbaren bzw. sichtbaren Amplitude einrechnen.

Insofern sollte die Übertragungszeit für die Daten bei der zudem noch relativ geringen Anzahl von Led tatsächlich keine wesentliche Rolle spielen.

Mein Vorschlag:

  • Mit FastLED einen Testsketch schreiben, der zyklisch Änderungen vornimmt (günstigerweise so, wie sie im worst case erwartet werden)
  • Mit dem schnellstmöglichen Wechsel beginnen
  • Eine "künstliche" Latenz per delay() einbauen
  • Diesen Wert so lange verändern, bis der Effekt erkennbar ist

Um dies schnell zu erreichen, empfiehlt sich "lineares Eingabeln", also mit einem großen Wert zu beginnen, falls der Effekt sichtbar ist, den Wert halbieren. Wenn weiterhin sichtbar, wieder halbieren, sonst die Mitte zwischen den letzten beiden Werten nehmen etc.

Zum Verfahren siehe

https://de.m.wikipedia.org/wiki/Regula_falsi#:~:text=Als%20numerische%20Methode%2C%20auch%20lineares,vom%20Sekantenverfahren%20und%20der%20Bisektion.

Viel Erfolg
ec2021

1 Like
12

Ich wollte vorhin schon da drauf einsteigen, was bei der ganzen Geschichte vergessen wird.
Es ist ja nicht die Geschwindigkeit als solche, die das Problem ist, sondern die Latenz
Und wer mal 10ms Versatz zwischen Bild und Ton bei einem Interview gesehen hat, hat keine Fragen mehr.

Ein Einsatz auf den Takt vom Drummer mit 10ms oder mehr Latenz macht jedes Stück (visuell) kaputt.

Man stelle sich mal vor: Bluemangroup mit Versatz zwischen dem Anschlag auf dem Fell und dem tatsächlichen Farbwechsel :see_no_evil_monkey:

13

Das Datenblatt ist dir bekannt? Dort steht sowas drin.

14

Um die Problematik besser verstehen zu können, wäre es hilfreich, wenn Du die Gesamtkette beschreiben würdest, die Du realisieren willst.

Dann ließe sich erschließen, an welcher Stelle ggf. Optimierungen sinnvoll und möglich sind

15

Anstelle der WS2812B gibt es die ca. zehnmal schnelleren APA102 oder vergleichbare mit Takt und Daten getrennt. Der Nano kann die höhere Framerate allerdings nur so gerade an der SPI-Hardware rausgeben, sollte für einen Test aber reichen, bei nur 61 Pixeln auch nicht unmäßig teuer.

Je nach Komplexität Deines Programms könnten auch die notwendigen Berechnungen eine Rolle spielen. Ein Teensy 4 ist deutlich flotter als ein NANO.

Nur so Gedanken :slightly_smiling_face:

16

Die Übertragung der Farbdaten (RGB) aus dem Speicher des NANO an die WS2812B ist durch die Geschwindigkeit der Datenübertragung bestimmt. Die ist fix 800kHz und Bilbliothksunabhängig.

Wie Du den "Bildspeicher" füllst ist eine andere Geschichte. Das ist das was die Geschwindigkeit Deines Sketches bestimmt.
Da Du diesen nicht gezeigt hast können wir keine Aussage über Zeitverschwendung bze Verbesserungsvorschläge machen.

Grüße Uwe

2 Likes
17

Das mit Latenz und BlueMan Group trifft es sehr genau.
Das ganze wird eine "Beleuchtung" für Keyboards (s. dazu unten mehr), die via MIDI gestuert wird.

Danke für diese Info. Bisher unterlag ich dem Irrglauben, dass man die 800kHz ändern könnte. Wieder was gelernt.
Aber 800 KhZ (also 0,00000125s pro Byte) dürften reichen, um 61 LEDs schnell genug zu steuern. Das Problem düfte eher MIDI mit seinen 31.250 Hz/Baud (= 0,000032s pro Byte oder 0,00000375s pro 3 Byte/LED) sein (s. auch dazu weiter unten).

Nun, da ich gerade u.A. an diesem Programmteil arbeite, kann ich den Code leider noch nicht posten, der er schlicht noch nicht einsatzfahig ist. Daher ja auch meine Fragen jetzt schon, damit ich nicht "bödsinnigen" Code zusammenstricke und nacher alles neu machen muss.
Ich werde Euch aber gerne, sobald ich einen wirklich sicher laufenden Code habe, diesen Posten, denn verbessern kann man sich ja immer.

Und, Uwe, ich habe bisher sehr viele Deiner Posts gelesen, daher denke ich, Du WIRST bestimmt etwas finden/verbessern können :wink:
Aber erst einmal selber basteln und lernen.

Momentan habe ich z.B. noch Probleme, "Note Off" Meldungen SICHER zu erkennen. Ich benutze noch keine MIDI Library. Manchmal bleiben einzelne LEDs an, was ein nochmaliger "Note Off" dann ändert. Es ist aber nicht das Signal selber, sondern der Arduino scheint es nicht richtig mitzubekommen. "Note Off" geht hingegen 100%ig.

Ich verwalte die RGB LEDs als Array, so ist meine bisherige Herangehenweise. Ich fülle dieses mit "MiÍDI Note On" Signalen, bzw. mit dem Velocitywert, von dem die "Ton On" Farbe abhängt.
Bei "Note Off" fülle ich die entsprechende Arrayzelle mit "0", was mir dann eine andere Farbe (oder auch aus) anzeigt.
Daher machen es auch HSV Werte leichter, damit zu arbeiten, da ich den Hue Wert einfach addieren/subtrahieren kann, denn Helligkeit und Sättigung bleiben ja gleich.
Das Rechnen mit RGB Werten erfordert ggf. viel zusätzlichen Code.

Da MIDI nun leider eine festfelegte (und sehr niedrige) Baudrate hat, kommen die Noten des Instrumentes nicht schneller und gerade die Latenz zwischen "spielen" und "sehen" ist recht wichtig. Wenn eine LED erst z.B. 0.2 Sek. nach dem spielen leuchtet, kann man nicht mehr flüssig musizieren, da man sich visuell auf die LED "einschießt" und dann was anderes sieht , als das, was man hört.

Ich spiele auf dem Keyboard eine Note, dieses braucht ein paar ms, um das MIDI Signal zu erzeugen, dieses muss vom Optokoppler (6N138) empfangen und an den Nano weitergegeben und dort "berechnet" und schließlich zur Anzeige gebracht werden. Das alles dauert.
Sicher, ein Arduino rechnet deutlisch schneller, als zwei MIDI Signale nacheimander kommen und diese Zeit muss/werde ich nutzen, um das Array zu brechnen und an die LEDs zu senden.

Bisher schaffe ich es noch, so zu spielen, dass die LEDs noch "nachkommen", aber wenn ich oft nacheinander 5, 6, 7+ Noten gleichzeitig drücke oder loslasse, bemerke ich die Latenz irgedwann deutlich.

Gucky.

18

da krankt es schon.
Wozu in ein extra Array schieben, wenn die Adafruit_Neopixel ohnehin einen internen Puffer hat den man wie ein Array befüllen kann.

19

Ok, hast Recht, stimmt. So meinte und mache ich das auch, logo.

Gucky.

20

6N139 passt besser :wink: Da habe nie probleme mit gehabt.

Ich denke Du solltest dennoch den Code Posten.
Denn Mit diesem MIDI Signal kannst Du ja auch Expander bedienen ohne hörbare Latenz.
Und in meinem Hinterkopf ist da @my_xy_projekt der sich gut in sachen MIDI auskennt.
Ich vermute das hakt schon im vorhandenen Code. Und wieso nicht gleich richtig angehen? Musst da vielleich bissel gas geben beim Lernen des Codes aber dafür klappt das dann auch.
Übrich bleibt wenn es dann nicht klappt nur noch die Hardware. da käme dann der Vorschlag von @agmue zum Tragen.