Open BenoitAnastay opened 4 years ago
I'd be open to considering this if we can get a confirmation that it doesn't cause any issues for the more widely used use case which is < 256 LEDs. Is anyone else able to test this?
@joeybab3 If I rember it's just using a uint 16 instead of an uint 8
Im trying this with 300 Leds on an esp8266 and instead of using all 300 the Scroll effct stops at 256 and on the other side when it reaches LED number 0 it changes direction and scrolls back in direction where it comes from 44 LEDs. Looks like that: +++++LR+++++ (+= LED Off; L=Leftside scroll effect; R=Rightside scroll effect) ++++L++R++++ +++L++++R+++ (last LEDs never light up on right side) R+L+++++++++ (scroll effect that disappeard on right side shows up at the left side) +A+++++++++ (and goes backwards [here both scroll effects are at same spot]) LR++++++++++
Oups no forgot to update the INO file
@HerbertHorst the INO for the esp8266 was updated and it doensn't seem to be an issue with the ESP what you have sound like a integer overflow can you check how you are calculating the LED index in your INO ?
those lines
packetBuffer[len] = 0;
N = ((packetBuffer[i] << 8) + packetBuffer[i + 1]);
RgbColor pixel((uint8_t)packetBuffer[i+2], (uint8_t)packetBuffer[i+3], (uint8_t)packetBuffer[i+4]);//color
ledstrip.SetPixelColor(N, pixel);//N is the pixel number
Sound like in you code you have N = packetBuffer[i+1]
To explai a bit can only contain 8bit b1111111 is xFF (255), 256 is b100000000 x100 If you read only the 8 bits on the right the N value become 0 when the sent index il 256
To go higher of the 255 limit we had to use uin16 2 byte the first byte withe the lefts ones and the second with the right ones so if the value is 300 you will have the uint b100101100
To encode that on two uint 8 we shift 8 bits the right so it become b1 the b00101100 are kida out So you got your first byte wich is x01 and the second you just keep the 8 bits on the right b00101100 (44)
Then you receive both, you shift b1 << 8 it becomes 256 and you adition b00101100 (44) and 256+44=300
It's just cutting the binary string in two and recombing it because you can only handle 8bit at time
I double checked that my ESP is flashed with the right code and also not broken (minimizing LED count function proberly so it really flashes). Im very new to python and this Project so im not sure if the following that I checked make sense. In led.py strandtest part I added some hardcoded LEDs at position 280... and they also light up at the beginning instead of the end of the stripe, but no exception that it is out of bound. So I gues the led.py is not the problem. But I also updated my 'ws2812_controller_esp8266.ino' file like the one shown in this commit Raise limits. The only things I changed are Num_LEDS and my Wifi settings. Is there a way for me to check that my LED stripe isn't brocken? (dunno if this is possible in a way that causes this error. I never saw my LED stripe lighten Up the Last LEDs because this is the first project im trying to use it for). Also im very new to github community and if this is the wrong place for this questions I apologise and ask for advise.
@HerbertHorst It's not your strip it's really an issue with N value
Can you add this to your code after ledstrip.SetPixelColor(N, pixel);
and give me the result ?
Serial.println();
Serial.print("N :")
Serial.print(N, BIN)
Serial.print("\t p1 :")
Serial.print(packetBuffer[i], BIN)
Serial.print("\t p2 :")
Serial.print(packetBuffer[i +1], BIN)
Serial.print("\t p1+p2 :")
Serial.print(((packetBuffer[i] << 8) + packetBuffer[i + 1]), BIN)
@BenoitAnastay Here the output after adding the few lines and running led.py (strandtest) Seriel Print.txt
@HerbertHorst
23:35:09.122 -> N :11111111 p1 :0 p2 :11111111 p1+p2 :11111111
23:35:09.157 -> N :00000000 p1 :1 p2 :00000000 p1+p2 :100000000
Ok thanks for the report, I had forgot to change N to uint16, it was receiving the correct data stream but there was an overflow on the N variabla.
It's now fixed, checkout the last commit https://github.com/scottlawsonbc/audio-reactive-led-strip/pull/254/commits/12643245c4a738dd2af0976edf5ddd263c87937d
I coded the LED id on two bytes, I'm able to drive 576 leds with my ESP8266 lag free (I dont have more leds to test)
For my personal usage I also change the number of update per packet and the buffer size but this PR is the minimal requirement tu use more LEDs