Closed sunnstix closed 3 years ago
Maybe I’m missing something here but how is what you are saying different from how it’s implemented?
Each frame contains 8 bits for each color to allow for the values 0-255 (2^8 = 256), so we end up with 24 bits for those colors plus 8 bits for index (allowing only 256 leds), which leaves us with…
8+8+8+8 = 32 bits?
Whoops - misread some of the source code, good catch. This being said, as a side note for anyone who may want a solution for addressing more LEDs in their code (as opposed to 256) while maintaining the network traffic, I found that a very simple solution was rather dropping bits from the 8 bit color representation and rescaling them on the Arduino (7+7+7+11). For my own project, I wrote a funky little function to scale back the bit representation of colors according to the number of light regions (scaled to actually LEDs on the Arduino) I wanted to address.
I was personally writing my own implementation of this project using my RasPi's serial bus with multiple Arduino Unos and Megas and I briefly considered reducing the amount of traffic through the Serial bus and it was almost instantly obvious to me to make the switch from 32 bit integers to 8 bit unsigned integers for the RGBs and 16 bit unsigned integers for the indices seeing that (as far as I am aware) there would be no reason any of the RGB values should ever fall outside of the 0-255 range and I sincerely doubt there would be any significant use case with more than 65,536 LEDs. Now I know that this is an insignificant improvement to internal memory usage for the light processing but reducing the number of packets sent through the network for the esp8266 design by almost 1/3 should be a decent improvement I would think? Food for thought and a fairly simple solution for anyone struggling with network latency / packet loss.