Troubleshooting a tree

[Kensington]

I've been banging my head against this megatree since Saturday.  Although it has been getting incrementally better, I haven't solved the problem yet.

Physical configuration

Tree is set up as 360 degree, 32 physical strands of 95 12v  WS2811 nodes.  Strands (1, 2), (3, 4), (5, 6),…(31, 32) are joined at the top of the tree.  One string of four strands is connected to a single output on the V1 bank on the F16v2.  Power is injected at beginning, middle, and end of string.

The whole tree tests good on all F16v2 test modes.  There are 4 bad pixels on the tree.  3 are at the end of strand 8 (don’t light), and one is in the middle of strand 26 (won’t go all white).  None of the bad pixels appears to affect the tree’s performance.

Falcon F16v2

Software v1.09

The Falcon F16v2 is in 16 string mode.

Each port is assigned 380 pixels (4 physical strands).  Port 1 starts at channel 1 and ends at 1140.  Port 2 starts at 1141 and goes to 2280.  Port 3-16 are numbered in increments of 1120 channels/380 pixels each.  Port 8 ends on channel 9020.

There are 64 universes defined.  Multicast.  Universes 1 through 34 are set for 285 channels each (95 physical pixels) per universe.  35-64 are 510 (nothing is on them)

Zig count is 0

Xlights

Type: Round
Degrees: 360
Rotation: 0
Spiral wraps: 0
Bottom/top ratio: 6
Perspective: 2
# of strings: 8
Nodes/String: 380
Strands/string: 4
Starting Location: bottom left
Start Channel: 1
Node layout matches the physical layout of the tree.

FPP

FPP string output matches the F16v2.  64 universes, multicast, 285 channels per universe

Here's the problem: All test patterns from the F16v2 work flawlessly.  There are no power issues of which I am aware.  I have created a test sequence in Xlights consisting of the tree model with all pixels turned on.  However, instead of all pixels on, I get the pattern shown below.

Any ideas of the cause?  The only thing I haven't done is reformatted the SD card and USB stick for FPP.

[Gilrock]

In your description you didn't specify the xLights setup page.  Your network need to be 285 per universe to match what you are configuring everywhere else.  It defaults to 512 per universe so maybe that's your problem.  I would switch everything to 512 per universe anyways.  You have Falcon hardware so no reason not to do it that way.  It just makes it easier to let it flow continuously through the universes to capacity.

[Kensington]

Xlights is set up identically to the controller and FPP.  285 channels per universe.  String 1 (strands 1-4) runs off Falcon output 1, String 2 from Falcon output 2, etc.  There are no Tees between the String sets.

In further testing, the first 14 strands work just fine.  At strand 15, things start going downhill.  I've counted the pixels on the affected strands, and it appears that at strand 15, 20 pixels at the top of strand 15 are lit, and the rest of the string is blank.  Then strand 16 is just the opposite--the top 75 pixels are lit, but the bottom 20 are blank.  That pattern is repeated on the other strands, albeit with differing numbers of lit or blank.

[Kensington]

Regarding your comment about using the default of 512 channels, I was trying to set it up so that I didn't have universes divided amongst multiple strands, and I could thus avoid having to insert a pigtail for a new data line at odd places on the tree (I wanted them all at the bottom so any strand could be placed at any point on the tree).    For instance, if I went with 510 channels per universe (170 pixels), universe 1 would run to strand 2, pixel 85.  U2 would be strand 2, pixel 86 to strand 4, pixel 65.  U3 would be strand 4, pixel 66 to strand 6, pixel 60.  U4 would be strand 6, pixel 61 to strand 8, pixel 41.  Then I'd have to put a pigtail in halfway up the strand to connect a new output to the controller.

Or am I thinking of a tree the wrong way?

[Gilrock]

You're using a Falcon it does not really care where universes start and end.  You will never need to change where your pigtails are.  You can have a Falcon output start anywhere.  I just run all my outputs back to back so without even realizing it I ended up with an output that starts on channel 511 of a universe.  So it literally only uses 1 channel from that universe and then all the data from the next universe.  It's an FPGA so it copies all that data where it needs to be super fast.  With other cards you might not want to do it that way because they have normal CPU's that can't handle doing the same amount of work.

[Kensington]

Shows what I know about my hardware.

Heretofore, I have assumed that the physical outputs from the Falcon must be input into the tree at the point where one set of 4 universes ends and the next one begins.

So are these correct conclusions (a) I can daisy chain all the strands together on a single data line, and (b) I can input the Falcon outputs anywhere along that line and the correct signal will reach the correct pixel at the correct time?  (Of course, power injection needs to occur, but that problem is sorted out already)

For example, Falcon output 2, which controls channels 2049 to 4096/pixels 641-1280, could be physically connected to the data line at a tee located around pixel 1920, but would still send data to pixels 641 to 1280?

[Gilrock]

I think the only limitation is number of pixels on an output.  I believe its 680 pixels for a Falcon output unless you are running an expansion card and then it's 320 per output.

[Kensington]

I'll fabricate some power isolation tees and daisy chain the strands.  It can't get any worse, right?

Thanks for the suggestions, Gil.

[Kensington]

I thought I'd give an update on the saga.  I abandoned the 360-degree plan, and limped through the holidays with a 180-degree tree.  I wanted to have it sorted out before I took it down and packed in away, so I called David Pitts yesterday after rewiring the tree twice, and he ran through it over TeamViewer.  After verifying that the universe/outputs matched across the F16v2, FPP, and Xlights, he didn't see any packets across the controller.  He changed the configuration to Unicast.  Boom.  Xlights started pushing data from small sequence Dave was changing on the fly in Xlights, and I had full 360-degree pixelated gloriousness on the tree.

However, FPP would not run the sequence correctly.  He hypothesized that Xlights hadn't producing a good fseq.  That's probably correct, as I noticed that on several renders Xlights took much longer than usual to produce the fseq.  Dave got into Xlights and uploaded the known-good sequence he'd been playing with to FPP with FPP connect (I did not know such a thing existed).  It worked (finally), so I wiped the FPP playlist and content files, then re-uploaded with FPP connect (actually took me several tries through multiple iterations; I'm posting the short version).  Everything now works, and my wife's description of the tree has changed from "that stupid thing you spent a full month on" to "it's beautiful".

[Gilrock]

It is possible to end up with an FSEQ file that does not match the number of channels you have in setup.  I saw it happen but don't remember the exact steps.  I'm guessing its when you change the size of a model and then later add more channels to setup but you've already produced an fseq file.  We read the fseq at startup and if it exists then that can determine the number of channels instead of your setup.  Best thing is just delete the fseq file and re-render.  The other trick I use is just change the duration by 1 second and close the settings dialog...then change it back.  That causes the fseq data to be deleted and it starts you off fresh.

[Kensington]

That's probably what was going on.  I thought I had fresh fseqs for each sequences, but I had to make some changes to each file and re-render each sequence before everything worked perfectly.  And combined it with FPP and F16 reboots.