Posts by jochenf

    Hi,


    @esprit1711


    Dann hast du ja fast den selben Deal geschossen, wie ich damals bei meinem eBay Vertex. Hatte diesen auch mit defekter Beleuchtung und Info Button für 85€ gekauft.


    Die "defekte" Beleuchtung ließ sich mit einem Mausklick in den erweiterten Einstellungen "reparieren". Den Info Knopf habe ich eigentlich nie vermisst. Wenn der Vertex eine Signaländerung feststellt, geht ja das Display kurz an. Bedienen lässt sich das Gerät eh viel komfortabler über den PC.


    @sophie


    Nee, HDR Tonemapping geht auch mit dem Vertex und Integral 2 leider nicht. Der Integral2 ist quasi 1:1 ein Vertex, nur halt ohne Display. Die Signalinfos werden aber zusätzlich eh per OSD angezeigt.


    Grüße


    Micha

    Moin,


    ist eigentlich egal ob du Original oder Clone nimmst. Wenn du in Arduino IDE die Boardverwalter URL hinzugefügt hast, stehen dann jeweils über 20 Modelle zur Auswahl. Meines Wissens gibt es da nur Unterschiede bei der GPIO Belegung und im Hardwarelayout. Ich hatte einfach die billigste Version genommen, bei der die GPIO Pins bereits verlötet sind. Die verwendeten GPIO Pins sind dann in der .ino definiert.
    Aktuell würde ich aber den ESP8266 vorziehen, auf dem ESP32 lief der Sketch bei mir nicht ganz rund. Das Projekt wurde auf dem 8266 gestartet und erst vor kurzem auf dem ESP32 adaptiert.
    Das Gute an der Geschichte, der ESP verhält sich an der seriellen Schnittstelle wie ein Adalight, deine LED's sollten also per Kabel erstmal ganz normal funktionieren. Kannst dann in Ruhe auf udp umstellen.


    Auf der Wiki Seite sind 2 recht gute Videos verlinkt.


    Die ersten ESP's hatte ich bei azdelivery über Amazon gekauft, die weiteren dann bei Aliexpress oder Ebay zu 2-4€ das Stück.


    https://www.amazon.de/s?k=azde…95%C3%91&ref=nb_sb_noss_2


    Grüße


    Micha

    Hi,


    1. der ESP muß nur die Anzahl wissen, WLED kann auch dutzende eigene Effekte, Hyperion musst du trotzdem die LED Zone einstellen
    2. ist WLED egal
    3. nee, definierst du im Webinterface, nur die GPIO's in der .ino


    ESP8266 80MHZ -> 5x Uno
    ESP32 2x240MHz -> 40x Uno
    + mehr RAM und mehr Flash


    Nun ja mein System läuft ja mit arduino soweit gut.


    Deshalb ja vielleicht was für die kalten Wintertage. o_O


    Grüße


    Micha

    Hi,


    wenn du lange Weile hast und vielleicht auf paar Kabel verzichten willst, kannst du dir ja mal WLED anschauen. Läuft auf dem ESP32 und ESP8266 seriel als Adalight, nimmt aber zusaätzlich aber per UDP, HTTP, MQTT, Alexa und dergleichen Befehle entgegen. Im Webinterface lässt sich LED Anzahl, Stromstärke und der Rest komfortabel anpassen. Nee App für IOS und Android gibt es auch. Ich steuere damit 256 LED's am TV und 75 am Monitor kabellos an.


    https://github.com/Aircoookie/WLED


    Grüße


    Micha

    Hi,


    hyperion beginnt bei der 0 mit der Zählung, ist also normal, dass da eine fehlt. Stell doch einfach mal eine mehr ein und schau, ob sie dann alle leuchten. Ich persönlich würde mich wegen einer aber nicht heiß machen, sieht man von vor dem TV doch eh nicht. ;)


    Grüße


    micha

    Hi,


    ja, habe auch 2 Instanzen laufen, eine mit 74 LED's und eine mit 256 LED's beide Streifen hängen an je einem ESP8266 und werden per udp raw angesprochen. Das mit der Last bei mehreren Instanzen könnte hinkommen. Die Last von über 50% stellte sich bei mir erst ein, als beide wieder aktiv waren.
    Werde das dann noch mal checken und mit nur einer Instanz beobachten.


    Edit 13:45


    irgendwie stehe ich gerade etwas auf dem Schlauch. Hyperion zieht nunmehr nur noch 35% CPU mit 2 Instanzen, also Livebild vom PC per "Hyperion Screen Capture" an den Monitor plus USB Grabber 640x480/4 auf den TV. Die einzige Änderung die ich gestern gemacht habe, war den hyperion.service aus dem Autostart rauszunehmen und diesen nur bei Bedarf per Alexa zu starten.
    Selbst mit 1080/4 Bild komme ich jetzt nur noch auf 75% CPU Last.


    Grüße


    Micha

    Bevor ich mir wieder selbst antworte, habe ich diesen Beitrag mal lieber editiert.


    Hyperion läuft bei mir unter Raspbian, die Plattformaufnahme ist nicht aktiv.


    Zum Verständnis, um nicht 2 Sachen durcheinander zubringen.


    Bei meinen Tests weiter oben habe ich noch nicht gewusst, dass der Raspi auch ohne angeschlossen Graber bei "top" schon bei über 90% Auslastung liegt. Bei meinen Experimente mit dem neuen Grabber und Bildverkleinerungsfaktor von 16 komme ich dann auf ca. 98% CPU Last. Mir war also noch nicht bewusst, dass der Grabber eigentlich nur 8% Last zieht.


    GnaGetier empfahl mir bezüglich der weiter oben angesprochenen Probleme, mal den Git von Sputnik zu testen, welcher die Grabber Auflösung auf 1280x720 setzt.


    Ich habe den Git von Sputnik daher mal für den raspi und die vero neu kompiliert. Doch auch dieser lastet den raspi 4 schon zu 90% aus, obwohl noch gar kein USB Grabber angeschlossen ist. Die Last mit Grabber liegt wieder bei über 95%. Im Vergleich zu meiner hyperion Version kann ich nun mit dem Bildverkleinerungsfaktor jedoch auf 4 runtergehen, die 1280x720 bringen also grob 3%.


    Auf der Vero 4k zeigt sich das selbe Bild, hyperion liegt ohne USB Grabber schon bei über 90% CPU Last. Als Ursache der hohen CPU Last habe ich meine Hyperion Config ausgemacht. Starte ich mit einer leeren, liegt die Last im Leerlauf auf beiden Systemen bei um die 10%.


    ---------------------------------------------------------------------------


    Nach Bereinigung meiner Config habe ich nun im Idle (Raspbian, nur Hyperion) ca. 50% CPU Last. Nehme ich die Version von Sputnik und Stelle 640x480 als Auflösung und Verkleinerung 4 ein, liege ich bei rund 65% Last. Damit kann ich sehr gut leben. Nach meinen Beobachtungen liegt die generell recht hohe CPU Last bei mir eventuell an der LED Ansteuerung per udpraw.


    Bezüglich HDR haben sich folgende Anpassungen als ideal erwiesen.


    v4l2-ctl --set-ctrl saturation=255
    v4l2-ctl --set-ctrl contrast=220
    v4l2-ctl --set-ctrl hue=16


    Als Resümee des Ganzen würde ich sagen, dass ich bei halben Preis gegenüber dem Y&H sehr zufrieden bin und das Setup bis zum Erscheinen einer all in one Lösung mit HDMI Input so fahren werde.


    Grüße
    Micha

    Cool,


    Danke, schaue ich mir gleich mal an.


    Was ich gerade bemerkt habe, dass Hyperion auf dem 4er Raspi auch 90% CPU Last zieht, obwohl der Grabber momentan garnicht dran hängt. Bin außerdem gerade dabei, den Graber mal an meiner Vero4k zu testen, mal schauen was dabei rauskommt.


    Danke


    Micha

    Hi,


    folgend ein kleiner Erfahrungsbericht und ein Hilfegesuch bezüglich meines neuen Grabbers.


    Der Grabber wird von v4l2 korrekt erkannt und von hyperion.ng unterstützt. Als Pixelformat wird leider nur YUYV untertützt. Auf Grund der entstehenden Datenmenge habe ich auf dem 4er Raspi jedoch eine CPU Auslastung von etwa 300%. Trotz dessen beträgt die geschätzte Latenz nur etwa 100ms. Stelle ich den Bildverkleinerungsfaktor auf 16, sinkt die Auslastung auf 95%. Bei der Latenz habe ich keinen Unterschied bemerkt. Abgesehen von der zu hohen CPU Last wäre ich mit dem Ergebnis eigentlich zu frieden. Bezüglich blassen HDR Farben bekomme ich mit "v4l2-ctl --set-ctrl saturation=255" ein wunderschön buntes Bild ohne Farbverfälschung die mir mein analoger Grabber produziert hat.



    Nun zu meinen Hilfegesuch. ;) Wie esprit1711 ja schon geschrieben hat, ignoriert hyperion die per "--set-fmt-video" gesetzte Auflösung leider. Es wird von hyperion also ein Bild mit maximaler Auflösung gegrabbt. Welches bei meinen Graber, der ja leider kein mjpeg kann, sicherlich um die 4MB ist. Die hohe CPU Last rührt vermutlich daher. Die nachträgliche Bildverkleinerung in hyperion bringt daher nur eine geringe Performance Verbesserung.
    Mein Wunsch die Grabber Auflösung schon vor der Eigentlichen Bildverarbeitung durch hyperion zu reduzieren, scheitert leider an meinen nicht vorhanden Programmierskills. An der Anpassung, der Auflösung in der "hyperion-v4l2.cpp" hänge ich gerade fest.


    Ergänzung 26.01 14:00:


    Um den weiteren Threat nicht durcheinanderzubringen mal ne kleine Ergänzung. Der Grabber läuft aktuell einwandfrei. CPU Last bei 1280x720/4 etwas 60%. Delay geschätzt bei 100-200ms zur Live Vorschau in Hyperion.Von mir also :thumbsup: für das Gerät und :geek: für die gesparten 50€ gegenüber dem Y&H.


    Grüße und vielen Dank


    Micha

    Hi,


    kleines Update von mir. Der Grabber ist heute angekommen und leider durch sämtliche Tests gnadenlos durchgerasselt. ;(


    Das Gerät wird weder von Debian, Raspbian noch OSMC korrekt erkannt. Ein Video0 Device ist nicht existent. Unter W10 wird die Box als USB Display erkannt. Also falsche Amazon Artikelbeschreibung und daher was für den Sondermüll.


    Gut dann wirds also der Y&H. Leider musste ich mit Entsetzen feststellen, dass dieser aktuell nicht über Amazon direkt lieferbar ist und aus China verschickt wird. Es musste also kurzfristig ne Alternative her. Also, getreu der Devise "wer billig kauft, kauft 2x" und dem Motto "Versuch macht klug" werde ich folgender Box mal eine Chance geben.


    https://www.amazon.de/gp/produ…tle_o00_s00?ie=UTF8&psc=1


    Grüße


    Micha

    Hi,


    sollte jemand mal über selbiges Problem stolpern, folgend das Resüme der Aktion, mit der ich Paulchen vermutlich den Samstag Abend versaut habe. :confused:


    Auf der Vero4k unter OSMC vor dem cmake folgende Anpassung in der Datei CMakeCache.txt im build Ordner haben zum Erfolg geführt.


    //Flags used by the compiler during all build types.
    CMAKE_CXX_FLAGS:STRING=-I/opt/vero3/include -L/opt/vero3/lib -O3 -march=armv8-a+crc -mtune=cortex-a53 -mfpu=neon-fp-armv8 -mfloat-abi=hard -ftree-vectorize -funsafe-math-optimizations



    //Flags used by the compiler during all build types.
    CMAKE_C_FLAGS:STRING=-I/opt/vero3/include -L/opt/vero3/lib -O3 -march=armv8-a+crc -mtune=cortex-a53 -mfpu=neon-fp-armv8 -mfloat-abi=hard -ftree-vectorize -funsafe-math-optimizations


    Grüße und vielen Dank an Paulchen:thumbsup:


    Micha

    Hi,


    irgendwie ist da anscheinend doch der Wurm drin. ;(


    Das kompilieren des aktuellen git läuft nun zwar fehlerfrei durch, beim Start erhalte ich jedoch "segmentation fault". Kompiliere ich ohne "-DENABLE_AMLOGIC=ON" geht zwar der Amlogic Grabber nicht, hyperion.ng startet dann aber ohne Fehler.
    Wenn ich den Master Branch vom 08.12.2019 kompiliere, funktieren hyperion.ng fehlerfrei! Irgendwas an den letzten 5 Änderungen, die seit dem eingeflossen sind, verträgt sich wohl nicht mit der Vero4k unter OSMC.


    Irgend was ab dem commit "Add RS232 timeout for asynchronous connection (#650)" müsste es dann wohl sein.



    Grüße


    Micha


    ps. Ich kann mit der Dezember Version leben, wegen mir also keine Anstrengungen. ;)