DFAtmo der Treiber für Atmolight Controller für VDR, xbmc und xinelib basierte video player

Servus,

Nachdem mein df10ch Atmo nun immer echt super funktioniert hat, bekomme ich es nun nicht mehr zum laufen.

Hatte die dumme Idee auf Ubuntu 11.10 (Kernel 3.0.0-16) zu updaten, seitdem gehts nicht mehr.

Verwende die aktuelle xine-lib, xine-ui und den aktuellen grab patch für xine-0.9.4. Erkannt werden die Controller einwandfrei,
und über das Setup Programm kann ich auch einwandfrei auf die 4 df10ch Controller zugreifen.

Hab mal ein paar Logs gemacht.
Einmal wenn ich versuche das Atmo über die Fernbedienung zu starten (enabled=0) und wenn es sofort startet (enabled=1)

Nach dem Start des X-server ist mir noch folgende Meldung aufgefallen:

::write(36561) returned -1, error 32: Datenübergabe unterbrochen (broken pipe)

Welches Plugin soll man denn jetzt verwenden?
Habe bis jetzt immer dieses verwendet: xine-atmo-post-plugin-v0.8

oder ist das jetzt aktueller:
https://github.com/durchflieger/DFAtmo

Danke Schonmal
Gruß
Johannes

Die udev regeln sollten eigentlich passen:

ACTION=="add", SUBSYSTEM=="usb*", ATTR{idVendor}=="16c0", ATTR{idProduct}=="05dc", MODE="0660"

Habe jetzt mal auf dfatmo umgestellt, da steht dann auch etwas mehr im xine log

DFAtmo: video open
DFAtmo: output driver closed
DFAtmo: output driver unloaded
DFAtmo: search output driver '/usr/local/lib/dfatmo/drivers/dfatmo-df10ch.so'
DFAtmo: loading output driver failed: /usr/local/lib/dfatmo/drivers/dfatmo-df10ch.so: undefined symbol: libusb_open
DFAtmo: loading output driver fails!
DFAtmo: no channels configured!
DFAtmo: video opened

dmesg:

dfatmo-df10ch.s[2617]: segfault at 1 ip 0000000000000001 sp 00007fff3aa88f28 error 14 in dfatmo-df10ch.so[7f7753876000+4000]

Einen Backtrace bekomme ich leider nicht hin, bzw. es steht nichts brauchbares drin:

No symbol table info available.

Hallo, bin neu hier, ich bin derjenige, der diese "Ambilight-SW" für das SEDU-Board geschrieben hat, und wurde auf diesen Thread aufmerksam gemacht.

Dort hiess es, dass man über das angesprochene Thema hier in diesem Thread weiter diskutieren solle, also mal die Fragen von drüben hier kopiert und beantwortet:

Zitat von AnDann

1. Das Seduboard kann nur 250000 (256000 geht wohl auch) und 500000 Baud.

Wenn der richtige Treiber installiert ist (der, bei dem das SEDU-Board in der Geräteüberischt auch so heisst, und *nicht* "USB serial Port"), dann gehen auch 115,2 k Baud.

die Kommunikation erfolgt hier über einen FT232 und dann über UART am Mega16/Mega644p - der µC kann nur bestimmte Baudraten, abgeleitet vom Systemtakt, eben die "geraden" wie 250 k, 500 k, 1 MBit.

da aber die Übertragung vom Rechner zum FT232 über USB erfolgt, gibt es hier keine Baudrate, der Treiber "sagt" dem FT232 nur, wie er das dann ausgeben soll, und der "SEDU-Treiber" wurde eben so modifiziert, dass der FT232 dann 250 k ausgibt, wenn man am Rechner 115,2 k (das ist halt einfach eine oft verwendete Baudrate, auch bei Processing o.ä.) einstellt.

Dies ließe sich auch für andere Baudraten so machen, also z.B. auch wenn man 230 k einstellt, dass dann 250 k raus kommen - siehe dazu die entsprechende AN bei ftdichip.com - ob/wie das für Linux geht, weiß ich aktuell leider nicht...

letztlich ändert man da nur ein paar Zahlen (Prescaler zur Teilung des internen FT232-Takts auf die Baudrate) in der Treiber-Datei, so dass dann eben eine andere Baudrate rauskommt, wenn man am Rechner ne Standard-Baudrate einstellt.

Zitat von AnDann

2. Das Protokoll des Seduboard ist miniDMX mit 256Byte Nutzdaten. Der proto String wird dadurch sehr lang und unter XBMC kommt dann der fehler das der proto String nur 255 Zeichen enthalten darf.

Ja, das ist so ein Problem bei Mini-DMX mit den festen Framegrößen, manchmal ist ein Frame gerade 3 Bytes zu klein, manchmal wird er zur Hälfte mit Overhead aufgefüllt...

daher wurde "bei uns" im LED-Forum ein neues Protokoll mit flexiblen Framegrößen entwickelt - dieses lässt sich hier auch umsetzen. Man muss nur den Startcode 0xC9 schicken, dann 0xDA für Datenframe, dann die Framegröße Hi-Byte/Lo-Byte, dann die Nutzdaten und dann 0x36 als Blockende-Code.

der Protocol-Descriptor würde dann z.B. so aussehen:

xC9|xDA|0|15|Rc|Gc|Bc|Rl|Gl|Bl|Rr|Gr|Br|Rt|Gt|Bt|Rb|Gb|Bb|x36
                       areas: Center, Left 1, Right 1, Top 1, Bottom 1

Die "15" eben für die 15 Bytes Nutzdaten, diese Zahl muss dann halt an die verwendete Framegröße angepasst werden, bei mehr als 255 dann in 16 Bit auf die Bytes 3 und 4 aufgeteilt...

für dieses Protokoll wird demnächst eine SW zur Umsetzung auf WS2801/WS2811/TM1804 etc. hier veröffentlicht, open source, also auch an andere HW als SEDU anpassbar - die macht dann halt nur die Umsetzung für das Ambilight, ohne die ganzen Standalone-Programme etc. - in der nächsten "Plug&Play"-Fertigversion wird das Protokoll aber auch drin sein...

Zitat von AnDann

Ich habe immer 2 LED`s zu einem Kanal zusammengeschaltet, da das SEDU Borad nur 64 Kanäle kann.

Das kommt daher, dass es damals für das Zusammenspiel mit AtmoWin entwickelt wurde, und dieses eben max. 64 Kanäle raus schickt.

Vor ein paar Monaten wurde mal angedacht, die Kanalzahl zu erhöhen, weil Boblight auch 256 Kanäle ausgeben könnte - da hatte mir aber niemand gesagt, welchen (inoffiziellen) Mini-DMX-Startcode für die Framegröße 768 Bytes ich nun nehmen soll, also ist das wieder eingeschlafen...

Das "Problem" ist dann aber auch mit der tpm2-auf-WS2811-etc.-SW bzw. dem nächsten Update behoben... da sind dann bis zu 1.024 RGB-Kanäle drin...

Es gab in dem anderen Thread auch schon ne Antwort, gleich hier rein gebastelt:

Zitat von AnDann

Hi, das kligt ja super, dann kann ich ja demnächst alle Kanäle scharf machen

Das mit dem Treiber ist aber nur unter Windows möglich wenn ich dich richtig verstanden habe (also 115k einstellen für 250k).

Es gibt von mir diesen modifizierten Treiber leider nur für Windows - und zwar hier...

mit Linux kenne ich mich nicht aus, ist da ein Treiber für FT232R schon dabei...? - falls ja, kannst Du mir die Datei ja mal schicken (PN), dann kann ich da mal rein gucken, sollte da ja ähnlich funktionieren, *irgendwo* muss das ja drin stehen, was der FT232 für nen Baudraten-Prescaler nimmt, wenn man am Virtuellen Com-Port (bzw. das Pendant bei Linux, k.A. wie das da heisst) 115,2 k einstellt...

Zitat von durchflieger

Da fehlt wohl das Paket libusb-1.0

Leider nicht:

root@vdr-wohn:/# apt-get install libusb-1.0-0 libusb-1.0-0-dev
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut
Statusinformationen werden eingelesen... Fertig
libusb-1.0-0 ist schon die neueste Version.
libusb-1.0-0-dev ist schon die neueste Version.
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 3 nicht aktualisiert.

Zitat von Pesi

mit Linux kenne ich mich nicht aus, ist da ein Treiber für FT232R schon dabei...? - falls ja, kannst Du mir die Datei ja mal schicken (PN), dann kann ich da mal rein gucken, sollte da ja ähnlich funktionieren, *irgendwo* muss das ja drin stehen, was der FT232 für nen Baudraten-Prescaler nimmt, wenn man am Virtuellen Com-Port (bzw. das Pendant bei Linux, k.A. wie das da heisst) 115,2 k einstellt...

unter Linux ist das
ftdi_sio Kernelmodul für den virtuellen COM Port zuständig. Das scheint aber keine Optionen zu besitzen.

durchflieger

Hast du vielleicht sonst noch eine Idee?
(hab jetzt auch die libusb mal neu installiert, aber das hilft auch nichts)

Oder vielleicht einen Hinweis wie ich dem Backtrace mehr entlocken kann.

durchflieger:

siehst du eine chance für softhddevice unterstützung?

gruss urknall

Zitat von durchflieger

Die Fehlermeldung bei dir deutet ja schon daraus hin dass beim laden des DF10CH-Treiber der Funktionsaufruf "libusb_open" nicht
gefunden wird. Das ist eine Funktion aus der libusb-1.0.
Ich vermute das die libusb Library nicht gefunden wird.
Was da aber genau auf deinem System schief läuft weis ich auch nicht. Vieleicht gibt es ja noch andere User die deine Ubuntu Version
verwenden. Mit der habe ich bisher nicht getestet.

Gruss
durchflieger

Habe gestern noch die ganze Zeit probiert, bin aber nicht weitergekommen.
Auch wenn ich eine ältere Libusb verwende ändert sich nichts.

Tja, dann gibts halt erstmal kein Atmo mehr.
(hätte das mit dem Updaten halt wohl einfach sein lassen sollen)

Vielleicht schaffe ich es mal, dass ich zum Testen einfach wieder auf das vorherige Ubuntu zurück gehe.

Gruß
Johannes

Bin nun endlich dazugekommen DFAtmo im XBMC einzurichten und es läuft echt von Anfang an perfekt!

Nun nur noch die Frage, ob es möglich ist, dass das Ambilight auch auf die Visualisierung beim Musik Abspielen reagiert. Bisher schaltet es sich ja immer erst ein, wenn man einen Film abspielt.

Ist das irgendwie möglich?

Zitat von durchflieger

Sollte machbar sein. Aber eine konkrete Planung für die Umsetzung habe ich noch nicht.

durchflieger:

danke für die info, du solltest mal softhddevice testen, da sind welten zwischen xine und co. und softhd.
johns macht da wirklich einen super job, was der mann in der kurzen zeit auf die beine gestellt hat und
wie super das ganze läuft ist schon beeindruckend.

vielleicht beschleunigt ein test die dfatmo unterstützung von softhddevice

lg urknall

Hallo durchflieger
habe es gerade mal installiert ..bin begeistert !!
Das Atmo jetzt auch als Plugin zu haben ist total klasse !!
Vielen Dank
speed

Hi!

Mein herzlicher Dank gilt dir Durchflieger, hab gerade das neue Plugin mit softhddevice getestet, funktioniert wunderbar

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