tobi/KDEAmbi
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: Add lesson learned about resolving LED flickering with increased frame rate

Browse Source
This commit is contained in:
Tobias J. Endres 2025-08-16 06:42:42 +02:00
parent 6695ca9f99
commit 5b050dab9c
1 changed files with 11 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
lessons_learned.md
View File

@ -4,7 +4,7 @@ This document captures key insights, challenges, and solutions encountered durin
## 1. Importance of Incremental Testing and Visualization
* **Challenge:** Initial attempts to debug the `HyperionProcessor`'s output were hampered by a lack of clear visual feedback. Printing raw color values (`#RRGGBB`) to the console was not intuitive, and the initial ASCII visualization was difficult to interpret without proper color support or dynamic updates.
* **Challenge:** Initial attempts to debug the `HyperionProcessor`'s output were hampered by a lack of clear visual feedback. Printing raw color values (`#RRGBB`) to the console was not intuitive, and the initial ASCII visualization was difficult to interpret without proper color support or dynamic updates.
* **Solution:** Breaking down the problem into smaller, verifiable steps proved crucial. First, confirming the `WaylandGrabber` and `HyperionGrabber` were correctly capturing and scaling images (via `QLabel` display) isolated the issue to the processing pipeline. Then, visualizing the *intermediate* step of black border detection (showing the cropped image) provided immediate confirmation of that component's functionality.
* **Lesson:** For complex image processing or graphical tasks, robust visual debugging tools that show intermediate steps are invaluable. They allow for quick identification and isolation of issues, significantly accelerating the development process.
@ -75,4 +75,13 @@ This document captures key insights, challenges, and solutions encountered durin
* **Solution:** Implemented a configurable color order mechanism within the `WledClient` to allow specifying the desired output order (e.g., GRB). This involved remapping the color components (Red, Green, Blue) based on the selected order before sending the data to the WLED device.
* **Lesson:** When dealing with external hardware or protocols, it's crucial to account for variations in data formats, such as color order. Providing configurable options for such parameters enhances compatibility and flexibility.
[Commit: d81fe64cc10be17f371b43de992be383c8cd7e7f] - feat: Implement GRB color order for WledClient
[Commit: d81fe64cc10be17f371b43de992be383c8cd7e7f] - feat: Implement GRB color order for WledClient
## 12. Resolving LED Flickering with Increased Frame Rate
* **Challenge:** LEDs exhibited noticeable flickering when controlled by our Hyperion Grabber, despite the WLED device working flawlessly with other control signals. This suggested an issue within our client's implementation rather than the WLED hardware or configuration.
* **Diagnosis:** Analysis of real-time LED control protocols (like DDP used by WLED) indicated that timing and update frequency are critical for stable operation. Our application's `processTimer` was set to a very slow 1 frame per second (1000 ms interval), which is insufficient for smooth LED updates and can lead to perceived flickering as LEDs hold old values for too long between updates.
* **Solution:** Increased the `processTimer` frequency in `main.cpp` from 1000 ms to 33 ms, aiming for approximately 30 frames per second. This significantly improved the update rate of LED colors sent to the WLED device.
* **Lesson:** For real-time LED control applications, a sufficiently high and consistent frame rate is crucial for preventing flickering and ensuring smooth visual transitions.
[Commit: 6695ca9] - feat: Increase HyperionGrabber frame rate to 30 FPS