I just uploaded the 0.10.2 to a fresh '8266 and have been testing my new HolidayCoro props with it. To simplify my wiring, I just daisy-chained several props together and with the last one ran over the 1-universe limit of pixels (150 before, 235 now). I didn’t notice it at first but the pixel exactly at the 171’st location is dark. I have my xLights set up for 510 channel universes as I have used in the past. I changed it as a test to 512, but that ended up just removing one pixel from the data stream and shifting the rest of the pixels one location forward (so the 171st pixel’s data came from pixel 172, 172 from 173, etc)… which then keeps the 171st pixel from being dark but then the last pixel is dark instead. Any suggestions on this? The WLED code without the E1.31 works fine across the 170 pixel barrier, so it is somewhere in the E1.31 handling. Anybody else notice this issue with the 0.10.2?
Hello
The same thing happened with Arnet, but with the previous version.
The new version is perfect.
What I can’t know is if in arnet mode the maximum is 500 LEDs.
With scan reach 820 LEDs without problems.
I have to start modifying the code.
Excuse me, I use google translator.
So it’s not just me with this problem. Did you figure out how to fix this problem or is it a software bug?
Thank you for reporting, I could indeed reproduce the issue using xLights!
After 2hrs of troubleshooting, managed to fix the issue. It was an off-by-one error that actually caused the last LED of the first universe (170th) to stay unlit.
The strange part is that this didn’t happen with LedFX (my go-to E1.31 testing client for its simplicity), despite it being set up for 510 channels as well.
In any case, the issue is fixed now in latest master!
I just installed WLED on my esp8266 and I have a similar, if not exactly the same problem. I’m using XLights to control my LEDs. They all work except for the 1st LED on the 2nd universe. (It could also be the last LED on the first universe)
I’m having the exact same issue as well with the 170th, 340th and 510th all unlit in my string of 578 when using xlights. Running a new setup completely with wled 0.10.2 - the latest release.
As per Aircoookie’s post above, this was an issue that should have been fixed in the lastest MASTER. The latest RELEASE is still previous to this fix, so you would need to pull down the master and compile it yourself, unless I misunderstood his post.
Thanks @samstreak - I didn’t undestand that the MASTER wasn’t the latest release lol. Not sure how to pull down and compile myself, so I guess I’ll have to figure that out now.
I have the same issue. Besides that, if i change the universe size the next universe starts only after the led 170.
For example: I have 13 strips with 60 leds each one. All strips are connected in series.
With a 510 channel universe, I need 5 universes to cover all the leds. The last led of each universe stays black.
If I reduce the universe to 180 channels, the leds from 1 to 60 work ok, between 61 and 170 stay black. From 171 to 230 work ok, between 231 to 340 stay black.
I didn’t see the code yet, but a I guess the 510 number could be “locked” in some part of the code.
There would need to be some sort of Universe Size option added to WLED, as it is apparently just assuming the ‘full’ size universe of 510 (technically full universe is 512, but nearest divide by three for RGB is 510 -> 170)
I think that I have the same issue. I am trying to get Jinx! working with WLED using E1.31. I have a 16x16 matrix working with WLED. In Jinx! I set up two universes. The first universe is 10x16, 160 pixels, 480 channels. The second is 6x16, 96 pixels, 288 channels. The first 10 pixels in the second universe remain dark. So it seems that the pixels in the second universe only work once the 480 channels in the first universe plus 30 channels in the second universe (i.e. total 510) is exceeded.
Am I correct in thinking that this is the same issue and that it will be remedied in some future release as mentioned above?
Thanks.
I am assuming you are using one wled controller?
I believ to do what you want you need to have all channels continuous. Why did you create a break?
I believ If you wish to have the matrix separated like this you will need to install dummy pixels in between and tell jinx don’t light them. But it is easier just to make the channels continuous.
There is a limit of 512 channels per universe both in E1.31 and Arc-Net. Practically this is 510 channels since each pixel uses 3 channels so 170 pixels max. With 16x16 = 256 pixels in the matrix there is no choice but to have at least 2 universes. My first universe is 160 pixels which is the nearest complete column scenario below 170. I don’t understand your comment about dummy pixels.
You don’t need to stop at 160 pixels. Keep going till 170, then start the next universe.
I am
Not familiar with jinx but your channels need to be continuous. Your matrix behavior aligns with your definition somewhere being incorrect.
So take 10 pixels from your 96 and move to your first universe.
Thank you @Thedannymullen !!! I had tried that using Jinx!'s Fast Patch but it would not properly populate the remaining pixels. Inspired by your answer I manually configured the remaining 6 pixels in the partially completed column then used Fast Patch for the remaining 5 columns and it worked. Thanks so much.