Oddest tool of the day award goes to "sewing needles for debugging bad pixels"

[CaptainMurdoch]

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.   

[Made2Rock]

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

[CaptainMurdoch]

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.

[maffeirw]

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.