You are welcome to add an entry to the CHANGELOG.md as well

Built artifacts for commit 1e770a3

Firmware

• Ultra APP DFU Package
• Ultra binaries
• Lite APP DFU Package
• Lite binaries

Client

• Linux
• macOS
• Windows

Probably need to turn off the single red indicator, not sure.

Im not sold on this being hardcoded. Either pitch it to me ( ;) ) or maybe make it a setting? (preffered?)

Good point. I realized that the batt check (via button) currently uses a cyan monotonic scale. I've implemented the charging progress using a similar 8-led scale for consistency, but with added color coding (Red -> Yellow -> Cyan -> Green).

My question to you: should we standardize this color-coded scale across the entire firmware (including the manual battery check), or do you prefer to keep the progress bars monotonic?
I'm all for color coding, but the last word is yours.
As for the color breathing during charging, it seems a bit of a placeholder.
If you choose color coding, I planned to add a smooth color change (Red -> ... -> Green).

What do you think about it?

Color coding does sound sensible and might be worth switching that on the button action then too.

Idk, maybe @LupusE has an opinion there too.

And while the color breathing during charging does indeed seem like a bit of a placeholder, it shows that smthngs happening and thats good enough for most people id say?

Maybe a switch between "no lights / indicator, breathing, charge status" might be useful as I could see people wanting to disable that as not to be annoying in a dark room?

But good point indeed.

Okay, I haven't understood the colour changing part in the fist place. This sounds like a good change.

Let me test it this week. From the source it looks good.

Hello everybody.

One more thing to mention: after testing this build for a week on my chinese hardware clone, I noticed some minor 'oscillation' at the threshold points. Occasionally, the indicator might jump back to the previous step for a minute or two before finally stabilizing on the higher value. This is likely due to ADC noise or voltage fluctuations at the transition boundary, which can be quite common on these clones.

To make it rock-solid, we would eventually need to implement hysteresis, i think. Ideally, I’d love to verify this on the original Chameleon Ultra to see if its hardware handles it better, but unfortunately, I don't have the budget for the original device at the moment.

Regarding @GameTec-live's suggestion about adding a toggle in the settings: I've implemented the core logic and I'm open to making it a selectable mode on the firmware side. However, I must clarify that I am not an Android developer, so I won't be able to update the mobile client myself. I can provide the backend, but the GUI implementation would need to be picked up by someone else.

Also, as a side note: I’ve recently sideloaded (via adb) the full Android client onto my Mobvoi TicWatch Pro 3 (Wear OS 3.5). The backend works perfectly, but the UI is completely unusable (microscopic buttons, cropped text and so on). Since Flipper Zero already has a dedicated Wear OS app, it would be true amazing to see a similar companion for the Chameleon in the future. If anyone decides to pick this up, I’d be happy to help with usability testing and feedback on real hardware.

@LupusE, as you test it this week, let me know if you find this 'flickering' acceptable for the initial PR or if you’d prefer to see a hysteresis implementation included.

P.S. Symmetric animation is cool (:

I am at 7 LED now, I wait until it got to 8, to see the switch state at the original CU.

We've merged #363 lately. Here some variables got renamed, in parts of your PR.
For example: https://github.com/RfidResearchGroup/ChameleonUltra/pull/363/changes#diff-473734bda477c442ee51b271d9a95c4d973db82ab00ca9f18870ddd2e7966706L48-R49

You have a better overview about your code than I have. Could you adopt the latest changes? Else I don't see any blocker at the first sight.
I come back to you when I see the switch to the next level.

After GameTec_live showed me the build runs in an error, I reviewed my review ...
it seems I tested locally at the state before, maybe because I wanted to see if the flickering appears on my original RRG CU.. Sorry for that.

It seems the variables line 40 and 41 are copied and set again in 837/838. This is easy to delete.

static uint8_t battery_display_prev_leds_lit = 0;
static uint8_t battery_display_prev_percentage = 101; // Initialize to impossible value to force first update

Than line 38 shows up as unused:

static uint8_t rgb_marquee_usb_idle_color = RGB_RED;

If I comment this line, it gets ugly with the dependencies ...
Too much to check for me right now, time for bed. But it needs a major review, before we can merge it.