scottlawsonbc
Control more than 256 LED's with ESP8266
ESP8266 supports a maximum of 256 LEDs. This limitation will be removed in a future update. The Raspberry Pi can use more than 256 LEDs.
Where is the future update? How is it possible to control more than 256 LED's? Which component limits the number of LED's?
I think that current is the limiting factor. I believe you can increase the number of LED's by using a power supply - seen heaps of videos on youtube about it, but have never tried it my self.
The limiting factor is the protocol for communicating with the esp. For every frame, each led has its respective colour indexed by a single byte. This puts the limit at 256.
On Sat, May 26, 2018, 03:40 Phippsy [email protected] wrote:
I think that current is the limiting factor. I believe you can increase the number of LED's by using a power supply - seen heaps of videos on youtube about it, but have never tried it my self.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/scottlawsonbc/audio-reactive-led-strip/issues/150#issuecomment-392229957, or mute the thread https://github.com/notifications/unsubscribe-auth/Ae5azM1tDXIM3U-G2K2d5fCAyQscAlNTks5t2MCNgaJpZM4UOAOs .
This is doable if you're okay with some interpolation from what is on the visualizer to what is on your LED Strip.
On the ESP8266, I remap the number of received input pixels to the number of LEDs on that particular strip. This is intended primary to have one visualizer control multiple strips of different sizes. However, it also means that you're not limited by the 256 LED limit.
While it's for an entirely different codebase, you might check out the code here (look for "Interpolate across our real pixel count" ): https://github.com/rando-calrissian/Vela/blob/master/sonoff/xplg_ws2812.ino
It does mean if your pixel count doesn't match, you get an interpolated value between any two pixels, though.
Anyway, if you're interested in the whole deal, here's the whole repo: https://github.com/rando-calrissian/Vela
@rando-calrissian That's an interesting take. I solved this a different way, I added a bit to the UDP stream for the 100s place.. so instead of pixel#, r, g, b it's pixel#-100s, pixel#, r, g, b then on the receiving end multiply the first bit by 100 and add to the second bit to get your pixel number
Full detail here: https://github.com/scottlawsonbc/audio-reactive-led-strip/issues/200#issuecomment-486053417
Checking out your codebase now, looks nice. I plan on adding some of the MQTT stuff to mine.. I'm just digging around and seeing what's out there and will likely end up rolling my own solution. Cheers
from what I've seen the main problem is actually that it works with 8bit data (char type) and having more than 256 LEDs requires something bigger like uint16_t, the problem there is actually parsing two chars into 16 bits, I have adapted the code in my project but did not test if it works with more than 256 LEDs, for anyone interested, this snippet could help on the embedded side, not sure about needed changes in python though, I reckon that changing the array packing to uint16_t uint_8t uint_8t uint_8t would be enough:
// helper function for transforming 2 chars into 16 bit int
uint16_t unpack_uint16_t(char first, char second) {
return (((uint16_t) second << 8) | first);
}
// ... snip
for(int i = 0; i < len; i+=5) {
packetBuffer[len] = 0;
uint16_t pos = unpack_uint16_t(packetBuffer[i], packetBuffer[i+1]);
pixels.setPixelColor(pos, pixels.Color((uint8_t)packetBuffer[i+2], (uint8_t)packetBuffer[i+3], (uint8_t)packetBuffer[i+4]));
}
// ...
