Beiträge von durchflieger
-
-
Ich bekomme das libusb Problem auf meinem Ubuntu 12.04 LTS nachvollzogen.
Ich habe mal probehalber die "lucid" Version der libusb rückportiert aber auch da
bleibt das Problem.
Es liegt vermutlich an den Compiler/Linken-Optionen habe aber leider auch noch
keine Idee was da wohl falsch läuft.Gruss
durchflieger -
Hier gehts auch weiter: DFAtmo v0.3.0!
Mit den Funktionserweiterungen der Option "proto:" im serial output driver dürfte die Konfiguration jetzt deutlich kürzer ausfallen.
Siehe README-Datei des Projekt.
Auch der CPU load bei vielen Sektionen ist jetzt wesentlich niederiger.
Wäre schön wenn das mal jemand mit SEDU Board testet.Gruss
durchflieger -
Hallo,
die neue Version 0.3.0 des DFAtmo steht auf github zum Download bereit!
Auszug aus dem Changelog:
Code
Alles anzeigenOptimize performance of image analysis algorithm: 1. By introducing a new weight table so that only calculation for pixel with relevant weight (currently > 5%) is done. 2. Do not calculate windowed histograms if windowing size is 0. Fixed calculation of weight table for border sections. Fixed analysis error for saturation window size 0. Serial output driver: Extend maximum output package length to 1023 bytes to support SEDU B0 mode. Enhanced protocol descriptor syntax: For constant values a repeat count or fill up count could be specified to define a arbitrary number of bytes with the same constant value. A couple of RGB groups within the same area with monotone increasing or decreasing sections could be defined with the new shortcut operators '+n' and '-n'. README: Added performance hints. Added enhanced protocol descriptor syntax. Added SEDU protocol example.
Update lohnt wegen der Performance Verbesserungen auf jeden Fall!
DFAtmo auf github
XBMC addon für WindowsViel Spass beim ausprobieren!
Gruss
durchflieger -
ok, danke.
Wir lassen uns das mal auf der Zunge zergehen und schauen uns das im Code mit den bisherigen serial/df10ch Treibern an, gefällt uns aber auf den ersten Blick gut.
Würde das implizieren diese miniDMX firmware zu benutzen von der Krautmaser geredet hat? (Das hat für den Betrieb glaub ich noch andere Vorteile, hab ich in dem anderen Board gelesen)
Christian
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. -
danke, dann fass ich mal zusammen:
Der SEDU mit den Stripes spielt prima mit deinem dfatmo, sowohl mit vdr als auch mit deinem xbmc addon. - ist aber, gerade wenn es um viele PIX geht, nicht wirklich ergonomisch zu konfigurern, zumindest hab ich schon jemanden hier im Forum gefunden der so eine Kombination physisch vorhanden, jedoch nicht am laufen hat.Ist das soweit korrekt? Wenn sich das so verhält würden Horchi und ich da gern was machen, Controller sind zwar noch nicht vorhanden aber im Zulauf.
Deshalb würde ich gern einen geeigneten Ansatz erörtern:
- soll man das df10ch_setup.py dementsprechend erweitern? - Python ist jetzt nicht unsere Sprache, aber wenn das deiner Meinung nach nur marginale Änderungen sind ist gfs eine Alternative.
- gibt es gfs schon ein passendes Tool für xbmc, windows oder whatever, dessen Konfiguration man konvertieren kann (Bevor alle losschreien, das Setuptool des Controllers läuft eh unter Windows)
---- was ist da mit diesem Tool von Krautmaster, ist das schon weiter und kann das mittlerweile (wie vor ein paar Monaten diskutiert) den Kontroller bei passender Firmware im miniDMX mode fahren.
---- warum ist das Konfigfile für xbmc egtl nicht äquivalent?
- würde man es ins Pluginsetup des dfatmo bauen - würde ja egtl Sinn ergeben - wäre das im vdr nur mit der FB (ohne Tastatur und Maus) noch ergonomisch zu bedienen
- hättest du dazu andere Ideen die wir weiter verfolgen könnten?Gruß
Christian
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
durchfliegerP.S.: Das dfatmo/df10ch war auch mein erstes Python Projekt. Hat sehr viel Spass gemacht mit dieser
mächtigen Scriptsprache. -
ich muss hier noch mal auf blöd fragen:
dieses df10ch_setup.py Python Sktipt kann auch benutzen um das dfatmo auf andere Controller, bsw den SEDU mit WS2801 LED Stripes einzustellen, der Name des Sktipts kommt einfach daher das er im Zuge des DF10CH Projektes entwickelt wurde?
Und wie viele separate Kanäle unterstützt das dfatmo Plugin bzw xbmc addon, der Controller macht ja in der aktuellen Version bis zu 256 Kanäle?
Christian
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 -
Ja, die kannte ich schon.Den "xine-lib-vdr-input-grab.patch" für die xine-lib hast du aber nicht drin!
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
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 -
ok erstmal dankeschön =)
driver_param hatte ich von angepasst mit diversen String, werde das aber heute Abend bzw bei Gelegenheit mal testen.
Das MiniDMX zu ergänzen wäre natürlich eine feine Sache.
Turi schrieb im Detail dass folgende Modi möglich sind:
64 Kanäle reichen aber oft nicht aus weshalb es diese erweiterten Modi gibt.
Für einen Test tut es mir aber auch der kleine 192 Byte Daten Modi.
Seh ich dann richtig dass für zb nur 3 Kanäle der String so aussehen müsste:
com3&speed:256000&proto:x5A|xA1|Rt1|Gt1|Bt1|Rt2|Gt2|Bt2|Rt3|Gt3|Bt3|xA5
oder wie ist die |0| noch zu verstehen?
(wären in diesem beispiel 3 Top Kanäle oder?)
Vielen Dank!
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 -
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
FozzyBei 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 SupportWeiterhin wurde der Fehler beseitigt dass temporär veränderte Parameter im Setup gespeichert wurden.
Viel Spass beim ausprobieren...
- durchflieger
-
Hallo,
anbei ein Patch der die "grab unsupported" Meldungen im log vermeidet wenn das sofhddevice im suspend
mode ist und das DFAtmo plugin läuft.Gruss
durchflieger -
Hi Durchflieger,
erstmal danke für das tolle Plugin - es funktioniert einwandfrei und OOTB mit meinem Uralt-Atmolight (seriell)
Eines ist mir dabei etwas störend aufgefallen: Der Hauptmenüeintrag und der Konfigurationseintrag 'Launch on startup' scheinen dasselbe zu sein. Habe ich atmo eingeschaltet und setze 'launch on start' via Konfigurationsmenü auf 'no' wird es sofort abgeschaltet. Wenn ich es eingeschaltet habe wird der Eintrag auf 'yes' gesetzt und beim nächsten Einschalten des VDR auch das Licht eingeschaltet..
Lässt sich das nicht entkoppeln?Pit
Hmm, das sollte eigentlich entkoppelt sein. Muss ich selber nochmal prüfen.
-
durchflieger:
Gibt es eine Möglichkeit auf den Stand von xine-lib (df-extensions) von vor 3 Wochen zurückzugehen ?
Ich würde das gerne testen.Ins xine-lib Projektverzeichnis wechseln:
git log | more
Die commit id (HEX-Zeichencode) des gewünschten Zeitpunkt merken. Dann:
git checkout <commit-id>
-
hallo,
ich habe 2 controller inkl. led stripes abzugeben weil ich mir einen philips mit ambilight zugelegt habe.
bei interesse einfach mal melden: 01722656885
viele grüsse
r. daun
@Hendrik
da gibts noch fertig aufgebaute gebraucht zu kaufen.