VDR Plugin zur Anbindung an SEDU Controller

    Moin


    nach dem die Hardware Findung ja hier SEDU Amblight mit LED Flex Stripes und dfatmo abgehandelt wurde, diese nun vorhanden ist mehr als zufriedenstellend funktioniert hier ein neuer Thread in Richtung Softwarestrategie. Da wir immer noch nicht so ganz tief in dem LED Thema unterwegs sind, zwar viel aber längst nicht alles gelesen haben möchten wir ein paar Meinungen einholen die uns die ideale Richtung des weiteren Vorgehens aufzeigen können.


    Wir waren am Anfang davon ausgegangen, dass es hinreichend wäre das dfatmo um eine weitere Controllerschnittstelle zu erweitern und alles ist gut. - Das ist aber mitnichten der Fall. Wenn wir das machen fehlt ein xbmc addon, ein geeignetes setup tool und auch ein testtool um mal schnell zu sehen ob etwas funktioniert oder auch nicht.


    Da wir ja bisher nur mit den SEDU gelieferten Windowstools getestet haben, wir für vdr ja noch nichts haben hab ich gestern mal Boblight installiert. - ich muss sagen ich hatte das in 10 Minuten in Gang und es gefiel mir ganz gut. Boblight ist so eine Deamon Client Geschichte, es gibt verschiedene Frontends wir ein xbmc addon, ein commandline testtool und auch ein boblight-X11, in letzteres hab ich mich noch nicht eingelesen. - Dazu gibt es ein sehr schickes Setuptool von Krautmaster (wenn auch für Windows, aber benutzt man ja nur einmal) Ein großer Vorteil von Boblight wäre weiterhin das die Unterstützung des SEDU bereits implementiert ist, also ootb unterstützt wird. Auch nimmt er für alle "Clients" dieselbe conf und da so eine Serielle Schnittstelle ja genauso zickig wie alsa ist wäre ein hin und herschalten zwischen verschiedenen Applikationen mit einer direkten Verbindung immer eine Fummelei (ich sag nur kein Ton in xbmc)


    Die Frage die ich mir gerade stelle ist ob es überhaupt eine so gute Idee ist das dfatmo an SEDU anzudocken, oder ob es nicht vllt viel pragmatischer ist so ein plugin auf der Inputseite wie dfatmo zu haben, auf der Outputseite jedoch an boblight anzupassen. - Warum das Rad neu erfinden. – Alles was neu dazu kommt muss auch gewartet werden, boblight ist ziemlich verbreitet in der xbmc Szene und wird an anderer Stelle gepflegt.


    Übersehe ich da was bzw. gibt es gute Gründe nicht in diese Richtung zu denken?


    Christian

    CKone: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G540, 2x 2GB Kingston DDR3, Zotac GT630 1GB, S2-1600, Ocz Agility 3 60GB, LG GH24NS DVD, 15.6" Selbstbau TFT, Harmony 665, CIR Selbstbau - das Ganze im Silverstone SST-SG03B
    CKtwo: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G1610, 2x 2GB Corsair DDR3, Zotac GT630 1GB, TT S2-1600, Ocz Vertex 2 50 GB, 92 Kanal Seduatmo, Harmony 665, atric USB
    CKthree: yavdr-ansible/22.04 LTS/2.6.1/kodi19.3 auf Intel NUC, Celeron J4005, UHD Graphics 600, 4GB Crucial DDR4, Ocz Vertex2 50 GB, Harmony 350

    PowerEdge: Ubuntu Server 16.04 LTS / VDR 2.4.1 auf Dell PowerEdge T20, Xeon E3-1225 v3, 16GB ECC DDR3, 2x Cine S2 V6 mit Duoflex, Samsung 840 EVO 120GB, 3x WD White WD80EZAZ 8TB in SW Raid5



    so, etwas weiter:


    Wir haben etwas gespielt um mit dem SEDU und der Firmware vertraut zu werden, dabei ist ein kleines Programm entstanden mit dem man den SEDU ohne Windows mit Befehlen entsprechend der Protokollbeschreibung auslesen und programmieren kann. - Das ging mit dem Standardzubehör bisher nur unter Windows, ist aber etwas stressig ewig umzustecken wenn man was ändern möchte.


    root@CKtwo:/usr/local/src/linseducfg# ./linseducfg

    Code
    Usage:  linseducfg [-h] [-v] [-d <device>] [<hex> <hex> <hex> <hex> ... <hex>]
  -h  show usage
  -v  verbose
  -d  tty device (default /dev/ttyUSB0)


Examples:
  - Read configuration:  linseducfg a5 5a ff c1


    [Edit] ich hab das setuptool wegen einer Miniänderung noch mal ersetzt [/Edit]


    Dann mal schnell zwei weitere Bilder nach der Erstinbetriebnahme unter boblight-X11:
    da geht noch einiges, hier wurden nur auf die Schnelle die LEDs bekanntgemacht, es hat kein gamma-/ weißwertabgleich stattgefunden. Dies ist nur quick n dirty damit wir ein besseres Gefühl für die einzelnen Tools bekommen. - Der Test ist übrigens noch unter xbmc, das boblight-X11 arbeitet so nicht mit softhddevice zusammen, an der Stelle würde wir dann ein eigenes Plugin schreiben, welches diese Anbindung bereitstellt.


    Christian

    Bilder

    Dateien

    linseducfg.tar.gz 1,77 kB – 230 Downloads

    CKone: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G540, 2x 2GB Kingston DDR3, Zotac GT630 1GB, S2-1600, Ocz Agility 3 60GB, LG GH24NS DVD, 15.6" Selbstbau TFT, Harmony 665, CIR Selbstbau - das Ganze im Silverstone SST-SG03B
    CKtwo: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G1610, 2x 2GB Corsair DDR3, Zotac GT630 1GB, TT S2-1600, Ocz Vertex 2 50 GB, 92 Kanal Seduatmo, Harmony 665, atric USB
    CKthree: yavdr-ansible/22.04 LTS/2.6.1/kodi19.3 auf Intel NUC, Celeron J4005, UHD Graphics 600, 4GB Crucial DDR4, Ocz Vertex2 50 GB, Harmony 350

    PowerEdge: Ubuntu Server 16.04 LTS / VDR 2.4.1 auf Dell PowerEdge T20, Xeon E3-1225 v3, 16GB ECC DDR3, 2x Cine S2 V6 mit Duoflex, Samsung 840 EVO 120GB, 3x WD White WD80EZAZ 8TB in SW Raid5



    Einmal editiert, zuletzt von CKone ()

    Hi, ich habe ein Ambilight mit dem SEDU Board bereits seit einem Jahr mit dem dfatmo Plugin am laufen. Mann kann die Ansteuerung mit dem Protokoll parameter für das SEDU anpassen.
    Die Einstellungen müssen in XBMC und im VDR Plugin gesetzt werden, die umschaltung zwischen beidem funktioniert einwandfrei.


    Hier mal meine Konfiguration des VDR Plugins aus der setup.conf:


    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

    copy paste in die setup.conf und läuft, vielen Dank.


    allerdings 66% CPU schon im kleinen A1 Mode.... hmm


    Christian

    CKone: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G540, 2x 2GB Kingston DDR3, Zotac GT630 1GB, S2-1600, Ocz Agility 3 60GB, LG GH24NS DVD, 15.6" Selbstbau TFT, Harmony 665, CIR Selbstbau - das Ganze im Silverstone SST-SG03B
    CKtwo: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G1610, 2x 2GB Corsair DDR3, Zotac GT630 1GB, TT S2-1600, Ocz Vertex 2 50 GB, 92 Kanal Seduatmo, Harmony 665, atric USB
    CKthree: yavdr-ansible/22.04 LTS/2.6.1/kodi19.3 auf Intel NUC, Celeron J4005, UHD Graphics 600, 4GB Crucial DDR4, Ocz Vertex2 50 GB, Harmony 350

    PowerEdge: Ubuntu Server 16.04 LTS / VDR 2.4.1 auf Dell PowerEdge T20, Xeon E3-1225 v3, 16GB ECC DDR3, 2x Cine S2 V6 mit Duoflex, Samsung 840 EVO 120GB, 3x WD White WD80EZAZ 8TB in SW Raid5



    also mit nem kleinen Skript für die config Zeile konnte ich das nun in meinem Setup zum funktionieren zu bewegen: ich musste allerdings aus A1 Mode zurückgreifen da ansonsten irgend eine Logik einen Fehler vermutet:

    Code
    Nov  3 14:44:23 CKtwo vdr: [5972] DFAtmo: output driver error: message to long

    habe also jetzt "nur" 85 LEDs konfiguriert (max in A1 Mode, weiß noch nicht ob die Reihenfolge stimmt aber geht!)


    Problem ist hier mE die Systemlast, nicht ganz so schick: ich stell mir hier schon was anderes vor wenns fertig ist ;D



    Christian

    Bilder

    CKone: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G540, 2x 2GB Kingston DDR3, Zotac GT630 1GB, S2-1600, Ocz Agility 3 60GB, LG GH24NS DVD, 15.6" Selbstbau TFT, Harmony 665, CIR Selbstbau - das Ganze im Silverstone SST-SG03B
    CKtwo: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G1610, 2x 2GB Corsair DDR3, Zotac GT630 1GB, TT S2-1600, Ocz Vertex 2 50 GB, 92 Kanal Seduatmo, Harmony 665, atric USB
    CKthree: yavdr-ansible/22.04 LTS/2.6.1/kodi19.3 auf Intel NUC, Celeron J4005, UHD Graphics 600, 4GB Crucial DDR4, Ocz Vertex2 50 GB, Harmony 350

    PowerEdge: Ubuntu Server 16.04 LTS / VDR 2.4.1 auf Dell PowerEdge T20, Xeon E3-1225 v3, 16GB ECC DDR3, 2x Cine S2 V6 mit Duoflex, Samsung 840 EVO 120GB, 3x WD White WD80EZAZ 8TB in SW Raid5



    Einmal editiert, zuletzt von CKone ()

    richtig eingestellt sieht die config dann so aus, funktioniert technisch einwandfrei mit softhddevice:


    root@CKtwo:/var/lib/vdr# cat setup.conf | grep dfatmo


    Wenn man es in A2 mit den 512Byte Nutzdaten verwendet meldet das dfatmo zu lange Pakete: ist wohl für solche Megastreams nicht gebaut. Man muss sich hier zunutze machen, dass die SEDU Firmware wohl einen kleinen Bug hat und sich nicht um weggelassene Nullen schert, wenn ich nur meine 92 Kanäle übertrage funktioniert das trotzdem, auch wenn es nicht mehr miniDMX konform ist.


    Für meinen Geschmack ist das boblight hier mehr smooth, funktioniert irgendwie geschmeidiger. Das kann jedoch auch gut daran liegen, dass ich in dfatmo noch nicht die idealen EInstellngen gefunden habe. - In jedem Fall ist das Plugin alles andere als ressoucenschonend!


    Trotzdem haben wir hiermit jetzt eine (erstmal) funktionierende Lösung für vdr und xbmc, für den Anfang schon mal super!


    Christian

    CKone: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G540, 2x 2GB Kingston DDR3, Zotac GT630 1GB, S2-1600, Ocz Agility 3 60GB, LG GH24NS DVD, 15.6" Selbstbau TFT, Harmony 665, CIR Selbstbau - das Ganze im Silverstone SST-SG03B
    CKtwo: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G1610, 2x 2GB Corsair DDR3, Zotac GT630 1GB, TT S2-1600, Ocz Vertex 2 50 GB, 92 Kanal Seduatmo, Harmony 665, atric USB
    CKthree: yavdr-ansible/22.04 LTS/2.6.1/kodi19.3 auf Intel NUC, Celeron J4005, UHD Graphics 600, 4GB Crucial DDR4, Ocz Vertex2 50 GB, Harmony 350

    PowerEdge: Ubuntu Server 16.04 LTS / VDR 2.4.1 auf Dell PowerEdge T20, Xeon E3-1225 v3, 16GB ECC DDR3, 2x Cine S2 V6 mit Duoflex, Samsung 840 EVO 120GB, 3x WD White WD80EZAZ 8TB in SW Raid5



    Einmal editiert, zuletzt von CKone ()

    Zitat von CKone

    Wenn man es in A2 mit den 512Byte Nutzdaten verwendet meldet das dfatmo zu lange Pakete: ist wohl für solche Megastreams nicht gebaut. Man muss sich hier zunutze machen, dass die SEDU Firmware wohl einen kleinen Bug hat und sich nicht um weggelassene Nullen schert, wenn ich nur meine 92 Kanäle übertrage funktioniert das trotzdem, auch wenn es nicht mehr miniDMX konform ist


    Hierzu habe ich gestern Abend von durchflieger folgendes Fix erhalten:


    Zitat

    Im serialoutputdriver.c dazu Zeile 339 ändern:

    Code
    uint8_t msg[512]; --> uint8_t msg[1024];


    damit gehts dann auch protokollkonform bis einschießlich B0 Mode und 256LEDs max


    Um zu verhindern das sonst die große Plugin Compile Orgie losgeht: Vllt könnte das jemand freundlicherweise in das yavdr Paket patchen, danke. ;D


    Christian

    CKone: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G540, 2x 2GB Kingston DDR3, Zotac GT630 1GB, S2-1600, Ocz Agility 3 60GB, LG GH24NS DVD, 15.6" Selbstbau TFT, Harmony 665, CIR Selbstbau - das Ganze im Silverstone SST-SG03B
    CKtwo: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G1610, 2x 2GB Corsair DDR3, Zotac GT630 1GB, TT S2-1600, Ocz Vertex 2 50 GB, 92 Kanal Seduatmo, Harmony 665, atric USB
    CKthree: yavdr-ansible/22.04 LTS/2.6.1/kodi19.3 auf Intel NUC, Celeron J4005, UHD Graphics 600, 4GB Crucial DDR4, Ocz Vertex2 50 GB, Harmony 350

    PowerEdge: Ubuntu Server 16.04 LTS / VDR 2.4.1 auf Dell PowerEdge T20, Xeon E3-1225 v3, 16GB ECC DDR3, 2x Cine S2 V6 mit Duoflex, Samsung 840 EVO 120GB, 3x WD White WD80EZAZ 8TB in SW Raid5



    Kanns kaum erwarten, auch wieder zu basteln. :tup

    - Client1: Thermaltake DH 102 mit 7" TouchTFT * Debian Stretch/vdr-2.4.0/graphtft/MainMenuHooks-Patch * Zotac H55-ITX WiFi * Core i3 540 * 4GB RAM ** Zotac GT630 * 1 TB System HDD * 4 GB RAM * Harmony 900 * satip-Plugin

    - Client2: Alfawise H96 Pro Plus * KODI
    - Server: Intel Pentium G3220 * DH87RL * 16GB RAM * 4x4TB 3.5" WD RED + 1x500GB 2.5" * satip-Plugin
    - SAT>IP: Inverto iLNB

    Hallo Jungs,
    mein dfatmo mit SEDU-Controller läuft schon mal fast perfekt. (CPU-Last ca.27 %) Die Einspeißung ist bei mir rechts unten, es geht dann im Uhrzeigersinn herum(von vorn gesehen). Das entspricht wohl nicht den default-Angaben von durchflieger. Ich hoffe, das kann mann korrigieren.

    Zitat

    First Led of chain starts at bottom right corner. Order of Leds is clock wise around the TV.

    Leider sind bei mir auch rechts und links vertauscht. Eingestellt habe ich:

    Code
    dfatmo.driver = serial
dfatmo.driver_param = /dev/ttyUSB0&speed:500000&proto:x5A|xA2|Rbl|Gbl|Bbl|Rb33|Gb33|Bb33|-32|Rbr|Gbr|Bbr|Rr21|Gr21|Br21|-20|Rtr|Gtr|Btr|Rt33|Gt33|Bt33|-32|Rtl|Gtl|Btl|Rl21|Gl21|Bl21|-20|xA5


    Alle LEDs leuchten, aber teilweise "gespiegelt" oder eben rechts und links getauscht. Mir fehlen nur noch ein paar Tips bezüglich der driver_param Einstellung.
    z.B. wie gebe ich die Stelle der Einspeißung an, wie gebe ich die Umlaufrichtung an, was bedeutet "1 Led for each corner", wo muß die dazu gezählt werden, usw.
    Leider konnte ich das aus der Readme von Durchflieger nicht rauslesen.
    Wer hat da schon Erfahrung und kann mir helfen ?
    PS: Im XBMC läuft auch das dfatmo-plugin mit den gleichen Merkmalen.
    Danke Euch

    MLD 4.0.1-64: softhddevice, skinnopacity, tvscraper ,...
    HTPC-Hardware: C847MS-E33+Celeron 847,Geforce GT610,4GB Ram,Cine S2 V6.5,WD15EADS 1,5TB,be quiet! Pure Power L7 300W,Lian Li PC-c37b,seduatmo + SEDU Controller SW 3.0 + T+B je33 Pix,L+R je 21 Pix mit WS2801, 7" Touch TFT,TV:LG42LH9000, AV: Onkyo TX-NR717+RC-836M mit Atric IR-WAKEUP USB eco[br][br]MLD 3.0:,div. Plugins,LIRC,LG-Brenner, Hauppauge Nexus2.1 m. RGB Out (handgebondet), Hauppauge WinTV NOVA SE2, K7S41, AMD GEODE 1750, 512 MB,300GB HDD, GLCD 240x128,SST-LC13,outsourced to my mother

    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

    Thueringer01
    Wieso nimmst du nicht einfach das VDR-Plugin-Seduatmo.
    Ist einfacher und verbraucht auch nicht soviel Rechenpower.


    Hier


    Gruß Santos

    VDR1
    - Yavdr 0.5 - Zotac D2700 Atom 2X2.13GHZ - GT520 Onboard- 4GB Speicher - 32GB CF- Technotrend TT S2-4100 - Alphacool Display - YaUsbIr 2- Technotrend Fernbedienung - Gehäse Plexiglas (Stable)


    VDR2
    - Yavdr 0.5- AsRock 77 mit i3-3220T 2X2.8GHZ- 4GB Speicher- GT 440 Passiv - 64GB SSD 2,5"- DigitalDevices Cine S2- LG Bluray - 10" Monitor - YaUsbIr 2 - T Home Fernbedienung - uMouse Cardreader - Gehäse Bitfenix Prodigy M (Unstable)

    durchflieger,
    Danke,klar kontest du mir helfen. Ich habe alle Ecksektionen , z.B bottom_left=1 etc auf "0" gesetzt. Die haben wohl Alles durcheinander gebracht. Dann noch rechts <->links getauscht. Jetzt passen die Seiten und es gibt auch keine gespiegelten Seiten mehr. Angepasst sieht das jetzt so aus:

    Code
    dfatmo.driver_param = /dev/ttyUSB0&speed:500000&proto:x5A|xA2|Rbr|Gbr|Bbr|Rb33|Gb33|Bb33|-32|Rtl|Gtl|Btl|Rl21|Gl21|Bl21|-20|Rtr|Gtr|Btr|Rt1|Gt1|Bt1|+32|Rbr|Gbr|Bbr|Rr1|Gr1|Br1|+20|xA5


    Jetzt brauche ich noch etwas Tuning. Gibt es die Beschreibung der Parameter auch in German ? Ich hab teilweise Flackern, Farbstimmung muß korrigiert werden, Überlappung der Pixel ist zu groß, Eintauchtiefe ins Bild. Mit probieren komme ich hier nicht so richtig weiter.
    Santos
    Da hatte ich auch dran gedacht. Jetzt bin ich hier erst mal weiter. Braucht man den Patch noch und wann kommt das seduatmo in stable ?
    Danke und viele Grüße
    noch ein paar Bilder von der Hardware:

    noch ein Bild: Einspeißung unten links, umlaufend clockwise (von hinten gesehen), SEDU-Controller mit V 3.0,Stripe von Ali., Netzteil ist ein MW 5V,5A von Reichelt.

    Bilder

    MLD 4.0.1-64: softhddevice, skinnopacity, tvscraper ,...
    HTPC-Hardware: C847MS-E33+Celeron 847,Geforce GT610,4GB Ram,Cine S2 V6.5,WD15EADS 1,5TB,be quiet! Pure Power L7 300W,Lian Li PC-c37b,seduatmo + SEDU Controller SW 3.0 + T+B je33 Pix,L+R je 21 Pix mit WS2801, 7" Touch TFT,TV:LG42LH9000, AV: Onkyo TX-NR717+RC-836M mit Atric IR-WAKEUP USB eco[br][br]MLD 3.0:,div. Plugins,LIRC,LG-Brenner, Hauppauge Nexus2.1 m. RGB Out (handgebondet), Hauppauge WinTV NOVA SE2, K7S41, AMD GEODE 1750, 512 MB,300GB HDD, GLCD 240x128,SST-LC13,outsourced to my mother

    nein das Patch benötigt man lang nicht mehr - ich maile mit Lars damit er es nach stable kopiert.


    Es ist so wie Santos sagt, dass das seduatmo ideal auf den SEDU Controller zugeschnitten ist und auch viel ressourcenschonender ist


    Christian

    CKone: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G540, 2x 2GB Kingston DDR3, Zotac GT630 1GB, S2-1600, Ocz Agility 3 60GB, LG GH24NS DVD, 15.6" Selbstbau TFT, Harmony 665, CIR Selbstbau - das Ganze im Silverstone SST-SG03B
    CKtwo: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G1610, 2x 2GB Corsair DDR3, Zotac GT630 1GB, TT S2-1600, Ocz Vertex 2 50 GB, 92 Kanal Seduatmo, Harmony 665, atric USB
    CKthree: yavdr-ansible/22.04 LTS/2.6.1/kodi19.3 auf Intel NUC, Celeron J4005, UHD Graphics 600, 4GB Crucial DDR4, Ocz Vertex2 50 GB, Harmony 350

    PowerEdge: Ubuntu Server 16.04 LTS / VDR 2.4.1 auf Dell PowerEdge T20, Xeon E3-1225 v3, 16GB ECC DDR3, 2x Cine S2 V6 mit Duoflex, Samsung 840 EVO 120GB, 3x WD White WD80EZAZ 8TB in SW Raid5




    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

    durchflieger,
    jetzt wird das langsam klarer. Du hast natürlich Recht, die Ecksektionen waren noch drin. Jetzt aber:

    Code
    dfatmo.driver_param = /dev/ttyUSB0&speed:500000&proto:x5A|xA2|Rb33|Gb33|Bb33|-32|Rl21|Gl21|Bl21|-20|Rt1|Gt1|Bt1|+32|Rr1|Gr1|Br1|+20|xA5


    Damit passen die LEDs auch genau zum Bild. (Hatte durch die Ecksektionen eine Verschiebung um 1-2 Pixel)
    Flackern ist auch weg (filter_threshold), toll.

    Zitat

    Überlappung der Pixel wird über die Anzahl Sektionen und deren Zuordnung im "proto" konfiguriert.


    Das habe ich noch nicht ganz verstanden. Ich habe z.B. im Top 33 Pix. Ich muß doch dann auch in den driver_param 33 Pixel einstellen, oder? Wie bekomme ich dort die max. "Schärfe" hin. Das sieht bei mir etwas verwaschen aus.
    Zu DF10CH komme ich erst nächste Woche.


    Grüße

    MLD 4.0.1-64: softhddevice, skinnopacity, tvscraper ,...
    HTPC-Hardware: C847MS-E33+Celeron 847,Geforce GT610,4GB Ram,Cine S2 V6.5,WD15EADS 1,5TB,be quiet! Pure Power L7 300W,Lian Li PC-c37b,seduatmo + SEDU Controller SW 3.0 + T+B je33 Pix,L+R je 21 Pix mit WS2801, 7" Touch TFT,TV:LG42LH9000, AV: Onkyo TX-NR717+RC-836M mit Atric IR-WAKEUP USB eco[br][br]MLD 3.0:,div. Plugins,LIRC,LG-Brenner, Hauppauge Nexus2.1 m. RGB Out (handgebondet), Hauppauge WinTV NOVA SE2, K7S41, AMD GEODE 1750, 512 MB,300GB HDD, GLCD 240x128,SST-LC13,outsourced to my mother


    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

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden