High responsiveness was always among the main goals of this project and reasons to fork it as HyperHDR from Hyperion NG. Now as the video processing is almost done with tuning up it's time to look at the other end of the system: the LED strip driver. You are sure that your large, high-density LED strip setup that is driven by the Adalight/Arduino doesn't have a bottleneck? Well, you may be wrong. Or do you have problems with Wifi's stability while using WLED?
Then you may be also interested in my new side-project for HyperHDR: ultra-fast USB serial port AWA protocol for ESP8266 at @2000000 baud with data integrity check at https://github.com/awawa-dev/HyperSerialEsp8266 Pure facts backed by results from the Saleae logic analyzer vs subjective opinions like "I think I don't see any lag anyway". Remember, you use it on your own risk.
It includes build-in calibration for each channel for RGBW led strips. Read more about it here: https://hyperhdr.blogspot.com/2020/12/my-build-log-using-sk6812-rgbw-led.html
There is also my new fork HyperSerialWLED available with the support for the AWA serial protocol at 2Mb speed: https://github.com/awawa-dev/HyperSerialWLED Can't guarantee it will work as stable as HyperSerialEsp8266 because WLED has a lot of other things to do in the background (ex. handling Wifi) and timing control for the serial port could be at stake for larger number of LEDs. But you don't need to abandon all the benefits offered by the WLED which can be a big advantage for some users.
Why the data integrity check was introduced which causes incompatibility with other software? Because at 2Mb speed many chip-makers allow few percentage error in the transmission. And we do not want to have any distracting flashes.
In this version generic performance for decoding YUV stream increased up to 30% in higher resolutions. New decoders were added for incoming new modern grabbers: NV12, xRGB, RGB24, I420.
Also I own now some devices from Philips Hue ecosystem so this module received and will receive even more support if necessary. Please migrate your Hue setups to the Entertainment API. You won't want to go back to the old and very slow restful API. Check logs after you activate it as it can fall-back to the restful API in some circumstances (you should see a message about activating the stream and no errors if everything is OK).
Main changes:
- New: ultra-fast USB serial port AWA protocol for ESP8266 at 2 000 000 baud with data integrity check for WS2812b & SK6812 at https://github.com/awawa-dev/HyperSerialEsp8266 and https://github.com/awawa-dev/HyperSerialWLED (you use it on your own risk!)
- Improvement: increase performance for YUV decoding up to 30% and decrease CPU usage by 40% for higher resolutions & frame rates. The internal video pipeline shouldn't be blocked now in specific circumstances (for example 1080p60).
- New: add popular I420, RGB24 and NV12 & XRGB decoders particularly for incoming modern lossless USB3.1 grabbers
- Fix: some non-standard chars inside the USB grabbers identifier caused the destruction of the grabber's configuration. Rullz Navy U3 is affected and probably Rullz Coffee and Black with internal loop.
- Philips Hue fix: Entertainment API driver is back from the dead and it's working now. Lamps can be power off on black colors and wake up automatically.
- Philips Hue new: new options to set sleep/wake time for lamps to eliminate unnecessary flickering.
- Philips Hue fix: also for the old restful API power off/wake up issue is resolved. But please migrate to the Entertainment API as it is much, much faster.
- Philips Hue new: add options for the bottom of the screen section for hue lamp's configuration.
- Philips Hue new: Rpi/Windows with HyperHDR will wait for Hue Bridge if they are power on simultaneously (for ex. when they are connected to the same surge protector). Philips Hue Bridge needs about 1 minute to be ready and Raspberry Pi is much faster.
- Improvement: better compatibility with some MJPEG grabbers and cameras for Linux.