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

Here are software that related with Samsung F series TVs.
Please don't create any new topic here unless you have software to post/release.

tasshack
SamyGO Project Donor
Posts: 65
Joined: Thu Aug 23, 2018 5:54 am
Location: Istanbul, TURKEY

Re: [App] libSambilight E/F/H (MST-only)

Post by tasshack »

j0hnd03 wrote: Sat Jun 18, 2022 12:42 pm Thx again, I tested the new version these days - w/o issues and the performance benefit is noticable on E.
Haven't really compared with TEST_FRAMES on the previous build, but on the new version I'm getting solid 25fps (GFX_LIB=1; CAPTURE_SIZE=2), which is more than I hoped for 8-)

I strongly recommend you to give WLED a spin, imo it's yet another brilliant example of a group of individuals investing their free time to build something absolutely genius to share with the community. Also (My personal flicker issue aside) it integrates perfectly with libSambilight - i.e. LEDs are showing WLED effects when TV is off and automatically switch to Adalight input when its received. And in both cases you have full direct control of the ESP with a lot of features via web GUI.

Rgd. Flicker:
- I agree it's extremely unlikely to be directly libSambilight-caused and might have electrical reasons
- However, its definitely not voltage on the strip... because
a) The flicker occurs regardless of position on the strip (as mentioned you can set offsets on WLED; I managed to move the flicker from end of the strip to beginning of the strip that way)
b) WLED can display a preview of the strip via GUI - and the flicker is noticable on the web preview as well.

On your remarks rgd. input timeout / current limiting by WLED: Both are configurable / deactivatable on WLED, and I deactivated both, but the issue occurrs regardless.

So, imo 2 suspicions..
Either there's an physical issue on the (analogue) connection between TV and ESP via my FTDI, either the FTDI itself or some magic like ground loop etc.
Or like you say, WLED has some bug in that area. Looking at WLED code, this might make some sense. I'm not a great programmer but comparing WLEDs serial code with your ino sketch shows it has a bit more complexity at that end as WLED integrates TPM2 & has outbound serial functionality as well which might overlap. Also, the behavior I'm seeing could make sense considering WLEDs flow (see below) -> the pixels with wrong color seem to be displaying the "complementary" color to the one they should be displaying, i.e. most of the times red is displayed where it should be green. In addition, I could not manage to use WLEDs latest build as that crashes the ESP in conjunction with Adalight in (I'm using a modified version of 0.13.0-b6 instead).

https://github.com/Aircoookie/WLED/blob ... serial.cpp

I dont have a ESP8266 to test at the moment, only ESP32s, and the one I'm using here is nicely installed behind my TV. But I'll keep digging and report back. For now I'm out to enjoy the unusual, almost "Istanbulish" weather in Germany ;)
I have discovered WLED recently and I use it on my PC case lighting to integrate it to the rest of my home lights but i have never tried the adalight feature on WLED.
I you are seeing the flicker on the app too that definitely means there is something wrong at the serial communication but not the leds side. I will look into that and release a new version to fix the issue on WLED. Meanwhile, you can flash the ino file from first post to check the problem caused by the FTDI serial converter or WLED firmware.
By the way i don't have ESP8266, i use ESP32 on a custom pcb. I tied the sleep pin of FTDI to a gpio to determine TV is on or off unlike WLED just relies on constant communication from serial.

Thank you for your feedback, have a nice day.
j0hnd03
Posts: 9
Joined: Sun Aug 04, 2019 5:15 pm

Re: [App] libSambilight E/F/H (MST-only)

Post by j0hnd03 »

I can confirm its working fine with the sambilight sketch.
Would be awesome to have wled as well, so thx a lot for adding it to your list 👍
But even if not, I'll keep the sketch

May I know whats your plan to adress the issue with wled? tpm2?
Some observations:
wled 0.13.0b6 works ok on esp32 with 921600 (set in wled.cpp serial.begin()), but glitches for me after 85 pixels (85x3colors=255 but not sure if thats a red herring) .
wled latest fails on my esp32 when setting custom baudrate via web gui (introduced feature after 0.13.0b6), but not on the 8266 which I meanwhile got because I thought your sketch only worked on 8266 :)
tasshack
SamyGO Project Donor
Posts: 65
Joined: Thu Aug 23, 2018 5:54 am
Location: Istanbul, TURKEY

Re: [App] libSambilight E/F/H (MST-only)

Post by tasshack »

j0hnd03 wrote: Sun Jun 26, 2022 5:36 am I can confirm its working fine with the sambilight sketch.
Would be awesome to have wled as well, so thx a lot for adding it to your list 👍
But even if not, I'll keep the sketch
I am glad to hear that because it means your hardware setup is ok also the issue is not caused by the libSambilight itself.
j0hnd03 wrote: Sun Jun 26, 2022 5:36 am May I know whats your plan to adress the issue with wled? tpm2?
Some observations:
wled 0.13.0b6 works ok on esp32 with 921600 (set in wled.cpp serial.begin()), but glitches for me after 85 pixels (85x3colors=255 but not sure if thats a red herring) .
I am not sure the plan of attack yet but i need to reproduce the issue first. I have checked the code of the wled but i am not sure what tmp2 is yet. I need to read some information about it but currently i don't have any time for any of that.
Preferably i don't want to modify the current protocol of sambilight which is already compatible with the adalight protocol and works with the adafruit example sketches. If there were a compatibility issue,i think it must be resolved on wled firmware. Wled is not the most stable firmware to begin with anyway and it constantly crashes on my esp32 too.
You can try prismatik on your PC to test your wled setup with adalight protocol. If it still flickers that means issue must be resolved on wled side. I can contribute the project if i understand the reason of flickering but it sounds like a buffer overflow problem to me.
j0hnd03 wrote: Sun Jun 26, 2022 5:36 am wled latest fails on my esp32 when setting custom baudrate via web gui (introduced feature after 0.13.0b6), but not on the 8266 which I meanwhile got because I thought your sketch only worked on 8266 :)
It is not related to libSambilight or ESP32, I forgot that the current sambilight arduino sketch is not compatible with the esp32. I have made the required changes and the new version should work on esp32 too. You can download it from the first post.
j0hnd03
Posts: 9
Joined: Sun Aug 04, 2019 5:15 pm

Re: [App] libSambilight E/F/H (MST-only)

Post by j0hnd03 »

Yup I fully agree, this proves that both sambilight and my physical setup are fine.
Although I cannot really judge if there is some "Adalight inaccuracy" in sambilight that only causes issues with more complex environments, whereas its fine on the basic adalight sketch.
Testing with Prismatik might make sense yes.. but fwiw, my way from wled to sambilight sketch went via Arduino OTA, my way back to wled would require access to the esp via microusb to flash, which would require tearing down tv and all the nicely tugged cabling from the wall once more... I'll shout if I found the motivation :)

In my case, wled (0.13.1) is only flaky when receiving adalight via serial.. otherwise no crashes for me.
And looks like we're not alone
https://github.com/Aircoookie/WLED/issues/2618

My guess is these problems were introduced with
https://github.com/Aircoookie/WLED/pull/2517

And I agree about the potential overflow in 0.13.0.b6, otherwise, fail after 255 would just be too much of a coincidence.
Also the glitching is different on esp8266 as far as what pixels affected - which might make sense due to hardware specific memory layout. But I get glitches with wled/sambilight on esp8266 as well.

From what I understood on TPM2 is it serves the same purpose as Adalight but is binary and slightly more efficient (less protocol overhead)

Just a thought:
How complex do you think it would be to create a hacky workaround in wled that simplifies its serial interface down to the basic sketch with 921600 statically set? I would not mind losing serial out, improv and tpm2 unless you plan to support it..
j0hnd03
Posts: 9
Joined: Sun Aug 04, 2019 5:15 pm

Re: [App] libSambilight E/F/H (MST-only)

Post by j0hnd03 »

Actually I just tried the workaround idea, here's my customized wled fork / wled_serial.cpp :)
The hope to have it fixed so easily got me motivated to demount my setup once more.

Result:
- This seems to fix the crashes when receiving adalight, BUT
- The glitches >pixel 85 are still there

Furthermore, testing made me suspect the glitches are in relation to wifi activity on the esp.
I'm able to trigger light glitching by looking at wleds preview (low traffic)
And I got heavy glitching while flashing my custom binaries via ArduinoOTA...

... then I confirmed the wifi theory by disabling wifi on my custom wled via GUI - which stopped any glitching, so the basic sketch might simply work because it has no wifi functionality...

... Which lead me here:
https://www.reddit.com/r/esp32/comments ... fi_solved/
What a riddle, but feels like I'm getting close and will attempt integrating FastLED-idf next
Chillout
Posts: 7
Joined: Thu Jun 03, 2021 9:34 pm

Re: [App] libSambilight E/F/H (MST-only)

Post by Chillout »

This is a brilliant piece of work!
I've been using Hyperion for a few years but ever since I got a Shield TV, I hated that the image grabber wasn't capable of getting data from drm videosources like Netflix.
I'll try the software soon, after I've rebuilt my ambilight hardware.


I've been thinking about smoothing, to allow for a softer transition. I guess this could be done on the Arduino side, by calculating the average color for each pixel, over a configurable timespan. I'll see if I can cook up some proof of concept for this.
j0hnd03
Posts: 9
Joined: Sun Aug 04, 2019 5:15 pm

Re: [App] libSambilight E/F/H (MST-only)

Post by j0hnd03 »

I'm also coming from hyperion, migrated to this great lib for drm reasons as well, in my case the drm gpu drivers for raspi 4 broke local grabbing. And obv the major advantage of not being limited a specific source. Haven't looked back :)
At first I was concerned about smoothing with libsambilight too, but having it running, I'd say going w/o smoothing is less of an issue than I thought.
However, during my research for a wled workaround I stumbled across some Adalight code w/ smoothing functionality.. just in case..

https://github.com/Benik3/Adalight_WS28 ... ht_ESP.ino
tasshack
SamyGO Project Donor
Posts: 65
Joined: Thu Aug 23, 2018 5:54 am
Location: Istanbul, TURKEY

Re: [App] libSambilight E/F/H (MST-only)

Post by tasshack »

Chillout wrote: Fri Jul 08, 2022 9:45 pm I've been thinking about smoothing, to allow for a softer transition. I guess this could be done on the Arduino side, by calculating the average color for each pixel, over a configurable timespan. I'll see if I can cook up some proof of concept for this.
I also thought about smoothing but i decided not to implement it. Leds need to finish color transformation before getting the next frame data and that means lagging. Also delay between frames are not same so it is tricky to decide transformation duration. I think Phillips uses some kind of pid loop for each led to provide smooth transaction but personally i prefer sambilight experience to Phillips TVs.
Also you don't need smoothing because of the high frame rate. +15 FPS (40ms between frames) is perfectly acceptable for ambient lighting application and you can lower the capture size to get higher FPS values in expense of color accuracy.
Basically, with smoothing you don't see those fancy lightning effects like on the demo.
Chillout
Posts: 7
Joined: Thu Jun 03, 2021 9:34 pm

Re: [App] libSambilight E/F/H (MST-only)

Post by Chillout »

Good point, thanks tasshack and j0hnd03!

Looking forward to be able to use WLED with this!

Testing my prototype setup here:
Image
Chillout
Posts: 7
Joined: Thu Jun 03, 2021 9:34 pm

Re: [App] libSambilight E/F/H (MST-only)

Post by Chillout »

Update: got it running with WLED without flickering. The only issues I have currently is not having a very persistent root on my tv... I guess I have to do something to delay the usb initiation. But that's unrelated to this awesome lib 8-)

Edit: finalized the hardware, installed it all in an old Raspberry Pi case :mrgreen:
Tests are succesful, although it's not yet running from startup, despite having 01_99_Sambilight.init in init.d, with executable rights.. I guess I must have slipped up somewhere, or does this sound familiar to anyone?
Edit2: fixed it :-) turned out there was some ux-windows issues with the file :lol:

Post Reply

Return to “[F] Software”