Sending data to pixels over 8 bundled (data) wires

Yes, pixels regenerate the data line and so using a null pixel is electrically is no different from using an F-Amp, Line Buffer chip or level shifter, however it does require it to be catered for in software, meaning you do need to let the system know that it's there, unlike the former options.
 
Skymaster said:
Yes, pixels regenerate the data line and so using a null pixel is electrically is no different from using an F-Amp, Line Buffer chip or level shifter, however it does require it to be catered for in software, meaning you do need to let the system know that it's there, unlike the former options.
Click to expand...
I believe that WLED has a setting for this (skip 1st LED) which is very useful.
 
I have an update.

I am no longer trying to send the data over a UTP cable. I have scrapped the idea of using Esps and I have purchased a Kulp 32A-B. I have replaced 2 runs of the cheap retic wire from the controller to the first pixel with an 18AWG hookup wire.

The wire run from the controller to the first pixel is about 4m and each run controls 400 pixels each.

9 times out of 10 it works flawlessly. However, when most of the pixels are active, I get flickering as well as inverting colours. So it shows the correct effects and colours but then it flickers or the colours invert. I.e. red sometimes changes to green. And yellow can change to blue. I am testing this with the fire effect on xlights with snow rising like smoke. I have tested the Butterfly effect and have similar results.

I don't see what I am doing wrong. Does anyone know what my problem maybe?

Thank you. Please let me know if you would like pictures or videos of the setup.
 
Could you remind me, are you using 5V or 12V pixels?

I have always suspected this was an issue with the data, V+, and V- voltages changing in relation to each other as the current changes and resistance causes the voltage to increase/decrease.

Switching or ramping full white is the fastest way to test this. If it flickers or locks you'll find out quickly.

This is why the null pixel or f amp was suggested. At one point it sounded like it was helping? Ought to be easy to add more and see if it helps. Some diagram might show the pixel load and wire lengths, which would tell where it might go, or just try a few places. Trial and error works for me.
 
corfoto4 said:
...
9 times out of 10 it works flawlessly. However, when most of the pixels are active, I get flickering as well as ...
Click to expand...
This is an indication that voltage drop in the V- or GND pixel wiring is causing the Data Signal to lose its reference (to the V- wire).

As current in the V+ and V- wires increase either due to more pixels being illuminated and/or higher drive levels, a greater voltage is developed in both the V+ and V- wires. The Data wire voltage due to its extremely low current stays very close to the controller's, F-Amp's, or previous pixel's output voltage, whichever one of those it may be. The developed voltages in the V+ and V- wires are loosely called voltage drop but technically, Voltage Drop is in the V+ wire as at the pixel the voltage drops from the supply (generally the reference point). Voltage in the V- rises above the supply's reference point. Essentially, Voltage Drop in the V+ and Voltage Rise in the V-. Voltage Rise as just mentioned de-stabilizes the Data signal from the controller to the first pixel.

I re-read the thread to refresh my memory a bit. While not specifically stated, 5 Volts is mentioned numerous times so I assume you are using 5 Volt pixels. If your design of the strip has not changed, from the graphic above it seems you have 8 strips of 100 pixels power injected at the beginning, middle, and end. I see nothing wrong with the power injection other than wires look small. I've no comment on anything else in the graphics as that likely changed with the Kulp controller.

While there could be Data signal interference, I'm more inclined to suspect voltage drop. I would suggest illuminating a single string (100 pixels) a solid single color (R, G, or B) and measure the voltage at 4 points; at the supply, string beginning, string middle, and string end. If all 4 voltages look all right, say 4.5 Volts or higher add another 100 pixels and again measure the voltages at the 7 points; (supply, both string beginnings/middles/ends). Goal is to determine if voltage drop is a problem and where does it begin.
 
Thank you for your suggestions. I was able to find a fix!

I originally had all of the pixels powered through a power box with the Kulp controller on its own power supply (separate to the power box). I then connected a ground wire between the Kulp PSU and the power box to create a common ground for the data flow to all pixels. Then to send data to the pixels, I ran a single data cable from the controller to the lights (data only. No power was provided to the lights by the Kulp).

Although the circuits were complete and I was able to get results, it was unreliable. I changed the data wire to 18AWG instead of the thin retic wire which had minimal improvement. That was when I posted my last message on the forums. Since then, I did a lot of research and looked at examples people had working on YouTube. And all of them were taking power output from the Kulp ports as well as data. So I decided to try that.

Long story short, by running an extra ground wire to the pixels from the Kulp, I was able to get the tree to work flawlessly! For the ground wire, I am still using the cheap retic wire because it has almost no current running through it and I just need a way to connect from the Kulp to the pixels.

My thoughts on why this solution worked and my previous attempts did not:
For any electrical circuit, there must be a path for the electricity to flow from positive to negative or vice versa. In my first situation, the data was able to travel because I had a common ground that was connected to my controller. Why did it not work? Because WS2811 data is 'fragile.' Meaning that not much is required to change or affect the data which results in issues such as flickering or having odd colours as I have mentioned before. For the data to travel from the Kulp --> pixels --> Kulp again, it had to go to the pixels, back through the power box (powering the whole tree), through fuses, through a single wire to another power supply, and finally back to the Kulp. Knowing that the ground wire is shared along this route with devices that were drawing more current, affected the flow of the electrical connection. And when the electrical current is affected, the WS2811 data is affected which runs to the pixels.

So, running an extra ground cable to the pixels from the Kulp ports allows the data circuit to send the data and have a much easier and faster path back to the Kulp without having to compete with other devices drawing more current. Thus, better results are achieved.

Before I was only able to send the data over a 2m cable at most before I had issues, but now I am sending it over 5m with no issues at all.
Hopefully what I have explained above makes sense. I can't believe how simple the fix was!

Thank you to everyone who helped me out. I can finally take a sigh of relief. I have also attached links to 2 videos of the tree before and after the fix below.

Before:

View: https://youtu.be/WuSMWOw7Ohs


After:

View: https://youtu.be/lKKNNLBo8J8
 
Spot on. Well done. Voltage drop (or rise) on the ground to the pixels will definitely cause some funky things to happen. An extra, direct conductor along with your data is always worthwhile.
This was something we discussed at the Sydney mini - always run a Pos and Neg from your PSU, and always run a Data & Neg from your controller, joining the negs at the LEDs - even when connected together at the power supply/controller end. Whilst it appears to be a complete path, other things at play can cause these issues you were seeing.


PS: those are some pretty funky effects you've got going there. Love them!
 
@corfoto4 You're welcome for the help/suggestions.

The problems with the original setup was almost certainly voltage drop in the wires from the power box to the pixel strings. While running a single Data without a V+ and V- wire from the controller is possible (I wouldn't recommend doing so however) it heavily relies on a very low voltage drop in the wiring between the power source and the pixel strings. As you indicated further in your post, the first pixel's Data reference was back to the power box and then on to the controller.

Whether one powers pixel strings through the controller or not is personal preference. Powering via the controller is I think more common. My design practice is no pixel power from the controller, Data only. However I include the V- from the controller and 'up-size' the power injection wiring (generally 14 AWG currently and I avoid CCA). Close attention is paid to possible voltage drops which may destabilize the Data signal and because there is a V- 'ground loop' from supply to pixel to controller to supply that minimal V- current occurs from the controller to the pixel.

Doesn't matter much but with the design structure I am presently using I have some cables close to 10 meter lengths with no problems. Essentially minimize voltage drops and maintain a good V- reference for the Data signal.

As @Skymaster mentioned, nice effects. Definitely cool. And always run a V- with the Data from the controller. The V+ is optional.
 
You must log in or register to reply here.
Back
Top