atmocontroller v3

  • Warum schon wieder eine neue Version?


    Was kann V3 besser:
    Einstellbarer Gammakorrektur auf dem Atmocontroller
    Weißabgleich auf dem Atmocontroller
    Gesamthelligkeit auf Atmocontroller einstellbar
    Abspeichern der Einstellungen im EEPROM
    Sourcen in C
    Viel freie Rechenleistung für Erweiterungen (Helligkeitssensor, Farbprogramme ohne PC, DMX Receiver...)


    Warum die ganzen Korrekturen auf dem Atmoboard?
    Wenn man, so wie ich, die unveränderten Alpahtec LED-Module verwendet, muss beim Weißabgleich grün und blau extrem zurück gedreht werden. Dass führt dann bei dunklen Szenen zu einem rotstich. Dieser muss dann wieder per Gammakorrektur am PC korrigiert werden. Wenn dann noch die Gesamthelligkeit zurückgedreht werden soll, bleiben von den vielen Millionen darstellbaren Farben bleiben, nur noch ein paar hunderttausend übrig. Damit läßt sich leider nicht mehr jede Farbe vernünftig darstellen.
    Das Verfahren wäre dann so, als würde man die Monitorhelligkeit im Grafiktreiber einstellen. Das geht, sieht aber oft mies aus. Deshalb werden in V3 die Korrekturen im Anzeigegerät (Atmocontroller) durchgeführt.


    Für die Einstellerei wurde das Protkoll etwas erweitert (siehe Receive.c), die alten Atmocontroller lassen sich davon aber nicht irritierern. Im Anhang befindet sich auch ein grauenvolles Winproggie zum einstellen und ermitteln der Parameter.


    Das funktioniert dann ungefähr so:
    Volle Helligkeit einstellen (mit „+“)
    die zu hellen Farben anpassen (mit „qwe“ uns „asd“ )
    eine dunkle Helligkeit einstellen mit (mit „-“)
    eventuell das Gamma jeder Farbe anpassen (mit „rtz“ und „fgh“)
    Speichern mit „S“


    Danach ist der Weißabgleich im atmocontroller drin und braucht nicht mehr im Plugin eingestellt werden (Achtung: im Plugin darf jetzt kein Weißabgleich und verbogene Gamma drin sein)


    Bin gespannt auf Euer feedback


    swifty




    PS:
    Das Atmoadjust gibts hier: Download



    [edit]
    Bugfix 1: Kanal 2 ließ sich nicht ansprechen (war immer auf Summenkanal konfiguriert). Neue Version: 0.81
    Bugfix 2: Bei ungültigen Werten von Contrast und Gamma konnte die Reihenfolge durcheinander geraten, Danke an Igor, der es gemerkt hat. Neue Version: 0.82

  • Hi,


    coole Sache!


    Was mich jetzt vor allem interessiert ist die Theorie dahinter :)


    Du schreibst, dass du "leichten Rotstich bei dunklen Passagen" mit der Gammakorrektur wegbekommen hast. Dass sowas geht, ist mir klar, deshalb haben wir ja die Gammakorrektur im Plugin dringelassen. Aber warum?


    Villeicht interessierts dich auch (da du ja offenbar ein gutes Auge hast) wo ich vor über einem Jahr stehengeblieben bin mit der atmo Entwicklung. Hab damal nicht mehr weitergemacht, weils offenbar überflüssig war und alle glücklich.


    Hab mal versucht die unterschiedlichen Farbräume der LEDs und des Fernsehers anzugleichen, hast du davon schon mal was gehört? Hat leider nie vernünftig geklappt...sollte aber nach meiem Verständnis der Theorie Extramfarben und eben die von dir erwähnten leichten Abweichungen korigieren...


    Grüße,
    Simon

  • hm, wie erklär ichs...


    Ich denke das Problem ist die 8Bit Auflösung der seriellen Schnittstelle, die auf die 11Bit PWM per Gammakorrektur abgebildet werden muss. Die RGB Übertragung ist durch den diskreten Wertebereich von 0...255 nichtlinear, es ist in dem Falle also nicht egal, ob Weißabgleich-RGB_Übertragung-Gammakorrektur oder RGB_Übertragung-Weißabgleich-Gammmakorrektur gemacht wird. Wenn alle Werte im Farbabgleich nahe beieinander liegen merkt man keinen Unterschied, wohl aber wenn wie bei den Alphatec LEDs die absoluten Helligkeiten bis zu ca. 200% auseinander liegen.


    [edit]
    Ein extremes Beispiel: Ein im PC Weißabgleich errechnetes dunkles "weiß" führt zu den RGB Werten (20/10/12). Bei der statischen Gammakorrektur im atmo ist rot schon mit ca. 5/2048 an, grün ist aus und blau hat nur 1/2048 der PWM. In diesem schwachen Lichtbereich ist das Auge aber sehr empfindlich und sieht "rot".


    Die Farbräume von Fernseher und LED anzupassen ist glaube ich ein ganz anderes Kapitel und vermutlich unmöglich. Eine Fernsehröhre, eine Beamerlampe, ein TFT und ein Plasma haben physikalisch andere Lichterzeuger mit jeweils eigenem Spektrum. Man müsste alse LED Streifen bauen die ganau die Wellenlänge des Lichterzeugers treffen.
    Ich glaube aber, dass mit guter Auswahl der Wellenlängen der LED-Streifen man sich dem Farbraum des jeweiligen "Fernsehers" ganz gut annähern kann. Aber der Aufwand steigt extrem und billig wird es auch nicht. Mir reicht es so wie es (nun) ist, da jetzt ein guter Weißabgleich über einen großen Bereich möglich ist.


    swifty

  • Hi!


    Ich komme auf:
    Contrast (Helligkeit) R:100, G:52, B:54
    Gamma R: 22, G: 22, B:21
    Gesamthelligkeit bleibt auf 100


    Der Weißabgleich wurde aber bei mir nur auf den Monitor getestet. Beim Beamer kommen sicher andere Werte. Hinzukommt, dass die Module noch für Rot getuned werden müssen, die schwächste Fabe bestimmt leider die Gesamthelligket.
    Ich weiß noch nicht ob ich wie samc mit Brücken eines Rotwiderstandes oder nachbestücken, oder beides die Rothelligkeit erhöhe.


    swifty

  • Moin,


    Zitat

    Contrast (Helligkeit) R:100, G:52, B:54


    also bei solchen Werten würde ich die Ursache und nicht die Symptome
    bekämpfen.
    Sprich, wie Du schon vorgeschlagen hast, was an den LED-Streifen machen.


    Samael

    Für Heilige gibts 'nen Heiligenschein - für Fernseher das Solarstorm.

  • Tach auch!


    Absolut richtig. Der perfekte Atmocontroller kann vergurkte LED Streifen nicht rettten. Aber die Kombination aus gutem Controller und gutem LED-Modul ist glaub schon ganz charmant. Zumal das Dimmen dann ohne Auflösungsverluste möglich ist (^= Einstellung Contrast am Monitor).


    Da Ihr ja von Anfang an dabei wart hätte ich ein paar Fragen:
    Warum habt ihr den Atmega8 und nicht den Atmega26 verwendet?
    Warum habt ihr die Taktfrequez nicht auf 16MHz eingestellt?


    Zur Info: ich habe auf einem Atmega16 mit JTAG entwickelt. Ohne die Debugmöglichkeiten hätte ich nach 10h aufgegeben. Und die Serielle läuft auch mit 16MHz tadellos.
    Wenn ihr mit dem Atmega8 entwickelt habt, mein absoluten Respekt, das ist wirklich nicht einfach.


    swifty

  • Zitat

    Original von swifty99
    Hi!


    Ich komme auf:
    Contrast (Helligkeit) R:100, G:52, B:54


    Wow, dass ist aber in der Tat extrem. Alphatec == Alphalicht, oder? Weil bei meinen LED-Modellen ist eigentlich das rot die stärkste Farbe. Eventuell eine neue Revision?

  • Hi,


    bei 16Mhz lief die Serielle zwar, aber konnte nur ein paar bytes empfangen bevor sie asynchron wurde.


    Es gibt mehrere verschiedene Versionen der Sreifen, Rot ist _immer_ die dunkelste Farbe, bei manchen ist aber Grün noch überdurchschnittlich hell.


    Ansonsten hängen die Weißabgleichwerte sehr stark vom verwendeten Fernsehen/Monitor ab...da hab ich schon gewaltige Unterschiede feststellen müssen. Deshalb _muss_ jeder den Weissabgleich selbst so einstellen wies ihm gefällt. Wird was am Fernseher verstellt, muss man auch den Weißabgleich neu einstellen..



    Grüße,
    Simoin

  • Moin!


    Zitat

    Warum habt ihr den Atmega8 und nicht den Atmega26 verwendet?


    Das ist einfach historisch gewachsen (erst CCFLs, dann LEDs, usw.).
    Wenn ich heute noch mal anfangen würde, würde ich wahrscheinlich
    auch einen anderen Controller wählen (mit ausreichend Hardware-PWM-Kanälen).
    Da die Hardware aber durch das Vorgängeprojekt quasi fertig war, war
    die Soft-PWM von samc eine super Rettung/Lösung!


    Zitat

    Wenn ihr mit dem Atmega8 entwickelt habt, mein absoluten Respekt, das ist wirklich nicht einfach.


    Ja, haben wir. Aber so wild war es nicht, wenn man sich erst über die
    serielle Schnittstelle debug-Möglichkeiten schafft. Ansonsten hilft einfach
    fehlerlosen Programmieren ;)


    Zitat

    Grüße,
    Simoin


    Nanü? Si-moin? Wird aus Dir noch ein Nordlicht? ;D


    Gruß,
    Daniel

  • Na dann: Respekt!


    Ich habs mit der fehlerfreien Programmierung nicht so, hab ja JTAG.


    Die Serielle läuft auf meinem 16MHz Atmega völlig synchron.. Naja, es wird ja nur die PWM Grundfrequenz gesenkt. Bei Atmo v3 ist sie übrigens 112Hz, also locker ausreichend.


    swifty



    PS: Hat es mal jemand getestet?

  • Hallo Leute,


    swifty schrieb unter "Was kann V3 besser" unter anderem "Viel freie Rechenleistung für Erweiterungen (Helligkeitssensor, Farbprogramme ohne PC, DMX Receiver...)". Heist das, daß man den Atmocontroller von einer DMX-Steuerung regeln kann?
    Wenn ja wie schließt man diese an und wie wird die Startadresse eingestellt?


    Gruß Matthias

    VDR1: DVB-S 2.3 und Skystar, ctvdr, LCD, Brenner
    VDR2: DXR3 und TT-Budget, ctvdr, LCD

  • Hi!


    DMX ist derzeit eine "Option". Will heißen, die automatische Umschaltung der Baudrate (DMX=500kBit) und das Decodieren (Code gibts glaub en Masse) muss noch eingebaut werden.
    Ich hatte vorgesehen, die Startadresse über das Atmoconfig mit einzustellen.


    Ist aber "optional" :), will heißen es gibt noch nix wirkliches.


    swifty

  • Hallo,


    dann bin ich ja mal noch auf die Zukunft in Sachen Atmolight gespannt. Zum testen bin ich auf jedenfall bereit.


    Matthias

    VDR1: DVB-S 2.3 und Skystar, ctvdr, LCD, Brenner
    VDR2: DXR3 und TT-Budget, ctvdr, LCD

  • Soa, hab jetzt auch geflasht, allerdings: bei mir geht dann nur Kanal 1. Kanal 2 bleibt stumm!


    Bei der Kalibration sind beide Kanäle da, dann unter AtmoWin nur noch der erste. Kanal 2 bleibt schwarz.


    Also: BUUUG! :(

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!