Odd issue with ONE strand on my megatree...

[sielbear]

I've got a strange issue that's affecting a single strand on my megatree.  It is delayed from all of the other strands on hard changes (i.e., the entire tree changes from red to green or white to black).  On fast (very fast pulses, perhaps 1/10th or 1/5th of a second, it looks like the strand is on the "off-flash".  If the tree flashes blue, black, the entire tree will go black EXCEPT for this one strand.

I've changed SSCs and cables.  I've reflashed PICs.  On slower fades, etc., I don't see ANY noticeable issues.  It may still be delayed, but I just can't see it - not sure. 

You think it's a bad strand of nodes?  I MIGHT have another strand of smart string lights and I am renting the lift tomorrow.  I could probably change the strand if necessary. 

Any other thoughts than condemning the entire strand? 

[tbone321]

If you are using connectors between the string and the controller, swap the controller with another one on the tree but DON'T change the address of the controllers and see if the delayed string moves with the controller or stays with the string.  If it stays with the string then the string is the issue and if not, then more looking is in order.

[chrisatpsu]

what's the starting address of the affected ssc.   I think some people on here have found a "boundary" pixel issue i think with the old version of the EtherDongle.

[sielbear]

Fan-freaking TASTIC idea tbone...  I'll try that tonight or tomorrow.  Freaking brilliant!

Chris-  I encountered that issue earlier in the season with my etherdongle - I'm actually driving this with the conductor.  Generally playback is perfect.  Just have this one ROGUE strand. 

Oh, one more thing - this ONE strand doesn't always get an off signal.  I have one song that it never gets the final off command, so the ENTIRE megatree goes black with the rest of the house but this ONE freaking strand...

Will report back findings from swapping the controller.  Great idea.

[sielbear]

Swapped SSC and problem followed the controller. Start channel is 3713, universe 3 of pixelnet. 128 node strand.

[tbone321]

Then the next step would be to re-address two of the controllers, the one wiith the issue and some other random victim on the tree.  Then see if the issue follows the controller or the channel set.

[rm357]

Your starting address  may be your problem.

3713 + 128 * 3 = 4097

The ssc has to collect all of the string data before it can output the pixel data stream. When it sees the sync byte, the counter gets reset so that it can start counting up towards the start address to start collecting the next frame of data. It may not sense that the buffer is ready until it starts loading the next data set making it 1 frame behind.

I know, the last data byte on the last node should be address 4096, but change the string length to 127 nodes just for grins and I bet your issue will go away.

[sielbear]

Hmm - I understand what you're saying, however, I think my math is different from yours...

My starting node is 3713.  If I add 384 to that start value, I do get 4097, however, don't I subtract 1 because my start value is 3713, not 3714?  i.e., 3713 is my "1", not my "0" value for this strand?  I'm not sure I'm making sense with this post...  I know when I made my spreadsheet calculating values, I had to take the previous strand end value, add 1 for starting channel of next strand.  Add 384, and subtract 1.  If I didn't, I noticed all of my strands were 385 channels, not 384.  A more simple example - if I'm using 10 channels and my start address is channel 11, I'd add 10 and subtract 1 to get the channels occupied by that controller: 11 + 10 = 21.  21 is the start value of the NEXT controller as channels 11, 12, 13, 14, 15, 16, 17, 18, 19, and 20 are the values for this controller.

Please let me know if I'm off in left field.

One other note - this strand that's misbehaving is almost in the exact middle of the matrix (but it is definitely occupying the LAST universe / channel available.  The strand to the right (still part of the matrix) is in perfect time with all other strands.  Really odd.

Again, let me know if any of my math / above comments are incorrect.  I can re-render a show, it's just NO fun to do so... 

[sielbear]

Thinking through this - I'll re-render my most problematic song on another conductor flash card and give it a go.  What you're saying makes sense, I just don't understand why it's acting up as is if my math is correct.  I can give up a pixel to get rid of the annoying issue I'm seeing!

[sielbear]

One last note - to clarify, I can drop one pixel from my LSP app, OR can I re-program my smart string controller to drop one pixel?  In theory if it's a hardware issue (waiting on one last pixel) I can tell the smart string controller to NOT wait for that last bit of data.  I don't have to re-render in that case...

Heck, I have an extra SSC here.  Going to try to program one and get it in the show while still running tonight....  BRB.

[sielbear]

Freaking genius!  Setting SSC to 127 fixed it from my brief testing tonight. 

If you get a moment, double-check my math.  Are you an LSP user?  I'm curious why I had to set the show up like this but I'm a happy, happy guy right now.  The perfectionist is screaming, "Your megatree now only has 2,559 pixels..." but the practical me is saying, "holy crap I'm glad that's fixed!!!"

If you're an LSP user, one reason I used this addressing scheme was to keep contiguous channels between the two halves of the matrix.  I start my matrix on channel 257 Universe 3 and run through 3840 on Universe 4.  At the time, I thought this was a requirement for LSP.  I believe I can have gaps, I just need to have my channels arranged properly in LSP so there are no channels between / intermixed within my channel groups. 

Thanks so much for your help tonight!  One more irritation off the list!

[Mickpat]

I have 11 flex strips and the 11th strip behaves differently.  It seems to lag the others and sometimes doesn't update.  I will post some videos.  The starting number for this string is 3601 - 3960.  I am using the Conductor too.  I could move this string to another hub and reconfigure the channel numbers.  Not looking forward to renumbering 120 channels though in LSP.  Is there an easier option? 

[sielbear]

Is 3960 the last channel in the universe?  I've been thinking about this issue I faced - I wonder if the SSC is waiting to get data for another channel outside of it's range before sending the data.  In my case, I was consuming the last available channel in the universe, no additional data could be received to send sync signal.

Try dropping the hardware node count on your last SSC by one channel and see what happens.  If I were a betting man, I'd say there's a reasonable chance you'll see the delay gone.  Note, this is PURELY speculative at this point...