Learned something new I was unaware of, reverse strand doesn't work on CCB100D C9 shortened strands!

[Orville]

Well tonight, I finally finished up modifying my show sequences, not completely, but added an CCB100D controller and 2 C9 strands that were cut down to 23 bulbs to fit a display area.

Well after plugging in the SD Card, only one port was working port 2, Port 1 had been checked to reverse the strand.  But those lights were not coming on, I swapped ports to see if maybe port 1 had an issue and wasn't lighting the bulbs, so plugged in the lights from port 2 to port 1, no lights.   WTH?  Why isn't this working, I figured a cut down strand should still be "reversible", but it's NOT!  If the strand is less than 50 bulbs, and you check the reverse strand 1 or reverse strand 2, neither work, uncheck them and they work fine.   I even reloaded the firmware, just in case that was an issue. 

After about 2 hours or so, I finally figured it out, if the strands are shortened the CCB100D {Original 5V} controllers WILL NOT reverse those shortened strands!   Don't know why they won't, I would have thought that should work no matter what length or bulb count the strand was.   I even tried different logical resolutions, nope, that didn't work either for reversing a port.   So I unchecked both ports, so they ran normal, and they worked fine.  Just couldn't reverse the one strand I wanted, since there are other full strands before them that have one strand{port} reversed.

Fortunately this can be accomplished in a sequence, so now, looks like I may have to go back and modify all those sequences again.  Ugh!  Not something I'm looking forward too.

So I'm leaving them as is, for now.  Fortunately it doesn't seem too noticeable where the short strands are.   So will probably fix them after the season.

But this one sure like to have driven me completely insane{not like I'm not there already with this hobby! LOL} trying to figure out what the problem was!

Just glad I figured it out and got all the bulbs working on the shortened strands.

p.s. I tried this on my Trellis Arches, as they are bullet node strands cut down to 45 bulbs per strand, and the same effect happened, whatever port or ports were checked for reverse, the bulbs would not light at all.

 

Edited December 15, 2021 by Orville

[TheDucks]

@Orville

When you reverse, you deal off the bottom of the Pixel deck.  The deck length is set by the controller. (Pixies only 1 deck length per controller).

so YOUR First REAL node is 24, counting UP to 50 (assumes set to 50) You need 24 nodes of logical padding (1-24) in front of your first real node.

did that make sense?

Edited December 15, 2021 by TheDucks
Count UP, not down

[TheDucks]

Try this visualization.

Draw a line on a sheet of paper.  Label the left end 50, label the right end 1

Put a mark about half way label the left side 24 and the right side 25.

Now put the paper face down (on a light table/window). Notice the controller end is now at the Logical 50 end . your data is really counting from physical 50 because my data  deck must be 50

[Mr. P]

Pixels are not numbered meaning they don't have a ID of say 1-50. They retrieve their data by the order the data gets to them whether there are 20 pixels or 100 pixels, whether they are starting at the beginning or the end. If the pixels are not working in the reverse order then there is something in the programming not applied properly.

[k6ccc]

8 hours ago, Orville said:

I figured a cut down strand should still be "reversible", but it's NOT! 

NEVER.  Pixels are ALWAYS unidirectional - period.  Data can only go through the pixels in one direction.

If what you are talking about is the logical reverse that a CCP controller allows, yes you can, but TheDucks explanation is good.

 

 

[dibblejr]

8 minutes ago, k6ccc said:

NEVER.  Pixels are ALWAYS unidirectional - period.  Data can only go through the pixels in one direction.

If what you are talking about is the logical reverse that a CCP controller allows, yes you can, but TheDucks explanation is good.

 

 

I had a vendor tell me the pixels could be placed in reverse, obviously that test didnt work well, I always have to check what I am told when it doesnt make sense. The same pixels had "directional arrows". Needless to say I have not used the vendor since.

JR

[Orville]

5 hours ago, Mr. P said:

Pixels are not numbered meaning they don't have a ID of say 1-50. They retrieve their data by the order the data gets to them whether there are 20 pixels or 100 pixels, whether they are starting at the beginning or the end. If the pixels are not working in the reverse order then there is something in the programming not applied properly.

Sorry, nothing is incorrect in the programming, if I put a 50 light pixel strand on that same controller it works fine, but using a "cut-down" strand to 23 pixels does not work period. "Edit":  That is the first 23 pixels will light at the beginning of a NON-Reversed strand of 50 Pixels, if a 50 strand is reversed, then ONLY the last 23 Pixels will light on that strand, because now bulb #50 is bulb #1 and Bulb #28 is bulb #23. In reverse order, not Bulb #23 to Bulb #1{bulb at the beginning of strand next to controller}, seems the reverse option only sets the last 23 bulbs only on the strand as stated earlier.  So I'm not sure how that could be corrected in a sequence to make that only the first 23 bulbs {1-23, only 23 bulbs} on the shortened strand, just found it easier to just code any shortened strands in reverse within the sequence manually, as that worked out fine.  And seemed to be the best solution to this issue.

I even tried removing all channels from 25-50 so that the info WAS NOT there, still did not work{even tried deleting #24 as well}.  I tried every option and everything possible to make them work using the box that allows you to set the controller to use "reverse strand 1 or reverse strand 2", nothing worked.   So, that's within the controller hardware itself, and there is only one way that I found that works, the sequence has to be coded in reverse for those strands I want to reverse.  I made a test sequence to verify that, and it worked.   But you CAN NOT configure an older Original CCB 5V Controller to reverse any strand that has been "shortened".  It just WILL NOT work.

And since you CAN NOT change the physical pixel bulb count to anything but the default of 50, there is no way this would ever work.  If the "physical pixel count" was able to be changed to 23, or however many pixels the shortened strand is, then this would probably work.  But the default of 50 pixels is unchangeable, so no way this will ever work with a shortened strand of pixels EXCEPT by manually coding it within the actual sequence itself.

@TheDucks, I'm not sure if I fully understand your response on the settings, but just know I tried everything, and they refused to light if the strand was less than 50 pixels!

@Jim, I'm not sure what you mean about "NEVER."  Does that mean this IS NOT possible on a "shortened strand" of pixels?  If so, I already figured that out with my testing and research trying to get the reverse strand 1 or reverse strand 2 to work in the CCB configuration area in the HU, and didn't.

 

Edited December 15, 2021 by Orville

[k6ccc]

My reference to NEVER was actually getting data to flow backwards through the pixels (the physical connection).

As for logically reversing the string, it absolutely will work - but you have to understand what is going on.  Remember, the pixels themselves could not care less what number in the string they are.  So no matter what you do with reverse settings, the pixel closest to the controller is physically the first pixel.  When you logically reverse a string, all you are doing is telling the controller to reverse the order of pixel data that is sent out the port.  The controller has no idea how many pixels are actually there.  It only knows how many you have told it there are.  In the case of the CCB / CCP controllers, you don't have that option, so it THINKS that there are always 50 pixels.  Therefore, if the string is logically reversed, when the controller sends out data, it sends data for pixel 50, then pixel 49, then pixel 48, etc.  If for example the actual string only has 10 pixels, and the string is logically reversed, the pixel closest to the controller gets 50 pixels worth of data in reverse order.  That means that the first 24 bits (logically pixel 50) gets stripped off and processed by that pixel, and the pixel passes along the remaining 49 pixels worth of data (logical pixels 1 - 49).  The next physical pixel does the same thing.  It receives 49 pixels worth of data and strips off the first 24 bits, processes it to control it's LEDs, and passes the remaining 48 pixels worth of data along.  So in the case of only a 10 pixel string, the 10th physical pixel will receive 41 pixels worth of data, and just like every other pixel, will process the first 24 bits of data, and pass along the remaining 40 pixels worth of data - which will fall out the end of the wire.  So your 10 pixel string that is logically reversed will absolutely work, bit it will be treated as pixels 41 - 50.  Since you can't shorten the logical string length in a CCB / CCP controller, those 10 pixels will always be pixels 41 - 50 in the string, or RGB channel sets 41 - 50 on whatever controller ID it happens to be.  Assigning them in Sequence Editor is nothing special - just assign then as channels 41 - 50.  The only time this is a complication is if someone insists on initially building the string in Sequence Editor as a controller (as in a CCB / CCP / CCR) rather than a series of RGB channel sets.  If built as a series of channels, assigning channels 41 - 50 is no harder than assigning channels 1 - 10.  No magic or anything special required other than understanding what channels will be involved.  Although this description is S4 specific, the same is true in S5 except that it is created in the Preview Editor rather than the Sequencer.

 

[Orville]

Thanks, Jim.  That is exact;y what I was thinking you meant, but wanted to be sure.   So I'd have to treat those 23 pixels for a reverse strand as pixels 28-50 in my sequences and NOT as pixels 1-23, then that should fix any reversal problems if I use the HU to configure that particular CCB controller port to be reversed for a shortened RGB strand.  Correct?

 

Edited December 16, 2021 by Orville

[TheDucks]

2 hours ago, Orville said:

Thanks, Jim.  That is exact;y what I was thinking you meant, but wanted to be sure.   So I'd have to treat those 23 pixels for a reverse strand as pixels 28-50 in my sequences and NOT as pixels 1-23, then that should fix any reversal problems if I use the HU to configure that particular CCB controller port to be reversed for a shortened RGB strand.  Correct?

 

That was what I was trying to explain. in my 2 answers.

(the controller does not know the strand is shorter than its setting)

[k6ccc]

Bingo!

 

[Orville]

Thanks, Jim.  I tried it, and it worked fine.   So, all those strands I cut down to a specific # of bulbs, mainly due to a lot of failed pixels in the strand at, or near the end, or were already cut when I got them {purchased used w/controllers}, I'll need to redo my sequences and put those channels back in {easier to just add in a new controller and assign it the same ID #, copy from original to updated one with all 50 bulbs in place}, that's what I did with the 23 bulb count strand, copied the 1-23 channels to 28-50, tried reversing strand in HU and that did work like it should.

I guess the smart RGB controllers aren't as smart as I thought they would be. LOL  I figured they'd know {or could sense} how many actual bulbs were on the strand, but since the default of 50 pixel bulbs can't be changed, I should have figured that one out, Duh uh!   Sometimes the answer is right in front of you, and you just can't see it.

 

 

[TheDucks]

56 minutes ago, Orville said:

Thanks, Jim.  I tried it, and it worked fine.   So, all those strands I cut down to a specific # of bulbs, mainly due to a lot of failed pixels in the strand at, or near the end, or were already cut when I got them {purchased used w/controllers}, I'll need to redo my sequences and put those channels back in {easier to just add in a new controller and assign it the same ID #, copy from original to updated one with all 50 bulbs in place}, that's what I did with the 23 bulb count strand, copied the 1-23 channels to 28-50, tried reversing strand in HU and that did work like it should.

I guess the smart RGB controllers aren't as smart as I thought they would be. LOL  I figured they'd know {or could sense} how many actual bulbs were on the strand, but since the default of 50 pixel bulbs can't be changed, I should have figured that one out, Duh uh!   Sometimes the answer is right in front of you, and you just can't see it.

 

 

ONLY if Reversed. They are just short if normal. Node 1 is still Node 1

[Orville]

20 hours ago, TheDucks said:

ONLY if Reversed. They are just short if normal. Node 1 is still Node 1

Aware of that, however, when reversed Node 50 BECOMES node 1 and node 23 becomes node 28.  Once I copied the 1-23 channels to 28-50, reversed strand in controller it worked.  I know in the beginning of a strand that node 1 is actually node 1, but when reversed node 1 is now the last node in a strand of 50 pixels, which would be node 23 in my case of the shortened strand, so node 23 is node 50 which IS now node 1 in my set-up, since the strand does not have 50 physical pixels this is how the controller sees it.  At least to MY understanding, this is how it works when a strand is reversed that has been shortened to less than 50 pixel nodes on it.