Debugging ideas needed for sk6812 strip

[tuba59]

Hey,

I was able to make my setup work a year ago, but one day I was doing some cable management and the LEDs went out. Since then I put the whole setup in the drawer after spending hours checking the connections, which were all good.
I'm not sure that my led strip is functional at all, I'd like to test it somehow. (Maybe I short-circuited it somehow??)
I already tried to just send one color from the Remote control tab, but the leds are still not lightning up.
What would be the easiest way to test whether my led strip still works?

It's a cheapo aliexpress sk6812 strip, which is connected to my rpi3 via gpio18. The ground is also connected to the pi. The strip has an external power source that is connected to both ends.
hyp_log.txt
I didn't see anything weird in the logs, but maybe you guys see something that could help.

[awawa-dev]

SPI method for neopixel LED strips had never worked for me personally. You can find alternative method and link to the configuration in the HyperHDR FAQ on the main page.

[tuba59]

Thanks, I will try to light up the strip using arduino to make sure that it works. Regarding the SPI communication with the sk6812 strip, I remember that it only worked after I selected ws2812 from the controller list, then back to sk6812 :D Also there was a top limit in the led count (255) and I have ~270 on my tv, which resulted in only a few leds lighting up. But this could be solved by not adressing the leds which were over the 255 index.

…

On Sun, Apr 24, 2022, 01:07 Awawa ***@***.***> wrote: SPI method for neopixel LED strips had never worked for me personally. You can find alternative method and link to the configuration in the HyperHDR FAQ on the main page. — Reply to this email directly, view it on GitHub <#258 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACYCOU3XJIHLCRE7GXVALPTVGR7CDANCNFSM5UFKUOSA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[awawa-dev]

It was tested by me for 299 SK6812 LEDs (using PWM ws218x method as root + level shifter) so probably in your case it was a configuration problem. Nevertheless driving neopixel LED strips from RPI is not officially supported because there are better solutions.

[tuba59]

I was able to breathe some life into the led strip using a D1 board. I connected the strip to the D4 pin and to the ground of the board. I flashed your port of WLED onto it, when using the WLED interface I was able to change the colors of the strip.
But when setting it up in HyperHDR I'm not able to turn on the LEDs, first I'd like to send a static color through Remote Control.
In the log I can see these few lines repeating:

2022-04-25T21:45:35.069Z [LEDDEVICE] Opening UART: ttyUSB0
2022-04-25T21:45:35.069Z [LEDDEVICE] (ProviderRs232.cpp:141) _rs232Port.open(QIODevice::ReadWrite): ttyUSB0, Baud rate [2000000]bps
2022-04-25T21:45:35.179Z [LEDDEVICE] (ProviderRs232.cpp:146) portName: ttyUSB0
2022-04-25T21:45:35.180Z [LEDDEVICE] (ProviderRs232.cpp:147) systemLocation: /dev/ttyUSB0
2022-04-25T21:45:35.180Z [LEDDEVICE] (ProviderRs232.cpp:148) description: USB2.0-Ser
2022-04-25T21:45:35.181Z [LEDDEVICE] (ProviderRs232.cpp:149) manufacturer: 1a86
2022-04-25T21:45:35.181Z [LEDDEVICE] (ProviderRs232.cpp:150) productIdentifier: 0x7523
2022-04-25T21:45:35.182Z [LEDDEVICE] (ProviderRs232.cpp:151) vendorIdentifier: 0x1a86
2022-04-25T21:45:35.182Z [LEDDEVICE] (ProviderRs232.cpp:152) serialNumber:
2022-04-25T21:45:35.187Z [LEDDEVICE] (ProviderRs232.cpp:173) delayAfterConnect for 5000 ms - start
2022-04-25T21:45:35.188Z [LEDDEVICE] (ProviderRs232.cpp:180) delayAfterConnect for 5000 ms - finished
2022-04-25T21:45:35.412Z [LEDDEVICE] (ProviderRs232.cpp:93) Flush was successful
2022-04-25T21:45:35.412Z [LEDDEVICE] (ProviderRs232.cpp:95) Close UART: ttyUSB0
2022-04-25T21:45:36.474Z [LEDDEVICE] (ProviderRs232.cpp:199) !_rs232Port.isOpen()

My LED hw setup:

I also tried to update the baud rate in the wled sync setup page on the bottom in wled, but no success.

Do you see maybe something that I'm doing wrong?

[awawa-dev]

It should work at lower speed. Just to be sure: after you set the lower speed in WLED did you update HyperHDR serial port speed also?

[tuba59]

That was it, thanks.
When selecting lower speed on both ends (wled and hyperion, namely 115200) it started to dance :)
The only issue is that it's laggy and slow as hell.
BUT, I found that there's an option to use WLED over the network which is working pretty fast ^^
If I'll find this solution slow in the end, then I will try out other binaries on the ESP, maybe one of them will work with 2000000 baud rate.

[awawa-dev]

BTW
2022-04-25T21:45:35.187Z [LEDDEVICE] (ProviderRs232.cpp:173) delayAfterConnect for 5000 ms - start
2022-04-25T21:45:35.188Z [LEDDEVICE] (ProviderRs232.cpp:180) delayAfterConnect for 5000 ms - finished
these logs dont make any sense for me delayAfterConnect should be 0 as on your screenshot
and after that "Close UART: ttyUSB0" and it's dead.
You should not change delayAfterConnect (it's for some problematic arduino, here it can cause problems) and leave it at 0.
And should easy get much higher speeds even if your serial port chip on ESP board is not 2Mb capable.

[tuba59]

Could you give some additional advice on the hw part?
I'm using a 5V20A psu to control 268 sk6812nw leds, this is connected to both ends of the strip (5v and gnd). The din of the strip is connected to the d1 mini on gpio2 directly, also the gnd is connected to here as well from the strip.
The rpi 3b connects to the d1 mini through usb (but this part is currently not really necessary because I'm driving it through wifi).
I experience some stutter here and there on the strip, I guess this could be solved by some additional hw between the strip's data and the d1 mini, is this right? I saw that this could be a resistor or a level shifter, what do you recommend?

I have the following cheapo hdmi capture card.
Whats the best capturing method for this in your opinion? Mjpeg, or yuyv? Based on the limited testing I did so far 720x480, 30fps yuyv looked good and performant.

Also I'm using an nvidia shield for which I lost the CEC functionality when its behind the hdmi splitter. Is this feature dead for good because of the splitter?

[awawa-dev]

Start with a level shifter. Practically 5V20A is a overkill for 268 leds, but the question if it's stable. I don't fully understand what that stutter means. Usually the LED strip is just blinking when something is electrically wrong. The grabber is good but USB2.0, if you want a faster one then choose USB3.0 grabber. More on my blog. Usually splitters blocks CEC but there are some exceptions.

[tuba59]

Under stuttering, I meant epilepsy level blinking 😄 (weird but it looks like that the bottom first segment is stable, then the remaining 3 are blinking, all 4 segments are connected with this L shape Aliexpress connector), but I discovered that the cable that went from the psu to the strip was really thin, so I changed it to a thicker one and it's gone.
Also when the white channel is set to Dual in WLED the white scenes are still flickering like hell, when it's set to Accurate its gone.
This points to a psu issue... From the strip to the d1 mini its also a thinner cable, but I guess it should be ok, cause its just the data and the ground.
I will give a try to the level shifter.

[awawa-dev]

then the remaining 3 are blinking

For 99% it was a problem with a L connection after first segment (or less likely damaged/less tolerant last LED at the bottom segment or the first one at the next segment) not the power supply or too thin cable. This L connectors are problematic, can also loose connectivity with time.

[tuba59]

I just gave the first L connector some wiggle and it was better :)
There's still some variance in color, but at least there's no blinking. I will solder the segments together.
Thanks for your help :)