Experimente mit MY9221 und MY9268 LED Treiber IC für Pixel

2bl · 15. November 2012

Hallo zusammen!

Ich habe MY9221 Treiber ICs bekommen, und damit ein paar kleine Test-Matrix-Elemente gebaut. Meine Erfahrungen möchte ich hier teilen.

Die Highlights des IC:
- 12 Kanäle
- PWM mit 8, 12, 14 oder 16 Bit
- Bildwiderholrate >1kHz bis 256 kHz, je nach Farbtiefe
- und vieles mehr...

Zur Ansteuerung habe ich zuerst einen Spartan3 FPGA verwendet. Nicht weil es nötig ist solche Geschütze aufzufahren, sondern eher aus Neugier wie schnell das geht. VHDL code anbei.MY9221.zip
Dann habe ich auf Basis von Pesis "DMX -> WS2801" Assembler code für Atmegas die Bitbangroutine erweitert (hingepfuscht trifft es eher), um die etwas kompliztierteren Datenworte an den IC zu senden. Ich habe hier neulich gelesen, das es auch via hard-SPI geht, wenn man die Frequenz der Clock-Rate halbiert, der IC möchte seine seriellen Daten nämlich zu beiden Clock-Flanken bekommen... Eigentlich klar, und deutlich eleganter!

Ich verwende in beiden Fällen den 14 Bit Betriebsmodus, und rechne die 8 Bit DMX Werte mit einer Lookup-Tabelle in eine für das Auge linearere Dimmerkurve um. Das ist tatsächlich ein Unterschied wie Tag und Nacht, da sind ganz andere Farben drin als ohne! Wunderschön!

Die Platinen stammen von iteadstudio, wie immer spitzen Preis für die kleinen Dinger, und in 2 Wochen waren sie da! (9,90 USD für 10 Platinen doppelseitig durchkontaktiert, max 5x4 cm², 25 EUR Porto bei Expresslieferung)

Hier ein paar Fotos und zwei Videos, demnächst mehr Denn: Nach der Matrix ist vor der Matrix!!
Ich habe auch eine Platine für den MY9268 gemacht, der 16 Kanäle im 8:1 Multiplexbetrieb steuert. An diesen passen dann etwa 40 RGB LEDs, aber hierfür habe ich die Ansteuerung noch nicht fertig, die ist nochmal etwas komplizierter.

36 Stück 3535 RGB LEDs mit diffuser Optik und schwarzer Front, Abstand 8mm, 9 Stück MY9221
Hier ist erstmal (meine) Grenze des Routbaren erreicht, denn bei engeren LEDs rücken die Treiber auf der Rückseite noch weiter zusammen, und auf 2 Lagen wird es dann zu eng. ALternativ gibt es den MY9221 auch als QFN, dann ist er nur 4x4 mm² groß Für größere Flächen in dieser Dichte muss man vermutlich auch den LED Strom von derzeit 18 mA deutlich reduzieren, da die ganze Sache sonst einfach zu hell ist... Kommt aber auf den Anwendungszweck an.

16 Stück 5050 RGB LEDs, diffus, schwarze Front, 4 Treiber ICs, Abstand 12.5mm
Das gleiche, aber größere LEDs und Mehr Abstand.

4 Stück 5050 LEDs, ein MY9221, Abstand 25 mm
Das ganze als Streifen. Entsprechend aneinendergereiht und in Plastikröhren wird eine "Lattenzaun"-Matrix daraus, bei Bedarf auch mit kleinerem oder größerem Pitch.

Externer Inhalt www.youtube.com

Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.

Durch die Aktivierung der externen Inhalte erklären Sie sich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.

www.youtube.com/watch?v=4tEjphNOlMk

turi · 15. November 2012

Ja, man sieht, dass Du Dir wie immer Gedanken gemacht hast. Der IC ist schon nicht schlecht, aber etwas ungewöhnlich in der Ansteuerung. Dafür sind eben die max. 16 Bit nicht zu unterschätzen, wie Du auch schon sagst. Also insgesamt ist das Teil schon eine gute Sache. Wissen sollte man noch, dass es wohl eine Art Patentstreit in China zwischen MySemi und Macroblock gibt. Macroblock meint, dass diese Technik wohl von Ihnen stammt. Aber das können wir uns gemütlich von Außen ansehen.

Unsere Platine als Streifen mit dem MY9221 ist noch im Prototyp-Stadium. Ich bin noch nicht dazu gekommen, die zu löten. Wenn sie fertig ist, stell ich die auch mal mit rein.

Pesi · 16. November 2012

Ja, krasse Scheisse!

mit 8 mm Pixel-Pitch ist das halt schon Hi-Res-Video...

und ich bin immer wieder erstaunt, wie schnell Du mit was fertigem daher kommst, bei turi, Basti und mir ist das gerade noch im "Wir denken mal drüber nach"-Stadium....

coole Sache jedenfalls, und ja, wenn man einfach den Clock-Ausgang mit nem Flipflop halbiert, kann man auch den HW-SPI nehmen, ansonten halt Bitbang...

Counterfeiter · 16. November 2012

Sehr geil... freu mich schon die Teile mal live zu sehen....

8 mm Abstand? Baust du ein LED TV für die nächste Fußball EM oder WM?

Zitat von 2bl

der IC möchte seine seriellen Daten nämlich zu beiden Clock-Flanken bekommen... Eigentlich klar, und deutlich eleganter!

Hm, Ansichtssache... bei 01 Wechsel hat man auf der Datenleitung immer noch die selben Frequenzen wie vorher, nur auf der Clockleitung die Hälfte... ob das den Vorteil bringt?
Jedenfalls macht es erstmal schwieriger das mit einem µC anzusteuern... die AVR Reihe kann es IMO nicht... weiß nicht wie das bei PIC oder MSP430 aussieht....

Pesi · 16. November 2012

Ja, wie schon gesagt (war ja Dein Vorschlag, und von Neni kam er auch noch mal), einfach mit nem Flipflop den Takt halbieren...

Und, das hatten wir doch schon mal irgendwo: Bei nem 010101....-Wechsel, also höchste Frequenz auf der Datenleitung, hast Du auf der Takt-Leitung die selbe Frequenz, weil die ja auch bei jedem Bit wechselt...

beim normalen SPI hast Du auf der Clock-Leitung die doppelte Frequenz, weil's ja pro Bit 2x wechselt...

Counterfeiter · 16. November 2012

Da hast du natürlich recht... ja da hatten wir schon mal darüber gesprochen, da hat es bei mir aber noch nicht klick gemacht

Mir war so, als wenn MOSI in der Zeit der Bitpause... also der nicht zu erkennenden Flanke immer zu High gesetzt wird.

Aber das passiert wohl nur in den Bytepausen und nicht in den Bitpausen....

So gesehen ergibt das natürlich schon Sinn mit der Takthalbierung der Clockleitung...
Laut Wikipedia kann man wohl nicht mal behaupten die Chinesen machen kein ordentliches SPI....

Zitat

Ein Protokoll für die Datenübertragung wurde von Motorola zwar nicht festgelegt, doch haben sich in der Praxis vier verschiedene Modi durchgesetzt...

Grüße

Basti

P.S. Wenn die Teile wirklich so geil sind, wovon ich ausgehe, verklingel ich mein WS2803 Tisch bei Ebay und bau den mir neu mit den ICs hier auf

leddie · 17. November 2012

Geilomat bzw GEILOMATRIX !

2bl · 18. November 2012

Zitat von Counterfeiter

Hm, Ansichtssache...

ich habe mich darauf bezogen, das es elegant ist, den Hardware-SPI zu benutzen, und den Takt anschliessend zu halbieren, anstelle von Bitbang
Aber das mit der EMI-reduction macht schon auch irgendwie Sinn, wie Pesi beschrieb...

Zitat von Pesi

mit 8 mm Pixel-Pitch ist das halt schon Hi-Res-Video...

Schon! Ich würde gerne etwas bauen, auf dem man auch Videos schauen kann. Aber das *so* flächig zu bauen hat leider 2 "Nachteile"...

1) Viel zu hell... Lösung: mit dem Strom massiv 'runtergehen. Alternativ: 3528 LEDs statt den 3535 nehmen, die sind (aus welchen Gründen auch immer) auch massiv billiger, und etwas dunkler. Das bringt uns auch zu Nachteil 2:

2) Zu teuer... Die hohe Dichte an LEDs und Treibern geht massiv ins Geld! Wie schon angesprochen sind 3528er RGB LEDs deutlich günstiger. Wenn die Helligkeit beim 1-aus-8 Multiplexen auch noch ausreichend ist (evtl. dann wieder mit etwas mehr Strom?), dann wäre der MY9268 die günstigere Wahl. im 8fach Multiplexing versorgt dieser 128 Kanäle, kostet aber ungefähr genausoviel wie der MY9221, der 12 Kanäle bestromt. Der Nachteil hier ist die deutlich komplexere Ansteuerung. Der MY9268 braucht neben den Daten und der Daten-clock auch die Greyscale-Clock, und dann müssen auch noch im richtigen Moment die Spaltentreiber zum Multipleximg umgeschalten werden. Keine Ahnung, ob das mit Bitbang noch funktioniert, wenn nebenbei auch noch DMX empfangen/gesentet werden soll? In einem kleinen FPGA ist die Implementierung natürlich eine reine Fleissaufgabe

Anbei noch meine Idee zum Platinenlayout für den MY9268. So natürlich nicht dicht-an-dicht anreihbar, aber leider ist die Platinenrückseite hinter den LEDs voll mit Durchkontaktierungen für die Zeilen-Spalten-Logik. Evtl. würde es mit einer Huckepack-Platine funktionieren, die den IC und die Peripherie trägt, und die Zeilen- und Spaltenverbindungen müssen dann irgendwo zwischen den LEDs Platz finden... Noch nicht zuende durchdacht jedenfalls...

Viele Grüße
Andre

Pesi · 18. November 2012

Krass, auch schon wieder gleich fertig, die "Idee"....

da wäre dann vielleicht mal ne Multilayer-Platine angesagt, also eine Seite LEDs, andere Seite Chip mit Zubehör, Zwischenlage die Matrix-Verdrahtung...?

klar, richtig Video wird natürlich teuer, rein wegen der Menge... wenn man nur mal von 800x600 ausgeht (ca. PAL-Auflösung), dann wären das ja schon 480.000 Pixel - auch mit den billigeren PLCC4 wird man alles in allem kaum unter 30 Cent/Pixel kommen, kann man dann ja ausrechnen, was die ganze Videowand kostet, die dann aber mit 6,40 m x 5,12 m und 8 mm Pitch schon ein echter fetter Outdoor-TV ist...

Counterfeiter · 30. November 2012

Nabend,

hab nun auch nen paar Tests gemacht. Sieht wirklich sehr schick aus.
Nur die Gamma von 8 auf 16 Bit von hier erstmal genommen: http://www.mikrocontroller.net/articles/LED-Fading
finde ich persönlich gewöhnungsbedürftig.
Welche hast du genommen, Andre?
Das D Flip Flop kann man beim XMega auch weglassen, hab ich gerade herausgefunden. Hab bis jetzt eine Rate von 4 MHz ohne das ich den Prozessor belaste... also wieder Daten per DMA... geht sicher noch ein wenig mehr, muss aber auch nicht sein... Sind ja so schon 3000 LEDs.

Grüße

Basti

2bl · 30. November 2012

Hi Basti,

ich habe auch die in dem Thema verlinkte Excel-Tabelle benutzt, rechne allerdings auf 14 Bit um - das erschien mir ein guter Kompromiss zwischen Farbtiefe und Wiederholrate.

Konkret kam bei mir das hier heraus:

Code

--


type rom_array_t is array (0 TO 255) of integer;


-- exponential transfer function to translate a 8-Bit value into a 14 Bit value
 
CONSTANT rom_array  : rom_array_t :=
(0,21,21,22,22,23,23,24,25,25,26,27,27,28,29,30,30,31,32,33,34,35,36,37,38,
39,40,41,42,43,44,45,46,48,49,50,52,53,54,56,57,59,60,62,64,65,67,69,71,73,
75,77,79,81,83,85,87,90,92,94,97,100,102,105,108,111,114,117,120,123,126,129,
133,136,140,144,148,152,156,160,164,168,173,178,182,187,192,197,203,208,213,
219,225,231,237,243,250,257,263,270,278,285,293,300,308,317,325,334,343,352,
361,371,381,391,401,412,423,434,446,458,470,482,495,509,522,536,550,565,580,
595,611,628,644,662,679,697,716,735,755,775,795,816,838,861,884,907,931,956,
982,1008,1035,1062,1090,1120,1149,1180,1211,1244,1277,1311,1346,1382,1419,
1456,1495,1535,1576,1618,1661,1705,1751,1798,1846,1895,1945,1997,2050,2105,
2161,2219,2278,2339,2401,2465,2531,2598,2667,2738,2811,2886,2963,3042,3123,
3207,3292,3380,3470,3562,3657,3755,3855,3958,4063,4172,4283,4397,4514,4634,
4758,4885,5015,5149,5286,5427,5571,5720,5872,6029,6190,6355,6524,6698,6877,
7060,7248,7441,7640,7843,8052,8267,8487,8714,8946,9184,9429,9680,9938,10203,
10475,10755,11041,11336,11638,11948,12266,12593,12929,13274,13628,13991,
14364,14747,15140,15543,15958,16383);

Alles anzeigen

Ich empfinde die Kurve als sehr angenehm, habe aber noch nicht groß verglichen mit anderen Parametern in der Exponentialfunktion!

Viele Grüße
Andre

Counterfeiter · 30. November 2012

Ah, danke...

Siehste daran lags. Hab nicht die excel-datei geladen und gleich aus dem geposteten Source auf der Seite rauskopiert. Aber das sah mir gleich etwas komisch aus, jetzt wo ich deine sehe glaub ichs.

Mit deiner funktionierts Weltklasse

Danke,

Basti

synvox · 1. Dezember 2012

Es gibt eigentlich eine recht einfache Formel, womit sich die Wertetabellen für die Gamma-Korrektur einfach, flexibel und akkurat nach geltenden Standards (Potenzfunktion und nicht Exponentialfunktion) berechnen lassen:

wobei s für die Bittiefe der Quelle (source), t für die Bittiefe des Ziels (target) und g für das Gamma steht.

Will man zum Beispiel 8-Bit Werte in eine 16-Bit-PWM gamma-korrigiert bei einem Gamma von 2,2 (heutiger Standard für Monitore) überführen, setzt man für s = 8, für t = 16 und für g = 2,2 ein.

Mit dem Gamma-Wert kann man etwas spielen. Standard für Monitore ist heute wie gesagt 2,2, aber Apple Macs hatten früher z.Bsp. 1,8. Die Werte können auch je nach Monitor und dessen Einsatzgebiet schwanken. Für LED-Panels kenne ich die optimalen Werte nicht, würde aber vermuten, dass sie nicht gross von denen für Monitore abweichen.

Gruss
Neni

Pesi · 2. Dezember 2012

Zitat von synvox

(Potenzfunktion und nicht Exponentialfunktion)

Ja, genau so hatte ich meine Tabelle auch erstellt, da ich kein Excel kann, hardcore jeden Wert mit dem Taschenrechner nach der Formel y=(x^g)*k, wobei ich k vorher so berechnet hatte, dass halt dann bei x=255 für (y^g)*k der Maximalwert der Zielauflösung raus kommt... und dann eben im unteren Bereich noch bisschen "geschoben", so dass da die Werte enger beieinander liegen, ich also die untersten Stufen "besser ausnütze"

Zitat von synvox

Standard für Monitore ist heute wie gesagt 2,2, aber Apple Macs hatten früher z.Bsp. 1,8.

Genau aus dieser Überlegung (sowohl alter Mac vorhanden wie auch aktueller PC) habe ich mal ein Gamma von 2 genommen, und das dann direkt im µC rechnen lassen - weil es so simpel ist, x^2 = x*x, das kann der µC auch easy, 2 Werte (also 2x der selbe) multiplizieren...

bis jetzt nur für 8 Bit auf WS2801, also x*x, und dann das High-Byte vom Ergebnis genommen, aber das hat schon gut funktioniert, ganz unten nicht ganz so fein abgestuft wie die "korrigierte Tabelle", aber insgesamt eben ne Gamma-Korrektur, also nicht mehr so "ab 50% ist's eh' nur noch hell" wie ohne Korrektur...

wenn ich meine MY9221-Ausgaberotine mal fertig habe (dauert noch, morgen wieder von 13:00 - 22:00 auf nem Weihnachtsmarkt Kapellen mischen und dann Anlage und Bühne Abbauen, am Montag Kram im Lager sortieren etc.), werde ich dann mal einfach x*x rechnen, und das 16-Bit-Ergebnis auf den MY9221 geben, und ich glaube, das wird gar nicht so schlecht

ist mir klar, dass 255*255 nicht 65.535 sind, sondern nur 65.025, aber ich denke nicht, dass man da nen großartigen Unterschied sieht, man erreicht halt nicht die maximal mögliche Helligkeit, sondern nur ca. 99%, aber eben der Strahlungsleistung, was ja für die gesehene Helligkeit praktisch kein Unterschied zu 100% ist...

P.S.:

Zitat

guter Kompromiss zwischen Farbtiefe und Wiederholrate

Wenn ich das Protokoll richtig verstehe, musst Du doch immer 16 Bit pro Kanal rein schieben, egal, wie viel Du davon tatsächlich benutzt....? - also bringt ein reduzieren auf 14 Bit auch keinen Vorteil hinsichtlich Wiederholrate...(?)

synvox · 2. Dezember 2012

Zitat von Pesi

Ja, genau so hatte ich meine Tabelle auch erstellt, da ich kein Excel kann, hardcore jeden Wert mit dem Taschenrechner nach der Formel y=(x^g)*k

Dass du die Potenzfunktion für die Gammakorrektur auch kennst, hatte ich schon vermutet . Du hast ja selbst in nem Thread mal geschrieben, dass du dir die Grundlagen der Gammakorrektur mal genau angeschaut hast. Das ist eben auch genau das, was man doch etwas öfter bei Nutzung solcher Verfahren machen müsste, bevor man sich allzusehr auf vorberechnete Tabellen verlässt, meine ich. Mikrocontroller.net hat zweifellost sehr viele tolle Tutorials etc. zu bieten, ist aber meiner Meinung nach für die Recherche von physikalischen Grundlagen-Zusammenhängen nicht immer die Quelle der Wahl bzw. sollte man dabei zumindest noch andere Quellen beiziehen.

Übrigens setzt sich der Faktor k aus 'deiner' Funktion genau aus den Elementen zusammen, welche ich in Abhängigkeit der Bittiefen ausgeschrieben habe, also k = (2^t-1)/(2^s-1)^g.

Wenn man sich solche mathematischen Zusammenhänge auch mal graphisch anschauen (ist oft sehr hilfreich) und dabei mit den Parametern 'spielen' möchte, kann ich den Desmos Calculator (gratis Webapplikation) empfehlen.

Zitat von Pesi

Wenn ich das Protokoll richtig verstehe, musst Du doch immer 16 Bit pro Kanal rein schieben, egal, wie viel Du davon tatsächlich benutzt....? - also bringt ein reduzieren auf 14 Bit auch keinen Vorteil hinsichtlich Wiederholrate...(?)

Da hat Andre schon recht bzw beide etwas . Beim MY9221 ist die Wiederholrate der PWM-Zyklen, also die PWM-Frequenz abhängig von der eingestellten Bittiefe der PWM (ist ja klar ). Das kann sich nun insofern auch auf die maximal mögliche Framerate auswirken, als dass je nach Anzahl der in Serie geschalteten MY9221er die Zeit für eine komplette Frame-Übertragung kleiner sein kann als die Zeit für einen kompletten PWM-Zyklus.
Das hat nun bei Standard-Pixel-Ansteuerungen (jeder Pixel-Farbkanal hat eigenen MY9221-PWM-Kanal) nicht so viel Bedeutung, weil auch 16 Bit-PWM noch eine ausreichend hohe PWM-Frequenz bietet. Und bei dieser Art Ansteuerung muss man auch bei kurzkettigen MY9221-Anordnungen nicht mehr als 25 - 30 fps erreichen können. Bei langkettigen Anordnungen wird die maximal mögliche Framerate dann sowieso wieder durch die Länge des Datenstroms limitiert.
Hingegen kann bei einer Matrix-Ansteuerung mit typisch kurzkettiger MY9221-Anordnung die PWM-Frequenz durchaus limitierend werden, weil ja da wegen dem zeilenweisen Bildaufbau deutlich höhere Bildwiederholraten gefordert sind, damit kein Flimmern mehr bemerkt wird. Je nach Zeilen-Anzahl kann da 16-Bit-PWM u.U. schon nicht mehr möglich sein, weil pro Zeile zumindest ein voller PWM-Zyklus durchlaufen werden muss.

Gruss
Neni

2bl · 2. Dezember 2012

Hallo zusammen!

ja, ich bezog mich nicht auf die Dauer für die Datenmenge, also die Zahl der Data clock cycles. DIese ist natürlich konstant.

Aber bei 16 Bit dauert ein Greyscale-Clock Zyklus 65k Takte, und bei 14 Bit nur 16k. Die Bildwiderholrate ist also höher.
Siehe anliegend die Tabelle aus dem Datenblatt:

@Neni: vielleicht kannst Du mir bei einem Verständnissproblem betreffend den MY9268 helfen? Ght im Prinzip um das gleiche Thema. Daten und Datenclock müssen hier ja getrennt reingeschoben werden, weil der MY9268 keine interne Greyscale Cloock hat, und man ausserdem im richtigen Moment (also nach der richtigen Anzahl an Greyscale clocks) noch die Zeilenmuliplexer umschalten muss.

Wenn ich mir jetzt die Grafik im Datenblatt ansehe, bin ich nicht sicher, ob ich die Greyscale Clock unabhängig von der Fütterung mit neuen Frames laufen lassen kann, oder ob ich eine Reihenfolge
"Datenzyklus" - "ganzzahliges Vielfaches des Greyscalezyklus - "Datenzyklus" - "ganzzahlig...
einhalten muss?
Beim My9221 kann man ja wählen, wie verfahren soll, wenn ein Datenzyklus während einem laufenden Greyscale Zyklus eintrifft:
1) den laufenden Zyklus fertigmachen, dann neuen Zyklus mit den neuen Daten
2) Zyklus abbrechen und sofort neuen starten
3) immer nur einen Greyscale Zyklus pro empfangenem Datenzyklus (wüsste nicht wo das nützlich ist?)

Anbei noch die Grafik aus dem 9268 Datenblatt, über Hinweise bin ich dankbar! Ansonsten probiere ich einfach beides mal aus. Angenehmer wären mir ja zwei getrennt laufende Prozesse - Greyscale und Daten - die nicht gegenseitig aufeinander warten müssen?

Viele Grüße
Andre

Pesi · 2. Dezember 2012

Ach, ja, beim Multiplexen dann, da ging's dann wohl eher um den MY9268....?

EDIT: Oh, Post dazwischen, lese ich später, muss jetzt weg...

Zitat von synvox

bevor man sich allzusehr auf vorberechnete Tabellen verlässt, meine ich.

Ja, die von Mikrocontroller.net hatte ich vor Jahren auch schon mal ausprobiert, haben mir aber auch überhaupt nicht gefallen...

dort war auch der Wikipedia-Artikel verlinkt, in dem es eben heisst, die Reizstärke zu Empfindung ist eine Potenzfunktion - dort wurde für sehen ^3 genannt, das war aber zu krass, die Tabelle in dem verlinkten Post wurde dann mit ^1,5 gerechnet, die ist aber doch etwas zu "sanft" - für meinen Geschmack passt ^2 eben ganz gut, umso besser, dass sich das so trifft, dass es auch ein µC leicht rechnen kann...

ist wohl auch ein gängiger Wert, zumindest gibt es in vielen Dimmern auch die voreingestellte Dimmerkurve "Square", die eben "quadratisch", also "hoch 2" bedeutet...

Zitat von synvox

Übrigens setzt sich der Faktor k aus 'deiner' Funktion genau aus den Elementen zusammen, welche ich in Abhängigkeit der Bittiefen ausgeschrieben habe, also k = (2^t-1)/(2^s-1)^g.

Ja, genau - diese Formel war mir damals (bei der Tabelle für WS2801, die in dem Kugelcontroller drin ist) noch nicht bekannt, ich hatte halt ganz banal gerechnet 255x255=65.025, raus kommen soll dann 255, also ist k dann 255/65.025, für andere Auflösungen halt dementsprechend...

turi · 2. Dezember 2012

Habe inzwischen mit dem XPlain-Board und der Test-Firmware von Counterfeiter unsere Streifen auch zum Leuchten gebracht. Das ist schon ein sehr angenehmes Fading, was man da sieht. Der Steifen funktioniert übrigens komplett ohne Probleme, obwohl die Pins für den IC etwas zu weit auseinander sind. Habe irgendwie noch gar kein Foto davon ...

Externer Inhalt www.youtube.com

Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.

Durch die Aktivierung der externen Inhalte erklären Sie sich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.

Counterfeiter · 2. Dezember 2012

Nabend,

@Neni, ja man sollte nicht gleich alles glauben, klar ist die Formel einfach. Hatte hier sogar schon ne fast fertige Excel, aber sollte halt mal schnell gehen. = Copy & Paste

turi oder 2bl interessant fürs Forum wäre ja ein Vergleichsvideo zwischen 8 Bit IC und 16/14 Bit und das bei langem Faden (wie im Video von turi). Ich denk dann sieht man das am schönsten.

Kann man eigentlich bei den Videocams die Blende (heißt das so?) fixen. Bei dem Video von Turi sieht man deutlich wie beim hochfade die Cam versucht den Lichteinfall zu reduzieren und beim runterfaden die Cam etwas braucht. Dadurch sieht das so aus, als wenn das hochfaden lange bei einer Helligkeitsstufe verweilt.

Grüße

Basti

turi · 2. Dezember 2012

Das Video ist aber auch mit dem Handy erstellt ... also da kann man nicht so viel erwarten. Habe schon versucht, nicht so direkt zu filmen, aber die Unterschiede gleicht die Cam halt aus. Muss mal schauen, ob man irgendwie die Einstellungen fest machen kann.

Wenn man das richtig vergleichen will, müsste man ja eine Sequenz komplett gleich ausgeben, nur mit unterschiedlichen Farbtiefen.

Teilen