[UPDATE] Projekt RGB-Wall: Plasma-Effect

  • Hallo Stefan,
    wenn ich mein ursprüngliches Vorhaben mit einzelnen, abgeschlossenen Lichtkammern für die 'Pixel' weiter verfolgt hätte, dann wäre sicherlich truLED-Plexi oder ein anderes milchig-weisses das Mittel der Wahl gewesen, da es eben insbesondere durch die starke Streuung aber auch durch Reflexion des Lichtes nach hinten, und dann durch den weissen Hintergrund wieder nach vorn etc. zu einer sehr homogenen Ausleuchtung der ganzen 'Pixel'-Fläche kommt.
    Bei meinem jetzigen Vorhaben ohne Kammern muss das Plexi eine möglichst hohe Transmission (möglichst ohne oder nur wenig Reflexion) bei gleichzeitig guter Lichstreuung bieten, und da ist eben Satin Ice die beste Wahl, welches die 'Pixel' genügend weichzeichnet, aber dennoch wenig 'Übersprechen' zwischen den 'Pixeln' (oder besser gesagt Farbklecksen) verursacht. Deshalb ist ja auch der Hintergrund (d.h. die Platine) jetzt in matt-schwarz gehalten, damit etwaige Rest-Reflexionen am Plexi nach hinten dann möglichst vom Hintergrund geschluckt werden.


    Bezüglich Lötstoppfarbe:
    Pesi hat da schon das richtige Zitat von mir rausgesucht, deshalb wiederhole ich es jetzt nicht nochmals. Ausserdem ist in meiner Antwort oben an Stefan der Grund nochmals aufgeführt. Aber ich muss auch zugeben, dass mir das Schwarz jetzt auch rein vom Style her besser gefällt (wie auch Fightclub) als das Weiss.


    Bezüglich Lobby bzw. PRO-Bereich:
    Ich hätte für die Fortsetzung der Projekt-Fortschritts-Dokumentation mit der neuen Platine Version 2 noch so gerne einen neuen Thread im PRO-Bereich aufgemacht, nur leider bin ich dort immer noch nicht freigeschaltet worden, obwohl meine Bewerbung dort schon seit Ende Oktober letzten Jahres mit lauter "PRO"-Bekundungen drin steht. Aber eigentlich will ich wegen sowas gar nicht rumjammern. Wenn man mich freischaltet, ok, und wenn nicht, auch ok, ich bin ja nicht auf den PRO-Berich angewiesen.


    Bezüglich Spam:
    Schneeblau, dein Interesse an meinem Projekt in allen Ehren, aber der Kommentar mit den Elkos war schon etwas dümmlich, das wirst du wohl auch selbst zugeben müssen, wenn du ganz ruhig darüber nachdenkst. Schliesslich habe ich Montage-Bohrungen (3 mm) auf meiner Modul-Platine in jeder Ecke, da werde ich wohl kaum irgendwelche elektronischen Bauelemente als Abstandhalter oder sogar Montage-Elemente missbrauchen, meinst du nicht auch? ;) . Damit will ich es hier aber bewenden lassen, kühlt bitte eure Gemüter etwas ab und lasst uns hier wieder so zivilisiert es geht zum eigentlichen Thema zurück kommen.


    Grüsse aus Zürich
    Neni

  • So meine erstes Testprogramm lief inzwischen. Ist doch garnicht so schwierig zu programmieren, habe haber noch nicht alle Register probiert. Allerdings ist die LED Leuchtkraft für meine Vorhaben noch etwas gering. Kennt jemand sehr helle LED´s im 1206 Gehäuse? Möglichst farbige?

  • So, nur ein kurzes Update hier, Details, Bilder und Videos zum Test werden dann in einem überarbeiteten Thread zum Projekt im PRO-Bereich reingestellt werden, sobald ich Zeit dafür habe.


    Die Platine Version 2 funktioniert einwandfrei :) . Ich habe eine kleine Testfirmware mit versch. festen Animationsmustern draufgespielt. Dabei wird der Dipschalter (der normalerweise zur Adresseinstellung des einzelnen Modules dient) zum Einstellen von Muster, Animationsgeschwindigkeit und Farbmodus 'missbraucht'. Der Test war ein absoluter Erfolg, und insbesondere muss ich sagen, dass ich diesmal von der sehr niedrigen Varianz der LEDs zueinander total überzeugt bin. Die verwendeten Samsung-PLCC6-LEDs sind bezogen auf die Anforderungen in diesem Projekt also ihr Geld in allen Belangen wert. Bei den zwei getesteten Farbmodi - einmal klassischer Hue-Regenbogenverlauf und einmal dasselbe aber mit Helligkeitsausgleich (die Lichtemmissionsleistung wird über den gesamten Hue-Bereich möglichst konstant gehalten) - bin ich mir noch nicht ganz im Klaren, welcher für meine Zwecke der idealere ist. Da muss ich aus optischer Sicht noch ein paar weitere Vergleiche anstellen. Vom Gesamtstromverbrauch her hat natürlich der Farbmodus mit Helligkeitsausgleich einen klaren Vorteil.


    Soweit mal also das Update hier, im Post darunter stelle ich noch den BASCOM-Testcode rein, wo man sich auch die i2c-Ansteuerung des TLC59116 rauslesen kann.


    Gruss
    Neni

  • Hallo maxi,


    es könnte daran liegen, dass du eine zu niedrige CPU-clock verwendest. Diese muss nämlich mindestens 16 mal höher sein als die gewünschte SCL-Taktrate. Bei 400 kHz SCL-Takt musst du also mind. 6,4 MHz CPU-clock haben, idealerweise aber ab 8 MHz.


    Gruss
    Neni

  • Hallo maxi,


    es könnte daran liegen, dass du eine zu niedrige CPU-clock verwendest. Diese muss nämlich mindestens 16 mal höher sein als die gewünschte SCL-Taktrate. Bei 400 kHz SCL-Takt musst du also mind. 6,4 MHz CPU-clock haben, idealerweise aber ab 8 MHz.


    Gruss
    Neni

    Das kanns in meinem Fall abe rnicht sein da ich sogar 20 Mhz nutze, also sogar mehr als du. Komisch!

  • hmmm, also hast du kontrolliert, ob die $crystal-Angabe in deinem Code auch stimmt?
    also $crystal = 20000000
    Es passiert nicht selten dass man mal eine Null zu wenig eingibt oder so ;) , und dann stimmen die entsprechenden Berechnungen für die Registerwerte im Compiler eben nicht.


    Was gibt er dir denn als Fehlermeldung aus?


    Gruss
    Neni

  • hmmm, also hast du kontrolliert, ob die $crystal-Angabe in deinem Code auch stimmt?
    also $crystal = 20000000


    Nö, das hat schon gestimmt. Ich habs aber nun gefunden, es lag daran das die crystal Anweisung hinter der LIB Anweisung kam, sie musste davor. Ich dachte das ist egal. Nun klappts auch mit 1 Mbit TWI

  • Hallo maxi,


    naja, ich muss zugeben, dass ich etwas 'faul' war in der letzten Zeit. Darum habe ich noch kein Video gemacht. Die Test-Animationen laufen allerdings super, und ich benötige bei 400 kHz i2c knapp etwas mehr als eine Millisekunde für die Datenübertragung aller 16 RGB-LEDs, also pro Frame. Damit kann ich mit dem aktuellen Test-Animationen-Programm locker 500 Frames pro Sekunde schaffen. Wenn der µC in der Endversion dann noch etwas mehr beschäftigt sein wird (wobei die Frame-Verarbeitungszeit zur reinen Datenübertragungszeit hinzukommt), wird die max. erreichbare Framerate auf vielleicht 300 - 350 Frames pro Sekunde sinken. Da ich aber die Framerate sowieso auf max. 100 pro Sekunde limitieren werde, ist das noch locker in den Spezifikationen drin.


    Im Moment bin ich am Planen des Gesamtaufbaus (16 Module, 256 RGB-LEDs) inkl. Gehäuse, Hauptcontroller, Überlegungen zum Steuerungsprotokoll etc. Auch deshalb bin ich noch nicht dazu gekommen, ein Viedo zu machen, den Thread neu aufzubereiten und in den Pro-Bereich zu stellen (mit dem Video allein ist's eben auch nicht getan).


    Gruss
    Neni

  • Das macht doch glatt Lust auf Mehr :thumbup:


    Echt toll was du da auf die Beine stellst.


    Ich komme leider vor lauter arbeit nicht dazu auch nur eins meiner Projekte ernsthaft zu bearbeiten ;( Und die Liste mit anzufangenden Projekten wird auch immer länger :D