Hallo, ich bin zur Zeit am bauen eines POV Globes und wollte hierzu einen Raspberry Pi nutzen sowie einen LED Streifen mit WS2812B LEDs. Folgende Eckdaten zum Projekt: LED-Streifen: 144 LEDs Geplante Auflösung des Globes: 144x288 Pixel = 41472 Pixel gesamt Geplante Wiederholfrequenz: 30 FPS Nun habe ich das mal durchgerechnet (natürlich erst nach dem Bestellen des LED-Streifens...) und komme zu folgenden Timings: 1,25µs bei 800kbit/s (50 + 144 * 3*8 * 1,25) µs = 4370 µs pro streifen/Zeile. Jetzt habe ich natürlich nicht bedacht dass ich das ja noch mit der horizontalen Auflösung multiplizieren muss: 4370µs * 288 = 1,258s pro Frame. Damit komme ich also niemals auf die 30 FPS (33,3 ms). Liege ich hier richtig und kann den LED-Streifen direkt wieder zurück schicken oder habe ich einen Denkfehler gemacht? Was für einen Streifen würdet ihr mir denn empfehlen für so eine Anwendung bzw. gibt es überhaupt streifen mit der nötigen Geschwindigkeit? Schaff ich das überhaupt mit dem PWM/PCM Ausgang des PI oder muss ich auf etwas anderes gehen (SPI, Display Ausgang, USB?)
Habe deine Fragestellung nur kurz überflogen und die Berechnung nicht angeschaut. Eine Möglichkeit wäre, den Streifen zu teilen und dann vom Raspberry parallel anzusteuern.
>Was für einen Streifen würdet ihr mir denn empfehlen für so eine >Anwendung bzw. gibt es überhaupt streifen mit der nötigen >Geschwindigkeit? Einen Streifen mit APA102 (SPI). Die PWM im WS2812 soll für POV auch nicht gut geeignet sein. Zu langsam.
holger schrieb: > > Einen Streifen mit APA102 (SPI). > Die PWM im WS2812 soll für POV auch nicht gut geeignet sein. > Zu langsam. Ok, hab ich mir jetzt angeschaut. Allerdings müsste ich, um das ganze bei 30 FPS bei 288 Spalten zu betreiben, die LEDs mit ca. 30 Mhz ansteuern. Schaffen das die APA102 und auch der Raspberry?
C0dR schrieb: > holger schrieb: >> >> Einen Streifen mit APA102 (SPI). >> Die PWM im WS2812 soll für POV auch nicht gut geeignet sein. >> Zu langsam. > > Ok, hab ich mir jetzt angeschaut. Allerdings müsste ich, um das ganze > bei 30 FPS bei 288 Spalten zu betreiben, die LEDs mit ca. 30 Mhz > ansteuern. Schaffen das die APA102 und auch der Raspberry? Ich plane auch gerade einen POV Globe zu bauen, allerdings mit einem STM32 uC und auch etwas kleiner (48 LEDs) wegen der Fliehkräfte ;-) Bei einem Test mit einem STM32F102 liefen die APA102 LED's mit gut 18 MHz SPI Takt. Über die Feiertage teste ich mal mit den 42MHz bei einem STM32F407 board. Ich würde mir an deiner Stelle aber mehr Gedanken zu der Stromversorgung machen... Die muss sich ja auch mit 30Hz mitdrehen ;-) Und bei 144 RGD LED's kannst du den max. Strombedarf mit gut 60mA pro WS2812 LED rechnen... Macht immerhin knapp 9A... Nicht schlecht ;-)
@C0dR (Gast) >Raspberry Pi nutzen sowie einen LED Streifen mit WS2812B LEDs. Schlechte Idee. DIe WS2812 sind eher langsam, die Himbeere nur mit Krampf schnell über SPI nutzbar. >LED-Streifen: 144 LEDs >Geplante Auflösung des Globes: 144x288 Pixel = 41472 Pixel gesamt >Geplante Wiederholfrequenz: 30 FPS Das sind satte 1800 U/min. >1,25µs bei 800kbit/s >(50 + 144 * 3*8 * 1,25) µs = 4370 µs pro streifen/Zeile. Ja. >Jetzt habe ich natürlich nicht bedacht dass ich das ja noch mit der >horizontalen Auflösung multiplizieren muss: >4370µs * 288 = 1,258s pro Frame. Sieht so aus ;-) >Damit komme ich also niemals auf die 30 FPS (33,3 ms). Liege ich hier >richtig und kann den LED-Streifen direkt wieder zurück schicken Ja. > oder habe ich einen Denkfehler gemacht? Nein. >oder muss ich auf etwas anderes gehen (SPI, Display Ausgang, USB?) SPI ist das Mittel der Wahl.
@ Reiner_Gast (Gast) >Ich würde mir an deiner Stelle aber mehr Gedanken zu der Stromversorgung >machen... Die muss sich ja auch mit 30Hz mitdrehen ;-) Schleifkontakte wurden vor über 100 Jahren erfunden und können viele Ampere übertragen.
Falk B. schrieb: > > Schleifkontakte wurden vor über 100 Jahren erfunden und können viele > Ampere übertragen. Ja, damit wollte ich das auch versuchen. Hatte erst daran gedacht, das ganze per Induktion zu Übertragen. Aber da bin ich mir nicht sicher, ob das reicht.
@ Reiner_Gast (Gast) >Ja, damit wollte ich das auch versuchen. Hatte erst daran gedacht, das >ganze per Induktion zu Übertragen. Aber da bin ich mir nicht sicher, ob >das reicht. Es reicht, wenn gleich 9A schon arg viel sind. Siehe Royer Converter.
Falk B. schrieb: > @ Reiner_Gast (Gast) > >>Ich würde mir an deiner Stelle aber mehr Gedanken zu der Stromversorgung >>machen... Die muss sich ja auch mit 30Hz mitdrehen ;-) > > Schleifkontakte wurden vor über 100 Jahren erfunden und können viele > Ampere übertragen. Falk B. schrieb: > @ Reiner_Gast (Gast) > >>Ja, damit wollte ich das auch versuchen. Hatte erst daran gedacht, das >>ganze per Induktion zu Übertragen. Aber da bin ich mir nicht sicher, ob >>das reicht. > > Es reicht, wenn gleich 9A schon arg viel sind. Siehe > > Royer Converter. Ich wollte es erstmal mit einem Kugellager als "Schleifkontakt" versuchen. Wenn das nicht hinhaut sieht der Royer Converter echt sehr interessant aus. Vielen Dank für die ganzen Infos und Tipps hier! @Reiner_Gast: Mich würden deine Ergebnisse mit dem STM32F407 interessieren, das könnte eventuell mein Ausweichplan sein falls ich aus dem Raspberry Pi nicht schnell genug die SPI Signale bekomme :)
Falk B. schrieb: > @ Reiner_Gast (Gast) > >>Ja, damit wollte ich das auch versuchen. Hatte erst daran gedacht, das >>ganze per Induktion zu Übertragen. Aber da bin ich mir nicht sicher, ob >>das reicht. > > Es reicht, wenn gleich 9A schon arg viel sind. Siehe > > Royer Converter. Danke für den Link, das schaue ich mir mal an. Bei den von mir geplanten 48 RGB LED's sinds zum Glück "nur" gut 3A...
C0dR schrieb: > @Reiner_Gast: Mich würden deine Ergebnisse mit dem STM32F407 > interessieren, das könnte eventuell mein Ausweichplan sein falls ich aus > dem Raspberry Pi nicht schnell genug die SPI Signale bekomme :) Ich schau mal, ob die APA102 die 42 MHz schaffen und werde dann berichten... Beim PI hätte ich jetzt bedenken, ob der das richtige Timing schafft für die einzelnen Segmente. Wenn du bei den 288 Pixeln Breite bleibst, dann wären das 30x288 = 8640 Datenaktualisierungen pro Sekunde, die möglichst genau erfolgen müssen damit das Bild ruhig bleibt.
@ Reiner_Gast (Gast) >Beim PI hätte ich jetzt bedenken, ob der das richtige Timing schafft für >die einzelnen Segmente. Wenn du bei den 288 Pixeln Breite bleibst, dann >wären das 30x288 = 8640 Datenaktualisierungen pro Sekunde, die möglichst >genau erfolgen müssen damit das Bild ruhig bleibt. Und das bitte auch phasensynchron. Wenn gleich die Himbeere rein von der Hardware genug pOwer dafür hat, glaube ich nicht, daß man mit den üblichen Mitteln und dem darauf laufenden Linux das hinbekommt. Dazu müßte man das Ding pur ohne Linx porgrammieren oder wenigstens einen echt guten Low Lever Treiber schreiben. Beides ist ziemlich anspruchsvoll. Ein AVR oder einer der aktuellen 32 Bitter OHNE Linux und ähnliches ist das DEUTLICH einfacher handhabbar. Braucht man wiklich 42 MHz, um die LEds schnell genug zu laden? Kann man einfach ausrechnen. f_SPI = f_fps N_columns N_LED * Bit_per_led macht bei 30 fps, 288 Spalten, 144x3 LEDs (RGB) * 8 Bit/LED = 29,9 MHz. Uuups ;-)
Falk B. schrieb: > Ein AVR oder einer der aktuellen 32 Bitter OHNE Linux und ähnliches ist > das DEUTLICH einfacher handhabbar. Braucht man wiklich 42 MHz, um die > LEds schnell genug zu laden? Kann man einfach ausrechnen. > > f_SPI = f_fps N_columns N_LED * Bit_per_led > > macht bei 30 fps, 288 Spalten, 144x3 LEDs (RGB) * 8 Bit/LED = 29,9 MHz. > > Uuups ;-) Naja... eigentlich kommst es noch schlimmer... 1.) Die APA102 brauchen 32 Bits pro RGB LED (die ersten 8 Bits sind für die allgemeine Strombegrenzung für die 3 LEDs gedacht) 2.) Es wird ein Startframe (32x 0-bit) und ein Endframe (32x 1-Bit) benötigt. Macht demnach rechnerisch 146 LEDs Somit Gibt das ganze dann 30 x 288 x 146 x 32 = 40,4 MHz Doppel-Upps ;-)
Reiner_Gast schrieb: > Ich plane auch gerade einen POV Globe zu bauen, > allerdings mit einem STM32 uC Ein STM32 mit 8-Bit parallel über DMA hat vergleichbar wenig RAM-Overhead im "Grafikspeicher" und holt so ziemlich alles raus, was an Taktrate mit APA102 bzw. WS2812 möglich ist. Soll das Bild on the fly berechnet werden? Oder soll ein Film von einer SD-Karte abgespielt werden? Eventuell wäre ein RasPi Zero vielleicht im Vorteil. Kann der RasPi 8-Bit parallel über DMA? Und muss man dazu eigene Linux-Treiber programmieren? Der µC/RasPi soll doch im drehbaren Teil sein und darf weder groß noch schwer sein, oder?
:
Bearbeitet durch User
Torsten C. schrieb: > Soll das Bild on the fly berechnet werden? Oder soll ein Film von einer > SD-Karte abgespielt werden? Bei meinem Vorhaben geht's um statische Darstellung bzw. on the fly... Wie das bei dem Vorhaben von C0dR ausschaut, kann ich nicht sagen. > Eventuell wäre ein RasPi Zero vielleicht im Vorteil. > Kann der RasPi 8-Bit parallel über DMA? Glaube ich nicht. Was sollten denn 8-Bit parallel bei einem einzelnen Streifen bringen? > Der µC/RasPi soll doch im drehbaren Teil sein und darf weder groß noch > schwer sein, oder? Da sich hier Fliehkräfte entwickeln die ausgewuchtet werden müssen, ist klein und leicht vorteilhaft...
Reiner_Gast schrieb: > Was sollten denn 8-Bit parallel bei einem einzelnen Streifen bringen? Die Daisy Chain an sieben Stellen unterbrechen und dann an acht Stellen einspeisen, damit man auf eine höhere Drehzahl kommt und das Bild nicht flackert.
:
Bearbeitet durch User
Torsten C. schrieb: > Reiner_Gast schrieb: >> Was sollten denn 8-Bit parallel bei einem einzelnen Streifen bringen? > Die Daisy Chain an sieben Stellen unterbrechen und dann an acht Stellen > einspeisen, damit man auf eine höhere Drehzahl kommt und das Bild nicht > flackert. Ist aber nur was für gute Augen und ruhige Finger... bei den Stripes mit 144 LED/m sind das bei 5 mm LED Außenmaß nur gut 2 mm Abstand bis zum nächsten LED-Gehäuse ;-)
...die PWM der WS2812B arbeitet nur mit um die 400Hz wimre. Diese scheiden also definitiv aus, sonst hättest Du bei 30fps komische Muster alleine schon durch die PWM. Die APA102 verwenden wohl ZWEI PWM Frequenzen: Eine niedrige für die "globale" Helligkeit pro LED (582 Hz) und eine hohe für die RGB-Werte (19.2KHz), siehe auch hier: https://cpldcpu.wordpress.com/2014/08/27/apa102/ Ob sie für Dein Vorhaben geeignet sind hängt also auch davon ab, ob die 582Hz PWM zu einem konstanten "ein" wird wenn man auf max. Helligkeit geht. Andernfalls hättest Du dann ebenfalls mit Artefakten zu rechnen.
Naja, das Vorhaben ist in Summe mehr als ambitioniert. Bei 30 fps und 288 Spalten macht das 8640 Hz Spaltenfrequenz. Man müßte also eine PWM mit 8,6 kHz laufen lassen und das synchron zur Drehung. Machbar, aber anspruchsvoll. Die guten, alten TLC5940 & Co lassen sich mit bis zu 30 MHz takten, dort hat man eine Chance. Trotzdem würde ich empfehlen, das Alles erst mal ne Nummer kleiner zu bauen, vielleicht mit 1/4 der LEDs.
Falk B. schrieb: > Naja, das Vorhaben ist in Summe mehr als ambitioniert. Bei 30 fps > und > 288 Spalten macht das 8640 Hz Spaltenfrequenz. Man müßte also eine PWM > mit 8,6 kHz laufen lassen und das synchron zur Drehung. Machbar, aber > anspruchsvoll. Die guten, alten TLC5940 & Co lassen sich mit bis zu 30 > MHz takten, dort hat man eine Chance. Trotzdem würde ich empfehlen, das > Alles erst mal ne Nummer kleiner zu bauen, vielleicht mit 1/4 der LEDs. Wie gesagt... eben deswegen plane ich meines ja auch "nur" mit 48 LEDs und gut 120 Pixel Breite
Und dann?
Nur 0x00 und 0xFF senden, damit es keine Interferenzmuster mit dem PWM
gibt?
.oO( Welch ein Hinweis von adrock,
da hätte ich auch schon mal dran denken können.)
C0dR schrieb: > Ich wollte es erstmal mit einem Kugellager als "Schleifkontakt" > versuchen. Wenn das nicht hinhaut sieht der Royer Converter echt sehr > interessant aus. > Vielen Dank für die ganzen Infos und Tipps hier! Die eignen sich leider nicht für sowas. Man hat keinen permanenten Kontakt, da doch etwas Luft inkl. Schmiere dazwischen. Außerdem kann es bei größeren Strömen zu Funken kommen, die mit der Zeit den Kugellager beschädigen. Obs für die ersten Tests reicht, kann ich aber nicht sagen :) MfG, Andreas
Für Schleifer hatte ich mir mal Ersatzteil-Kohlebürsten für Modellbau-Motoren besorgt. Ich weiß nicht, wie lange eine Kupferschicht auf einem PCB hält. Vielleicht könnte man die Schleifringe gleich auf das Platinen-Layout ätzen. Ich hatte damals Märklin-Ersatzteile genommen. Irre teuer. Vielleicht gibt es bei HobbyKing oder so auch billigere.
Die eigentliche "Ausschüttung" der Pixeldaten würde ich per Arduino oder Teensy machen, da ist man "näher dran" an der Hardware. Empfang der Daten z.B. per WLAN (UDP), Stromversorgung über Schleifringe oder Kugellager. Um die erforderliche Drehzahl zu reduzieren: mehrere Streifen, z.B. 4 oder 6 von Pol zu Pol nehmen. Um die zu transferierende Datenmenge zu reduzieren (allerdings dann nicht mit Arduino wegen zu wenig Speicher), einen internen Bildpuffer über mehrere Umdrehungen ausgeben ... reduziert zwar die Frame-Rate, macht das Bild aber flackerfrei(er). Schleifring 230V 10A vom Chinamann für ca. 20,- https://i.ebayimg.com/images/g/gqIAAOSw9GhYiYTb/s-l1600.jpg
:
Bearbeitet durch User
Torsten C. schrieb: > Reiner_Gast schrieb: >> Ich plane auch gerade einen POV Globe zu bauen, >> allerdings mit einem STM32 uC > > Ein STM32 mit 8-Bit parallel über DMA hat vergleichbar wenig > RAM-Overhead im "Grafikspeicher" und holt so ziemlich alles raus, was an > Taktrate mit APA102 bzw. WS2812 möglich ist. > > Soll das Bild on the fly berechnet werden? Oder soll ein Film von einer > SD-Karte abgespielt werden? > > Eventuell wäre ein RasPi Zero vielleicht im Vorteil. > Kann der RasPi 8-Bit parallel über DMA? > Und muss man dazu eigene Linux-Treiber programmieren? > > Der µC/RasPi soll doch im drehbaren Teil sein und darf weder groß noch > schwer sein, oder? Also mein Plan war, dass die einzelnen Frames von einer PC Software (Selbstgeschrieben) aus einem Video vorbereitet werden und die fertigen Pixeldaten über LAN an den Raspberry übertragen werden, dieser buffert sich dieses und zeigt es dann auf dem Globe an. 40 Mhz ist deutlich mehr als ich gedacht hab, eventuell sollte ich wirklich 2 Streifen nehmen und die FPS halbieren. Bisher hab ich auf dem PI einen Realtime Kernel drauf, laut Datenblatt kann dieser SPI bis 125 Mhz. Ich hatte gehofft damit bekomme ich das hin. Würde denn der STM32 hier mehr Sinn machen?
C0dR schrieb: > Bisher hab ich auf dem PI einen Realtime Kernel drauf, laut Datenblatt > kann dieser SPI bis 125 Mhz. Es geht ja nicht nur um die reine Transferrate. Du musst auch das Timing präzise hinbekommen.
> C0dR schrieb: >> @Reiner_Gast: Mich würden deine Ergebnisse mit dem STM32F407 >> interessieren, das könnte eventuell mein Ausweichplan sein falls ich aus >> dem Raspberry Pi nicht schnell genug die SPI Signale bekomme :) > > Ich schau mal, ob die APA102 die 42 MHz schaffen und werde dann > berichten... > @C0dR: Kurzes Update hierzu... mit 22,4MHz SPI Takt erfolgt die APA102 Ausgabe noch fehlerfrei... ab 24MHz SPI Takt fangen die Fehler an...
Reiner_Gast schrieb: >> C0dR schrieb: >>> @Reiner_Gast: Mich würden deine Ergebnisse mit dem STM32F407 >>> interessieren, das könnte eventuell mein Ausweichplan sein falls ich aus >>> dem Raspberry Pi nicht schnell genug die SPI Signale bekomme :) >> >> Ich schau mal, ob die APA102 die 42 MHz schaffen und werde dann >> berichten... >> > > @C0dR: > > Kurzes Update hierzu... > mit 22,4MHz SPI Takt erfolgt die APA102 Ausgabe noch fehlerfrei... > ab 24MHz SPI Takt fangen die Fehler an... Ach mist, das ist echt schade...heißt ich muss dann wohl auf halbe Umdrehungszahl/Framerate gehen und zwei Streifen nutzen...
Hatte auch mal überlegt, dass ich mir einen solchen Globe baue, fand aber leider nie die Zeit dafür! Aber hier ein Gedanke, den ich damals hatte. Wenn du mit den FPS etwas runter gehst und dafür aber 2 LED Streifen gegenüberliegend machst (der eine Zeigt Spalte 1,3,5,..usw an und der andere Spalte 2,4,6,..usw) dann könnte man etwas Rechenleistung einsparren ohne gravierenden Qualitätsverlust des Bildes! Es kam aber nie soweit, dass ich das mal ausprobieren konnte, also auch keine Garantie darauf, dass es wirklich so ist! Gruß Josef
Josef T. schrieb: > Hatte auch mal überlegt, dass ich mir einen solchen Globe baue, > fand > aber leider nie die Zeit dafür! > Aber hier ein Gedanke, den ich damals hatte. Wenn du mit den FPS etwas > runter gehst und dafür aber 2 LED Streifen gegenüberliegend machst (der > eine Zeigt Spalte 1,3,5,..usw an und der andere Spalte 2,4,6,..usw) dann > könnte man etwas Rechenleistung einsparren ohne gravierenden > Qualitätsverlust des Bildes! Es kam aber nie soweit, dass ich das mal > ausprobieren konnte, also auch keine Garantie darauf, dass es wirklich > so ist! > > Gruß > Josef Ja das ist dass was ich meinte mit halber Framerate und zwei streifen.
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.