[App] libAmbiLight E/F/H (MST-only)

[adonis]

Anyhow, it's strange, that H_LEDS:36 V_LEDS:20 crashes the tv and H_LEDS:36 V_LEDS:18 doesn't. Might it have to be a 2:1 ratio?

I had a bug in my code which is now fixed and should work with H_LEDS:36 V_LEDS:20

My physical Setup is 70 horizontal LEDs and 38 vertical ones (on each side). I used to use
H_LEDS=36;
V_LEDS=18;
(half number and one off) and then double the leds in the app.ino because this worked without crashing. With your new version
H_LEDS=35;
V_LEDS=19;
does not crash anymore, yet it does not properly work either. It results in 4 (due to doubling, usually 2) LEDs being just white.

Using the actual number of LEDs
H_LEDS=70;
V_LEDS=38;
still crashes. That might be solved by increasing the "SLEEP" value. I have not tried that, since I prefer the lower "resolution" over slower performance.

I doubt it has to do with the SLEEP, but with the code itself. So, I grab the smallest picture possible which is 96x54px (to keep everything small and fast). I than subtract from each side (top, bottom, left, right) 9px (since some movies have black-borders which are within this range). I'm now left with a pixel range of 78x36 ... and here's the error... 36 is not enough to fit into your 38.. so therefore it crashes... Looks like you're using the more dense LED-strip which has more LEDS/meter, which at that time, I didn't know existed.

What happens if you try the following:

H_LEDS=35
V_LEDS=19

which is 108 pixels in total

and then in app.ino

NUM_LEDS 216 (double the total pixels)

int p = 0;
for (i = 0; i < NUM_LEDS; i+=2) {




r = incomingPacket[(p*3)];
g = incomingPacket[(p*3)+1];
b = incomingPacket[(p*3)+2];

new_leds.r = r;
new_leds.g = g;
new_leds.b = b;
new_leds[i+1].r = r;
new_leds[i+1].g = g;
new_leds[i+1].b = b;
p+=3;

}
fadeLeds();

this should theoretically work in the way, that two LEDS show the same color.

[aimaim]

SpoilerShow

I had a bug in my code which is now fixed and should work with H_LEDS:36 V_LEDS:20

My physical Setup is 70 horizontal LEDs and 38 vertical ones (on each side). I used to use
H_LEDS=36;
V_LEDS=18;
(half number and one off) and then double the leds in the app.ino because this worked without crashing. With your new version
H_LEDS=35;
V_LEDS=19;
does not crash anymore, yet it does not properly work either. It results in 4 (due to doubling, usually 2) LEDs being just white.

Using the actual number of LEDs
H_LEDS=70;
V_LEDS=38;
still crashes. That might be solved by increasing the "SLEEP" value. I have not tried that, since I prefer the lower "resolution" over slower performance.

I doubt it has to do with the SLEEP, but with the code itself. So, I grab the smallest picture possible which is 96x54px (to keep everything small and fast). I than subtract from each side (top, bottom, left, right) 9px (since some movies have black-borders which are within this range). I'm now left with a pixel range of 78x36 ... and here's the error... 36 is not enough to fit into your 38.. so therefore it crashes... Looks like you're using the more dense LED-strip which has more LEDS/meter, which at that time, I didn't know existed.

What happens if you try the following:

H_LEDS=35
V_LEDS=19

which is 108 pixels in total

and then in app.ino

NUM_LEDS 216 (double the total pixels)

int p = 0;
for (i = 0; i < NUM_LEDS; i+=2) {




r = incomingPacket[(p*3)];
g = incomingPacket[(p*3)+1];
b = incomingPacket[(p*3)+2];

new_leds.r = r;
new_leds.g = g;
new_leds.b = b;
new_leds[i+1].r = r;
new_leds[i+1].g = g;
new_leds[i+1].b = b;
p+=3;

}
fadeLeds();

this should theoretically work in the way, that two LEDS show the same color.

Thanks for the clarification. That explains why the "full pixel approach" won't work.
Not sure why the "H_LEDS=35 V_LEDS=19 plus doubling approach" results in four white pixels though.

I'm quite satisfied with the slightly off solution of H_LEDS=36 V_LEDS=18 plus doubling in ino.app. Thanks for the suggestion. I do the doubling by simply dividing i by 2 in the for loop:

Code: Select all

        for (i = 0; i < NUM_LEDS; i++) {
                new_leds[i].r = incomingPacket[(i/2*3)];
                new_leds[i].g = incomingPacket[(i/2*3)+1];
                new_leds[i].b = incomingPacket[(i/2*3)+2];
        }

Are you actually planning on realizing any of the ToDos from post #1 like smartphone control?

I did some research on the possibility of integrating the LED strip in my Philips Hue system, for when the TV is off. There are projects that basically simulate a Hue bridge (+ Hue bulbs) which then connects to your actual hue bridge in order to receive "light control commands", which then can be used to set the color and brightness of non Hue lights.
But I gave up pretty quickly as I lack the skills to actually get this stuff working.

[adonis]

Are you actually planning on realizing any of the ToDos from post #1 like smartphone control?

Actually, I have something already working , but this requires an additional RaspberryPi (or any other linux-computer, that is accessible from within the LAN) to work. This server kind of acts as a central-control-unit for the LEDs.

It can be found here: https://gitlab.com/ad-on-is/homelight

It's a simple server written in Go, with it's own settings file, where you can add Lights (receivers) and controll theme via app. So you can have i.e 2 LED strips, one on your tv and one somewhere else, and set it that eiter both receive the pixels from the TV, or one receives it from the TV, the other is set to a fixed rgb-value or... wait for it... animation

[aimaim]

Neat, I'm gonna try that once I have some free time, thanks!

[adonis]

Neat, I'm gonna try that once I have some free time, thanks!

Feel free to do so. Don't forget to modify 99_100_AmbiLight.init so that SERVER_IP and SERVER_PORT are the ones of the homelight-server, instead of the ESP8266

[adonis]

Hey guys,

I've just released a new version, with some fixes and black-border-detection.
@aimaim: this version should solve your problem with the four white pixels, let me know if it isn't the case.

Cheers!

[aimaim]

Hey guys,

I've just released a new version, with some fixes and black-border-detection.
@aimaim: this version should solve your problem with the four white pixels, let me know if it isn't the case.

Cheers!

It does solve the white-pixel-problem, thank you!!

Also trying the full resolution of "H_LEDS=70; V_LEDS=38;" does no longer crash the tv. Yet it doesn't work properly either. But doubling the pixels works well. So there's no real need for the "full resolution".

Thanks, I'm thrilled

Edit: The black border detection works really well for me too, *thumbsup*

[adonis]

Just out of curiosity, what'd be your expected result for 70x38, compared to what's actually happening?

The script works as follows now. It still has a max resolution of 96x54 to keep the calculations small, but it's more than enough)

So if you'd have 96x54 LEDS on each side, you'd get the "full" spectrum. (1, 2, 3, 4 ... 96) and (1,2,3,...54)
However, with H_LEDS 70 you should get skipped pixels, something like (1, 3,5,6, 8, 10, 11... 96)
And if (for whatever reason) you'd have 150 LEDS horizontally, you'd get some repeated pixels, like 1,1,2,3,4,4,5,6,6...96)

[aimaim]

Just out of curiosity, what'd be your expected result for 70x38, compared to what's actually happening?

The script works as follows now. It still has a max resolution of 96x54 to keep the calculations small, but it's more than enough)

So if you'd have 96x54 LEDS on each side, you'd get the "full" spectrum. (1, 2, 3, 4 ... 96) and (1,2,3,...54)
However, with H_LEDS 70 you should get skipped pixels, something like (1, 3,5,6, 8, 10, 11... 96)
And if (for whatever reason) you'd have 150 LEDS horizontally, you'd get some repeated pixels, like 1,1,2,3,4,4,5,6,6...96)

I tested with some "ambilight test" videos from youtube, which worked fine with the "doubling-solution".

"Full res version":
I put H_LEDS=70 V_LEDS=38 as they physically are and also set the OFFSET value to 35 (the led strip starts at the middle of the bottom).
In the app.ino I disabled the doubling.
So far so good. The tv did not crash anymore. But the LED colors did not match the picture anymore, at least not all the time. It is hard to describe as I could not really make out a pattern.
If you intend to look into this I could make a video tomorrow. Right now my girlfriend is using the tv.

Take care

[adonis]

Yeah, would like to see what's going on. I mostly use the testimage from my first post for testing.., cast it to the TV (centered) and adjust the offset.