DiyLightAnimation
Hardware => Lynx Smart String => Topic started by: CaptainMurdoch on December 01, 2013,
-
There, I'm sure that subject got your attention. :)
I figured I'd pass on an idea that I had the other night when I discovered that I had a few pixels at the end of one of my new technicolor strings that wouldn't light.
I have seen several people talk about cutting between the last-good and first-bad pixels and then describe testing procedures to determine whether it was the last lit pixel that was actually bad or the first non-lit pixel that was actually the bad one.
I had 6 nodes that wouldn't light at the end of a strand. I checked continuity from end to end and determined that my 12V and ground were making it all the way through, so it had to be a data flow issue at one of those two pixels, but I wanted an easy way to test.
Rather than cutting the line, I decided to rig up a jumper cable using a pair of sewing needles. Any needle or stick pin would do the trick, but these were the first two I could lay my hands on without my wife noticing. :)
I took the two needles and attached them with a short 5-inch piece of stranded wire from a piece of scrap Cat-5e.
I started a test sequence in xLights.
I knew the 12V and ground lines were good, so that left the data which is the middle wire on the technicolor strings. I poked the first needle through the insulation on the middle wire in front of the first non-lit pixel and then poked the second needle through the insulation on the middle wire after the first non-lit pixel. None of the lights after the first non-lit pixel lit up. That meant the first non-lit pixel wasn't actually bad (or on the odd case, I could have had 2 bad pixels in a row, but that's doubtful). I took the needle out of the wire after the first non-lit pixel and moved it up to the middle wire in front of the last lit pixel. Immediately the first non-lit pixel started mirroring the previously last-lit pixel and the rest of the pixels in the strand were lighting up to the test sequence but out of sync by one pixel since I was now duplicating data to two consecutive pixels. This told me that the last pixel that lights without the jumper is actually the bad pixel. Now, I can cut that pixel out and just put a dab of silicon or nail polish on the needle holes and I'm set. I think this was a bit quicker to test than cutting the line and testing the two sections.
Theoretically if the 12V or ground had been the issue, I could have just installed a jumper around the bad spot and I wouldn't have 3 wires to repair as I would if I had cut the line to test. If this strand wasn't for my (mini) mega tree strapped to pipe, I could also just bypass the data-line issue and black out the bad node for a quick fix until I could patch the strand.
I figured I'd pass the idea along, it may save someone else a little time.
-
Great idea. Thanks for posting
-
neat, +1
-
You can still have a good pixel. The dead one could have a shorted input on the data line. I had a bad pixel with a shorted chip. Yes I have been doing autopsies on all my dead pixels.
-
This is probably not going to work as well as you might think. The data line in smart strings is a special case. It is not a simple data stream like DMX or even PixelNet where everything sees the same data. Each node receives the data packet, strips off the first node of information for itself then regenerates the rest of the packet and sends it along to the next node. Now if the node has completely failed then this jumper method may find it but otherwise, you will be creating a jumbled mess of data between the data you are transferring and the data being generated by the node that may or may not be understood and can lead to unpredictable results.
-
Not sure I would follow that. The node knows nothing of it's location, so by passing it with the data line jumper is no different than just cutting it off and soldering on another pixel. So why would using a jumper to bypass a node that is not lit possibly cause an issue? E.g. it is not like the factory programs them in order on the string and they are waiting for a specific number to compare too.
-
By having the "clean" line (the jumper) you are removing the chance of the bad node putting bad data back onto the line for the nodes down the string. The jumper is allowing you to know clean data is going onto the line.
-
My interpretation of what he is saying is that if the node is not totally dead, not only will you get the signal through the jumper but also the bad data coming through the problem pixel mixed together.
Sent from my Thunderbolt using Tapatalk 2.
-
You can still have a good pixel. The dead one could have a shorted input on the data line.
Unless there is bad data on the line, then by bypassing each of the two pixels in question individually, you can pinpoint whether it's an issue on the output side of the last-lit pixel or on the input side of the first-non-lit pixel. In my case and description, none of the last 6 pixels were responding at all, so it did not appear to be bad data, there appeared to be no data. When I jumpered around the last-lit pixel, the non-lit pixels started working but were off-set by one compared to the other strands. Since I had jumpered around the last-lit pixel, the last-lit pixel and the next pixel in line were now getting the same data signal and mirroring each other, so that proved that the non-lit pixel was actually good and it was a problem on the output side of the (formerly) last-lit pixel.
This is probably not going to work as well as you might think. The data line in smart strings is a special case.
You don't need to try to educate me, I know how the data flow works and that's why I was confident that my test could work as it did and show me which pixel was bad without having to cut any wires. I also stated that the two pixels in question had identical/mirrored light output and that the rest of the following pixels in the strand were off by one. This is due to how the data flow works between nodes. Basically, my jumper was actually creating a 'T' in the data line with one leg having one pixel (the one with the bad output) and the other leg having the 6 previously non-lit pixels. In my description, I also stated that there was no light on any of the last 6pixels initially. So the odds were they were not receiving any data at all. The whole point of the post is not to dive deep into node troubleshooting, it's to point out another way to do some troubleshooting before having to start cutting. I knew what I was doing and it worked. I probably could have clarified that this method would only have a chance of working if the last pixels were not lit at all, but teaching how nodes work wasn't the point of the post. If so I would have went into much more detail, given an A->B->C->D pixel example talking about data flow, etc..
By having the "clean" line (the jumper) you are removing the chance of the bad node putting bad data back onto the line for the nodes down the string. The jumper is allowing you to know clean data is going onto the line.
Yeah, this works as long as there is no data making it to the first non-lit pixel as it appeared to be in my case. The jumper was a quick non-intrusive way to test that theory which was the main point. If the last-lit pixel was putting out bad data then it would have been garbled with the good data my jumper was providing and the last pixels probably wouldn't have worked.
My interpretation of what he is saying is that if the node is not totally dead, not only will you get the signal through the jumper but also the bad data coming through the problem pixel mixed together.
Yes, I agree, that's why I stated in my post that there was no light on the last pixels, not bad light which would have indicated bad data.
After thinking about this a little more, I think that this 'needle' test method has benefit even if you have to cut. If you know which pixel is bad, you can know where to save the wire at. If you don't know before-hand which pixel is bad, then you have to cut in the middle of the two pixels or potentially have to add in another piece of wire to maintain your pixel spacing. If you know which pixel is bad before you cut, then you can cut as close to the bad pixel as you want, leaving as much of the wire as possible connecte to the good pixels to allow you to join the two strand pieces together with only one joint rather than having to splice in a short bridge to maintain spacing.
-
What I am saying is that a shorted input on the dead pixel will stop all data flow. I would probably cut the data line between the last lighted up pixel and the unlit pixel. In that case I would use my meter to check it out. I hate to lose any pixels. I have the technicolor or fire pix pixels and having a good time troubleshooting the problems with these pixels.
Good luck with these pixels, I lost about 10 pixels on about 5 strings so far. I decided to put up the first ones I bought in July and I hope they do not fail.
-
is clear fingernail polish flexible enough to use as a cover up for the hole? I've heard of the stuff being used for other things, just haven't heard of it to cover electrical wires.
-
I think it would be OK since we're only talking about a small dot to cover the pinhole.
-
Not sure I would follow that. The node knows nothing of it's location, so by passing it with the data line jumper is no different than just cutting it off and soldering on another pixel. So why would using a jumper to bypass a node that is not lit possibly cause an issue? E.g. it is not like the factory programs them in order on the string and they are waiting for a specific number to compare too.
That is incorrect. It is true that all nodes think that they are #1 in the string. The problem is that unless the node is dead, it will continue to output whatever it was along with the signal that you are jumping across creating a complete mess. Putting a jumper from the nodes signal input to its output does NOT short it out because the signal doesn't go thru the node. It simply creates a parallel signal path. If you were to put one of these jumper on the +12V line, that would also have no effect on the node. If the node is dead than this is not an issue and should work and all I am saying is that just jumping the signal line is not a fool proof method of debugging.
-
all I am saying is that just jumping the signal line is not a fool proof method of debugging.
True, but it is another tool that can be used.
-
I don't think tbone321 was trying to educate you per say. Lets say I was unfamiliar with node failure and came upon this thread. Until tbone321 said what he did I would have assumed using the bypass wire would tell me if a node was bad in all cases. By the way I think using sewing needles is great. I wish you had been around a couple of years ago when I was cutting and splicing nodes almost daily due to rain (ip66 version). :)
-
I don't think tbone321 was trying to educate you per say. Lets say I was unfamiliar with node failure and came upon this thread. Until tbone321 said what he did I would have assumed using the bypass wire would tell me if a node was bad in all cases.
Thanks, if I was around a couple years ago I might have some sequencing done for this year. :)
For those reading the thread in the future. Remember, needles are just a tool in your sewing kit^H^H^H^H^H^H^H^H^H^H toolbox. :) They won't solve all bad pixel situations. If so, a bunch of Technicolor users would be hitting up Michael's and JoAnn Fabrics right now and there would be a run on needles/pins. :(
-
Let me try an rephrase what Tbone is saying
You have a "bad" node. All you know is the node is not acting right and the string is dead from that point on. The problem is you do not know what is going on inside. Is he the last good node's output dead or maybe the first bad node is shorted to ground or maybe shorted to +12v or maybe it is marching to the beat of a different drummer. The point here is your source of the test signal is of unknown quality. The next part of the problem is where you jumper the signal to. When you try and inject the signal into the next node you do not know what is going on with the output from the previous node. This previous node may be trying to output what it thinks it should or it may be dead trying to pull the line low or pull the line high. If you try and inject a good signal into the line and the previous node tries to fight you who is going to win. You might end up with what looks like a bad node but it is not.
BTW: I do think this is a good idea for the ground and +12V line and in those cases it would be worth a try.
Joe
-
The point here is your source of the test signal is of unknown quality.
I'm beginning to wonder if I need to make you guys a diagram or video. If the test works then it works, and if it doesn't then it doesn't and the results are inconclusive. I know that it won't always work, I've stated that. The point is that it can work, and is another tool to help in troubleshooting.
The input signal quality is why I stated that I tested from two different locations. The first was the signal of unknown quality after the last working pixel. Then I tested from a known good source in front of the last working pixel.
The next part of the problem is where you jumper the signal to. When you try and inject the signal into the next node you do not know what is going on with the output from the previous node.
Yep, I agree and it's why I agreed several times that it won't always work. The point is that it can work and can save a good bit of time.
BTW: I do think this is a good idea for the ground and +12V line and in those cases it would be worth a try.
:) Trying not to laugh a little over here because it worked for data in my case. I successfully identified the bad pixel. So, it was worth the try even on the data line. Whether it is a bad solder joint, broken wire, or bad chip I'm not concerned with right now. Even if it didn't work, it was still worth the try in an attempt to preserve the wire around the good pixels to make it easier to maintain desired pixel spacing with minimal splicing.
I'm done with this thread. I offered up a suggestion on how to save some time and I get nitpicked over not covering all possible reasons for no-blinky at the end of a string and telling me that my test wont work in 100% of cases when I already know that. I never said that my test was going to solve all pixel or the world's problems or end hunger. I didn't cover the fact you need to make sure that the SSC is configured to send data to the correct number of pixels and xLights must be sending data to all channels and that the string can't cross universes. I offered up a single test that might make it easier for someone else.
If you guys don't want to try it then don't, I don't mind. I'm sure it will help someone at some point and that was my reason for contributing.
-
I can’t speak for anyone else but I thank you for adding another method to my toolbox. It may save me from cutting out the wrong pixel as I have done a number of times in the past. :-[