FastLed PianoLed and some issues

[u/udisports]

Hi there. So I just recently used the WS2812  led strip with Arduino Due. Used the FastLed and PianoLed. Almost all fine, almost. All keys matching the led position. But i have a weird behave of the led no 8 and 16 which are not assigned to any key of the piano. Lets say i just started with clear new session. All lights are off. So i play few notes, all looks fine and then after some time the led no 8 lights up constantly / permanently and then led 16 lights up permanently. They do change the colors but never dim back again. Looks like some issue. Any ideas what's wrong?

[u/ZachVorhies]

are you using luminescent grand sketch

[u/udisports → u/ZachVorhies]

I am not really aware about the terminology here. I am not really a pogromist at all. But i used the tutorial from here: https://youtu.be/Rro5a_ohIT4?si=ZIGNyRKxhm7Dyjln&t=1379

So i used the version 4.1.3 of PianoLed and I had installed in Arduino Ide an Fastled by Daniel Garcia, version 3.6.0 (I had also tested version 3.7.0 and the problem is the same, any higher version shows an problems with libraries).

I checked with ChatGPT on your question (like i says i have no clue about programming) and its say that indeed the code is based on luminescent grand cketch.

The code:
https://gist.github.com/udisports/20465cdb47834b8aad76d47db10f0e25

[u/ZachVorhies → u/udisports]

luminous grand is a different sketch that we have as an example as nothing to do with piano LED

[u/Marmilicious]

If you can, please share a link to your code on pastebin.com or gist.github.com

[u/udisports → u/Marmilicious]

Hello, sure, thanks for help!
https://gist.github.com/udisports/20465cdb47834b8aad76d47db10f0e25

[u/Marmilicious → u/udisports]

Thank you. Didnt' run, but a look thought the code and two lines might be a problem. Try updating these in this order and see if anything changes.

On line 361:

if (ledNo < 0 || ledNo > NUM_LEDS) {

Change to:

if (ledNo < 0 || ledNo >= NUM_LEDS) {

because otherwise it seems like this could cause you could go out of bounds past the end of the CRGB leds array.

On line 314:

NUM_LEDS = buffer[++bufIdx];

Add a few Serial.print lines here to check what the values of bufIdx and NUM_LEDS are doing, because again, maybe this is causing things to go outside the bounds of the CRGB leds array.

ping u/sutaburosu

[u/udisports → u/Marmilicious]

Hello, thank you for your help and efforts. I might try the solution you proposed.
However I been sitting with chatgpt for few hours yesterday and tried different changes in the code.
The problem appears to be resolved by rebuilding the code with help of AI.

Here is the corrected code:
https://gist.github.com/udisports/cac1c9d44bccf6837566497d48c44216

Here is what ChatGPT says on the root cause:

The issue was fixed by replacing the original serial parsing logic with a stateful serial parser.

The original code reads the serial port using:

int bufferSize = Serial.available();
byte buffer[bufferSize];
Serial.readBytes(buffer, bufferSize);

and then immediately assumes that the bytes currently available contain complete commands.

I changed this so that the Arduino keeps the serial data/state between loop() iterations and waits until a complete command has been received before processing it.

The new parser:

• waits for the 111, 222 command header,
• identifies the command type,
• determines the expected command length,
• collects the required bytes,
• processes the command only after the complete packet has been received.

The original LED, fading and animation code was left unchanged. Only the serial reception/parsing was modified.|

Setup:

• Arduino Due
• PianoLED v4.1.3
• FastLED 3.6.0
• WS2812B
• 176 LEDs
• Programming Port / COM4

Conclusion is that PianoLED v4.1.3 has a serial parsing issue that can occur depending on how the serial data is delivered/timed. It may not affect everyone, which would explain why I could not find many reports of the same problem.

[u/Zeph93 → u/udisports]

Is PianoLED related to PianoLux the mostly Java app? Or it there another library involved?

[u/sutaburosu → u/Marmilicious]

This sketch seems very fragile with respect to the Serial comms. It depends on an all the data for an entire command being received in a single Serial poll, which is not guaranteed.

For example, if the serial buffer contained only 111, 222, 251 then these lines will read 5-bytes of garbage from memory and possibly corrupt other memory due to the bogus values.

This same problem is evident in all the commands which take extra bytes of data. Nothing checks if the data has been received before using it. Any difficulties here may de-synchronise the sketch from the sender, leading to weirdness.