(Workaround Discovered) Finding the faulty node

[injury]

Wonder if anyone has any suggestions other than trial and error cut in half method for finding my next bad node in this string of pixels.

Strand did have the white lockup problem originally, did the cut in half til I found the bad nodes method (happened to be two of them). Now reassembled I'm having a flashy issue I didn't notice when testing the sections individually. Basicly if I set red or green I get random flashes of white in various pixels, and groupings of pixels. Seems to be related to methods that let me vary the intensity. For example the colorfinder app from here seems to do it on everything except full blue with red and white off. Xlights testing the random multicolor fading one seems to manifest itself as just a flicker off on some of the bulbs, but a straight 2 color chase or alternate seems to show no symptoms.

The first pixel never flashed so I figured ah ha, but removing it didn't make any difference. Just not looking forward to doing trial and error on these again.

[rm357]

Usually the bad node is either the first node in the string that is acting up or the one before it.

Each node takes its data first, the passes the rest of the data on to the following nodes until it sees the reset signal, then it will again take its data....

If a node is not receiving the data correctly, the data passed on to the following nodes will be corrupted.

I usually cut before the first bad acting node and then test just the cut part. If it seems to work properly, I mark the node before the cut as bad. If the cut part still has issues, I remove the first node and test again. Incidentally, I have a number of strings with known bad last nodes. As the last node in a string, I really don't care if its output circuit mangles data, as long as the input circuit works fine... I usually cut the output wire on bad nodes too short to solder on another node so that I won't forget and try to add nodes next year.

[Steve Gase]

+1

[Corey872]

(I haven't searched, so maybe this has been brought up (many?) times before?...but) - I wonder what would happen if a person rigged up an SSC with alligator clips for the +12VDC and GND and put a small wire-piercing probe on the date line (sewing needle soldered to an alligator clip comes to mind).  You could clip into the head end of the string to supply power.  Then could you pierce the data line ~1/2 way down the string and see if all those nodes function fine.  If not, go 3/4 the way down, or if so, go up to 1/4 of the string and try again?  Or if you have a suspect node, inject data right before / after it to confirm?

You'd be perforating the data line with tiny holes - which would ideally be sealed when you're done.  But this might be preferable to all the cutting / splicing?  Maybe data transmission integrity can't be maintained by simply piercing the wire?  But since the nodes really don't know where they are...only 'take some data and pass it on', this should make any node after the pierce point think it's the first in the string and be an effective test for all following nodes?

[chrisatpsu]

many times you will find that the failing node is the first one to actually act up.

if a node is acting correctly, it recieves it's information, then lets everything else pass along.
all it does it take a value, and makes the dimming happen for that channel.

ok, now for a failing node.
failing can happen in three ways....
1.) it's dead.   you wont see any lights, and there wont be any lit after it.  could be a wire cut (open short), or the chip in the node could be fried.

2.) it could be malfunctioning slightly, that node will get wacky colors, but the nodes after it are still acting correctly.

3.) it could be malfunctioning badly, that node will get wacky colors, and so will the nodes after it. (they may be totally different colors, or all the same.


in all three cases, it's the node that's acting up, not the one before it.
it's extremely rare for a node to show correct colors, yet screw up the nodes after it. if this does happen, it's most likely an intermittent short in the wire carrying the data signal.

[dpitts]

Let me add 1 more case to the failing node. The node lights correctly, but it does not pass data correctly. Most of my failures were of this type.

[injury]

I think I have a node shorted on its board and pulling power off the wrong line or ringing something, I believe RJ mentioned some doing this in an old troubleshooting post.

Bear in mind this is a strand I had just cut and spliced back together yesterday to get rid of white lockup issues.

I think I mentioned earlier the new flashy, flicker issue (depending on my test method) is random sections except 1st node was fine, or all but the 1st node with a different sw. So unlike one being out of color or always bad after x node no real way to identify a section of 2 or 3 by visual queue.

Today for the other issue, removed the first 3 nodes first thing this morning since 1st never had the flicker but number 2 did no change other than the new number 1 would act in chorus with random other ones at times. Cut in Half, back half fine, front half bad. Cut front in half again, back half good, front half faulty...getting closer. Cut yet again and both halves test fine.   

At one point I thought I might have had a short in the 3 pronged connector, but replaced it with no change. And I've tested this SSC other strands to make sure it wasn't going whacky and had no issues.

I think by the time this string is good to go I'll have more solder splices than not.

[keitha43]

I have seen a node look normal yet screw up nodes further down the line. Usually the next in line. It can get worse if moisture gets in them. I have had the symptom a day after a rainstorm where lets say node 5 is the wrong color due to one of the leds is dead ands lets say a section starting at node 64 is either white or multicolor. Replacing node 5 (sometimes node 4) would correct the problem that started at node 64 as well. So the best procedure is to start with the one with the symptom and if it doesn't help try the one before it. Always start closest to the ssc.

[pk]

This is my first year with smartstrings.  I have 2 strings of the square modules that would randomly change colors when connected to a SCC V1.  There seemed to be no noticeable pattern as to which node was causing the problem. When connected the nodes to a V2 SCC the problem stopped.  Try a V2 SCC and see if that fixes the problem you are seeing.

[rm357]

After the first bad node (input or output, the first bad actor or the one before it) the data sent down the line is corrupted and invalid. The nodes further down the line will interpret their data the best they can, if they can, and pass the rest of the corrupted data. I have seen rainbow effects caused by 1 bad node early in the string.

Please do not waste your time and effort by cutting a string in half, then half again, then half again... Most of your nodes will be fine and you will have to splice the pieces together again, which will probably give you uneven spacing at every splice unless you add a little piece...

[injury]

Sorry doing the half and half, because I do remember reading the cases in the past (and what I'm experiencing now with this particular strand) where data is corrupted down the line somehow and affects pixels in front of it which is where the cut in half and half again method came from last year. If I recall the explanation given has to do with some kind of short on the board that messes with the data and power lines.

Unless you feel that the odds are good that about the first 20-30 nodes on this strand are all bad. I suppose that is possible as well but seems unlikely. I've already gone back at least 5 total first ones since I started with this strand since I do start with the easier "cut out the first bad and the one before it out" method first.

As it stands from my cutting in half I have at least 2 faulty ones, one or more in about the first 15, and a second bad one between 16 and 30. Individualy both of those sections with issues work fine but if I put either section of them with the remainder of the strand that tests fine they give me the flicker again.

[taybrynn]

I've found (as others have said) its usually the first node thats bad.  Otherwise your more likely to see the nodes working, then a bad one that is often the last one to light up or its the one after the one thats the last one lit up.

Also, if there are wires touching on the other end of the string, that can cause them to all act dead ... make sure the wires on the other end are sealed and not touching at all.

The other thing is to make sure your working with a proven SSC that works ... I've chased this problem before only to find I didn't have a good flash on the SSC or had the wrong
module type programmed into the SSC.

Just some ideas to consider.  Good luck.

[injury]

Getting to be a head scratcher I'm starting to think maybe I have a small issue elsewhere (active hub, etherdongle, or psu) and this strand just happens to be more sensitive to it for some reason after a certain number of nodes are added to it.

Here's where things currently stand...

The last 81 pixels on the problem strand seem fine after being reassembled from the trial and error cut in half process (that happened to be 3 sections of the split). So far the remaining front pixels in groupings of roughly 10 to 20 all seem to bring on the flicker. Each of these smaller sections seem to function normally when hooked up by themselves.

When I say flicker or flashy I mean at a certain color mix the entire strand flickers either off or flashes all white for a brief moment and the whole thing returns back to normal color. The frequency seems random, sometimes 20-30 seconds with nothing unexpected sometimes as fast as once a second. Things like solid green, red, blue seem alright, there are just several "sweet spots" in the colorfinder app that bring it on (or as I mentioned in an earlier post certain spots in Xlights mixed color cycling). I'm not talking about the issue where one node somewhere in the middle goes off color and all after it go out of whack, or where I have a node constanly shifting color with problems behind it.

Compared with a good strand, swapped SSC's between the strands, swapped all patch cables.

The reason I added the thought about this one being more sensitive was that my known good test strand is rock solid with everything I've thrown at it (it's roughly 120 nodes). However on my last mix with the colorfinder I was able to tweak a mix that was giving my problem strand a lot of trouble with the most frequent flickers, then when I swapped in the good strand it did flicker once in a long while (nothing compared to the problem strand and overall quite acceptable). If anyones curious this mix was 174, 159, 174.

[injury]

I figured out a way to work around it, but the why is puzzeling me.

I can put all of those strands behind the 81 and the whole thing works without a hiccup. Just to make sure I wasn't imagining things, I removed the 3 sections of 10, 1 at a time and tried them in front again and each one caused my flicker issue along the whole strand. I tried several arangements of the 3 sections on the back just trying to see them mess up there and all worked normal no matter the order.

My only guess is maybe he used some different components on some of those chips originally at front of the strand that could not handle the draw of the full strand, but could handle 30 or so. Maybe someone that understands the node circuits a bit more has an idea of why it would be so.

[chrisatpsu]

in dealing with the chips directly, there have been a couple where i left the soldering iron on longer than i should have...  i got similar results. some would work tacked on the end, some would just me flaky all together.