This is the best explanation of this issue I have seen! Thanks for the video! Just a note for those of us that use Vixen and FPP. Make sure if you have a computer running Vixen on the same network as FPP , That Vixen is completely closed while the show is running on FPP. If Vixen is open the lights will constantly flicker. This one bit me a few years ago, was pulling my hair out, til i noticed that it only happened while i had the program open.
Thanks, I appreciate that! The flashing lights issue is the most frustrating problem and it's a struggle sometimes to know where to start troubleshooting.
Thanks for the great video. I found another flickering source. I set up my megatree and a few props through a differential receiver just like last year but this year it flickered. After about an hour of troubleshooting wires and such, I discovered that I had the light switch on xLights turned on at the same time I was trying to run the show on xScheduler. Once I turned it off, flickering disappeared. Whew. Glad it was an easy fix. But duh!!
Great video. I found it after being at my wits end trying to resolve a flickering problem with BTS Lighting WS2814 FCOB 12V strips. I've installed about a half-dozen different LED projects with other strips but these ones seem to be particularly susceptible to flickering. I say this because I haven't needed a level shifter at all in my other projects. Level shifters are definitely recommended with this brand of strip. Anyway, my last project wouldn't stop flickering, even with a level shifter. As I mentioned, I was at wits end trying to resolve it. This video prompted me to look at the buck converter I was using to power the ESP32 and the level shifter circuit. When I powered the ESP32 with a micro USB cable, the flickering stopped. This was repeatable. I swapped in a different buck converter to see if it was just that board but the new one did the same thing. I have used that brand of buck converter (LM2596) quite successfully in other projects but there was some bad mojo with the components on this last one,
I've not used buck converters in my builds, but I bet they give off a lot of electrical interference. If you can keep the converter as far away from your data line as possible that may help. Also just a shot in the dark but you could try a makeshift faraday cage by surrounding the converter with some tin foil
@@BytesOfPi I've used buck converters quite successfully with some types of strips. Muzata 3535, for instance. These FCOB strips are quite sensitive, however. Clever idea on the home-made faraday cage. I tried it but must have shorted out a couple of contacts because smoke started emanating from one of the components. I think I fried the ESP32 board because I can no longer connect to it. No biggie, I have spares and they are easy to program. Before introducing tin foil into your enclosure, ensure you have all of the contact points correctly isolated!
Hey, I'm using a WS2811 in my current project and it won't stop flickering, I'm using the ESP32 as a controller too, do you have any idea why this is happening, thanks in advance.
@@omarelabasery7101 Ensure that one of the ground pins from ESP32 is connected to the neutral from your power source. If that is the case, you may need to incorporate a level shifter into your circuit.
Found this when I was looking for why my ESP32 always flickers the W2812B even when I switched the library and different ESP. Turns out that I didn't have a common ground which ultimately fixed my issue. Without it, the LEDs were flickering like a christmas tree and never stayed the same color or turned off properly :)
If your into exploring rabbit holes of electrical engineering then there is a very good old video "Tektronix - Transmission Lines" which explains why you see these problems in cables at high speed. Wire thickness is not necessary the answer, correct line impedance is very important.
Agreed. There are many videos and documentation out there that go to great lengths calculating the right impedance for a particular circuit. There are many different tools that can be brought to bear to analyze and address similar kinds of issues including oscilloscopes, varying levels of resistors, etc. For those that have passion for electrical engineering, definitely dig deeper. I started to see a lot of questions by people wanting to troubleshoot their particular issues with flickering but less interested in the technical aspects. The goal of the video was a quick, less technical (and hopefully less intimidating) explanation for troubleshooting steps to take that are easily accessible to anyone in the hobby and why. Choosing to spring for a thicker gauge of wire when connecting your controller at a distance from your LEDs is not a silver bullet for all flickering woes, but it is a rule of thumb the thicker a wire is, the less impedance is caused.
Hi Bytes of Pi do you sell your WT32 ETH01 PCB mount? I've been using this controller a lot lately but i'm a software guy and not very skilled at hardware and electronics stuff. So I spend a lot of time fumbling with wires and connections.... I really enjoy your videos btw, i've learnt a lot. Thanks for sharing your knowledge:)
Hey Jayson! I'm a software guy myself so I totally understand the hesitation. I would share the Gerber file with you so you could build your own through vendors like JLCPCB or PCBWay, but my first pass wasn't so successful. It works but the traces for the data to the level shifter were so close together they started to corrupt the signal between each other. I can get the farthest 2 mapped data pins to work, but adding a third pin makes the lights flicker. They cost enough that I've not tried a second time, but I think I would like to perfect embedding a NE555 time delay switch components and try out one of the WLED approved signal boosters. May even make for a good video. 😁
I think this also may be my issue as I'm using two power supplies and the pixels that are getting the flickering and random colors are on the separate PSU. If not, might be bad bulb because they become faulty colors after the same pixel...
Flickering led is a big issue when using low cost system. There is a reason the Pro Industry use RJ45-RJ45 cables from controller to a signal repeater (300m) 1 repeater for each pixel strip, the downside is that 1 Repeater cost 90$ each !
The Repeaters are differential signal repeaters which is different from the direct signal pixels expect.. it's the same signal that Ethernet uses to go long distances. But here's the kicker... The differential signal repeaters are physically bigger than a WT32-ETH01 board with Ethernet built in and WLED... So if you have to build an enclosure for a repeater and run CAT5/6... Why not just put an Ethernet enabled WLED controller close to your lights? Gives you the additional functionality of WLED and is much cheaper
5:22 Can I reduce the electrical noise in the datacable by wrapping around a sheath current filter out of Ferrit at the end and beginning of the long cable?
You can definitely give it a shot. I'm not sure of your particular setup, but if there are electrical components near those points it might help. Speaking of sheaths, my last data line was a sheathed coaxial cable I have lying around from the olden days of cable.
@@BytesOfPi Yea I have my ESP32 S3 in a Rack with alot of other gear and powersupply and above the rack is my Piano with all the lightstrips. So the ESP and Cables are around other devices closed in a metal rack. I will try it with the sheath current filter an see if the small higgs of lights every 30-50 sec will be todally removed. ;) I tried everything else of this video. 14AWG Cables, Level Shifter, Ohm Resistors to cleanup the signal, sordered the cables directly and checked with an multimeter all connections and even polarity check for the power outlet and the power supply to put it in in the right polarity (what I do for all devices, yup EU outlets suck) xD Still I have every 30-50 sec a small higgs of flicker for a sec. So this will be my last option I know 😅✌
@@marcusunivers oof.. if it's in a rack with a lot of other equipment, probably a lot to give it the jitters. Is there a way you can turn off everything else in your rack except the lights? If you can turn off everything but your powersource, ESP32 and lights, and get a stable connection, you can isolate your problem. Turn on one thing at a time till you get the jitters again. Also, Is there any way you could shorten the distance between your controllers and the lights? The closer you can get your ESP32 to the lights, the better.
@@BytesOfPi I tried it with the sheath current filter and it worked perfectly. No flicker anymore. 👍 And not really I cant shut down other Equipment in the rack because there are Mic Pres and Interfaces to use my Music Devices while doing Lightshows 😅✌
Good question. I started with the roofline using vinyl J-Channel from Home Depot that matched the color of the eaves and bullet pixels. I used a jig and a drill press to cut holes 2 inches apart. I tried PVC initially for the window outlines, but found the PVC rotated slightly with each hole and I ended up cutting a spiral of holes. The J-Channel worked so well that I ended up using it for the window and door outlines. While it's easy to cut straight holes in J-Channel, the frames are flimsy. J-Channel was great for the roofline. Still using J-Channel for the window frames, but I wouldn't recommend it... If/when I redo it, I might try 3/4 " PVC outlines.
Thanks for the advice, I have a fcob spi rgb ic led strip, I should install the strip far from the controller, unfortunately I have some flickering, I solved the data cable with a resistor, but because of the gnd I still have bad flickering, how can I solve it ?
How far away are you installing the controller from the LEDs? The closer you can get the better. A level shifter is probably the best thing to extend the distance or keeping the data wire separate
Hello, existing videos, exactly what I am looking for as a beginner right now is there a site where I can view your PCB or the schematic (7:47) of it to understand how you work wit the wt32 eth01
Appreciate it, but I haven't tried it out yet and I know the ne555 timer portion isn't vetted out yet. Once I get some time to try it out and have it working reliably in my own boxes, I can share the Gerber file. This was my first try at PCBs and they just came in. I wanted to simplify and clean up a lot of the wiring I have now.
I've bought my level shifters from Amazon, but the reliability of them is sketchy at best. I think that WLED's page is probably your best bet: kno.wled.ge/basics/compatible-hardware/#levelshifters
I have a few videos you can check out on building a controller. A behind the scenes video of our first controllers can be found here: ruclips.net/video/GeJxolPpiE8/видео.html
i have been installing permanent christmas lights on my house ones i designed using ws2811 pixels, i just tied in an additional section in a hurry and connected from the wrong end of the string now none of my pixels work at all i did confirm that the controller is good any suggestions how to fix or did i fry all of them?
That's a tough question. Most likely you did not damage your other strands. If the only thing you did was tie a strand of strings backwards, but you kept ground tied to ground and power to power, then they should all be good. The data goes one way, but doesn't cause damage if you connected them backwards. What usually causes damage is connecting a higher voltage than your strand can accept or touching ground to power. Was the backward strand at the end of your run or at the beginning? Are you assembling it all on the ground or in the air? If you can assemble the pieces on the ground and test them, it's worth it before you hang them up on a permanent installation
I don't believe that the thickness of the data line matters much, as it should not be carrying any current. The only thing that it does is cause a voltage level, and it is most likely driving a MOSFET style input in the chip, so it will carry basically zero current. Thicker won't help in that case. Also, it only drives the next pixel, not the whole strand, as each pixel will regenerate the data line. Thicker matters on current carrying wires however, like data and ground. The best solution is almost always a level shifter.
i have a question for option 4. does that mean i can not run multiple data lines using a cat5 cable? those cables are designed to carry digital signal i thought it should be possible
Do you mean option 3 for wire gauge? Cat5 and cat6 is a touchy subject for a choice of wire when sending data to your lights. There are many people that have used cat5 successfully to send data to their lights. However, when they do successfully do it, they usually have to connect 2/3 of the wires together, essentially raising the gauge of the wire. Cat6 has a leg up on Cat5 with that additional plastic core separating the twisted pairs. That helps reduce the cross talk mentioned in option 4. Cat 5 is four pairs of 24 gauge wire which is extremely thin. I'd say give it a try and use what works best for you. If you run into issues, raising the gauge of wire is just one option to try.
A lot of people don't understand what type of cabling to use for what type of signal. Yes there are a lot in the LED community which use CAT cable for LED data signals (and even power) but this is theoretically wrong but can still work somewhat in reality. "But Ethernet is up to 1Gbps and uses it too so it must be good!" Yes, that's correct but there is exactly the clue (which most don't understand). We're talking about two different kind of signals! "Single Ended" vs "Differential"! LED data signal is something called a "single ended" data signal. So there is a single signal wire which has either a 0 or a 1 (at 5v) on it vs GND. Ethernet signaling is different it uses something called differential signaling where it uses a pair of wires and each has the reverse of the other. So if you have a 1 with +3.3v the other wire will have a 1 with -3.3v (this is a simplified explanation). Because of this method the signal is a lot more robust vs outside interference and can also travel much much further. And well this also explains why Ethernet cables are not suitable for LED data signals, it's not designed to carry single ended signals. Yes, running one through there, potentially with a bit of power (or at least GND) over the other pairs, can work somewhat, it's just not ideal for it, a normal wire pair is much more so. Running multiple signals through there will also undoubtedly cause it to fail after a short distance because of all the signals interfering with each other. Maybe maybe if you ran CAT7 which is PIMF (Pair in Metal Foil) it could work since then they each pair is shielded against the other pair, but it's really just trying to find a solution to using the wrong type of wire. If you want to run data cables, run either a single cable or a dual-cable with data and GND next to each other (using an appropriate resistor). 3-wire cable is fine too like xConnect, etc. Oh and one last thing, some boards like Kulp and Falcon have differential extensions ports and those ARE well suited for Ethernet cables because they use a chip in between to transform the single-ended data signal to differential and then back again at the other end, that's a perfect solution to bridge long long (up to 100m/320ft) distances! Hope that explains it bit the why and how there are so many misconceptions and "it works for me..." out there. :)
@@IntermitTech That's a great explanation and thanks for weighing in Quindor. Just to clarify, the differential signal ports that kulp and falcon provide for distance require differential receivers on the LED side to translate the differential back to single ended. Might as well have a WLED controller with Ethernet jack just taking DDP or E1.31 data close to the LEDs at that point.
@@BytesOfPi no, i mean option 4, lets say i have 4 strips with each one using an independent data line, i thought using a single cat5 cable was enough to get those 4 signals to their strips what you are saying is that it should not be possible, because each data line is affecting in any way the other data lines intermit sama answered my question btw, thanks for answering anyway, it could have been a disaster for me if i did that ahaha
@@IntermitTech oooh it helps a lot, i got this idea because another person, hpwit, used that method or i think he did, to carry his signals to his led panel, i knew it was bad for power but did not thought it was bad for signal as well, so the common 3x18 awg wires are good enough?
Thank you for this video, I ordered my KeeYees 10pcs 4 Channels IIC I2C Logic Level Converter, hopefully it will solve my issue. I have completed my project and I am running into some flickering issues. I used 5v strips which required many power injection but I followed Bill's video/advice as well. I am running my project on a DigQuad using 2 channels. Everything is working fine but sometimes I have flickers (I actually pout together a quick video for beginners like me about the outdoor install), you can have a look towards the end it'll give you an idea of my issue (I recorded 3 different pattern/example). This is the link to my video - ruclips.net/video/bMG79kfk2Ps/видео.html Thanks again for your great videos!!!
Hey, I just watched the video and that is definitely signal flickering. I'm not sure how far your DigiQuad is from the start of your lights, but a signal booster may help. Quindor also has an article about his latest boards and going long distances. If you check near the end of the article he says that There is a built-in 249Ω and 33Ω resistor. By default it uses the 249. However, for longer distances, you can switch to the 33Ω. That may help as well quinled.info/data-signal-cable-conditioning/ Lastly, like the video says make sure your data line isn't near things like power sources other controllers and the neutral wire
@@BytesOfPi Following your advice, I worked on the issue tonight, I had purchased a few data-booster boards so I was able to easily switched from 249 to 33 ohms. It seemed to have fixed the issue... My data cable is longer but I used a bigger gauge and stayed within the parameter recommended by Quindor. Thanks so much!!!
@@BytesOfPi Following this issue, last night I had some more flickering... I am thinking about moving my controller (DigQuad) closer to have a shorter data run... Have you ever had to put a controller outside, somewhere by the soffit? I am trying to keep my setup as discrete as possible so less wire and less visible the better. Any suggestions or ideas? Thanks in advance.
@@idscomm Sorry, just looked back at history and saw you already used the DigIQuad 33 ohm change. I've got a box using the KeeYees booster and it's working ok, but I'm doing a bit of headscratching right now with another box. the booster seemed to work when I tested it before mounting, but when I mounted it, the booster is not translating the data as expected... I do have outdoor boxes, but not small enough to fit behind a soffit. If you're not enclosing your power supply with the Digi quad, you could get a smaller profile electrical box from a big box store like Lowes or Home Depot.
Excellent video mate. Very clear and concise.
Glad you liked it! Thanks for the feedback
This is the best explanation of this issue I have seen! Thanks for the video! Just a note for those of us that use Vixen and FPP. Make sure if you have a computer running Vixen on the same network as FPP , That Vixen is completely closed while the show is running on FPP. If Vixen is open the lights will constantly flicker. This one bit me a few years ago, was pulling my hair out, til i noticed that it only happened while i had the program open.
That's a good point. A similar thing happens with xLights and FPP. If two machines are broadcasting data , the controllers get confused and flicker
This is the best troubleshoot for this issue I've ever seen. Very thorough and easy to understand and not pedantic. Well done!
Thanks, I appreciate that! The flashing lights issue is the most frustrating problem and it's a struggle sometimes to know where to start troubleshooting.
Thanks for the great video. I found another flickering source. I set up my megatree and a few props through a differential receiver just like last year but this year it flickered. After about an hour of troubleshooting wires and such, I discovered that I had the light switch on xLights turned on at the same time I was trying to run the show on xScheduler. Once I turned it off, flickering disappeared. Whew. Glad it was an easy fix. But duh!!
🤣 That's happened to me a couple times... Luckily those issues are really easy to fix.
Great video. I found it after being at my wits end trying to resolve a flickering problem with BTS Lighting WS2814 FCOB 12V strips. I've installed about a half-dozen different LED projects with other strips but these ones seem to be particularly susceptible to flickering. I say this because I haven't needed a level shifter at all in my other projects. Level shifters are definitely recommended with this brand of strip.
Anyway, my last project wouldn't stop flickering, even with a level shifter. As I mentioned, I was at wits end trying to resolve it. This video prompted me to look at the buck converter I was using to power the ESP32 and the level shifter circuit. When I powered the ESP32 with a micro USB cable, the flickering stopped. This was repeatable. I swapped in a different buck converter to see if it was just that board but the new one did the same thing.
I have used that brand of buck converter (LM2596) quite successfully in other projects but there was some bad mojo with the components on this last one,
I've not used buck converters in my builds, but I bet they give off a lot of electrical interference. If you can keep the converter as far away from your data line as possible that may help. Also just a shot in the dark but you could try a makeshift faraday cage by surrounding the converter with some tin foil
@@BytesOfPi I've used buck converters quite successfully with some types of strips. Muzata 3535, for instance. These FCOB strips are quite sensitive, however.
Clever idea on the home-made faraday cage. I tried it but must have shorted out a couple of contacts because smoke started emanating from one of the components. I think I fried the ESP32 board because I can no longer connect to it. No biggie, I have spares and they are easy to program. Before introducing tin foil into your enclosure, ensure you have all of the contact points correctly isolated!
Hey, I'm using a WS2811 in my current project and it won't stop flickering, I'm using the ESP32 as a controller too, do you have any idea why this is happening, thanks in advance.
@@omarelabasery7101 Ensure that one of the ground pins from ESP32 is connected to the neutral from your power source. If that is the case, you may need to incorporate a level shifter into your circuit.
@@jeremymercer665 okay thank you 🙏❤️
Found this when I was looking for why my ESP32 always flickers the W2812B even when I switched the library and different ESP. Turns out that I didn't have a common ground which ultimately fixed my issue. Without it, the LEDs were flickering like a christmas tree and never stayed the same color or turned off properly :)
Awesome! That common ground issue is easy to fix and easy to overlook especially if you use 2 different voltages like 12-24v lights.
best video!
If your into exploring rabbit holes of electrical engineering then there is a very good old video "Tektronix - Transmission Lines" which explains why you see these problems in cables at high speed. Wire thickness is not necessary the answer, correct line impedance is very important.
Agreed.
There are many videos and documentation out there that go to great lengths calculating the right impedance for a particular circuit. There are many different tools that can be brought to bear to analyze and address similar kinds of issues including oscilloscopes, varying levels of resistors, etc. For those that have passion for electrical engineering, definitely dig deeper.
I started to see a lot of questions by people wanting to troubleshoot their particular issues with flickering but less interested in the technical aspects.
The goal of the video was a quick, less technical (and hopefully less intimidating) explanation for troubleshooting steps to take that are easily accessible to anyone in the hobby and why. Choosing to spring for a thicker gauge of wire when connecting your controller at a distance from your LEDs is not a silver bullet for all flickering woes, but it is a rule of thumb the thicker a wire is, the less impedance is caused.
Thank you, I was missing the common ground between my controller and the power supply.
Awesome! Glad you found the issue. Those common ground issues are nasty
Hi Bytes of Pi do you sell your WT32 ETH01 PCB mount? I've been using this controller a lot lately but i'm a software guy and not very skilled at hardware and electronics stuff. So I spend a lot of time fumbling with wires and connections....
I really enjoy your videos btw, i've learnt a lot. Thanks for sharing your knowledge:)
Hey Jayson! I'm a software guy myself so I totally understand the hesitation. I would share the Gerber file with you so you could build your own through vendors like JLCPCB or PCBWay, but my first pass wasn't so successful. It works but the traces for the data to the level shifter were so close together they started to corrupt the signal between each other. I can get the farthest 2 mapped data pins to work, but adding a third pin makes the lights flicker.
They cost enough that I've not tried a second time, but I think I would like to perfect embedding a NE555 time delay switch components and try out one of the WLED approved signal boosters.
May even make for a good video. 😁
common ground helped me with my flickering
That's a common issue to run into, but luckily easy to fix. Thanks for the response. Hope your project works out!
I think this also may be my issue as I'm using two power supplies and the pixels that are getting the flickering and random colors are on the separate PSU. If not, might be bad bulb because they become faulty colors after the same pixel...
Flickering led is a big issue when using low cost system. There is a reason the Pro Industry use RJ45-RJ45 cables from controller to a signal repeater (300m) 1 repeater for each pixel strip, the downside is that 1 Repeater cost 90$ each !
The Repeaters are differential signal repeaters which is different from the direct signal pixels expect.. it's the same signal that Ethernet uses to go long distances.
But here's the kicker... The differential signal repeaters are physically bigger than a WT32-ETH01 board with Ethernet built in and WLED... So if you have to build an enclosure for a repeater and run CAT5/6... Why not just put an Ethernet enabled WLED controller close to your lights? Gives you the additional functionality of WLED and is much cheaper
5:22 Can I reduce the electrical noise in the datacable by wrapping around a sheath current filter out of Ferrit at the end and beginning of the long cable?
You can definitely give it a shot. I'm not sure of your particular setup, but if there are electrical components near those points it might help. Speaking of sheaths, my last data line was a sheathed coaxial cable I have lying around from the olden days of cable.
@@BytesOfPi Yea I have my ESP32 S3 in a Rack with alot of other gear and powersupply and above the rack is my Piano with all the lightstrips. So the ESP and Cables are around other devices closed in a metal rack.
I will try it with the sheath current filter an see if the small higgs of lights every 30-50 sec will be todally removed. ;)
I tried everything else of this video. 14AWG Cables, Level Shifter, Ohm Resistors to cleanup the signal, sordered the cables directly and checked with an multimeter all connections and even polarity check for the power outlet and the power supply to put it in in the right polarity (what I do for all devices, yup EU outlets suck) xD
Still I have every 30-50 sec a small higgs of flicker for a sec. So this will be my last option I know 😅✌
@@marcusunivers oof.. if it's in a rack with a lot of other equipment, probably a lot to give it the jitters.
Is there a way you can turn off everything else in your rack except the lights? If you can turn off everything but your powersource, ESP32 and lights, and get a stable connection, you can isolate your problem. Turn on one thing at a time till you get the jitters again.
Also, Is there any way you could shorten the distance between your controllers and the lights? The closer you can get your ESP32 to the lights, the better.
@@BytesOfPi I tried it with the sheath current filter and it worked perfectly. No flicker anymore. 👍
And not really I cant shut down other Equipment in the rack because there are Mic Pres and Interfaces to use my Music Devices while doing Lightshows 😅✌
@@marcusunivers that is great news! Congratulations!
Thnx alot very usefull!
Great video. For the house lighting, what method did you use to outline the windows and roof eaves?
Good question. I started with the roofline using vinyl J-Channel from Home Depot that matched the color of the eaves and bullet pixels. I used a jig and a drill press to cut holes 2 inches apart.
I tried PVC initially for the window outlines, but found the PVC rotated slightly with each hole and I ended up cutting a spiral of holes. The J-Channel worked so well that I ended up using it for the window and door outlines. While it's easy to cut straight holes in J-Channel, the frames are flimsy.
J-Channel was great for the roofline. Still using J-Channel for the window frames, but I wouldn't recommend it... If/when I redo it, I might try 3/4 " PVC outlines.
Thanks for the advice, I have a fcob spi rgb ic led strip, I should install the strip far from the controller, unfortunately I have some flickering, I solved the data cable with a resistor, but because of the gnd I still have bad flickering, how can I solve it ?
How far away are you installing the controller from the LEDs? The closer you can get the better. A level shifter is probably the best thing to extend the distance or keeping the data wire separate
Hello,
existing videos, exactly what I am looking for as a beginner right now
is there a site where I can view your PCB or the schematic (7:47) of it to understand how you work wit the wt32 eth01
Appreciate it, but I haven't tried it out yet and I know the ne555 timer portion isn't vetted out yet.
Once I get some time to try it out and have it working reliably in my own boxes, I can share the Gerber file.
This was my first try at PCBs and they just came in. I wanted to simplify and clean up a lot of the wiring I have now.
Can you recommend a specific level shifter and where to buy?
I've bought my level shifters from Amazon, but the reliability of them is sketchy at best.
I think that WLED's page is probably your best bet: kno.wled.ge/basics/compatible-hardware/#levelshifters
Hello,
The video is very helpful.
Can you please help us developing a controller for us ???????
I have a few videos you can check out on building a controller.
A behind the scenes video of our first controllers can be found here: ruclips.net/video/GeJxolPpiE8/видео.html
i have been installing permanent christmas lights on my house ones i designed using ws2811 pixels, i just tied in an additional section in a hurry and connected from the wrong end of the string now none of my pixels work at all i did confirm that the controller is good any suggestions how to fix or did i fry all of them?
That's a tough question. Most likely you did not damage your other strands.
If the only thing you did was tie a strand of strings backwards, but you kept ground tied to ground and power to power, then they should all be good. The data goes one way, but doesn't cause damage if you connected them backwards.
What usually causes damage is connecting a higher voltage than your strand can accept or touching ground to power.
Was the backward strand at the end of your run or at the beginning?
Are you assembling it all on the ground or in the air?
If you can assemble the pieces on the ground and test them, it's worth it before you hang them up on a permanent installation
I don't believe that the thickness of the data line matters much, as it should not be carrying any current. The only thing that it does is cause a voltage level, and it is most likely driving a MOSFET style input in the chip, so it will carry basically zero current. Thicker won't help in that case. Also, it only drives the next pixel, not the whole strand, as each pixel will regenerate the data line.
Thicker matters on current carrying wires however, like data and ground.
The best solution is almost always a level shifter.
Awesome Michael, thanks for the input.
i have a question for option 4.
does that mean i can not run multiple data lines using a cat5 cable? those cables are designed to carry digital signal i thought it should be possible
Do you mean option 3 for wire gauge?
Cat5 and cat6 is a touchy subject for a choice of wire when sending data to your lights. There are many people that have used cat5 successfully to send data to their lights. However, when they do successfully do it, they usually have to connect 2/3 of the wires together, essentially raising the gauge of the wire.
Cat6 has a leg up on Cat5 with that additional plastic core separating the twisted pairs. That helps reduce the cross talk mentioned in option 4.
Cat 5 is four pairs of 24 gauge wire which is extremely thin. I'd say give it a try and use what works best for you. If you run into issues, raising the gauge of wire is just one option to try.
A lot of people don't understand what type of cabling to use for what type of signal. Yes there are a lot in the LED community which use CAT cable for LED data signals (and even power) but this is theoretically wrong but can still work somewhat in reality.
"But Ethernet is up to 1Gbps and uses it too so it must be good!"
Yes, that's correct but there is exactly the clue (which most don't understand). We're talking about two different kind of signals! "Single Ended" vs "Differential"!
LED data signal is something called a "single ended" data signal. So there is a single signal wire which has either a 0 or a 1 (at 5v) on it vs GND.
Ethernet signaling is different it uses something called differential signaling where it uses a pair of wires and each has the reverse of the other. So if you have a 1 with +3.3v the other wire will have a 1 with -3.3v (this is a simplified explanation). Because of this method the signal is a lot more robust vs outside interference and can also travel much much further.
And well this also explains why Ethernet cables are not suitable for LED data signals, it's not designed to carry single ended signals. Yes, running one through there, potentially with a bit of power (or at least GND) over the other pairs, can work somewhat, it's just not ideal for it, a normal wire pair is much more so. Running multiple signals through there will also undoubtedly cause it to fail after a short distance because of all the signals interfering with each other. Maybe maybe if you ran CAT7 which is PIMF (Pair in Metal Foil) it could work since then they each pair is shielded against the other pair, but it's really just trying to find a solution to using the wrong type of wire. If you want to run data cables, run either a single cable or a dual-cable with data and GND next to each other (using an appropriate resistor). 3-wire cable is fine too like xConnect, etc.
Oh and one last thing, some boards like Kulp and Falcon have differential extensions ports and those ARE well suited for Ethernet cables because they use a chip in between to transform the single-ended data signal to differential and then back again at the other end, that's a perfect solution to bridge long long (up to 100m/320ft) distances!
Hope that explains it bit the why and how there are so many misconceptions and "it works for me..." out there. :)
@@IntermitTech
That's a great explanation and thanks for weighing in Quindor. Just to clarify, the differential signal ports that kulp and falcon provide for distance require differential receivers on the LED side to translate the differential back to single ended.
Might as well have a WLED controller with Ethernet jack just taking DDP or E1.31 data close to the LEDs at that point.
@@BytesOfPi no, i mean option 4, lets say i have 4 strips with each one using an independent data line, i thought using a single cat5 cable was enough to get those 4 signals to their strips
what you are saying is that it should not be possible, because each data line is affecting in any way the other data lines
intermit sama answered my question btw, thanks for answering anyway, it could have been a disaster for me if i did that ahaha
@@IntermitTech oooh it helps a lot, i got this idea because another person, hpwit, used that method or i think he did, to carry his signals to his led panel, i knew it was bad for power but did not thought it was bad for signal as well, so the common 3x18 awg wires are good enough?
Thank you for this video, I ordered my KeeYees 10pcs 4 Channels IIC I2C Logic Level Converter, hopefully it will solve my issue. I have completed my project and I am running into some flickering issues. I used 5v strips which required many power injection but I followed Bill's video/advice as well. I am running my project on a DigQuad using 2 channels. Everything is working fine but sometimes I have flickers (I actually pout together a quick video for beginners like me about the outdoor install), you can have a look towards the end it'll give you an idea of my issue (I recorded 3 different pattern/example).
This is the link to my video - ruclips.net/video/bMG79kfk2Ps/видео.html
Thanks again for your great videos!!!
Hey, I just watched the video and that is definitely signal flickering.
I'm not sure how far your DigiQuad is from the start of your lights, but a signal booster may help.
Quindor also has an article about his latest boards and going long distances. If you check near the end of the article he says that There is a built-in 249Ω and 33Ω resistor. By default it uses the 249. However, for longer distances, you can switch to the
33Ω. That may help as well
quinled.info/data-signal-cable-conditioning/
Lastly, like the video says make sure your data line isn't near things like power sources other controllers and the neutral wire
@@BytesOfPi Following your advice, I worked on the issue tonight, I had purchased a few data-booster boards so I was able to easily switched from 249 to 33 ohms. It seemed to have fixed the issue... My data cable is longer but I used a bigger gauge and stayed within the parameter recommended by Quindor. Thanks so much!!!
@@idscomm that's great news! Congratulations.
@@BytesOfPi Following this issue, last night I had some more flickering... I am thinking about moving my controller (DigQuad) closer to have a shorter data run... Have you ever had to put a controller outside, somewhere by the soffit? I am trying to keep my setup as discrete as possible so less wire and less visible the better. Any suggestions or ideas? Thanks in advance.
@@idscomm
Sorry, just looked back at history and saw you already used the DigIQuad 33 ohm change.
I've got a box using the KeeYees booster and it's working ok, but I'm doing a bit of headscratching right now with another box. the booster seemed to work when I tested it before mounting, but when I mounted it, the booster is not translating the data as expected...
I do have outdoor boxes, but not small enough to fit behind a soffit. If you're not enclosing your power supply with the Digi quad, you could get a smaller profile electrical box from a big box store like Lowes or Home Depot.