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:

    Code
    ::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


  • Ja bitte nur noch dieses verwenden:
    https://github.com/durchflieger/DFAtmo


    Sind die Zugriffsrechte richtig gesetzt? (/etc/udev/rules.d)

  • Die udev regeln sollten eigentlich passen:

    Code
    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

    Code
    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:

    Code
    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:

    Code
    No symbol table info available.

  • Da fehlt wohl das Paket libusb-1.0


    Für Ubuntu kannst du einfach deb Pakete bauen und diese installieren.
    Siehe unter "Ergänzung zum Teil 1" hier:
    DFatmo Plugin unter yaVDR 0.4 Final mit Karatelightsupport | Installationsanleitung

  • 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:

    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.


    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:


    Code
    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...


    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:



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


    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...

  • Da fehlt wohl das Paket libusb-1.0

    Leider nicht:


    Code
    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.
  • 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.

    SERVER: Chenbro SR105, Intel DQ77MK, Xeon E3-1220LV2 (17W TDP), 16GB Ram, 64GB SSD, 3 x 3TB HDD (ZFS Raidz1), L4M S2 V5.5 + DD DuoFlex S2, ESXi 5.1, Openindiana (NAS), Ubuntu Server 12.04 x64 mit YaVDR 5.0 Repository, Ubuntu Server 12.04 x64 mit OpenHAB
    VDR1: SilverStone LC17S
    , ASUS P5KPL, Core2Duo E6300 @ 1,4Ghz, Zotac GT520 Zone Edition, 4GB Ram, 64GB SSD, mceusb, 188 Kanal Ambilight (seduatmo)
    VDR2: Amisos X15e, AsRock Z68M/USB3, Intel G630T, ASUS GT610, 4GB Ram, 32GB SSD, IRTrans Einschalter, 96 Kanal Ambilight (seduatmo)
    VDR3: Zotax ION 330-1, Intel Atom 330, 2GB Ram, 16GB
    SSD

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


    Im DFAtmo ist doch jetzt unter Linux 250000 und 500000 Baud direkt konfigurierbar. Damit sollten doch angepasste ftdi Treiber eigentlich überflüssig sein?

  • 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.


    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?

  • 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

    VDR: yavdr-ansible/22.04 LTS auf Intel NUC (BOXNUC6CAYH), 2x Kingston KVR16LS11/4, One For All URC 2981

    VDR-Server: yavdr-ansible/22.04 LTS in ESXi VM

  • Hallo,


    die Version V0.2.0 von DFAtmo steht im git zum Download bereit!


    Die wichtigste Neuerung dürfte wohl das neue DFAtmo VDR Plugin sein das jetzt auch mit dem softhddevice und vermutlich auch mit den
    SD und/oder HD full featured Ausgabekarten zusammenspielt.
    Prinzipiell läuft das Plugin mit dem "softhddevice" out of the box. Für eine bessere Performance empfehle ich jedoch noch meinen Grab
    Patch für das softhddevice den ich in einem gesonderten Thread veröffentlichen werden.


    Weiterhin habe ich noch den "combined" Filter überarbeitet der in bestimmten Situationen ein Flackern in der Ausgabefrequenz (20ms / 50Hz)
    zeigte.
    Weiterhin kann man jetzt die Ausgaberate mit dem Parameter "output_rate" konfigurieren. Manchen Karatelight Controllern sind die 20 ms der
    Standardeinstellung wohl zu schnell.


    Weiterhin gabs intern noch ein paar Umstellungen um die gemeinsamme Codebasis für die drei Varianten VDR, XBMC und Xine zu verbessern.


    Alles weiterer zur Installation findet Ihr wie immer im README zum Projekt (Siehe github Link im ersten Artikel dieses Thread),


    Viel Spass damit!!!


    Gruss durchflieger

  • Hi!


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

    VDR: yavdr-ansible/22.04 LTS auf Intel NUC (BOXNUC6CAYH), 2x Kingston KVR16LS11/4, One For All URC 2981

    VDR-Server: yavdr-ansible/22.04 LTS in ESXi VM

  • Hi Durchflieger,


    erstmal danke für das tolle Plugin - es funktioniert einwandfrei und OOTB mit meinem Uralt-Atmolight (seriell) :tup


    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

    VDR2: ASRock J4105-ITX, DVBSky S952, openSUSE Tumbleweed, VDR 2.4.7

    softhddevice/vaapidevice, DFAtmo, xmltv2vdr, tvscraper, tvguideng, VDRAdmin-AM (alles git, aber alt)

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

Jetzt mitmachen!

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