Skip to content

Conversation

@benjamw
Copy link
Contributor

@benjamw benjamw commented Oct 15, 2025

There was an issue with my setup where the first ~100 lights in my ~500 light string would not twinkle and would stay as the background color.

This fixes that issue on my setup.

AI seems to think that because the hw_random method creates a 32 bit number, when it's combined and truncated, it somehow leaves out a portion of the segment when the segment size is much smaller than 2^32.
Switching to a 16 bit random number fixed it. I'm not sure why, but I've built and tested it, and it works as expected with the same segments as the previously broken one.

Summary by CodeRabbit

  • Refactor
    • Adjusted the Twinkle effect’s internal random generation to a consistent 16-bit source, improving stability and visual variety of sparkle patterns.
    • Slight changes to random sequencing may subtly alter existing Twinkle animations’ appearance; no action required from users.

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Oct 15, 2025

Walkthrough

Changed local PRNG16 in mode_twinkle (wled00/FX.cpp) from type unsigned to uint16_t; seed still initialized from SEGENV.aux1 and updated using 16-bit arithmetic, altering PRNG width but not control flow.

Changes

Cohort / File(s) Summary of Changes
PRNG width change in mode_twinkle
wled00/FX.cpp
Local variable PRNG16 changed from unsigned to uint16_t; initialization from SEGENV.aux1 and update expression (PRNG16 * 2053) + 13849 now operate with 16-bit arithmetic. No control-flow changes.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title Check ✅ Passed The PR title "Fix blank area issue with Twinkle" is fully related to the main objective of the changeset. The pull request aims to resolve a visual bug in the Twinkle effect where approximately the first 100 LEDs out of 500 were not twinkling and remained at the background color. This was fixed by changing the PRNG16 variable type from unsigned to uint16_t to properly handle the 16-bit overflow requirements of the pseudo-random algorithm. The title accurately captures the problem being solved from a user's perspective and clearly identifies both the issue (blank area) and the affected feature (Twinkle effect), making it immediately understandable to someone reviewing the repository history.
Docstring Coverage ✅ Passed Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 3be95a6 and 76bc8ee.

📒 Files selected for processing (1)
  • wled00/FX.cpp (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • wled00/FX.cpp
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (16)
  • GitHub Check: wled_build / Build Environments (usermods)
  • GitHub Check: wled_build / Build Environments (esp32_wrover)
  • GitHub Check: wled_build / Build Environments (esp32_eth)
  • GitHub Check: wled_build / Build Environments (lolin_s2_mini)
  • GitHub Check: wled_build / Build Environments (esp32s3dev_8MB_opi)
  • GitHub Check: wled_build / Build Environments (esp8266_2m_160)
  • GitHub Check: wled_build / Build Environments (esp32s3_4M_qspi)
  • GitHub Check: wled_build / Build Environments (esp32s3dev_16MB_opi)
  • GitHub Check: wled_build / Build Environments (esp01_1m_full_compat)
  • GitHub Check: wled_build / Build Environments (esp32c3dev)
  • GitHub Check: wled_build / Build Environments (esp32dev)
  • GitHub Check: wled_build / Build Environments (esp01_1m_full_160)
  • GitHub Check: wled_build / Build Environments (nodemcuv2_compat)
  • GitHub Check: wled_build / Build Environments (nodemcuv2_160)
  • GitHub Check: wled_build / Build Environments (esp01_1m_full)
  • GitHub Check: wled_build / Build Environments (nodemcuv2)

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@DedeHai
Copy link
Collaborator

DedeHai commented Oct 15, 2025

good call, I wonder how no one noticed this before, this bug was introduced a year ago.
your AI is wrong however. the issue is that PRNG relies on 16bit overflows, so it must be uint16_t
please update and once approved, please cherry pick this PR for 0._15_x a this needs backpporting to 0.15.2 (I can do that if you do not know how)

wled00/FX.cpp Outdated
{
SEGENV.aux0 = 0;
SEGENV.aux1 = hw_random(); //new seed for our PRNG
SEGENV.aux1 = hw_random16(); //new seed for our PRNG (16-bit for better coverage)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is not the issue. please revert.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interestingly, in the 0_15_x branch, the method used here is random16, which I'm assuming is the 16-bit version of random.

I'm not disagreeing with you. PRs should be as small as possible and I have reverted that change.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I noticed because I got conflicts when I was cherry-picking.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was wrong. There is no random or random32 method in the FastLED lib. So random16 was the largest number available.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, I replaced all fastled pseudo random numbers (or almost all) with an implementation that uses the hardware random register that is available in all ESPs giveing almost true random numbers

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very nice! Thanks for the info.

}

unsigned PRNG16 = SEGENV.aux1;
uint16_t PRNG16 = SEGENV.aux1;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is what fixes it.

@benjamw
Copy link
Contributor Author

benjamw commented Oct 17, 2025

Should I just edit this PR to merge into 0_15_x?
Or create a PR for both?

NOPE. That didn't work. I'll create a new PR for that branch.

@benjamw benjamw changed the base branch from main to 0_15_x October 17, 2025 04:28
@benjamw benjamw changed the base branch from 0_15_x to main October 17, 2025 04:28
@DedeHai DedeHai merged commit ca5debe into wled:main Oct 17, 2025
20 checks passed
@netmindz netmindz modified the milestone: 0.15.2 Oct 18, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants