Cutting Cosmic Color Devices

[Jay Czerwinski]

I have read somewhere in this forum that a CCR basically takes the data in from its controller and the first pixel strips off the starting data, and then it passes the remaining data off to the next pixel - which in turn repeats the process. The conclusion was that each pixel section doesn't really care where it is in the series. If you cut some off of the end some time ago and kept it, then youcould splice it back in to the ribbon in the future if there was a pixel failure. It would just pick up where the prior segment left off. Hopefully I am explaining this clearly...

With all of that being said, I am wondering if the same logic holds true for a CCP or CCB. I would imagine they work the same way.

Thanks in advance for any advice/experience you can share.

[mmaness]

My novice guess at an answer would be yes, that is true. I know the CCBs and CCPs have 4 wires, which is typical of intelligent RGB nodes.

[LightORamaJohn]

I have read somewhere in this forum that a CCR basically takes the data in from its controller and the first pixel strips off the starting data, and then it passes the remaining data off to the next pixel - which in turn repeats the process. The conclusion was that each pixel section doesn't really care where it is in the series. If you cut some off of the end some time ago and kept it, then you could splice it back in to the ribbon in the future if there was a pixel failure. It would just pick up where the prior segment left off.

This is true for CCR/CCB/CCP pixels. It is also true for newer versions of the controller chips we will be using.

[edvas69]

This is how all the common pixel ICs work, they work by cascading the data from one pixel to the other whilst stripping that data that is used before passing it on, so effectively each pixel thinks its the first one as its using the first channel data that it recieves.

This means if you have a damaged pixel then its easy to either remove it or cut it out and replace it, the important thing is to ensure you have the input and output connected the correct way.

[Ken Benedict]

This is true for CCR/CCB/CCP pixels. It is also true for newer versions of the controller chips we will be using.

Is there a limit on extending a CCR/CCB/CCF?

I would think the built-in macros would limit at the factory default, but how about individual pixel addressing?

Could I make a longer CCR/CCB/CCF by adding an extension?

[edvas69]

I do know that with the CCR that if you add on a second strip you then set this in the hardware config but there are limitations to the CCR controller when adding multiple strips due to the way it sends data. So if adding an additional strips to the CCR you then loose pixel resolution as each 2 controllable pixel sections are then grouped together, so with 2 CCRs you still get only 50 controllable sections over the 2 strips instead of 100 controllable sections. You also loose dimming resolution as well.

Now this is not a limitation of the CCR strip itself, but instead its a limitation set within the controller due to the way the data is sent multiple times per cycle so as to give an appearance of smoother dimming steps which are equivalent 2 million colours from a 5 bit strip.

The strip itself is only bound by how many channels that a controller can control from one output and the data refresh rate. For example a J1SYS ECG-P2 can control up to 12 strips connected together using power injection to stop voltage drop. But there are limitations depending on the type of pixel IC used and data refresh rate to the pixels. You could use a sandevices E682 or j1sys P12R and these can control up to 3 strips or 170 pixels per output.

So to answer your question, yes the strip itself can be exteneded but if using the CCR controller you will then have limitations on resolution and dimming with each strip you add.

Now as far as the CCB and the CCP i cant answer but i do believe the IC used in these is either 8 or 12 bit so the data needed to be sent to these pixels shouldnt have the same bandwidth limitations as the CCR does.

Edited August 31, 2012 by edvas69

[Ken Benedict]

Good information. Thanks.

Now all I need is a custom LOR card to drive the new WS2811 strips.

The E682 is good for a centrally located controller, but I have some distance issues.

Maybe a smaller version of the ELOR for the WS2811 stuff.

Oh well. Looks like more CCBs in my future.

[LightORamaJohn]

We wanted to go in a direction that would make it easy for people to use pixels. There were two existing paths; matrix controllers that sit on a LAN and E1.31 to DMX controllers that also sit on a LAN. These require people to get power supplies and distribute the power to segments of pixels. Typically 50 pixels for triple-LED/pixel ribbons and 42 for single LED/bulb strings; after this many pixels the voltage drop made the end pixels go pinkish when they should be white. The topology is complex, needing custom enclosures, wide temperature range power supplies and LAN switches and DC power distribution -- more than most customers were willing to deal with.

To simplify this, we chose to fix the number of pixels/string at 50 and built devices that can power and manipulate them. We upped the wire gauge on the bulb strings to solve the pink problem. Fixing the number of pixels lets the software see all RGB pixel devices as the same simplifying programming. We also acquired SuperStar to further simplify programming. The next generation of the CCR controller will be like the CCB/CCP controller (weatherproof, integrated power supply), it will be out next year. We found that we could triple our current maximum network speed which allowed us about 2,700 channels on a network (900 pixels.) This means a simple USB dongle and daisy-chained controllers, making things much simpler for our customers. It also offers a lot of flexibility in placement of devices.

We have a matrix controller in the works, but it is impossible to make it as simple as the daisy-chained controller scheme.

[Crazydave]

What are your distance concerns using the e682?

my Pixels are 30' off the controller and are about 55 feet long.

I'm using 12v WS2801 pixels

the controller itself uses ethernet so it can be 300+ feet away from your computer.

[Ken Benedict]

Yes, the power problem is solved by injecting it after each string; I was curious about the software drivers ability to handle more pixels by adding onto the end.

Distance to some parts are 45-85 feet and the signal may degrade by then. Power is not an issue for me.

I know I could stick an extra pixel or two in between to rebuild the signal, but I'm trying to keep it fairly simple.

This is not a matrix; just linear segments scattered about in the display.