Beiträge von synvox

    Das mit schwarz in der Platte fand ich erst störend, aber nach 2 Minuten gucken, fand ichs dann auch gut


    Ja, das hat so etwas von Blobs, die aus dem Nichts langsam auftauchen und dann wieder verschwinden :) .


    Aber was mir noch nicht so zusagt sind die vielen Rotationen... Ich mag es, wenn das Plasma augenscheinlich in eine Richtung "wegwabbert". Wahrscheinlich braucht man es nur langsamer stellen und ist ja auch Geschmackssache


    Die Geschwindigkeit der einzelnen Modulationen hab ich im Video nicht verändert und sie eher mittelschnell wabern lassen, so dass man in nützlicher Zeit (Video) auch etwas sieht ;) . Diese kann man aber natürlich noch viel langsamer einstellen. Der Vorteil der wie 'Rotatonen' aussehenden Richtungswechsel (komplexer Algo) ist der, dass sich praktisch nie ein Frame wiederholt. Natürlich, die Grundstruktur bleibt schon die Gleiche, wenn man's bei fixen Einstellungen stundenlang laufen lässt, aber man bekommt auch dann wirklich praktisch nie genau das gleiche Frame nochmal zu Gesicht. Ausserdem sieht's bei höherer Zoomstufe (mehr ins Detail gehen) auch wieder weniger hektisch aus, bringt aber enorme Variation ins Bild. Ich habe den Zoom im Video so gewählt gehabt, dass man auch etwas Überblick hat ;) . Dadurch dass ja praktisch alles parametrisiert ist, kann man sich's auch je nach Geschmack, Lust und Laune einstellen, von einer uniformen Fläche, welche einfach die Farbe fadet, bis eben zu sehr komplexen Plasma-Animationen ;) .


    Wie bekommst du eigentlich den Processing-Code auf den ARM? Gibts da ne C Exportfunktion oder hast du nen Java Interpreter drauf?


    Iiiiiiiiih, Java-Interpreter :D . Nein, ich setzte es 'von Hand' um. Ist aber auch keine so grosse Sache, denn Java ist ja von der Grundnotation her nicht so weit von C++ entfernt. Die ganzen Klassen und Methoden für's OpenGL-Rendering auf dem PC-Bildschirm und die Schieberegler etc. brauche ich ja nicht umsetzen, sondern nur den reinen Algo-Code, und das ist ja im Grossen und Ganzen einfach eine Ansammlung mathematischer Operationen und Funktionen. Natürlich gilt es dabei auch, Optimierungen für den µC zu machen (wie eben die Trigo-Funktionen mit entsprechenden Fliesskomma-LUTs zu ersetzen), aber das ist mehr oder weniger Erfahrungssache und trickreiche Programmierung (das kann einem sowieso keine Soft abnehmen). Ich habe zum Beispiel erst in Processing mittels Rundungen etc. getestet, wie weit ich eine SinusTab für meinen Algo diskretisieren darf, ohne dass dabei auch bei höchster Zoomstufe visuelle Artefakte (Auflösungsverluste) entstehen. Dabei habe ich gemerkt, dass selbst bei ein 20stel Grad Winkelschrittweite noch leichte Artefakte sichtbar sind. Deshalb verwende ich eben dann eine Sinustabellen-Auflösung in C von einem 100stel Grad (9000 Werte für eine Viertelperiode).


    Achso, hab mal nachgemessen. Die Math.h Funktion sin() mit Fließkommazahlen braucht bei 24 MHz ca. 75 us. Also theoretisch sind damit auch Operationen möglich, wenn man wie du Neni die Module auf 16*16 Pixel beschränkt gibt es auch noch ganz gute Frameraten


    Hmmm, das wäre aber dann gerade mal ein einzelner Sinus, und bei 256 Pixel mit einem Sinus pro Pixel wären das schon rund 19 ms. Und da hat man dann aber noch kein Plasma ;) . Ich hatte ja vor Jahren auch mal mit AVRs rumexperimentiert (AVR Mega), und dabei ist herausgekommen, dass bei einigermassen sinnvoll komplexem Plasma-Algo (weit entfernt vom heutigen SynPlasma) mit der Sin-Funktion aus math.h bei 20 MHz bei 49 Pixel (7 * 7 Matrix) in etwa Schluss ist, wenn man unter 30 ms pro Frame bleiben will.


    Gruss
    Neni

    So, habe jetzt auch mal ein kleines Video meines SynPlasma Algos gemacht. Alles wird live in Processing berechnet und mit einem OpenGL-Renderer (in Processing integriert) mit Smoothing (simuliert in etwa eine diffuse Platte vor der Matrix) dargestellt. Die virtuelle Panel-Grösse ist hier 32 x 32 Pixel gross, was vier meiner geplanten Module entspricht. Generell benötigt der SynPlasma Algo schon mindestens eine Grösse von 16 x 16 Pixel, um überhaupt 'aufblühen' zu können :) , also genau eins meiner Module.


    Der Vorteil der Sache mit dem µC pro Modul ist, dass die Performance ja mit der Panel-Grösse mitskaliert, da jedes Modul seinen eigenen Ausschnitt des Plasmas berechnet. So sind zumindest theoretisch beliebig grosse Panels möglich. Ein Mastercontroller (kann ein beliebiger, auch schwachbrüstiger µC sein) übermittelt einfach die zu verändernden Parameter und den Sync-Wert (den plasmacounter sozusagen) via RS485 z.Bsp alle 20 ms (= 50 fps) an alle Module, was den Datenstrom relativ klein und unabhängig von der Panelgrösse (Anzahl Pixel) macht. Wie gesagt benötigt ein LPC1768 mit meinem C-Code für 16 x 16 Pixel (ein Modul) inkl. Rausschieben der Daten via SPI und Matrix-Multiplexing mit ca. 9600 Hz Zeilenfrequenz (also ca. 600 Hz Bildwiederholrate) ca. 8 ms für ein Frame des SynPlasma Algos in der aktuellen Ausprägung (wie im Video).


    Das Video ist etwas ruckelig. Das liegt zum einen an der Youtube-Konvertierung und zum anderen daran, dass bei gleichzeitiger Screen-Bereichs-Aufnahme (mit MPEG4 Codec) der Processing-Code (weil da natürlich auch noch die Kontrolle aller Schieberegler drin ist) etwas ins Stocken gerät. Auf der tatsächlichen Hardware (Module) würde das natürlich absolut smooth laufen. Ausserdem ist ein etwas 'hässliches' Aliasing zu sehen, was vor allem daran liegt, dass die virtuellen Pixel quadratisch sind (ein virtueller Pixel entspricht 16 x 16 Bildschirmpixel) und das OpenGL-Smoothing dann eben nicht sphärisch verläuft. Aliasing wird man zwar aufgrund der begrenzten Auflösung auch in Hardware haben, aber das wirkt sich dort weniger 'hässlich' aus. Dass Aliasing ausserdem manchmal auch ganz nette Effekte produziert, sieht man im Video bei etwa 7'30.


    Das Video beginnt mit einem relativ klassischen, einfachen Plasma, welches dann immer komplexer wird. Ich habe in meinem Processing-Code ein ganzes Arsenal Schieberegler (je einen für jeden einstellbaren Parameter des SynPlasma Algos), welche ich im Video live bediene, um das Plasma entsprechend zu beeinflussen. Manche Parameter sind eher zum manuellen Einstellen gedacht, da sie ein eher sprunghaftes Bild beim Verstellvorgang erzeugen. Andere eignen sich aber auch gut zur automatisierten, kontinuierlichen Manipulation (z.Bsp vom Mastercontroller aus), da das Plasma bei diesen ganz weich von einem in einen anderen Zustand kommt. Das sieht man auch im Video. Allerdings verstelle ich im Video nur einen kleinen Teil der rund 40 Parameter.
    Und bevor jemand fragt ;) , nein, ich verwende keine Palettenumschaltung und keine anderen Paletten im SynPlasma Algo. Alles wird immer aus dem HSV-Farbraum berechnet.


    Hier also das Video (zur Erinnerung: es entspricht einer 32 x 32 Pixel Matrix mit Diffusorplexi)
    g-Mvh8OePE0


    Gruss
    Neni

    Hallo Pesi,


    ein kleiner Tipp: Gerade deine beiden zuletzt verwendeten Paletten sind ja mehr oder weniger Teilbereiche der gesamten Hue-Palette. Solche Sachen lassen sich auch recht einfach durch Verringern der Modulationstiefe des Plasma-Algos auf die Palette und Verschieben des Offsets der Modulation bewerkstelligen :) .
    Oder um es mal in der Sprache der Plasma-Sinüsse :D zu schreiben: Farbpalettenmodulation = a + b * sin(x, y ,t) ... , wobei b die Modulationstiefe und a den Offset bestimmt.


    Gruss und schönes und glückliches Neues Jahr an alle
    Neni

    Wieso Cortex M3? Wenn schon ARM, dann kannst du doch gleich den M4 nehmen, der hat doch direkt ne FPU dabei... genial... Hab hier auch noch dev-Boards im Schrank liegen, fand aber das es etwas Overkill für nen einfaches Plasma ist. Aber ist halt immer die Frage nach dem Anspruch an die Größe und Optik der Matrix.


    Naja, da bei mir je ein µC pro Modul zum Einsatz kommt, sind die Kosten pro Chip (und auch der Stromverbrauch pro Chip bei Vollast) schon auch ein Thema, wenn ich das Ganze mal für den Verkauf produzieren möchte. Ausserdem reicht ein Cortex M3 hier locker für eine 16 x 16 Matrix pro Modul auch bei komplexen Algorithmen, und 16 x 16 ist in meinen Augen gerade ideal für ein einzelnes Modul mit 80 x 80 mm Grösse (also 5 mm Pixelabstand). Ausserdem kenne ich den LPC1768 jetzt schon sehr gut, weiss wo die Stärken und wo die Macken sind, was man vermeiden sollte etc. Und nicht zuletzt nutze ich ein sehr gutes, einfaches Entwicklungssystem dafür (mbed), welches ich mittlerweile sehr lieb gewonnen habe ;) .


    weil es könnte ja auch sein, dass der stur erst mal die Konstante ausrechnet, ah, ja, 256*3 = 768, und dann jedes mal ne SW-Divsion aufruft, die das durch 768 teilt, was natürlich deutlich länger dauert...


    Na ich würde ja schon hoffen, dass er zuerst die Konstante berechnet und dann eben modulo 768 und nicht zuerst modulo 256 und dann mal 3 rechnet, weil das ist keinesfalls das selbe. Im zweiten Fall würde man immer in 3er-Schritten durch den hinterlegten Farbraum scrollen, was ja Farbraumauflösung verschenkt. Allerdings mathematisch formal korrekt müsste man 256*3 in Klammern setzen, wenn man sicher sein will, dass alle Compiler das so machen ( modulo 768 ).


    Es gibt bei der aktuellen Implementation einiges, was es generell zu bedenken gilt. Die Colorspace-Table ist in diesem Fall ja im Prinzip eine HSV-Farbraum-Palette mit fixem S und V (auf maximum), man kann es also als Hue-Table sehen. Dabei hat eine Hue-Table, welche RGB-Werte von 0 bis 255 beinhaltet, aber eigentlich 'nur' 765 (=3*255) Elemente (bzw. 1530=6*255, falls man nicht wie hier die auf 'konstante' Lichtemission normierte Version verwendet). Die 768 Werte werden hier dadurch 'erreicht', dass jeweils die Einzelfarben (Rot allein, Grün allein, Blau allein) doppelt in der Tabelle vertreten sind, was streng genommen eben nicht ganz korrekt ist.
    Was die Auflösung betrifft, ist es eben so, dass bei einer Schrittweite von 1.4° sich im schlimmsten Fall (dort wo beim Sinus die Steigung am höchsten ist) die Werte um 0.024 ändern (Sinus von -1 bis 1), also Änderungen von 2.4 % vom Skalierwert (bei 0 bis 1023 also rund 12). Je nach Grösse der Farbtabelle, der Modulationstiefe (Sinus-Plasma-Algo-Teil auf Farbtabelle), der Zoomstufe (reziprok der Zellengrösse) und der Geschwindigkeit der Animation können da schon gut sichtbare Artefakte entstehen.


    Persönlich würde ich als Ansatz für erste Korrekturen die Colorspace-Table auf 765 Elemente bringen (Doppelungen rausnehmen), dann den Sinus in der Vorberechnung der LUT so skalieren, dass sich die Werte von 0 bis 764 bewegen, also skaliert mit 382 und Offset 382. Dann würde ich das Ergebnis der vier Sinus-Additionen durch vier teilen (also >> 2) und nicht durch 16 (>> 4). Damit hat man dann auf jeden Fall die volle Modulationstiefe (kann man immer noch verringern, wenn man möchte) des Plasmas auf den zugrundeliegenden Farbraum . Dann noch plasmacounter hinzuzählen und modulo 765 ausführen.


    Ich habe jetzt ein Screencapture-Proggi gefunden (http://camstudio.org/), werde also demnächst mal ein kleines Demo-Video meines SynPlasma Algos erstellen. Dank auch an stromflo für den Vorschlag, aber ich hatte das Proggi hier kurz vorher gefunden gehabt, deshalb habe ich nicht weiter ausprobiert.


    Gruss
    Neni

    Hier könnte man mit relativ einfachen Mitteln noch die Auflösung steigern, ohne ne größere Tabelle anlegen zu müssen: Ein kompletter Sinus besteht ja aus 4 "Viertelbögen", die (punkt-)symmetrisch zueinander sind.


    Es würde also reichen, in der Tabelle einen "viertelten Sinus" abzulegen, dann könnte man insg. 1024 Schritte durchgehen statt "nur" 256 - halt die Werte aus der Tabelle holen und je nach "Bereich" entsprechend umrechnen...


    Ja genau, das mache ich in meiner Umsetzung für den ARM Cortex M3 auch so. Allerdings teile ich dabei 90° (entspricht einer Viertelperiode) in 100stel-Grade auf, was dann 9000 Schritte für eine Viertelperiode (oder eben 36000 für eine volle) sind. Da ich aber für jeden Schritt in der LUT eine 32 Bit Fliesskommazahl (0 - 1) hinterlege, ergibt das trotzdem eine LUT von ca. 36 KB. Naja, wenn 512 KB Flash im µC zur Verfügung stehen, alles kein Problem ;) .
    Ich brauche natürlich diese Auflösungs- und Rechentiefe, weil bei meinem System mein SynPlasma Algo praktisch das Herzstück der Animationsgenerierung in den Modulen selbst ist und ich eben kein Pixel-Daten-Streaming von einem anderen System (PC oder was auch immer) aus mache. Da muss das natürlich für genügend weiche Animationen sorgen können, und das praktisch unabhängig von der 'Waber-Geschwindigkeit', wobei die fps-Rate aber konstant bleibt. Wenn das lokal berechnete Plasma mehr als 'nettes' Zusatzfeature eingeplant ist, wenn mal nicht der PC oder so angeschlossen wird, dann muss man natürlich einen solchen Aufwand nicht treiben.


    Muss mal schauen, ob ich im WWW nen Screencapture-Video-Tool für lau finde, dann könnte ich mal ein Beispielvideo von den SynPlasma-Animationen posten, da ich ja den Algo und jede diesbezügliche Erweiterung in Processing (JAVA-Wrapper) auf dem PC entwickle und teste, bevor dann die Adaptation und Optimierung in C++ für den ARM erfolgt.


    Gruss
    Neni

    Hallöchen,


    ich befasse mich ja jetzt schon sicher mehr als drei Jahre mit dem Plasma-Effekt, auch im Bezug auf mein aktuelles Projekt, gerade weil ich eben diesen Effekt (durch einen Diffusor hindurch) als ideal für Lounge- und Stimmungs-Leuchten-Anwendungen und für entsprechende Leucht-Möbel (Tische) empfinde. Vorraussetzung ist natürlich, dass der Algorithmus komplex genug ist, um liquid aussehende, sich kaum wiederholende Animationen zu produzieren und trotzdem mathematisch so trickreich umgesetzt ist, dass ein µC es mit mindestens 30 - 50 fps berechnen kann (je nach Matrix-Grösse natürlich).
    Mein Konzept ist in diesem Zusammenhang aber etwas anders, da bei mir auf jedem Matrix-Panel-Modul ein µC sitzt und 'nur' den jeweiligen Teilbereich des Gesamtpanels berechnen muss. In der aktuell in Entwicklung befindlichen Ausprägung umfasst ein einzelnes Matrix-Panel-Modul aber auch immerhin schon 16 x 16 RGB-Pixel, welche von einem µC berechnet werden müssen. Ein ARM Cortex M3 mit 100 MHz Core Clock schafft dabei ein Frame meines SynPlasma Algos in aktueller Ausprägung in weniger als 7 ms bei 16 x 16 Pixel. Ein popeliger 8-Biter wie der AVR wäre dabei gnadenlos überfordert.


    Ich kann/möchte den SynPlasma Algorithmus aber nicht öffentlich machen (zumindest nicht solange ich kein fertiges Produkt habe), da es sich praktisch um mein wichtigstes 'Baby' und Frucht intelektueller Arbeit der letzen Jahre (natürlich nicht durchgehend) handelt. Es ist natürlich auch der Hauptbestandteil des aktuellen Projektes. Ich mein, die Hardware ist ja keine grosse Sache, die kann ja schnell mal einer kopieren, wenn er genügend Ahnung von Elektronik hat. Ich kann nur soviel sagen, dass der Algo einiges komplexer ist, als die Algos, die man üblicherweise auf Plasma-Info-Seiten findet(oder auch der Basis-Code in Processing etc.). Deshalb habe ich meinem Algo auch einen eigenen Namen gegeben ;) .


    Pesi, den Code den du gemeint hast, habe ich glaub nur dir persönlich mal geschickt, ist aber auch schon lange her. Da hatte ich ja auch noch mit AVRs rumexperimentiert. Mittlerweile ist das Ganze schon noch deutlich komplexer geworden. Die SynPlasma-Animation kann mittlerweile mit fast 40 Parametern beeinflusst, gesteuert und moduliert werden ;) .


    Basti, dein Ansatz gefällt mir. Zumindest ist es das, was man mit einem AVR noch hinkriegen kann, wenn man damit auch noch eine entsprechend hohe Anzahl Pixel berechnen möchte. Allerdings sind natürlich schon auch sehr starke Einschränkungen mit eingeflossen. Zum einen ist in deiner Sinus-Tab eine komplette Periode in 'nur' 256 Zeit-Punkte aufgelöst, was unter Umständen zu relativ groben Abstufungen im Plasma führen kann (gut, durch diffuses Plexi wird's dann ja verwaschen). Zum anderen kommt es bei deiner Implementation sehr schnell zu identischen Musterwiederholungen in der Animation, also wenn ich's richtig überflogen habe, spätestens alle 512 Iterationsschritte der Variable plasmacounter, was bei 30 fps ca. alle 17 Sekunden wäre. Ok, da ist noch das Farbapletten-Looping (bei dir alle 768 Schritte einmal durch), aber dabei bleibt das zugrundeliegende Muster ja gleich. Zugegebenermassen ist is das aber durchaus sinnvoll, um bei limitierter Rechenpower die Plasma-Animation etwas aufzupeppen ;) , wurde ja früher von den DEMO-Codern (auf C64 und Amiga) auch gemacht.


    Gruss
    Neni

    Hallo Andre,


    hier noch ein paar kleine Korrekturen, welche zwar den Braten nicht mehr feiss machen, aber sich trotzdem etwas auf die Zahlen auswirken. Die Datenübermittlung für ein komplettes Frame würde 0,136 ms mal Anzahl Chips dauern, da du ja neben den Nutzdaten auch immer noch das Command-Wort übertragen musst. Die Anzeige eines kompletten Frames im low refresh rate modus (64 subframes) würde ca. 16,4 ms und im high refresh rate modus (256 subframes) ca. 16,5 ms dauern, da du noch jeweils ein Clock pro Zeilen-Scanning dazurechnen musst wegen der automatischen black frame insertion.


    Wie der MY9268 genau die PWM-Daten in den Subframes jeweils verteilt, ist im Datenblatt nicht beschrieben (naja, bei M-PDM-Verfahren ist ja auch patent pending angegeben ;) ), aber es werden auf jeden Fall die niederwertigen Bits der 16-Bit PWM-Werte einigermassen sinnvoll (um jeweils die Verteilung möglichst gut zu haben) auf die Subframes verteilt werden, im low refresh rate modus die niederwertigen 6 Bits, im high refresh rate modus die niederwertigen 8 Bits. Wie auch immer die Verteilung der Datenwerte nun genau gemacht wird, du wirst auf jeden Fall einen guten Teil der nutzbaren Auflösung verlieren, wenn du bei jedem zweiten oder dritten Frame dessen komplette Darstellung unterbrichst. Und das ist dann auch noch asynchron (bzw. synchron zur DMX-Framerate), also nicht immer an der gleichen Stelle, was zusätzlichen Jitter ins Spiel bringt.


    Ich persönlich würde in dem Fall einer gegebenen konstanten Framerate (DMX-Rate) entweder versuchen, den Clock so zu ändern, dass sich möglichst genau ein vielfaches der DMX-Rate einstellen lässt (ist natürlich durch Restriktionen wie erhältliche Quarze etc. nur beschränkt möglich) oder aber bei unverändertem Clock schauen, dass ein komplettes Frame in deutlich kürzerer Zeit dargestellt werden kann und somit die Frame-Anzeige-Rate ein zig-faches (mindestens 10-fach oder so) der DMX-Rate beträgt. Dann fällt ein kleiner Frame-Raten-Jitter überhaupt nicht mehr auf, auch bei langsamen Animationen nicht. Dies kann man bewerkstelligen, indem man explizit auf die volle 16-Bit-Auflösung verzichtet (da man wie oben ausgeführt im anderen Fall diese sowieso nicht wirklich vollständig nutzen kann) und z.Bsp 'nur' die oberen 10 Bit nutzt. Dann könnte man im low refresh rate modus das Frame nach genau einem Scanning-Vorgang (Subframe) mit einem weiteren Frame-Latch abbrechen und einen neuen Anzeige-Zyklus starten. Das würde die Frame-Anzeige-Rate auf ca. 1 kHz bringen. Wenn die Subframe-Datenverteilung einigermassen intelligent gelöst ist, könnte man z.Bsp. auch die oberen 12 Bit nutzen und das Frame nach 4 Subframes abbrechen und neu starten, aber eben, ich kenne das Verteilungsschema nicht. Beim TLC5971 (auch 16 Bit PWM und auch eine Art Advanced PWM zur Flicker-Vermeidung) ist z.Bsp. das Verteilungsschema genau angeben, und da kann ich zu 100% sagen, dass es auch jenseits der Subzyklen-Grenze mit der individuellen Bittiefen-Nutzung funktioniert. Wenn es also ähnlich gelöst ist, sollte es auch beim MY9268 gehen.


    Eine weitere Möglichkeit wäre auch, dass man jeweils nicht die volle DMX-Kanalzahl pro Universum nutzt und so dann die DMX-Ausgaberate in der Ausgabe-Software (Madrix oder was auch immer) entsprechend erhöhen/anpassen könnte, wenn das geht (?).


    Gruss
    Neni

    Hallo Andre,


    die doppelte Pufferung macht schon Sinn, wenn der Scanning-Vorgang asynchron zur Dateneingabe stattfinden können soll. Du schiebst ja die Daten Zeile für Zeile in die jeweilige Anzahl Chips rein, und nach jeder Zeile machst du einen kurzen Latch-Puls, welcher die aktuellen Zeilen-Daten aus den Eingangs-Schieberegistern an die entsprechende Stelle (Zeilenposition) im ersten Pufferbereich des SRAMs latcht. Das geschieht dann für jede Zeile eines Bildes. Wenn also während dieser zeilenweisen Dateneingabe der Scanning-Vorgang zum ebenfalls zeilenweisen Aufbau des Bildes (Anzeige) asynchron zu der beschriebenen Dateneingabe erfolgt und der Chip dabei aber die Daten für die Anzeige aus dem ersten Puffer lesen würde, dann würde es öfter dazu kommen, dass ein Teil des Bildes noch mit den Daten des letzten Frames und der Rest des Bildes mit Daten des aktuellen Frames aufgebaut (angezeigt) würde, was zu Ghosting- und Tearing-Effekten (kann man häufig bei PC-Games beobachten, wenn man Vertical Sync deaktiviert) führen würde. Um dies zu verhindern, wird eben ein doppelter Puffer implementiert, wobei dann mittels einer Frame-Latch-Anweisung (im Falle von MY9268 also länger Latch High und währenddessen DCK viermal pulsen) die Daten aus dem ersten Puffer in einem Rutsch in den zweiten Puffer kopiert werden und der zeilenweise Bild-Aufbau (Anzeige) neu startet.
    Kurz gesagt werden die Daten zeilenweise immer nur in den ersten Puffer geschrieben, währenddessen sie für die Anzeige immer nur aus dem zweiten Puffer gelesen werden. Frame-Latch/Frame-Start kopiert die Daten von Puffer 1 nach Puffer 2 und startet das Scanning neu, was somit sozusagen die Funktion eines Vertical Syncs erfüllt.


    Gruss
    Neni

    Hallo Andre,


    ich habe leider nicht das vollständige Datenblatt zum MY9268 vorliegen, sondern nur die erste Seite (wie man's bei MySemi runterladen kann). Deshalb kann ich deine Frage nicht mit absoluter Sicherheit beantworten, sondern anhand der mir vorliegenden Angaben nur entsprechende Vermutungen anstellen. Das Infoblatt gibt ja an, dass der Chip ein internes SRAM mit 4 kBit enthält. Das sind also 4096 Bit Speicher, also genügend für 16 Bit mal 16 Channel mal max. 8 Zeilen mal 2. Das sieht für mich so aus, dass der Chip einen doppelten Bild-Puffer besitzt, also prinzipbedingt dann GS-Clock und Scanning relativ unabhängig von der Dateneingabe stattfinden können. Wenn ich mir die von dir verlinkte Graphik anschaue, dann meine ich, dass das auch so ist. Die GS-Clock und die Zeilenumschaltung müssen natürlich synchronisiert sein, das ist klar, also bei dem Beispiel eine Zeilenumschaltung bei jedem 513ten GS-Clock. Die Dateneingabe kann meiner Meinung nach asynchron erfolgen, da die Daten in den Puffer-Bereich geschrieben werden und der aktuell angezeigte Frame aus dem anderen SRAM-Bereich gelesen wird. Lediglich beim Frame-Latch/Frame-Start muss man die Data-Clock bei Latch High viermal pulsen, wobei dann eben die Daten vom Puffer-Bereich in den Anzeige-Bereich des SRAMs gelatcht werden und der Bild-Anzeige-Zyklus zurückgesetzt wird. Diesen Frame-Latch/Frame-Start setzt man idealerweise so, dass er nach mindestens einem oder mehreren vollständigen Anzeige-Zyklen eines Bildes vorkommt und dann die GS-Clock und Zeilenumschaltung wieder von neuem beginnt.


    Gruss
    Neni

    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.


    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

    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

    Vielen Dank für eure Überlegungen. Ich sehe das eigentlich genau so, wie die meisten hier. Ich merke aber auch, dass es wahrscheinlich ziemlich schwierig ist, Ratschläge für etwas zu geben, wo man das System und dessen Einsatzzweck nicht überblickt.


    Deshalb möchte ein paar mehr Details angeben. Geplant ist ein flexibles Modulsystem aus RGB-Pixelmatrix-Modulen inkl. der Kunststoff-Montage-Elemente, aus welchen sich dann ein im Prinzip (natürlich limitiert durch Kosten, Stromverbrauch und gewisse Systemgrenzen) beliebig grosses Panel zusammenstecken lässt. Man kann sich das in etwa so vorstellen, wie diese ineinander steckbaren, quadratischen Kunststoff- oder Holz-Fliesen für Balkone und Terrassen. Die Module sollen dann eben in ein jeweiliges Möbel- oder Leuchten-Design integriert werden können. Ob dann ein Panel (aus einer bestimmten Anzahl der Module) horizontal zu liegen kommt (z.Bsp. integriert in eine Tischplatte) oder vertikal als Element einer Wandinstallation, einer Stehlampe oder eines Regal-Aufbaus etc.Verwendung findet, ist im Prinzip offen. Ein, zwei Prototypen-Möbel werde ich sicher selbst machen, ansonsten möchte ich aber eher mit einem Möbel-Designer zusammenarbeiten (wobei dieser Abschnitt des Projektes eher weiter in der Zukunft liegt und auch noch nicht festgelegt ist).


    Die Module selbst sind 80 x 80 mm gross und enthalten jeweils 256 RGB-LEDs (16 x 16) mit 5 mm Pixel-Pitch. Auch wenn ich speziell kleine (aber trotzdem lichtstarke) RGB-LEDs (PLCC4 2020) verwenden werde, sollte trotzdem klar sein, dass die Packungsdichte auf der Leiterplatte recht hoch ist und somit auch sehr limitierte Platzverhältnisse für Sensorbausteine vorliegen. Es ist nun auch so, dass ich aus diesen Gründen (und auch wegen der Kosten) maximal 4 entsprechend kleine IR-Sensor-Module pro Panel-Modul (deshalb 40 x 40 mm) unterbringen kann, was also jeweils 64 RGB-LEDs ( 8 x 8 ) entspricht, welche dann pro Touch-Pixel beeinflusst werden. Wenn ich mich für die kapazitive Methode entscheide, so könnte ich die Dichte der Touch-Pixel sinnvollerweise auf etwa 16 pro Modul erhöhen, was dann 16 RGB-LEDs (4 x 4) pro Touch-Pixel bedeuten würde, und die Touch-Pixel-Fläche wäre 20 x 20 mm.


    Was bei Touch passiert, ist noch nicht wirklich festgelegt. Von der Systemkonzeption her besteht eine weitgehende und eigentlich nur von der endgültigen Modul-Software abhängige Flexibilität. Denkbar ist zum Beispiel, dass bei Touch gewisse Animations-Parameter für die von dem Touch-Pixel beeinflussten RGB-LEDs verändert werden, oder aber dass bei Touch einfach ein gefadetes Weiss bei den jeweiligen RGB-LEDs über die Animation überlagert wird, beide Möglichkeiten sozusagen als direkte, visuelle Touch-Rückmeldung (wie bei den interaktiven Tischen etc.). Machbar ist aber auch eine zusätzliche Touch-Rückmeldung an den Haupt-Controller zur manuellen Steuerung von system-spezifischen Parametern. Eine Idee, welche mir z.Bsp. gerade im Kopf rumschwirrt, wäre eine LED-Stehleuchte mit gegen die Wand gerichteten Beleuchtungs-LEDs (indirektes Raumlicht). Die zum offenen Raum hin gerichtete Frontseite der Leuchte hat ein eingelassenes, länglich rechteckiges Panel (aus mehreren Modulen übereinander), auf welchem die Animationen ablaufen. Wenn man nun in vertikaler Richtung mit dem Finger über das Panel streicht, sieht man entsprechend die visuellen Effekte, aber man regelt damit auch gleichzeitig die Dimmung der Leuchte :) .


    Gerade weil eben die prinzipiellen Möglichkeiten so vielseitig sind, fällt es mir im Moment schwer, mich für ein Touch-System zu entscheiden. Zu sagen ist noch, dass bei beiden Verfahren die Empfindlichkeit via Software jederzeit kalibrierbar ist. Wäre das zum Bsp. beim kapazitiven System nicht möglich gewesen, wäre es sowieso ein Killer-Kriterium.


    Gruss
    Neni


    PS: Die Animationen laufen natürlich immer in Modul-Auflösung, also 16 x 16 Pixel pro Modul. Nur die Auflösung der Touch-Effekte wäre abhängig vom Verfahren, also ein Touch-Pixel wie gesagt 8 x 8 oder eben 4 x 4 LED-Pixeln entsprechend.

    Ich habe ein Projekt für ein interaktives Modul-System für RGB-LED-Matrix-Panels (keine Grosspanels, sondern eher kleinere High Resolution Panels zur Integration in hochwertige Design-Möbel und -Leuchten, ev. auch Kunst-Installationen etc.). Ich möchte nicht allzuviele Worte über das Projekt selbst verlieren, es gibt nur ein kleines Detail, bei welchem ich mir noch etwas Unschlüssig bin, deshalb meine Frage hier.


    Wichtig ist noch zu wissen, dass die Interaktivität per Touch nicht die wichtigste Interaktionskomponente im System ist, sondern eher als kleines Zusatzfeature zu sehen ist.


    Prinzipiell gibt es nun zwei Verfahren, mit welchen ich die Touch-Funtionalität umsetzen kann, kapazitiv oder per IR-Reflektion. Für beide Verfahren habe ich bereits eine funktionierende, detailierte, technische Umsetzung konzipiert. Beide Verfahren führen in meiner Konzeption zu keinerlei Beeinflussung der optischen Eigenschaften der LED-Matrix (Schattenbildung etc.), und auch die Panel-Dicke lässt sich mit beiden Verfahren in etwa gleich gestalten. Die Fläche eines Touch-Elementes ist dabei ca. 40 x 40 mm gross.


    Der Vorteil des IR-Systems besteht darin, dass auch kapazitiv nicht-aktive Gegenstände auf dem Panel 'erkannt' werden können, d.h. irgendwelche auf dem Panel liegenden Gegenstände, vorausgesetzt sie reflektieren genügend IR-Licht. Der Nachteil dabei ist, dass man die Empfindlichkeit der Touch-Elemente nicht für alle Material-Arten (der Gegenstände etc.) ideal einstellen kann. Wenn man beispielsweise die Touch-Elemente so einstellt, dass sie auch Gläser 'erkennen' können, werden sie bei Annäherung mit der Hand zu empfindlich, d.h. reagieren zu früh (bei grösserer Distanz der Hand zu Panel). Ausserdem ist die technische Umsetzung etwas komplexer, und die Kosten pro Touch-Element sind höher. Die technische Umsetzung ist bereits so vorgesehen, dass das System gegenüber IR-Umgebungslicht unempfindlich ist, dies wäre also kein Nachteil.


    Die Vorteile des kapazitiven Systems sind die intrinsische Selektivität und damit spezifische Anpassbarkeit auf Hand-Touch, die geringeren Kosten und die einfachere technische Umsetzung. Die Selektivität ist aber gleichzeitig auch ein Nachteil, da sich eben damit nur kapazitiv aktive Gegenstände (also in der Praxis Hand/Finger-Touch) 'erkennen' lassen.


    Der Kostenvorteil des einen Systems (kapazitiv) ist zwar da, er ist aber bezogen auf die Gesamtkosten eines Moduls nicht so riesig, vielleicht maximal 10 - 15 %.


    Deshalb meine Frage:
    Wie seht ihr das? Was wäre für euch wichtiger? Ein möglichst flexibles Touch-System mit Erkennungsmöglichkeiten für versch. Materialien, auch wenn es sich nicht für alle Materialien gleichzeitig optimal einstellen lässt, oder aber ein für Hand/Finger-Touch selektives System mit ca. 10 - 15 % Kostenvorteil?


    Schon mal Danke und Gruss
    Neni

    Hallo Pesi,


    was das Verschieben von Elementen angeht, so gibt es neu in Version 6 zumindest die frei zuschaltbare Gummiband-Funktion (im Bild unten der Button rechts; ich bin mit der Maus drüber, den Pointer sieht man auf'm Screenshot aber nicht):

    Damit kann man, wie auf dem Bild unten zu sehen, Elemente verschieben, und die Leiterbahnen, die physisch mit Bestandteilen des Elementes (auf dem gleichen Layer) verbunden sind, folgen dann als Gummiband (bis zum nächsten Knotenpunkt in der Leiterbahn).

    Dies ist sicherlich eine sehr nützliche Neuerung, wenn man Elemente mal ein paar Rasterpunkte hin und her schieben muss, oder so Multipin-Monster mit Bus-Verbindungen in einer Linie etwas verschieben will. Da muss man dann nur noch wenig nacheditieren. Wenn man aber ein grösseres Multipin-Objekt an einen ganz anderen Ort verschieben will, dann bringt es meiner Meinung nach nicht mehr so viel.
    Aber immerhin, die Funktion ist da, und eben instantan zu- und abschaltbar.


    Gruss
    Neni

    Also ich finde die neuen Funktionen schon sehr toll, muss ich sagen. Natürlich ist da immer noch ein grosser Unterschied in der Arbeitsweise zu den professionelleren Layout-Software-Paketen anderer Hersteller, aber andersherum wäre für mich Sprint nicht mehr Sprint, wenn man sich beim Layout für eine fast 'sklavische' Abhängigkeit von Knoten, Netzen und bauteilen aus einem Schaltplan-Editor entschieden hätte.
    Ich weiss, für manche ist das eine Notwendigkeit, dass Schaltplan und Layout so eng wie möglich verknüpft sind, für mich und meine Arbeitsweise hingegen ist genau das eine Qual und Kreativitätsbremse ;) . Deshalb bin ich ja so froh, dass es eben eine Software wie Sprint gibt, welche einem keinen bestimmten Arbeitsablauf aufzwingt. Bei mir zum Bsp. entsteht in einem Projekt der Schaltplan (ich arbeite mit sPlan vom gleichen Hersteller) am häufigsten parallel zum Layout (bzw. danach). Ich möchte eben gerne immer am Layout frei rumeditieren können, versch. Bauteilalternativen mit versch. Footprints gleich im Layout von den Platzverhältnissen her einschätzen und einbinden, ohne immer zuerst den Schaltplan entsprechend ändern zu müssen und die Netzverbindungen und Bauteile dann wieder rüber zu synchronisieren. Der Schaltplan dient mir persönlich eigentlich eher als Dokumentation. Da versteht es sich natürlich von selbst, dass ich dann lieber 10 statt 5 mal mit Argusaugen kontrollieren muss, dass alle Verbindungen bzw. das Layout insgesamt korrekt ist, aber das kommt meiner Art zu Arbeiten sehr entgegen, und ich nehme die zusätzliche Kontrolle für die 'Freiheit' in Kauf.


    Für mich hingegen könnte möglicherweise irgendwann einmal die Beschränkung auf maximal 4 Layer (Multilayer) zum Problem werden. Im Moment (momentan gerade ein Projekt mit 4 Layern) reichen mir diese vollauf, und bis ich mein erstes 6- oder 8-Layer Design entwickeln muss, wird es ja hoffentlich eine Version 7 geben ;) .
    Eine andere Schwäche, welche direkt mit Multilayer-Designs verknüpft ist, ist die fehlende, direkte Unterstützung (kein entsprechendes Element) für blind und buried Vias. Man kann sich diese zwar mit lochfreien und gelochten Pads auf bestimmten Layern rein vom Zeichnen her zusammenstiefeln, muss dann aber sehr aufpassen, welche Daten man von welchen Layern wie am Besten für die Platinen-Fertigung exportiert (bestimmte Drill-Daten nur von bestimmten Layern etc.).


    Gruss
    Neni

    Ich habe gerade ne Newsletter von Abacom erhalten, dass mein Lieblings-Layout-Programm Sprint endlich nach einer gefühlten Ewigkeit in der neuen, sehnlichst (von mir) erwarteten Version 6 erhältlich ist.


    - Das Wichtigste ist, dass das extrem einfache und intuitive Prinzip des Layout Malens/Zeichnens erhalten worden ist.


    Neu (im Vergleich zu Version 5) ist u.a.
    - eine deutlich erhöhte Auflösung bis auf 1µm.
    - neue Makro-/Bauteil-Verwaltung inkl. Pick&Place-Daten
    - Fangmodus beim Leiterbahnen Verlegen
    - Gerber-Import
    etc.


    Gruss
    Neni

    Basti, turi und ich experimentieren gerade auch mit dem MY9221, der 16 Bit Auflösung hat, da könnte man das auch nutzen, also erst mal (im Umsetzer tpm2 -> MY9221) mit Gamma-Korrektur von 8 Bit auf 11 Bit, und dann noch mit 5 Bit extra dimmen, ohne Farbauflösung zu verlieren...


    Apropos MY9221, ich habe hier noch einen Ausschnitt aus einer Schaltung, welche ich mal zusammengestiefelt habe, als ich noch vor hatte, den MY9221 für mein Projekt zu verwenden. Ziel war es, den MY9221 mit der Hardware-SPI-Schnittstelle ansteuern zu können, wozu ich die SPI-Clock mit einem D-FlipFlop durch 2 geteilt hatte. Hier die Schaltung, falls es etwas bringt:

    Für die SPI-Config kann man CPOL und CPHA auf 00 stellen. Wichtig wäre noch, dass man die entsprechenden Portpins für MOSI und SCK schon vor dem enablen der SPI-Schnittstelle auf Output und Low stellt, damit dieser Zustand auf den beiden Pins beim disablen der SPI-Schnittstelle eingehalten wird. Man muss die SPI-Schnittstelle nämlich nach jedem vollständigen Frame (über mehrere MY9221 hinweg) kurz deaktivieren und den MOSI-Pin dann kurz 4 mal HIGH pulsen, damit die übertragenen Daten gelatcht werden.


    Gruss
    Neni

    Also, ich muss ehrlich zugeben, dass mich dieses Lohnangebot als Schweizer echt schockiert hat :wacko: . Als IT'ler (jetzt mal egal welche Ausbildung) gerade mal 2200€ Brutto??? Also das kann doch nicht normal sein, auch für DE nicht, oder? Ich weiss ja, dass in DE Wohnraum im Schnitt deutlich günstiger und die Lebenshaltungskosten deutlich geringer sind als in der Schweiz, aber so viel günstiger nun auch nicht, als dass man solche Löhne für eine Anstellung in der IT-Branche als ok bezeichnen könnte.


    Ich kann mir das bloss so erklären, dass das eben via Verleihfirmen etc. so gelaufen ist, eigentlich irgendwie unlauter in meinen Augen :!: .


    Oder ist das wirklich der 'Normalfall' heutzutage in DE? ich kann's mir echt nicht vorstellen ?(


    Gruss
    Neni

    Der Electric Imp ist schon interessant, den habe ich auch schon seit Wochen im Auge ;) . Er konfiguriert sich quasi von selbst bzw. über ein von der Firma patentiertes Blink-Protokoll des jeweiligen, eigenen Smartphone-Bildschirms. Dazu gibt's ne App für Android oder iOS, welche dann die im Smartphone eingestellten WLAN-Parameter eben per Blink-Code optisch auf den Imp überträgt.


    Die Software für den Imp (bzw. den ARM darin) wird man via Online-Compiler in einer C-ähnlichen Skriptsprache programmieren können. Allerdings wird der Imp IMMER mit dem Internet verbunden sein müssen, da die gesamte Kommunikation via Server-Farm (bei Amazon gehostet) der Firma läuft. Das hat zwar den Vorteil, dass eigene Webapps dann auf Servern gehostet sind, um welche man sich nicht kümmern muss und dass eigene Imp-Software-Updates einfach per Internet auf alle Imps mit entsprechender ID gepusht werden können, aber auch den Nachteil bzw. die 'Gefahr', dass man die Kontrolle zum Teil abgeben muss und eben auch dass immer eine Internet-Verbindung bestehen muss.


    Gruss
    Neni