Misleading instruction for connecting the data cable

[bruno-dogancic]

Hey there, many thanks for the software, once again.

Finally the level shifter arrived (SN74AHCT125N) and I got to time to connect everything.

I've done according to the instructions here https://github.com/awawa-dev/HyperHDR/wiki/How-to-build-a-new-LED-system-or-to-upgrade-it.-Needed-components.#e-33v-to-5v-level-shifter , I think the instructions are written quite nice and a go to for manz who are starting with HzperSerial's, but these instruction use GPIO16 and GPIO33. Now, I know it makes sense to also recheck the original thread for HyperSerialESP32 and I barely stumbled upon the Pinout mentioned there https://github.com/awawa-dev/HyperSerialESP32#pinout

Since the afformentioned instructions are great and detailed, I suggest to make a statement that highlights that this setup is primarily oriented towards Multisegment setup where a GPIO pin for driving led can be set when compiling and perhaps even mention the wiki on how to use actions to compile for this particular GPIO pins.

With that said, can I set a GPIO pin in the firmware_esp32_s2_mini_WS281x_RGB.bin or firmware_esp32_s2_mini_WS281x_RGB.factory.bin, or should I proceed with re/soldering the wire towards the level shifter?

EDIT1: I have searched and found the answer to changing pinout https://github.com/awawa-dev/HyperSerialESP32/wiki#how-to-compile-project-using-github-action-and-change-the-speed-or-pinout-for-your-board

many thanks and have a great and healthy year 🙏

[awawa-dev]

Hi I added multi-segment clarification for https://github.com/awawa-dev/HyperHDR/wiki/How-to-build-a-new-LED-system-or-to-upgrade-it.-Needed-components.#e-33v-to-5v-level-shifter but as you noticed, the board is capable of multi-segment and single segment usage. The use of GPIO2 as the default results from a historical context, because this output is used by WLED and there were some custom boards that assumed the use of this GPIO. However, GPIO2 is not the best solution. Since WLED still uses it, it may not be a big problem noticed by users, but this GPIO is used when starting esp32 (but not esp32-s2)

[bruno-dogancic]

Hi I added multi-segment clarification for https://github.com/awawa-dev/HyperHDR/wiki/How-to-build-a-new-LED-system-or-to-upgrade-it.-Needed-components.#e-33v-to-5v-level-shifter but as you noticed, the board is capable of multi-segment and single segment usage. The use of GPIO2 as the default results from a historical context, because this output is used by WLED and there were some custom boards that assumed the use of this GPIO. However, GPIO2 is not the best solution. Since WLED still uses it, it may not be a big problem noticed by users, but this GPIO is used when starting esp32 (but not esp32-s2)

I see, when you put it like that it completely makes sense. 😃

Maybe just expand the paragraph in the mentioned tutorial with a sentence similar to: "... For this particular multi-segment capable board and ESP32-S2 mini, the LED output is on GPIO16 and GPIO33. The HyperSerial firmware for ESP32-S2 by default uses pin GPIO02 for data, so make use of github actions to compile firmware that will use, e.g GPIO16 for single segment setup or both GPIO16 and GPIO33 for multi segment setup, as explained here. The yellow pinout is optional, and it's used for HyperSPI connections; if you don't use it, you don't need to solder it:..."

I say this as I stumbled on Reddit and some forums with people not getting the data pushed but eventually realising they were having the same challenge as I did.

With that said, the setup so far is working wonderfully! The response for my 233 LED's is reaching nearly 100Hz 🥳

The only challenge is to make the colors a bit more calibrated. The reds seem to occur more than I'd like and the yellow are leaning towards green more often then needed.

I use WS2812b strip, do you have suggestions for calibration?

Cheers!

[awawa-dev]

The only challenge is to make the colors a bit more calibrated. The reds seem to occur more than I'd like and the yellow are leaning towards green more often then needed.

But are you testing on the video source or on effects/colors? If on a grabber, the colors may be distorted and the input source must be calibrated. If it's about effects/colors, you need to try different settings in the processing tab (btw, the default gamma 1.5 is not neutral). But honestly: I was not able to achieve a satisfactory effect in either the ws2801 or the ws2813, they were significantly behind those offered by the sk6812 rgbw (although sk6812 rgbw wasn't perfect at the beginning as the wled calibration was not satisfactory to me). The only advantages of WS2812b are: they are faster (due to the lack of a white channel, so it's worth it) and the blue color is deeper/more expressive.

[bruno-dogancic]

The only challenge is to make the colors a bit more calibrated. The reds seem to occur more than I'd like and the yellow are leaning towards green more often then needed.

But are you testing on the video source or on effects/colors? If on a grabber, the colors may be distorted and the input source must be calibrated. If it's about effects/colors, you need to try different settings in the processing tab (btw, the default gamma 1.5 is not neutral). But honestly: I was not able to achieve a satisfactory effect in either the ws2801 or the ws2813, they were significantly behind those offered by the sk6812 rgbw (although sk6812 rgbw wasn't perfect at the beginning as the wled calibration was not satisfactory to me). The only advantages of WS2812b are: they are faster (due to the lack of a white channel, so it's worth it) and the blue color is deeper/more expressive.

Thank you for a quality response 🙏

The colors seem good when single color/effect is applied. Previously mentioned color dispcrepation is seen when using the video source/capture device.

I'm still using that Rullz capture with splitter, as I'm waiting for MS2130 and Feintech to come.

lsusb output gives me this:

Bus 001 Device 003: ID 303a:80c2 WEMOS.CC LOLIN-S2-MINI
Bus 001 Device 004: ID 534d:2109 MacroSilicon USB Video

I will proceed to check on input device calibration to make it better.

Do you think it's worth trying to place the SK6812 next to the existing WS2812b and perhaps connect it through an ESP32 and some USB hub to the A95 F3 Air that is running HyperHDR? Is the procedure after that just creating a new instance with the other ESP32 that will serve as another LED device? Will USB Hub introduce any lag?

This would be the ultimate test I would perhaps want to make just for fun, as I still have some 15% free space left behind the TV 😅

[awawa-dev]

Seems like you have MS2109. Unless there is a firmware scam like in the case of MS2130 that came out recently, it should give a very correct result. Actually, the only thing wrong with the MS2109 is the slow USB2.0 connector, which imposes an additional 25-40ms delay compared to the latter. The USB hub should not generate additional latency, just make sure that the MS2130 will still be detected as a USB3.0 device. If you are using Debian Bullseye, make sure OS is fully updated as the udev bug (https://github.com/systemd/systemd/issues/25238) may cause incorrect detection of USB3.0 serial port devices by Qt libs and consequently by HyperHDR.

This would be the ultimate test I would perhaps want to make just for fun, as I still have some 15% free space left behind the TV

sk6812 and ws2812b side by side? Yes, this will be interesting :) I also have a similar ws2813, but I only use it for testing purposes, but then it reminds me why I should avoid RGB LEDs, although some of them look very tempting e.g. HD108 with 16-bit color precision. The only thing in which the sk6812 is inferior to the ws2813 is, as I already wrote, the weak depth of the blue color, it is not so saturated.