ws281x and sk6812 rgbw configuration when used directly with Raspberry Pi

[awawa-dev]

Definitely not recommended solution, you should use much better and safer configuration using ESP device (HyperSpi, HyperSerialESP32, HyperSerialEsp8266)... but if you want to take a risk that's the proper configuration for ws281x and sk6812. Adjust LED number for your configuration. HyperHDR must be run as root

ws281x:

sk6812 RGBW:

[sofakng]

I'd like to give this a try and report back. However, why is this not considered safe? Does the Raspberry Pi (4) not have the resources neccessary?

Also, how do I modify the HyperHDR SD card image/setup to use root instead of pi? (it looks to be using systemd to launch HyperHDR under the pi user?)

[awawa-dev]

Great it works! 👍 I would investigate that case with lowering brightness compensation: your power supply may be insufficient for full scale operation so you can measure the voltage on the LED strip when it is set to 100% and playing the rainbow effect.

[sofakng]

Glad to hear it! I don't know enough (or anything!) about timings with these different methods (PWM/SPI) but I'm wondering why they would impact the CPU?

For example, if you are using something like SPI what's the difference between that and the UART? I would expect that sending data to the SPI bus is handed off from the CPU, etc. (Here is an example project using SPI for the SK6812: https://github.com/leonyuhanov/SK6812viaSPI)

Anyways, I don't really know enough but I'm always trying to learn. It's always nice to simplify a project and reduce dependencies on other hardware, etc.

EDIT: This looks like a good article too: https://innomatic.home.blog/2018/12/24/ws2812sk6812-control-with-spi-and-dma/

EDIT2: I'm looking over the Hyperion/HyperHDR code and it looks like the sk6812spi/ws2812spi implementation doesn't use DMA transfers? (however, the PWM implementation does?) I'm guessing this might cause problems (ie. CPU).

[awawa-dev]

@sofakng you jumped from one subject to another 😉 Using SPI from Rpi is fine from the performance point of view for SPI driven LED strips (SPI data & clock lines: APA102,HD107 etc, the voltage level shifter is still needed!) or for other forms of the communication (for example HyperSPI project). But ws281x or sk6812 are not natively SPI driven LED strip with only one data line without a clock.

[mbspears]

I checked out my setup again and I did not need to dial down Brightness compensation, only the backlight compensation. Thanks for suggesting taking another look. The colors are bright and vibrant. Family loves the new immersive feel.

[sofakng]

@mbspears Which controller/driver are you using with the LEDs?

[awawa-dev]

I know many cases of burnt out or partially damaged Rpi's GPIO. Of course PWM takes additional resources too so it's better to delegate control to other (and cheaper) device. To run the application as root you can use link from the faq: https://github.com/awawa-dev/HyperHDR#faq

[awawa-dev]

Hi

Then I decided to try and use the ‘better’ method of using hyperspi/hyperserial8266, without success. When I reset back to original direct method,

Well, this is an advanced technique so no worry that it may not work for you after first time. How long were the cables and when it was not working did you connect also ground cable between Rpi and the esp8266 pinout (sometimes it helps even it's grounded by common USB connection)? GPIO18 is not used by HyperSPI, should not be connected so I don't know how can it become damaged when you were trying HyperSPI configuration.

My setup is rpi4 running hyperhdr17.0, I couldn’t get 18 to install for whatever reason. User error without doubt. I maybe will try again but have already forgotten how I set v17 to run as root and given how long it took me to get that installed as such, I’m reluctant to mess with things again.

It's very simply: #52 (comment)
before upgrading please backup your configuration from the HyperHDR v17 web panel. Or even better: export the settings and use another clean SD card to flash v18 and later import old v17 settings. Even if something goes wrong, then you can just swap SD card.

And yes: Rpi a great tool to experiment. There are also much easier to setup HyperSerialEsp8266 or HyperSerialESP32 if you don't want to try HyperSPI again ;)

[houseofquad1974]

Hi

Then I decided to try and use the ‘better’ method of using hyperspi/hyperserial8266, without success. When I reset back to original direct method,

Well, this is an advanced technique so no worry that it may not work for you after first time. How long were the cables and when it was not working did you connect also ground cable between Rpi and the esp8266 pinout (sometimes it helps even it's grounded by common USB connection)? GPIO18 is not used by HyperSPI, should not be connected so I don't know how can it become damaged when you were trying HyperSPI configuration.

My setup is rpi4 running hyperhdr17.0, I couldn’t get 18 to install for whatever reason. User error without doubt. I maybe will try again but have already forgotten how I set v17 to run as root and given how long it took me to get that installed as such, I’m reluctant to mess with things again.

It's very simply: #52 (comment) before upgrading please backup your configuration from the HyperHDR v17 web panel. Or even better: export the settings and use another clean SD card to flash v18 and later import old v17 settings. Even if something goes wrong, then you can just swap SD card.

And yes: Rpi a great tool to experiment. There are also much easier to setup HyperSerialEsp8266 or HyperSerialESP32 if you don't want to try HyperSPI again ;)

Thank you for the reply. The idea of trying a new SD card for v18 is excellent. I didn’t even think of that. Another question which will further confirm how much of a noob I am, will the v18 still install as root ?

Also, it was indeed HyperSerialEsp8266 that I tried. So if that’s the easy way and I still messed it up, then I guess I still have very much to learn !

As for my cable lengths, they are no longer than two jumper wires, so maybe 8-10 inches at the most. That’s between pi and led strip. The length from power supply to led strip is even less, about 3-4 inches. And yes, I always maintained a common ground, as when setting up my original confuguration, nothing worked properly until I had the common ground installed.

Thank you for the #52 suggestion, I will take a look at that now.

[awawa-dev]

SD image for v18 is using pi user. It was removed in the official Raspberry Pi OS but we restore it using script as this option was fortunately officially introduced at the same time. But please do not use official Raspberry pi OS flasher or at least do not set own user with it because it breaks the initial SD HyperHDR configuration. After flashing SD card, ssh to system and change to root if you want to use ws281x driver. At this point (when you already switched to root) import your old settings from json backup. If you do this earlier, your settings will be restored for pi user, and you will have to do this again when it runs as root.

[houseofquad1974]

Hi, thanks again for your replies so far. I just wanted to update my experience. After your simple suggestion of trying v18 with a fresh sd card, i went one further and decided to opt for v19beta. Everything went (when compared to my first installation of v17) unbelievably smoothly, it's amazing how much you learn when you persist through an encountered 'problem'. I have been running v19 this last week, and so far i am unable to see any difference. This isn't meant as a criticism, all it means is that i am still new to this, and have yet to delve deep into the settings. The LED strip, to my untrained eyes, is performing exactly as before on v17. At some point i would like to try the RGBW calibration tool, but before that i will attempt again to change my setup to your advised method of controlling the LED strip via HyperSPI. I suspect it didn't work for me the first time because i may have mixed up my Blue and Green jumper cables ! AND, i may flashed the wrong ESP firmware to the module !! As i said, i'm new at all this, and every step is becoming a lesson.

Despite my (self-inflicted) frustration, i am loving what you have created, and am so grateful. So, thanks again. How do we 'buy you a coffee' or whatever ?

[awawa-dev]

Hi
Giving a 'star' for the project is enough ;) There is a lot of changes since v17, many issues were fixed (but you may not encountered them for your setup), speed is also much improved (but you must compare statistics from v17 and v18, for certain modes like MJPEG HDR tone mapping the improvement is dramatic), new features (but stilll you may not need most of them for your setup) but I understand your point. I think the most important improvement for the ambient light quality was automatic HDR lut table calibrator in v18 (if you use HDR tone mapping) and RGBW calibration that allows to fix some issues with colors especially when your color of the wall behind the TV is not a pure white. I'm glad the update procedure went smoothly for you, in next version the upgrade will be even easier because we are preparing new package repository for usage with apt tool.