Beiträge von durchflieger

    Hallo,


    die neue Version 0.3.0 des DFAtmo steht auf github zum Download bereit!


    Auszug aus dem Changelog:



    Update lohnt wegen der Performance Verbesserungen auf jeden Fall!


    DFAtmo auf github
    XBMC addon für Windows


    Viel Spass beim ausprobieren!


    Gruss
    durchflieger


    Wie gesagt mit dem sedu hab ich mich nicht näher beschäftigt kann somit auch nichts zur firmware sagen.
    Beim df10ch bin ich so vorgegangen das ich Weissabgleich und Gammakorrektur im dfatmo Treiber durchführe
    weil hier mehr als genug Rechenpower zur Verfügung steht. Die Konfigurationsdaten werden hier allerdings nicht
    in eine eigene Datei geschrieben sondern vollständig im NVRAM des Controller gespeichert. Somit ist das dann
    plug & play auch bei mehreren Controllern egal an welchem USB Port/Hub die eingesteckt sind.
    Unterstüzung für mehrere Controller gleichzeitig ist für das sedu ja nicht notwendig womit die Sache dann doch einfacher wird.


    WIe gut oder schlecht das dfatmo mit dem sedu läuft dazu kann ich nichts sagen da ich kein sedu einsetze.
    Die Konfiguration so vieler Kanäle mit dem derzeitigen dfatmo serial Treiber ist aber sicher nicht optimal.
    Deshalb hab ich ja für den df10ch einen eigenen Treiber und eigenes Setup entwickelt.
    Meine Empfehlung wäre einen eigenen Treiber abgeleitet aus dem serial (und df10ch) für das sedu zu entwickeln.
    Bei den Stripes liegen die Kanäle ja immer schön seriell hintereinander so das eine Konfiguration jedes
    einzelnen Kanal wie derzeit in der "proto" Option realisiert nicht nötig ist (ist zu umständlich).
    Ein Weissabgleich sowie individuelle Gammakorrektur pro Kanal kann aber sinnvoll sein insbesondere
    wenn inhomogene LED's zum Einsatz kommen. Da wäre dann ein spezielles Setupprogramm alla
    df10ch_setup schon hilfreich. Dieses Programm könnte die Konfigurationsdaten ja in eine eigene
    Datei schreiben die dann vom sedu dfatmo treiber geladen würden. In dem Setupprogramm könnten
    auch die Treiber unabhängigen Parameter des dfatmo (oder ein Teil der Parameter) konfiguriert werden.
    Die derzeitige Treiberschnittstelle im dfatmo gibt das her und es wird vom df10ch Treiber auch genutzt.
    Damit wäre die Konfiguration Einheitlich für vdr und xbmc.


    Gruss
    durchflieger


    P.S.: Das dfatmo/df10ch war auch mein erstes Python Projekt. Hat sehr viel Spass gemacht mit dieser
    mächtigen Scriptsprache.


    Das df10ch_setup.py ist zur Zeit nur für den DF10CH Controler geeignet.
    Pro Bildschirmkante unterstützt das dfatmo zur Zeit bis zu 128 Kanäle, also insgesamt 517.
    Sieh auch das README zum Projekt.


    Gruss
    durchflieger


    Danke, klingt schonmal gut. Ich habe aber nirgends etwas gefunden, wie man den Input im dfatmo dann auf diese Karte einstellt. Früher beim Atmo wurde dann von /dev/videoX gegrabt. Evtl. muss man da dann Codemäßig noch etwas anpassen oder habe ich etwas übersehen?


    Es wird über die standard Grab-Funktion des primären Device im VDR gegrabt. Deshalb gibt es da nichts einzustellen.

    Eine kurze Frage:


    Ich nutze zur Zeit noch das Atmolight mit einer TT S2300 full featured Karte als Input zum Graben (oder alternativ eine Hauppauge NOVA-S Plus, die einen Video-Input hat, den man auch graben kann). Kann das dfatmo auch diesen Input zum Graben verwenden? Nach langer Suche sieht es für mich so aus, das dies nicht möglich ist (nur softhddevice oder xmbc). Ist das richtig? Falls doch würde ich nämlich gerne auf dfatmo umstellen.


    Danke!


    Ich habe zwar nie mit einer FF getestet aber prinzipiell sollte das auch funktionieren.


    Gruss
    durchflieger

    Hi,
    auch hier erst mal Danke für das tolle Plugin, funktioniert astrein mit dem Controller aus Papsis Sammelbestellung anno 2007.


    Was ich jedoch nicht gefunden habe ist ein timerabhängiger Startmodus des Plugins. Wenn nun nachts eine Aufnahme läuft, bekommts auch der Nachbar mit ;D
    Ist so eine timerabhängige Beleuchtung beim DFAtmo-Plugin auch möglich?


    Danke und Gruß,
    schef


    Das im DFAtmo-Plugin zu regeln ist der falsche Ansatz. Du musst verhindern das das Ausgabeplugin (softhddevice bei dir?) nur dann läuft wenn du auch zuschaust.
    Wenn kein Ausgabedevice läuft dann geht auch das DFAtmo in einen "standby" Modus und schaltet das Licht ab.
    Gruss
    durchflieger


    Alles soweit richtig. Das MiniDMX erwartet aber wohl feste Paketlänge von 192 Byte. Du musst also zu den bereits 9 Byte Nutzdaten noch 183 Byte Fülldaten hinzufügen.
    Das kann eben durch hinzufügen von Konstanten Null-Werten erreicht werden: "|0|0|..."
    Das MiniDMX ist aufgrund der festen Paketlänge auch nicht gerade ein ideales Protokoll für diese Anwendung.


    Hier mal meine Überlegungen zu einer Erweiterung des DFAtmo:
    Für den Betrieb deiner Stripes könnte man eine spezielle Variante des "proto:" String im DFAtmo implementieren die das ganze wesentlich abkürzen könnte.
    Deine Stripes dürften ja immer die selbe Reihenfolge der R/G/B Werte haben so das man die Folge "Rt2|Gt2|Bt2" zu "t2" verkürzen könnte.
    Weiterhin liegen die Kanäle einer Area ja immer in Folge so das aus "t1|t2|t3" dann einfach "t" werden könnte wobei dann die im DFAtmo konfigurierte Anzahl
    Sectionen dieser Area eingesetzt würde (bei 3 Kanälen Top wären das die 9 Nutzbytes) . Eventuell muss noch Aufsteigende oder Absteigende Reihenfolge defnierbar sein?


    Andererseits hast du ja schon ein Setupprogramm geschrieben mit dem du bereits die boblight.conf erzeugt. Das könntest du erweitern damit eine settings.xml für DFAtmo erzeugt wird.
    Dann müsste im DFAtmo nur das Limit für driver_param hochgesetzt werden.


    Gruss
    durchflieger

    Krautmaster


    der String im "driver_param" in der settings.xml müsste prinzipiell folgenden Aufbau haben:


    com3&speed:256000&proto:x5A|xA2|Rt1|Gt1|Bt1|Rt2|Gt2|Bt2|...|0|...|xA5


    Das "Datenpaket" im mini dmx Protokoll muss mit den Variablen für die Farbwerte in der "proto:" Option zusammengesetzt werden wobei die Reihenfolge hier
    ja von der konkreten Hardwareinstallation abhängt (Reihenfolge der R/G/B Werte bzw. der Areas (Oben, Unten ....) im Datenpaket.
    Da mini dmx wohl mit festen Datenpaketlängen arbeitet muss das Paket dann mit Nullwerten "|0|" aufgefüllt werden.
    Ein Problem dabei ist die grosse Paketlänge von 512 Byte da hier der "driver_param" String wohl schnell das Limit im DFAtmo von derzeit 2Kbytes überschreiten wird.
    Probier doch erstmal mit Prefix A0 (96 Byte Paketlänge). Wenn das funktioniert kann ich das Limit gerne hochsetzen oder sogar eine "mini dmx"
    Protokolloption ergänzen damit das ganze etwas geschmeidiger wird.


    Gruss durchflieger

    ..nur Frage ich mich, wie das mit dem dfatmo an/aus gehen soll? Also mit dem "a" auf der Tastatur geht es leider nicht.
    Im Menü habe ich auch keinen Eintrag für das dfatmo (ist auch normal, oder?).


    Viele Grüße
    Fozzy

    Bei dem xine player musst du in der "keymap" Datei für "DFAtmoEnabled" eine (noch nicht verwendete) Taste zuweisen. Die Datei findest du normalerweise unter $HOME/.xine/keymap


    Gruss
    durchflieger

    Ist im GIT drin.


    Wobei ein Suspend Mode auch für das dfatmo plugin nicht schlecht wäre.


    Johns


    Danke für die schnelle Integration des Patch.
    Das dfatmo kennt jetzt auch einen suspend mode. Der wird anhand des nicht gelieferten grab image erkannt. Dann wird die grab rate von 40ms auf
    konfigurierbare 250ms hochgesetzt und das Atmolight solange ausgeschaltet bis wieder images vom softhddevice geliefert werden.


    durchflieger

    Hallo,


    im git steht eine neue Version des DFAtmo VDR plugin bereit mit folgenden Verbesserungen:


    Wenn das video device beim grabben kein image zurückliefert weil z.B. das softhddevice im suspend mode ist
    dann wechselt das plugin nun selber in einen suspend mode. In diesem Mode wird das Atmolight ausgeschaltet
    und die grab und output rate auf die im Parameter "start_delay" angegebenen Zeiten gesetzt um die CPU Last
    zu senken.
    Um ein fluten des Log durch das softhddevice in diesem Mode zu vermeiden sollte noch dieser Patch
    angewendet werden: [softhddevice][patch] Verbesserter Grab Support



    Weiterhin wurde der Fehler beseitigt dass temporär veränderte Parameter im Setup gespeichert wurden.


    Viel Spass beim ausprobieren...


    - durchflieger

    Hmm, das sollte eigentlich entkoppelt sein. Muss ich selber nochmal prüfen.