BRT Community

Hi Rudolph,

Yes, that's correct, I found the issue and fixed it, so will work on both your accounts.


thanks

BRT Community Admin

Oh, this is what you meant by "I have solved it", now I can access the board with this account as well.

Interesting, with this test-account I can indeed see the board. wtf? 

Hi Rudolph,

I think I have solved it, please try and access the Board now.


thanks

BRT Community Admin

What's happening with BT822 ?

I tried to register a test account and it took me 20+ attempts to get past that captcha.
Ok, now I have to wait for approval.

I am using FireFox.
So I just logged in with this account using Edge - same thing, the board only shows when I am not logged in.
And I see the board when I log out in FireFox, it vanishes as soon as I log back in.

Hi Rudolph,

My colleague has logged in who does not have admin rights is able to view and post in Discussion - MCU. So I`m not sure what's happening with your account.

Can you create a test user name and see if you can view it?

thanks

BRT Community Admin

With the update to the newer board software version, the board "Discussion - MCU" still does not show when you are logged in.
I only know that it does exist from checking the forum at work.
And it shows up when I open a private window in firefox.

That also means that there is no way to post in that board.
Like for example pointing out that the download link for the new ESE 5.0.1 is linking to the wrong file.
Edit: and I just downloaded and installed it now

Hello,

we'd like to offer the following explanations and suggestions:
1. Mismatch in RGB Bit Depth (OUTBITS Setting)
Some LCD panels, although labeled as supporting RGB888 (24-bit), may internally operate using RGB666 (18-bit). If the EVE IC's output bit setting does not match the actual bit depth supported by the display, it can lead to color distortion or visual artifacts such as noise lines.
Suggestion:
Please verify your LCD panel's actual color depth and ensure that the REG_OUTBITS register is configured appropriately during initialization to match the panel.

2. Avoid Using CMD_GRADIENT for Red-Sensitive Precision Areas
CMD_GRADIENT uses internal linear interpolation. In high-contrast or precision-sensitive areas—such as gradients involving red—it is prone to rounding errors that may cause visible banding or fine lines.
Suggestion:
Consider using a custom gradient image (bitmap) instead, and load it into RAM or flash to ensure consistent rendering and avoid interpolation artifacts.

3. Fine-Tune the Gradient End Color & Refresh the Cache
Using red values like 0xFF0000 (full red) can fall on edge-case transitions in RGB666 mode, leading to visual inconsistencies.
Suggestion:
Try slightly dimming the gradient end color—for example, use 0xF00000 instead of 0xFF0000—and observe whether the black line still appears.
Also, try calling CMD_CLEARCACHE() to clear the on-chip bitmap cache, which may help eliminate any residual rendering artifacts.

Best Regards,
BRT Community

Was this ever solved? I am having the same issue when drawing a vertical gradient from orange to red, there is always a thin black line towards the red end but not on any other colors across any of the other gradients I have done. Turns out this issue is across gradients and RECTS that use the RED color