Hi @awawa-dev,
I just wanted to ask if you have already decided to add a white channel calibration option for the SK6812 SPI soon.
Many people who are already using their FTDI implementation would be happy to have this option. I would be happy too.

Hi
I re-introduced the white color calibration for the sk6812spi which had Nurikk in his PR.

@awawa-dev Hello,
Thank you for the quick implementation. I applied it to webOS yesterday and it worked. However, the following options are not available under the white LED algorithm "Subtract minimum":

Red/White-Channel-Aspect
Green/White-Channel-Aspect
Blue/White-Channel-Aspect
Brightness-Menu

In the Nurikk version, the menu item was called “Subtract minimum, custom”.

Nurikk version with "subtraction minimum, custom"

Reintroduce color calibration for sk6812spi Version with “Subtract minimum”

I would like to know whether this is what you wanted or whether I have made a mistake.

These changes have been missing in the latest #521 I'll recreate them but it's hard to me to provide ETA: a lot is happening in my professional life lately.

These changes have been missing in the latest #521 I'll recreate them but it's hard to me to provide ETA: a lot is happening in my professional life lately.

Hello,
I now understand why the options are missing. I understand that professional life always takes priority and there is little time for other things. You have already invested a lot of time in this big project, for which there is no fixed schedule.🤗
I thank them for that.🙏

I think a few weeks and everything will stabilize and get back on track :-) FTDI maybe I'll finish next weekend. Do you have the possibility to check on Windows if HyperSPI works via FTDI? Generally I plan at least 2 big changes/improvements for version 22. Currently HyperHDR has already reached high maturity so the changelog will be shorter from version to version.

I think a few weeks and everything will stabilize and get back on track :-) FTDI maybe I'll finish next weekend. Do you have the possibility to check on Windows if HyperSPI works via FTDI? Generally I plan at least 2 big changes/improvements for version 22. Currently HyperHDR has already reached high maturity so the changelog will be shorter from version to version.

@awawa-dev Hello,

I should check whether HyperSPI works via FTDI under Windows.
I only know RPI SPI/HyperSPI myself.
Or do you mean SK6812SPI? I have already tested that successfully.
I can connect the FTDI to the Raspberry Pi's SPI and test it, but what does Windows have to do with it?
Any hints in this direction would be much appreciated.

You just need esp32/rp2040 with a HyperSPI firmware: RPi is not neccesery. Then connect FTDI to esp32/rp2040 and see if you have some output on the serial port (https://github.com/awawa-dev/HyperSPI?tab=readme-ov-file#performancedebug-output) when you start/stop the LED device (HyperSPI type) in HyperHDR.

@awawa-dev
Hi,
I don't get Windows version in artifacts for your branch “full_ftdi_and_libftdi_dynamic_support”. All but Windows are built and in your GitHub there are no artifacts for the branch in the actions. I wanted to test HyperSPI via FTDI.

Its aqtinstall bug. Merge with the master branch (already fixed) or add these lines f78f6f5

Its aqtinstall bug. Merge with the master branch (already fixed) or add these lines f78f6f5

Yes, I saw that, thanks for pointing it out. I have added the lines.

Hello @awawa-dev,
I have flashed HyperSPI on an ESP32 S2 Mini. The HyperHDR Windows version recognizes it as “ESP32-S2 COM12 Serial USB Device”, but not as “HyperSPI LED Device”.

2025-05-21T11:56:43.311Z [LEDDEVICE0_HYPERSPI] (LedDevice.cpp:336) deviceConfig: [{"colorOrder":"grb","currentLedCount":302,"invert":false,"output":"/dev/spidev0.0","rate":25000000,"refreshTime":0,"smoothingRefreshTime":0,"spitype":"esp32","type":"hyperspi","white_channel_blue":255,"white_channel_calibration":true,"white_channel_green":255,"white_channel_limit":100,"white_channel_red":255}]
2025-05-21T11:56:43.311Z [LEDDEVICE0_HYPERSPI] (LedDevice.cpp:432) Refresh interval updated to 0ms
2025-05-21T11:56:43.311Z [LEDDEVICE0_HYPERSPI] Could not initialize the device before enabling
2025-05-21T11:56:44.556Z [NET_DISCOVERY] Found ESP32-S2 at COM12:-1 (Serielles USB-Ger t)
2025-05-21T11:56:44.548Z [SERVICE_mDNS] Starting the network discovery thread
2025-05-21T11:56:47.700Z [WEBSERVER] Web server resources initialized: C:/Program Files/HyperHDR/bin/../lib/web_resources.rcc
2025-05-21T11:56:47.961Z [WEBSOCKET] (WebSocketClient.cpp:40) New connection from ::ffff:127.0.0.1
2025-05-21T11:56:50.031Z [WEBSOCKET] (HyperAPI.cpp:946) log streaming activated for client ::ffff:127.0.0.1

On my LG webOS, however, it is recognized without any problems. It is the same “full_ftdi_and_libftdi_dynamic_support” branch.

Unfortunately, I can no longer test whether it works via FTDI.
I have also tried it with an ESP8266 Wemos D1 mini (CH340) and a Wemos D1 mini pro (CP2104) - with the same result.

I have flashed HyperSPI on an ESP32 S2 Mini. The HyperHDR Windows version recognizes it as “ESP32-S2 COM12 Serial USB Device”, but not as “HyperSPI LED Device”.

Thank you for testing. Doesnt matter how USB device with HyperSPI is presented: serial port is used only for debugging purposes, not for any operational usage. It can be even connected to the USB power supply and it should still drive the LEDs (but we cannot read the debug output then, irrelevant for the production setup).

Hello @awawa-dev ,
thank you very much for implementing the “HYPERSERIAL_CUSTOM” settings.🤗
I will carry out a detailed test tomorrow and then report back.
However, I can already assure you that it is perfect.❤️

Thank you. BTW while reviewing and debugging the nurikk RGBW calibration code I noticed that it behaves differently than my implementation in HyperSerial and HyperSPI. That's why I've now moved the code almost 1:1 from HyperSerial/HyperSPI to HyperHDR and FTDI. To be 100% I now have to debug it directly at the output using a logic analyzer. And in the queue is still waiting to check FTDI and HyperSPI (and separately from esp8266/esp32/rp2040...each device works in diffent way). In addition to that verification whether I haven't broken anything else in the classic HyperSPI support in HyperHDR on Linux. Development is probably over but now a lot of testing :-)

Hello @awawa-dev ,
I had time on Sunday to test the new SPI_FTDI LED controller with the “White Channel Calibration RGBW only” algorithm.
By being able to adjust the RGB white channel aspect individually to the RGBW, NW, CW or WW LEDs, I was able to achieve a true-to-life color rendering. The test device is fitted with SK6812 RGBW NW, which had a strong red cast with the standard RGB setting 255 and the blue was also very pale. By setting the blue-white channel aspect to 160, I achieved a realistic white and a reasonable blue value without having to change the gamma values in the image processing.
As I was able to switch between an RP2040 Adalight Feather Scorpio with HyperSerialPico and an FTDI-FT232H on the same device, I couldn't see much difference with the naked eye. Wide-eyed and amazed, I wondered how it is possible to achieve such good results without custom firmware on the FTDI, as is the case with the HyperSerialPico on the RP2040. Now I know why, because you said: “That's why I've now converted the code almost 1:1 from HyperSerial/HyperSPI to HyperHDR and FTDI.”👍 You can even fine-tune everything so that there are no differences. I have also not noticed any delay with a number of 266 LEDs. So once again an outstanding achievement from you. Thank you for that. 🤗

If further tests are required, I am still at your disposal.

Thank you for your help @satgit62 , I really appreciate it. As for the calibration algorithms, they were simply different than in my other HyperSerial/HyperSPI projects, I don't judge whether they are better or worse, just different. But they were correct for the both edge calibration settings (255,255,255) and (0,0,0). Now I'm testing HyperSPI. On the oscilloscope I have beautiful graphs from FTDI for SPI, unfortunately HyperSPI on rp2040 doesn't detect it. Maybe I need to activate another SPI mode. I have to experiment :)

It works! I had changes on my local HyperHDR repo (Github repo is/was OK) that I had forgotten about over the past few weeks and which were breaking communication. HyperSPI on Windows became a fact :-)

Pinout for Adafruit Scorpio rp2040:

Hi @awawa-dev ,
that looks good! But what is the purpose of this combination of RP2040 and FTDI? Is it a kind of master-slave connection, where the HyperSPI is flashed to the RP2040 and the FTDI takes over the LED output? Or how is this to be understood? And if so, is this also faster and more reliable than the data transmission of the individual controllers?

Of course for the average user it is much easier to use HyperSerialPico via USB than HyperSPI with FTDI... but let's think for a moment about the technical aspect of using FTDI. Neopixel LEDs like ws2812 or sk6812 are basically just emulated via SPI (on 3.3V), LED strips like APA102 are already closer to the proper application thanks to SPI but still do not solve the problem of the 3.3V to 5V level shifter that must be added to the APA102-FTDI chip... and basically only this setup as above using HyperSPI for FTDI fully meets the specifications: SPI on 3.3V to 3.3V GPIO.
But from my point of view the most important advantage of this solution is that it allows me to develop and debug HyperHDR with HyperSPI on Windows 😃