Posts by durchflieger


    Versionsnummern sind ok. Hast die neuste Version.
    Läuft xbmc vieleicht unter anderem User? Zugriffsrechte auf USB?
    Das vdr plugin darf nicht gleichzeitig laufen da immer nur ein plugin
    auf das usb zugreifen kann!


    Gruss
    durchflieger


    Hallo grappi,


    im git ist jetzt eine Version die mindestens alle 500ms die Farbdaten an den Atmocontroller sendet. Ist aber von mir noch ungetestet.


    Gruss
    durchflieger


    Ich vermute mal (habe kein SEDU) das SEDU Board schaltet auf die feste Farbe um wenn eine Zeit lang keine Daten gesendet wurden.
    Das DFAtmo ist aber so optimiert das es nur Daten an den Kontroller sendet wenn diese sich verändert haben.
    Vermutlich muss du nur im SEDU die Timeoutzeit für die feste Farbe erhöhen damit es besser klappt.


    Gruss
    durchflieger

    Ich hab zwar keinen Rapberry Pi aber soweit ich es bisher von anderen gehört habe fehlt zumindestens in der derzeitigen stablen XBMC
    Version 12.1 der Render Capture Support für den Pi. Ohne den läuft das DFAtmo nicht.


    Trotzdem das noch zu deinem Problem.
    Wenn der Schritt 1. bei dir ohne Fehler durchgelaufen ist dann sollten *.deb Dateien erzeugt worden sein (im Parentverzeichnis zum Projekt).
    Die haben vermutlich nicht amd64 im Namen sondern was anderes da der Pi ja eine andere Plattform ist.


    Gruss durchflieger


    Der Begriff "überlappung" ist vieleicht nicht richtig gewählt. Vielmehr gehts darum die Sektionengrenzen möglichst genau zwischen die LED's zu bekommen bzw. die LED's
    möglichst in die Mitte der Sektionen zu haben. Das DFAtmo teilt die sichtbare Bildschirmkante halt immer in gleich grosse Sektionen ein. Da kann zur Zeit auch nichts
    weiter konfiguriert werden. Mann muss halt dann die LED's am Bildschirm passend ausrichten.
    Wenn die Stripes länger als die sichtbare Bildschirmkante sind weil man z.B. bis zum anschliessenden Stripe die Ecke schliesst mancht es Sinn diesen
    LED's auch den Farbwert der Sektion zuzuordnen, die am nächsten an der Ecke liegt. Das konfiguriert man dann im "proto" String in dem man die selbe Variable einfach
    mehrfach verwendet. Der Einsatz von Ecksektionen macht bei den digitalen Stripes wenig Sinn da ja genügend Kanäle in der Hardware vorliegen.


    Das DF10CH Setupprogramm stellt dir die Sektionsgrenzen genau dar womit die Ausrichtung der Stripes sowie die Planung welche Sektionen welchen LED's zugeordnet werden
    sollen sehr vereinfacht wird. Weiterhin visualisiert es die Parameter analyse_size, edge_weighting und weight_limit womit deren Funktion auch einfacher verständlich wird.


    Gruss durchflieger

    Hallo,


    eine neue Version 0.3.4 des DFAtmo steht zum Download bereit.
    Neu ist der Support für vdr 2.x hinzugekommen bzw. alle VDR
    Versionen die bereits eine pkg-config basierte Konfiguration haben.
    Zum bauen des vdr plugin siehe README.


    Weiterhin habe ich das xbmc addon gegen XBMC V12.1 Frodo stable
    getestet mit dem DFAtmo einwandfrei funktioniert.
    Die fehlerbehaftete V12.0 wird vom DFAtmo nicht unterstützt!


    Gruss
    durchflieger


    In deiner "proto" Zeichenkette sind aber die Variablen für die Ecksektionen noch drin. Hier wird jetzt immer der Wert 0 ausgegeben wenn du die Ecksektionen auf 0 gesetzt hast da ja in der
    Bildanalyse keine Werte mehr für die Ecksektionen berechnet werden!


    Die Anleitung (README) gibt es bisher nur in Englisch.
    Das Flakern kann man mit filter_threshold = 99 reduzieren. Farbabstimmung mit den wc_* Optionen.


    Überlappung der Pixel wird über die Anzahl Sektionen und deren Zuordnung im "proto" konfiguriert.
    Es gibt da von mir ein grafisches Setupprogramm für den DF10CH Atomlight-Controller mit dem man die
    konfigurierten Sektionen am Bildschirm sehr schön visualisiert bekommt. Es berechnet die Sektionen ganuso
    wie das DFAtmo. Damit vereinfacht sich die korrekte Ausrichtung/Konfiguration der LED-Strips massgeblich.
    Man kann das Programm auch ohne DF10CH Controllerhardware betreiben in dem man mit der Option -s
    simulierte Kontroller einstellt.
    Veileicht hilft dir das Programm weiter. Siehe: DF10CH


    Gruss
    durchflieger

    In der "proto:" Option des driver_param gibst du die Reihenfolge der Datenbytes vor, die an den SEDU-Controller gesendet werden. Es hängt dann von deiner konkreten
    Verdrahtung deiner LED-Stripes mit dem SEDU-Controller ab, welche Datenbytes welchen LED's zugeordnet sind. Das musst du als erstes selber herausfinden.


    Ich versuchs mal anhand deiner derzeitigen Konfiguration zu erklären was da gerade ausgegeben wird:
    In deiner derzeitigen Konfiguration gibts du die Farbwerte in der Reihenfolge RGB für eine Sektion aus, beginnend mit den Farbwerten für die linke untere Ecke (von vorne gesehen),
    dann 33 Sektionen am unteren Bildschirmrand in absteigender Reichenfolge (33 ... 1), dann die rechte untere Ecke, dann 21 Sektionen am rechten Bildschirmrand
    in absteigender Reihenfolge, dann die rechte obere Ecke, usw.


    Dazu passend müsstest du die Sektionen wie folgt konfigurieren:
    bottom_left=1, bottom=33, bottom_right=1, right=21, top_right=1, top=33, top_left=1, left=21


    Deine Strips müssten somit insgesamt 1 + 33 + 1 + 21 + 1 + 33 + 1 + 21 = 112 RGB-LED's haben damit es passt.


    Die Einspeisung ist hier wohl unten links vorgesehen. Die Drehrichtung lässt sich nicht so richtig bestimmen.


    Für jede Ecke kann es immer nur maximal eine Sektion geben oder keine. Eine Ecksektion sollte den LED's zugeordnet werden, die genau an der Eckspitze am Bildschirmrand
    angeordnet sind bzw. alle den LED's die sich aufgrund eines Abstand zum sichtbaren Bildschirmrand in der Ecke befinden. Beispiel:


    TL T1 T2 ..
    L1
    L2
    ..


    TL TL T1 T2 ...
    TL
    L1
    L2
    ...


    Bei folgender Anordnung sollte keine Ecksektion konfiguriert werden (wobei XX für hier ist keine LED montiert steht):


    XX T1 T2 ...
    L1
    L2
    ...


    Ich hoffe das hilft dir weiter. Ich selber habe kein SEDU-Board im Einsatz und kann damit also nichts zur konkreten SEDU-Hardware/Konfiguration beitragen.


    Gruss
    durchflieger

    So, wie ich das bisher sehe gibts dafür keine Möglichkeiten, oder gibt es ein Plugin welches Informationen über andere Plugins liefern kann?


    Achso, kann dieses Thema bitte nach VDR-Plugins verschoben werden? Hab das vorhin nicht gemerkt, dass ich in Developer gepostet hab.

    Im git ist jetzt eine Version des vdr plugin das folgende SVDRP Kommandos versteht:


    enabled yes -> switch Atmolight on
    enabled no -> switch Atmolight off
    enabled -> return current enabled status (YES or NO)


    - durchflieger

    Hallo,


    eine neue Version 0.3.2 des DFAtmo steht im git bereit mit folgenden Erweiterungen:


    Added support for XBMC V13 git revision past Feb. 10 2013
    Note: Within XBMC V12.0 Frodo stable the DFAtmo support is brocken!!!
    Added untested Makefile 'vdr2plug.mk' to build plugin for recent vdr versions
    Added SVDRP command to vdr plugin to enable/disable plugin



    Viel Spass damit!


    Gruss
    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