Posts by cpresser

    Disclaimer: Ich bin derjenige der das KarateLight entwickelt hat. Ich versuche die Aussagen hier technisch und neutral zu machen!


    Quote

    Original von Simon69
    Ich habe gelesen, dass Sedu, da es WS2801 verwendet, nur 8bit Farbtiefe unterstützt, ist das ein zu vernachlässigbarer Nachteil oder merkt man die gegenüber dem KarateLight fehlenden 4bit deutlich an der Farbtreue?

    An dieser Stelle ist das KarateLight den WS2801-Lösungen überlegen.
    Die Farbauflösung macht vor allem dann einen Unterschied wenn die LEDs eher dunkel sind. Dann fehlt aufgund der Gamma-Korrektur schon deutlich Farbauflösung.
    Sehr gut sehen kann man das wenn man im niedrigen Helligkeitsbereich die Farben auf- und abdimmt.


    Sobald du über 50% der max-helligkeit bist fällt das aber nicht mehr ins Gewicht.


    Hier mal die Gamma-Tabelle die in der KarateLight-Firmware drin ist:


    Zum Vergleich eine 8-Bit Gamma-Tabelle:

    Da sind in den ersten 2 Zeilen (=12.5% vom Dynamikumfang) nur 4 verschiedene Werte drin.
    Beim 12-Bit KarateLight sind es immerhin 0x3D, also 61 verschiedene Abstufungen.



    Quote

    Spielt die höhere Auflösung bei Sedu eine große Rolle, mein Fernseher hat 60", steht jedoch auf einem Schrank relativ weit weg von der Wand. Ich kann mich nicht entscheiden zwischen KarateLight und SeduLight.


    Mit den WS2801-LED-Streifen ist die Auflösung um eine Größenordnung besser als mit dem KarateLight.
    Üblicherweise sind bei einem KarateLight-16-Setup die LED-Streifen circa 20cm lang. Mit digitalen WS2801-LED-Streifen (Raster 1/8") schafft man auf der Länge 6-7 mal mehr Kanäle unterzubringen. Bei Verwendung von WS2812-LED-Streifen (1/16" Raster) nimmt kommt nochmal der Faktor zwei dazu.
    Bei einem Setup bei dem der TV weit weg vom Reflektor (Wand) steht macht sich der Vorteil durch die Farbmischung (üblicherweise 120°) Abstrahlwinkel wieder zunichte. Wenn der TV aber eher nah an der Wand ist (<10cm Anstand Wand zu LEDs) ist der unterschied in der spatialen Auflösung schon deutlich.


    Ich hoffe damit die beiden großen Unterschiede hinreichend erläutert zu haben.
    Welche der beiden Lösungen nun besser ist kommt also vor allem auf die Anforderungen an die man daran stellt :)

    Quote

    Original von scirocco3
    Ja, das hat mich ja auch schon gewundert, aber auch, wenn ich 'karate-drivertest /dev/ttyACM0' eingebe. Dabei müsste er ja alle Kanäle durchlaufen lassen, findet er nichts.


    Gibt es ne möglichkeit, diese Schnittstelle manuell hinzuzufügen?


    Überprüfe mal bitte manuell die Modul-Konfiguration.
    Möglich das das ftdi-modul da probleme macht, das beansprucht teilweise auch die Hardware für sich.


    Bitte folgendes probieren:

    Code
    rmmod cdc-acm
    rmmod ftdi_sio
    modprobe cdc-acm
    dmesg | tail
    ls /dev/ttyA*
    Quote

    Original von cpresser
    Als ersten Schritt werde ich nun ab sofort bei 'stable' die Version 0x27 ausliefern.
    In circa zwei Wochen werde ich dann auch 'experimental' umstellen. Vorläufig werde ich dort dann wohl einen Hinweis platzieren das sich da was geändert hat. Mittelfristig wird dort dann aber auch Software auftauchen die wirklich experimentell ist :)


    Auch wenns jetzt schon mehr als zwei Wochen sind habe ich die Ankündigung mal umgesesetzt.
    Wer nun also versucht eine "Experimental-Firmware" aufzuspielen wird eine Fehlermeldung bekommen.

    Quote

    Original von ada0607
    ich möchte gerne updaten mein karatelight aber "update_firmware.sh" funzt nicht
    ich habe keine "/usr/share/doc/karate-tools/" Verzeichnens

    Weil die tools nicht installiert sind.

    Quote

    karate-tools_20120530_mipsel.ipk geht auch nicht weil steht dass das nicht kompatibel ist (OE2).

    Du kannst das Paket manuell entpacken und dann installieren.
    Oder auch deine opkg.conf ändern und dort mipsel als architecture hinzufügen (Siehe auch hier: opkg Archtecture Frage)
    Evtl. gibt es auch bei opkg eine force-option um das paket trotzdem zu installieren.


    Leider hatte ich immernoch keine Zeit nochmal ein Build-System aufzusetzen um dort ein mips32-paket zu compilieren, daher muss noch gebastelt werden.

    Hallo,


    an dieser Stelle mal eine Ankündigung.
    Und zwar geht es um die Firmware-updates. Die aktuelle Version 0x27 gibt es ja schon länger automatisch zum Download. Dafür muss man aber als Release 'experimental' angeben. Das entspricht ja nicht mehr ganz der Natur, diese Version ist nämlich stabil!
    Dementsprechend werde ich gerne die Version 0x27 ab sofort als 'stable' anbieten.
    Das macht auch den release-tag 'experimental' wieder frei, den ich in Zukunft gerne für Tests von neuen Features nutzen werde.


    Als ersten Schritt werde ich nun ab sofort bei 'stable' die Version 0x27 ausliefern.
    In circa zwei Wochen werde ich dann auch 'experimental' umstellen. Vorläufig werde ich dort dann wohl einen Hinweis platzieren das sich da was geändert hat. Mittelfristig wird dort dann aber auch Software auftauchen die wirklich experimentell ist :)


    Ziel der Sache soll sein das man als normaler Nutzer einfach immer 'stable' nehmen kann und gut.


    Wer also seine Firmware aktualisieren möchte sollte nun folgenden Aufruf verwenden:

    Code
    update_firmware.sh stable


    vg. Carsten



    p.s. da mit Sicherheit Fragen kommen was die (wirklich) experimentelle Firmware denn kann: Die bekommt einen Test-Modus welcher hautpsächlich für mich gedacht ist um die Geräte nach der Produktion zu testen. Des weiteren werde ich das Protokoll erweitern damit man damit auch mehr als 20 Kanäle ansprechen kann (für zukünftige Weiterentwicklung). Ich denke auch darüber nach die Status-LEDs zu ändern, da gab es teilweise Verwirrung weil wenn nach dem Anstecken vom Strom garnix blinkt (die rote LED wird ja erst aktiv wenn die USB-Verbindung okay ist).

    Quote

    Original von jcee
    Die Teile sind per DMX verkabelt und per LAN/DMX-Gateway kann ich sie aus dem LAN/WLAN ansteuern. Dazu wird einfach ein UDP Packet mit den Farbinformationen ge-'broadcastet'


    Hallo,
    wenn das ein ArtNet-Node ist (was bei DMX quasi Standart ist) kannst du mit 'ola' daten hinsenden.
    Soweit mir bekannt kann boblight daten an ola weiterreichen, damit könntest du ohne eigene programmiertarbeit ans ziel kommen.

    Quote

    Original von Nierotter
    Ich hoffe jemand erbarmt sich kurz mir das nachlesen von 127 Seiten zu ersparen ;-)
    Also, ich möchte ein möglichst fast fertiges System haben für einen 63 Zoll Plasma.


    Viele deiner Fragen sind in meiner FAQ beantwortet:
    https://ca.rstenpresser.de/index.php/faq.html


    Die Streifen von Ebay laufen problemlos. Es müssen nur Common-Anode-Streifen mit 12Volt sein (was quasi standart ist).
    Wenn du ein wenig löten kannst ist das die günstigste lösung.


    Ansonsten beantworte ich konkrete Fragen auch gerne per Mail :)

    Quote

    Original von platte07
    Mamba schreibt im ersten Post, es müsse der ttyUSBACM eingestellt werden.
    Carsten schreibt auf seiner Homepage ind der Anleitung Software enigma2, der ttyACM0 sei der richtige Port.


    Das ist nicht wirklich ein Widerspruch.
    ttyUSBACM ist ein symlink auf ttyACM0.
    Allerdings gibt es den nur wenn udev installiert ist, was nicht auf alle Images zutrifft, daher steht bei mir ttyUSB0 :)


    Sakartvelo: du kannst die Tools mit hilfe der programme 'ar' und tar' manuell installieren. Das geht auch unter OE2.0

    Quote

    Original von Sakartvelo
    gibt es schon ein neues karatetool?


    Ich hab noch keine OE2.0 buildumgebung aufgesetzt.
    Die 'alten' tools klappen da aber auch. Binary-kompatibel sind die Images nämlich, vor allem bei den tools gibt es da keine probleme da die statisch gelinkt sind.
    Installieren klappt halt nicht, aber das kann man umgehen indem man einfach manuell mit 'ar' und 'tar' entpackt :)


    Die Quellcodes für die karate-tools sind ja aber auch öffentlich, sprich du kannst dir auch dein eigenes OE2.0-Paket bauen :)

    hi,


    das ist kein ernsthaftes Problem.
    Ich tippe drauf das du eine zu alte Firmware aufgespielt hast. Das würde erklären das Kanal8 (oder 16, je nach Zählweise) rot leuchtet.


    1. Zuerst biegst du dir wieder Telnet hin.
    2. Dann alle Stecker am Gerät abziehen und das Gehäuse öffnen.
    3. Taster 'Boot' gedrückt halten und Strom anstecken
    4. Taster loslassen, die Rote LED sollte leuchten
    5. USB anstecken, nun soltle rot-grün abwechselnd blinken
    6. Firmware runterladen "wget http://ca.rstenpresser.de/tl_f…arate_v2.experimental.hex"
    7. Firmware mit "fsusb --program karate_v2.experimental.hex" aufspielen
    8. Fertig. Strom neu verbinden, und mit karate-constant ausprobieren ob alles klappt.

    Quote

    Original von aufdersuche
    ist das normal das das Device bei OE2 ttyUSB1 heist und nicht mehr ttyACM0 oder ist das eine Eigenheit vom NN


    Das ist eine Eigenheit von Linux, das hat nichts mit dem Image zu tun:
    http://de.wikipedia.org/wiki/Ger%C3%A4tedatei


    Linux Knowledge For-The-Win


    Nummern werden aufsteigend vergeben. Wenn eine Nummer (die 0) schon vergeben oder geblockt ist, bekommt das nächste Gerät welches angesteckt wird die 1.


    Angenommen du hast drei KarateLight, und klemmst die alle an bekommen die die Nummern 0 bis 3.
    Ziehst du nun das erste Gerät (Nummer 0) ab wird die Null frei, beim neuanstecken wird auch die Null wieder neu zugewiesen.
    Nun kommt der Trick: Falls eine Software läuft, welche auf Gerät 0 zugreift, und du dann das Gerät abziehst wird die Null nicht freigegeben. Beim Neuanstecken meldet sich das Gerät dann als Nummer 4.
    Je nachdem welches Programm/Software den Zugriff macht bleiben diese 'Zombie' Gerätedateien lange stehen.



    adi800: kann es sein das ich deine Mail übersehen habe? Ich kann mich gerade nicht daran erinnern irgendwas in der Richtung supported zu haben^^

    Ich denke trotzdem das das problem hier zu suchen ist:
    Der Wert "-1" kommt aus Zeite 288 libkarate.c.
    Dort wird, falls das read() weniger als 4 Bytes ergibt der Fehler KL_ERROR (=-1) zurückgegeben.


    Ein ähnlicher Fehlerfall ist ja auch im zusammenhang der libkarate und des daemons bekannt: Teilweise klappen die Tools mit genau dem Fehler (error reading channels) nicht mehr wenn man diese startet nachdem der Daemon beendet wurde. Ursache leider weiterhin unklar. Beheben kann man das z.B. ohne die Hardware neu anzustecken mit einem rmmod "cdc-acm && modprobe cdc-acm".


    mamba0815:
    Wäre es denn viel Aufwand die ganze Kommunikation auf libkarate.c umzustellen?
    Fehlen da evtl. noch wichtige Funktionen?
    Das würde ja das öffnen-schließen sparen, zudem gibt dir die libkarate auch immer die Rückmeldung ob die Daten nun auch an der Hardware angekommen sind.

    Quote

    Original von mamba0815
    Der Daemon liest alle 30 Sekunden den LDR-Wert aus. Daher kommen die Fehlerausgaben auch vom Daemon.


    hmm.. da könnte sich ein Problem verstecken.
    Wenn der Port mit zwei Handeln geöffnet ist, woher weiss der Kernel dann an welches Filehandle er die Daten die vom KL gesendet werden schicken soll?
    Oder schließt du jedes mal wenn du den LDR-Wert lesen willst die Verbindung und öffnest die danach neu?