Beiträge von René Arts

Good to hear that, I am using my TVs Scart output which goes directly to the framegrabber so that should be fine (UTV I guess... experimented with both UTV and STK). The calibration will be quite OK I guess, otherwise I'll need to find a compromise. I will give it a try sometime soon!
Manually switching it with a remote is no option, the switching really needs to be automatic for me to survive the WAF requirements

Just a quick question; as far as I understand it is possible to use both the internal and an external grabber (off course not simultaneously)? Does hyperion switch automatically between the two sources when switching? That should be possible when the priorities are set in the right order I presume?
I am currently still using an old installation (Bismarcks OpenELEC mit automatisierter Ambilight Quellenumschaltung), it restarts hyperion with a different configuration file on switching the TV input which is signaled via CEC. I would like to upgrade my installation and probably switch to LibreElec, but I want to be sure it can still switch automatically.

Het zal ook vooral een beetje afhankelijk zijn van de kabel denk ik. Wat je zou kunnen doen is de beoogde USB kabel nemen, in de connector doen en de weerstand meten tussen de pinnen van de connector en het andere eind van de kabel. Als die voldoende laag is zou je het kunnen proberen. Persoonlijk zou ik vooral voor de voeding voor een dikkere kabel gaan. Er loopt al snel 5-10A, dat is vrij fors

De USB standaard schrijft voor de connector maximaal 0.5A (USB 2.0) of 0.9A (3.0) voor. Persoonlijk zou ik het niet doen en kiezen voor een beter geschikte connector. De kabels zijn een geval apart, daar zitten erg grote verschillen tussen. Maar vanuit het oogpunt dat de connector al een limiet vormt zou ik ook andere kabels nemen.
Voor de data/clock zal het geen probleem zijn, maar voor de voeding wil ik het je ten zeerste afraden.

Zover ik weet is er momenteel geen automatische functie om dit te kunnen doen. Je kunt echter wel via de handmatige calibratie hier voor corrigeren. Ik heb geloof ik wel eens een wat foto's of een artikel gelezen om dit te doen, maar kan me zo 123 niet herinneren waar/welke.

edit: na even zoeken toch een wellicht bruikbaar linkje gevonden: http://hacks.esar.org.uk/hdmi-light-v2/

Ah yes, I do agree with your approach. Would be a nice feature indeed. Perhaps it is possible to do a dry run; just process some images on a pc with the resulting color as output, just to verify and tune the algorithm and the parameters?
The test can be enhanced by sending the resulting color (manually) to a running hyperion instance.

Just for some clarification; you are currently trying to mimic the Hue camera functionality, with all leds displaying the same color derived from the entire screen?

The original article is about finding the best matching color over an entire picture. Maybe it does not suit as well as we think/hope with only partial images? Or maybe noise can get too dominant when only using a few pixels (compared to the entire picture) are used?

Wow, that's awesome! Let's just say great minds think alike
The clock script would be great to have in python... my Perl isn't that good, ha.
Don't know if it's another coincidence; but the Penfold's wines are marvellous!

I already posted it in the "Which LED device is the best" thread, but this link might yield some inspiraton here as well: https://cpldcpu.wordpress.com/…understanding-the-ws2812/

It might be nice to have an ESP in between instead of an arduino. It can do almost the same, but faster. Added benefit might be that the ESP can be kept online while the RasPi running Hyperion can be powered down. It is then possible to let the ESP run some effects, i.e. projecting some time features like Light Clock (they also have a moon phase display) or home automation status stuff (current power usage/notifications).

Just thinking of the Light Clock... I guess that should be possible with a hyperion effect as well?

500 MHz would be... erhm, fast... way faster than remotely possible with an Arduino (or ESP) I'd guess you are meaning a 500 kbps SPI communication rate?
As the ESP runs a bit faster than an Arduino (80/160MHz vs 16Mhz) it might be possible to be a bit faster. Do remind however that the ESP cannot guarantee realtime requirements; it needs some time now and then to do its wifi housekeeping tasks.

I just saw a real nice article at Hackaday.com discussing a method and implementation for determining the perceived dominant color in an image. In a quick search I could not clearly find what algorithm/logic Hyperion is currently using to determine the output color(s); though it does a great job. Not necessarily a meant as an improvement, but this article might bring some inspiration for future development.
When someone can point me to the code/algorithm used by Hyperion; I'd love to get to know more about it --> someday I will probably build a FPGA based setup (I'm a FPGA/VHDL developer by daylight).

edit: just found some extra info in the linked articles about the Hue camera app

Vandaar inderdaad dat ik wil gaan experimenteren met de ESP8266: goedkoper en sneller dan een Arduino, makkelijk te programmeren (oa. FastLED library voor WS2812) en vooral: wifi!
Wil ook zeker eens gaan klooien met de recent ontwikkelde mogelijkheden om de hyperion output over UDP uit te sturen naar bijvoorbeeld een ESP met ledstrip.

Het grootste euvel met de WS2811 gebaseerde systemen is de timing van het doorsturen van de data: zowel de klokinformatie als de data moeten in 1 signaal verpakt worden. Omdat een ESP of Arduino veel makkelijker low-level te programmeren is, is het makkelijker om dit goed voor elkaar te krijgen dan op een RasPi omdat je geen rekening hoeft te houden met een OS wat tegelijkertijd ook draait. Het kan wel, bijvoorbeeld via de eerder genoemde PWM methode, maar dat is net wat lastiger dan via een Arduino.
De APA102 heeft net zoals de WS2801 het voordeel van een gescheiden klok- en datasignaal. Dat maakt een veel groter bereik van de klokfrequentie mogelijk en vooral de timing komt wat minder spits: mocht er even iets tussendoor komen op de RasPi dan is de klokflank wat later, maar dat is geen probleem. Bij een WS2812 kan het signaal dan al verkeer geinterpreteerd zijn (want een 0 of een 1 is gecodeerd als een puls met bepaalde tijdsduur).
Ik heb zelf vorige week een paar meter SK6812 RGBW strip besteld om een mee te gaan spelen icm de ESP8266. Denk in eerste instantie niet voor Ambilight, maar ben benieuwd hoe het presteert. Ze gaan waarschijnlijk toegepast worden als keukenverlichting en buiten in de tuin (vandaar dat ik de combinatie met warmwit interessant vind).

Kwam het toevallig straks tegen toen ik op de rest van het forum aan het rondneuzen was. Hoe en waarom welke LED(strip) te kiezen is ook al een mooie forumpost aan gewijd: https://hyperion-project.org/t…which-led-is-the-best.35/

Twee korte filmpjes hoe het er bij mij uitziet:

Ja, opzich voldoen mijn 30led/m prima. Maarja, je wilt altijd wat meer he. Denk dat het verschil met 60/m wel wat verbetering brengt en qua voeding ook enigzins te doen is
Heb overigens in de Ambilight thread op het Tweakers forum ook even melding gemaakt van deze fijne ontwikkeling, dan weten weer wat meer mensen de weg hierheen te vinden. Hoe meer zielen (en/of LEDs) hoe meer vreugd

Erg gaaf om te zien dat hyperion weer even een tikkeltje professioneler gaat! Ik ben al ruim 1.5 jaar een bijzonder tevreden gebruiker van dit mooie stuk software.
Mijn setup: RasPi model 2B met USB UTV007 framegrabber die beeld krijgt vanaf mijn Panasonic TV. Op de RasPi draait nu nog OpenElec maar zal binnen afzienbare tijd vervangen gaan worden door LibreElec --> een goede hyperionsupport is voor mij belangrijk, dus kijk nog heel even aan tot dat echt goed werkt
Ik gebruik een WS2801 ledstip met 96 leds (30 leds/meter) die in de toekomst wellicht nog vervangen gaan worden voor WS2812b of SK6812 met 60 of misschien wel 144 leds/meter.