-
Notifications
You must be signed in to change notification settings - Fork 193
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Channel to pixel map issue #1426
Comments
More details... If add two 1-channel null pixels (Start the actual string at channel #3), all pixels act normally except pixel #1 which is inoperative. This happens in all XLights versions, I attempted (2018.56 to current). It appears pixel #1 channel #1 is lost. It did originally work most of the Christmas season. Hope that helps. Thanks. |
You are going to need to share a lot more for us to do anything with this. |
Is this test mode? Is this scheduler? |
New to this world. My work around satisfies me. However, I'm willing to give you whatever details you wish. I used test mode channel by channel. Pixel 1 (absolute pixel address #1 only) can't produce red in Xlights (test mode or with sequences). Channel 3 test shows up as red on Pixel #2 (and then on and on). Pixel #1 appears to only use 2 channels. The anomaly appears regardless of the string I test. Pixel #1 can produce red when I test directly with the minleon controller. DDP or Artnet produce the same result. The controller is not E1.31. |
Can you package your logs (tools menu) and attach them so we can see how it is configured. Most likely this is a config issue on your hardware. |
This is the simple config that I tried to isolate the problem with... This works with my hardware except pixel #1. I would not even raise the issue except it worked before and now it doesn't. |
Since none of us have access to minleon controllers, you're likely going to have to do quite a bit of work to figure out what's happening. The starting point is likely to find the last version of xLights that it DOES work with (and thus the first version it doesn't). Without that, there is likely no way we'll be able to provide much help at all. |
Understood. Thanks. |
The next step beyond that would be to get Wireshark captures of the first DDP packets for each of the two versions. Finally, one thing you could try: in the DDP setup, turn off the "Keep Channel Numbers" checkbox and see if that changes anything. |
This is not a big enough issue to bring in Wireshark. I tried numerous Xlights versions that were known to work. They do not work either. Turning off "Keep Channel Numbers" checkbox reproduces the anomaly. Since it's 1 pixel at the beginning of a string I can easily compensate. I believe you are right and it's a hardware issue. There's almost no user control of the minleon config (protocol and lights only for DDP). I do have an inquiry into minleon, maybe they will respond. Thanks for the time. Your software is awesome. |
Added DDP contoller (minleon WEC). Testing a simple RGB string... Pixel #1 channel #1 tests green, pixel #1 channel #2 test blue, pixel #1 channel #3 jumps to pixel #2 and tests red. The issue cascades down the string. So, can't make red on pixel #1 and grouping is incorrect.
The issue cropped up after an update prior to that all worked as expected. I can't isolate whether it's software or hardware.
Using the minleon controller interface pixel #1 can make red.
The text was updated successfully, but these errors were encountered: