Posts by Doc.Ex

The Pi and the LED strip need to have the same ground because it uses voltage levels as a data carrier. A TTL signal has 0V (low level) and 5V (high level) (or 3.3V). Voltage is defined as the difference between two potentials. So 0V is basically ground potential and 5V is a higher potential. When the Pi and the strip have a connected ground, they share their base potential so they interpret the high level the same way. But if you don't connect the ground, the strip could have a ground that is on a higher base potential than the ground of the Pi. So when the Pi sends a 5V signal to the strip, that potential could be only 2V in relation to the ground of the strip. That would result in a lose of data because the controller on the strip would consider it as low level. Hope that was somewhat understandable. Anyway, either connect the grounds directly, or use the same power supply for both the pi and the leds.

6 inches is a pretty big distance. I would not recommend to have the stripes 90° to the wall. You would rather illuminate the whole room than just the wall. Those Leds do not have optics so they have a beam angle of about 120°. For 6 inches and 90° to the wall, this means that (in theory) you would have a darker ring of about 3,4 inches thickness around your tv. I would recommend a 30-45° angle. Sometimes you don't even need to cut and solder for those corners. I have seen videos where people were just looping the stripes or folding them for corners.

The RPi controls the leds and runs hyperion, but you can let the pc grab the image digitally with the windows x11 grabber. It'll grab the image and send it via network to hyperion on the pi.

Regarding the direction of the leds, it depends on the distance of your tv/monitor to the wall. If it's really close to the wall, definitely 90° angle. The larger the distance the more it has to face the wall. Ideal in most cases is a 45° angle.

Hi everyone, we have a great tutorial for colour calibration but I somehow don't get it perfect. I thought it would be nice to have a thread to discuss and gather tips for reaching the perfect colours. So feel free to add your expertise below.

Common issues I experienced so far:
- green cast on yellow
- dark grey reproduced as green
- dark brown reproduced as red

My understanding of the settings:

Whitelevel: Maximum brightness of the colour
Gamma: Brightness curve of the colour (outputColour = inputColour^Gamma)
Pure colour settings: Additional colour mixed into pure colour in order to reproduce TV image
Threshold: Data below set value will be lost
Temperature: ? (Is there a difference to whitelevels?)
Saturation: Amount of general colour (low settings will mix the other two colours into the output to reduce saturation, right?)
Brightness/Luminance: Amount of white (increases or decreases the output values of all colours at the same time)

Now to my problem:
I used the wiki etc. but there is an issue that I can't fix and maybe it's my perfectionism
I got my white levels fine. Green and especially Blue are way to bright so I reduce them significantly. White is alright then. I use the grey scale pictures to calibrate the gamma values. So I get a nice grey. Now comes the problem. If I am around a gamma of 2.5 or higher, dark colours are fine. Even a dark brown is somewhat possible. Problem is that midtones are way to saturated. If I reduce the saturation I lose most of the colour in bright colours and a decent amount in pure colours.
So another option is to reduce gamma to around 2. That way midtones become brighter and therefore less saturated. But then dark colours become way to saturated and intense. For example a subtle dark brown becomes a very saturated red. Another effect is that the Leds light up on black which shouldn't happen. Of course a threshold solves this but then you lose colour nuances. (Example: threshold=0,2=51; 200/50/0 will be 200/0/0)

I don't really know how to fix this. Also how does the temperature effect the colours? Whitelevel is the maximum brightness of the colour. But what does temperature do?

Lets gather some input. I am sure some of you encountered this. Maybe we can also think of ways on how to improve the colour processing algorithms. I think that the more people understand how hyperion processes the colour, the more ideas will come on how to improve it. One way that was discussed is to reduce saturation for dark colours. But maybe you have got more ideas.

Cheers.
doc.ex

Und hast du schon neue Ergebnisse? Muss den anderen allerdings zustimmen, dass das nicht viel mit dem Ambilux von Philips zutun hat. Dabei werden Microprojektoren eingesetzt, die ein richtiges Bild an die Wand werfen statt nur einer Farbe. Was dein Aufbau allerdings auszeichnen könnte wäre eine besonders homogene Lichtverteilung. Eine hohe Auflösung wird aber wahrscheinlich nur möglich sein wenn die Leds nahe des Bildschirmrandes angeordnet werden da sich die Farben ja sonst vorher schon mischen.. Das ist eben der Kompromiss den man machen muss. Hohe Auflösung <---> Homogene Verteilung

Nutzt du einfach nur eine Blende aus Karton um den Abstrahlwinkel der Leds zu begrenzen?

unfortunately not. I am thinking about buying new ones, and wanted to get the apa102 but then I read that u guys implemented the rgbw stripes. Now I wait on reviews, since they are a bit more expensive

Yeah brown contains a lot of red, but there is a small percentage of green which makes it brown instead of red. I know that there might be limitations regarding thresholds of the leds. This is getting very technical now. For example the diode only lights up when there is a voltage above 0,7V. Brown contains a lot of red, so the red led fires up. But the amount of green is so little that it is a brightness that would require the green led to fire up at, for example, 0,5V. But it can't since its technical limitation requires 0,7V. So the result is, only red fires up and therefore it doesn't show brown, it shows red. That is probably the reason why brighter colours are no problem to configure. You can reproduce that behaviour for brighter colours using the software colour thresholds. Maybe it is especially bad for my setup since the lpd8806 only supports 7bit pwm instead of 8bit like the apa102.
Anyway, one idea I have had was, what if we reduce the saturation gradually for darker colours? Bright colours wouldnt be affected. Sure it'll wash out dark colours, but personally I would rather have a washed out brownish grey that is not distracting than a flashy full color red.

Edit: I just got an idea how to figure out the thresholds. Maybe it makes sense when test all colours for their thresholds. So increasing brightness step by step from 0 until the led fires up. The value when it fires up is set to threshold. Now when we have mixed colours, the threshold is the minimum luminance for that colour (only for mixed colours).
Example:
Thresholds are RGB: (006/009/007)
Now we have a Brown (150/025/000) -> Everything is fine.
But a darker brown (050/006/000) -> would turn out red.
Solution: darker brown becomes (050/009/000) -> green fires up. result is a brown. maybe not 100% accurate but better than red

I like that idea, since it does not require additional hardware and therefor reaches a broad userbase. Another thing, and maybe we should discuss this further in an additional thread is: Yesterday I played around with the backlight and luminance parameters and noticed that the luminance influences also the saturation. For me it is very hard to configure the colours in dark scenes. I get the grey about right using the wiki, but when there is a dark brown it turns completely red for example. Lower gamma values solve that but since last update I have a backlight effect with gamma values below about 2,2. Also smoothing seems to influence the dark colours, depending on the colour that was displayed before. I guess we should somehow fix this before there are automatic brightness adjustments, in order to avoid complaints. I hope you get what I mean. Does somebody have the same problem and should we discuss the behaviour in a new thread?

Figured it out. Somehow the smoothing time needs to be a rather high number. Thought I could set it to 0 because the transition time that is specific to the hues is gonna smoothe it out anyway, but now that I set the smoothing time to 200ms it works.

Well I have more
But currently I am using only one with hyperion, so yes.

Intel i5 6600K
Nvidia GTX 970

Maybe not the latest graphics drivers, need to check that. But maximum 2 months old.

Tried it today, but it doesn't work for me. It says "Failed to take Screenshot".
Windows 10 x64.

I have 2 monitors connected, but only one monitor is activated so I assume that is monitor 0 then.
Also, I checked if all dependencies are installed and yes they are.

Is it supposed to work on Windows 10? Didn't try any games or anything, just the desktop.

Do you use OpenELEC?
If yes try the following:

[INDENT] "grabber-v4l2" :
{
"device" : "/dev/video0",
"input" : 0,
"standard" : "PAL",
"width" : 240,
"height" : 192,
"frameDecimation" : 2,
"sizeDecimation" : 1,
[INDENT](...)[/INDENT][/INDENT]
OpenElec supports framescaling for the stk1160 grabber, so you can directly tell the driver of the grabber which resolution it should grab.

Also check if there is enough power for the grabber. Mine doesn't work when connected directly to the Pi. It needs to be connected to a powered usb hub that is then connected to the pi.

Hi,

meanwhile I tried my luck with the latest version of Hyperion and the integration of my Philips Hue lights.
To provide the config of my Hue lights with colour input, I use the forwarder function in my main config for the LED strip behind the TV. That works very well.
But, since you can't limit the frame rate that is being forwarded, I enabled smoothing on the Hue config, set its time to 0ms and the update frequency to 5 Hz. So in theory, every 200ms there should be a new colour sent to the hue lights.
But that somehow doesn't happen.
The hue bulb turns on with the appropriate colour, stays on for about 1-2 seconds and the turns off. After a while it turns on again, adjusts to the right colour and turns back off. That behaviour repeats.

It isn't the forwarders fault since it also happens when I use v412. So the problem is definitely the smoothing.
No smoothing and v412 with framedecimation works perfectly, but you can't assign two configs to one grabber.

Does this have something to do with the flooding patch for the smoothing, that was implemented recently?
My only problem is that I need to limit the requests sent to the hue bridge, and the updatefrequency of the smoothing option doesn't work in its current state.

Cheers,
doc.ex

Quote from Pieface

As mad as it sounds, I have to set my Grabber config to PAL, but the HDMI2AV to NTSC.

It's the only way it works properly for me. Maybe try that?

That is because some of the converters are labeled wrong. I have one that was behaving the same way. When I opened it, the labels on the pcb were switched to the labels on the housing.

@qwebnm: what is the chipset of your usb grabber? usbtv007 (Fushicai) or stk1160?

Ah okay, yeah I figured it is not linear. Regarding the different variants, for ambilight purposes a rgbw stripe with neutral white (around 4000K) should always be used. Otherwise you would have to mix blue or red and green into it, which makes everything a lot more complicated. But yeah, I guess that people will buy ones with with warm white etc so maybe just consider them when implementing the support for rgbw.

Nice, I am excited. How is the support implemented? Are the white leds only used for full white input or do they mix with the rgb colours to produce lighter colours?

Quote from Brindosch

2. You want to control the lightstrip with a "Philips hue" comaptible remote/app instead to set a color wit the hyperion app. Right?

Exactly, since the new Hue app supports Homekit, Hue lights can be controlled via Siri. If the Hue bridge could control the Led strip, you could integrate it into scenes, etc without the need of additional 3rd party home automation solutions or a bazillion different apps. Would be a lot more convenient in my opinion. However, you would only be able to set single solid colours because Hue doesn't have addressable light strips but, anyway. Better then having to use different apps which often results in just leaving it off because of lazyness.

• Maybe not a common use case, but the ability to change the brightness of the leds for different light situations of the room. Most modern tvs change their brightness in relation to the surroundings. If we could integrate a light sensor or get the info from somewhere else, hyperion could do that as well. Simpler solution would be to control the brightness via a remote control, though.
• I dont know if possible at all, but to be able to control the lightstrip via the philips hue ecosystem. As if the lightstrip would be a hue product. Other way round is possible right now, but I think to be able to integrate the existing lightstrip behind the tv into the hue lights ecosystem would make a lot of sense in regard to using existing resources.

Problem solved. The issue was the power supply of the hdmi splitter. Somehow it caused flickering of the Leds.