Pixel string math to calculate how many E68x's one would need?

[mschell]

For those looking at this thread and getting more confused:
The E680 & E681 can control 680 pixels or nodes (pixels from now on). Forgetting rules about types of pixels and power supply problems, the following applies:
A universe is 512 channels or addresses (channels from now on), 3 channels are required to control a pixel.
512 / 3 = 170.667 or 170 2/3.
One of the rules: The 3 channels that control a pixel must be from the same universe.
There for: Only 170 pixels can be controlled by a universe.
Next rule: The maximum length of any string of pixels that can be connected to a E680 or E681 is 170.
The E680 & E681 have 4 outputs per universe (called clusters), so if you want to optimise the number of channels you can connect strings as follows:
1 x 170 = 170 of 170 available.
2 x 85 = 170 of 170 available.
3 x 56 = 168 of 170 available.
4 x 42 = 168 of 170 available.
But all the strings don’t have to be the same length.
So you could have:
3 x 40 + 1 x 50 = 170 of 170 available. The extra 10 (which can be controlled individually of the 40 on the 50 string) could form a feature on the top of your mega tree (I can see a star developing).
The E68x can control 4 universes. So 4 x 170 pixels.
Next rule: Strings cannot span universes. So you cannot have have 2 x 86 = 172 pixels on a pixels universe.
So you can have: 4 x all of the above, or any combination of the above.
Using 1 x E68x: you could build a mega tree with the following:
3 x 40 pixels & 1 x 50 pixels (10 extra) – universe 1
3 x 40 pixels & 1 x 50 pixels (10 extra) – universe 2
3 x 40 pixels & 1 x 50 pixels (10 extra) – universe 3
3 x 40 pixels & 1 x 50 pixels (10 extra) – universe 4
That would give you a 16 string tree with 40 pixels in each string & 40 ‘extra’ pixels for a star or feature on the top.
Hope that helps - feel free to PM me if it's messing with your head.

I'm not sure this is quite right, and here's why:

Each string in a given output cluster (there are 4 clusters) is defined in the E68x as the same length. So for cluster 1, every string is defined as either 40 pixels or 50 pixels. If, as in the example, you have 3 1 x 40 pixel strings and a 1 x 50 pixel string, and want to use all the pixels in it, you need to define the cluster to have 50 pixel strings. You can put 40 pixels on the first 3 outputs, that's fine. However, be aware that the DMX addresses for the 10 "missing" pixels on each of the short strings are still allocated and are part of the 4 universes that you have to play with.

Now, you can get away with using different length strings if you only use one or two of the outputs of a cluster, but remember then that you need to manage the zig zag, null pixel and other stuff yourself, rather than let the E68x do it for you.

Second, strings can span DMX universes, or in E68x terminology, sockets. In the E681 config guide, it mentions specifically that if you had 4 strings x 50 pixels x 3 addresses per pixel => 600 DMX addresses. This will use 510 channels from the first socket, skip 511 and 512, and then use 90 addresses of the 2nd socket or DMX universe. String 4 in that cluster would have DMX addresses from socket 1 and socket 2 or put another way, 20 pixels in DMX universe 1 and 30 pixels in the other.

All of this can mess with your head and it's easy to get confused. Rather than start counting with 4 universes worth of data, start with how many strings of what length you want/need. Remember that clusters have 4 outputs, and so things divisible by 4 is good.


4 clusters with 4 string outputs per E68x.
All strings are defined as the same length and the same pixel chip type in a given cluster. If you use less pixels than are defined, you "lose" addresses.

4 sockets per E68x, which translates to up to 4 separate DMX universes per E68x.

One last thing - you can "group" pixels together to respond to the same address. So you can actually have a 100 pixel string, but only use 50 RGB addresses if you group them in "2s". That means 2 pixels will light up the same color together for a given channel. So that 100 pixel string doesn't use 300 addresses (3 x 100), it only uses 150 (3 x 100/2).

 

[Barnabybear]

I'm not sure this is quite right, and here's why:

Each string in a given output cluster (there are 4 clusters) is defined in the E68x as the same length. So for cluster 1, every string is defined as either 40 pixels or 50 pixels. If, as in the example, you have 3 1 x 40 pixel strings and a 1 x 50 pixel string, and want to use all the pixels in it, you need to define the cluster to have 50 pixel strings. You can put 40 pixels on the first 3 outputs, that's fine. However, be aware that the DMX addresses for the 10 "missing" pixels on each of the short strings are still allocated and are part of the 4 universes that you have to play with.

Now, you can get away with using different length strings if you only use one or two of the outputs of a cluster, but remember then that you need to manage the zig zag, null pixel and other stuff yourself, rather than let the E68x do it for you.

Second, strings can span DMX universes, or in E68x terminology, sockets. In the E681 config guide, it mentions specifically that if you had 4 strings x 50 pixels x 3 addresses per pixel => 600 DMX addresses. This will use 510 channels from the first socket, skip 511 and 512, and then use 90 addresses of the 2nd socket or DMX universe. String 4 in that cluster would have DMX addresses from socket 1 and socket 2 or put another way, 20 pixels in DMX universe 1 and 30 pixels in the other.

All of this can mess with your head and it's easy to get confused. Rather than start counting with 4 universes worth of data, start with how many strings of what length you want/need. Remember that clusters have 4 outputs, and so things divisible by 4 is good.


4 clusters with 4 string outputs per E68x.
All strings are defined as the same length and the same pixel chip type in a given cluster. If you use less pixels than are defined, you "lose" addresses.

4 sockets per E68x, which translates to up to 4 separate DMX universes per E68x.

One last thing - you can "group" pixels together to respond to the same address. So you can actually have a 100 pixel string, but only use 50 RGB addresses if you group them in "2s". That means 2 pixels will light up the same color together for a given channel. So that 100 pixel string doesn't use 300 addresses (3 x 100), it only uses 150 (3 x 100/2).

Correct thankyou,
I've removed my post as it contained infomation the was not correct.

 

[mschell]

Correct thankyou,
I've removed my post as it contained infomation the was not correct.

The intent was not to have you remove ALL the info. Some of it was quite useful and explained things well. However, some of the info was slightly inaccurate based on the E68x implementation as documented by it's designer.

In the end, the goal is to maximize the amount of channels utilized, while also taking into account locations and configurations of light elements.

I put up a line of pixels this year - just under my gutterline. Each 8 foot strip of 32 pixels is mounted in coroplast. I have 6 "strips" across the front of my house. I chose to dedicate a single E681 to those 192 pixels, not because there was a channel limit, but more because of location and connection flexibility.

I plan to have 2 fans of 99 pixels on each side of the yard in front of the house. They are far enough away from my megatree and other pixel elements, that I'll probably dedicate an E681 to each.

Could I get away with just using 1 E68x controller to handle both fans - from a channel perspective, yes. However, the cabling going over the sidewalk tends to get in the way.

So to the original question - how many E68x do you need? The answer is "it depends" on locations, cabling, string size, and pixel type.

 

[fathead45]

wow thanks for the info on the strings having to be matching length. did not know that.

 

[mschell]

The issue is that you only define string length at the cluster level. You can't define different string lengths within a cluster. So either you lose addresses, or make it one long string from a controller perspective.

It's not as much a problem unless you don't know about it.

The beauty of this is that the controller can handle the zigs and zags or null pixels, and can hide it from the user at the sequencing level. The problem is that if you do this, you could lose some level of control from the sequence level.

It's all about trade-offs.

 

[Materdaddy]

The issue is that you only define string length at the cluster level. You can't define different string lengths within a cluster. So either you lose addresses, or make it one long string from a controller perspective.

It's not as much a problem unless you don't know about it.

The beauty of this is that the controller can handle the zigs and zags or null pixels, and can hide it from the user at the sequencing level. The problem is that if you do this, you could lose some level of control from the sequence level.

It's all about trade-offs.

I don't understand the zigs and zags part, can you please explain that a little bit more?

 

[Skunberg]

Barnabybear sorry to see your post removed. It was well worded and helpful to some understanding of this new world some of us are jumping into. Mark was right to bring up possible misleading parts but a edit would have made that post worth putting on the wall or at least a copy paste into the WIKI. Thank you for your time.

Brian

 

[Mudsculpter]

Luckily it was saved as a quote and in case any one wants to cut and paste it to the WIKI after correction...


For those looking at this thread and getting more confused:
The E680 & E681 can control 680 pixels or nodes (pixels from now on). Forgetting rules about types of pixels and power supply problems, the following applies:
A universe is 512 channels or addresses (channels from now on), 3 channels are required to control a pixel.
512 / 3 = 170.667 or 170 2/3.
One of the rules: The 3 channels that control a pixel must be from the same universe.
There for: Only 170 pixels can be controlled by a universe.
Next rule: The maximum length of any string of pixels that can be connected to a E680 or E681 is 170.
The E680 & E681 have 4 outputs per universe (called clusters), so if you want to optimise the number of channels you can connect strings as follows:
1 x 170 = 170 of 170 available.
2 x 85 = 170 of 170 available.
3 x 56 = 168 of 170 available.
4 x 42 = 168 of 170 available.
But all the strings don’t have to be the same length.
So you could have:
3 x 40 + 1 x 50 = 170 of 170 available. The extra 10 (which can be controlled individually of the 40 on the 50 string) could form a feature on the top of your mega tree (I can see a star developing).
The E68x can control 4 universes. So 4 x 170 pixels.
Next rule: Strings cannot span universes. So you cannot have have 2 x 86 = 172 pixels on a pixels universe.
So you can have: 4 x all of the above, or any combination of the above.
Using 1 x E68x: you could build a mega tree with the following:
3 x 40 pixels & 1 x 50 pixels (10 extra) – universe 1
3 x 40 pixels & 1 x 50 pixels (10 extra) – universe 2
3 x 40 pixels & 1 x 50 pixels (10 extra) – universe 3
3 x 40 pixels & 1 x 50 pixels (10 extra) – universe 4
That would give you a 16 string tree with 40 pixels in each string & 40 ‘extra’ pixels for a star or feature on the top.
Hope that helps - feel free to PM me if it's messing with your head.

 

[mschell]

Luckily it was saved as a quote and in case any one wants to cut and paste it to the WIKI after correction...


For those looking at this thread and getting more confused:
The E680 & E681 can control 680 pixels or nodes (pixels from now on). Forgetting rules about types of pixels and power supply problems, the following applies:
A universe is 512 channels or addresses (channels from now on), 3 channels are required to control a pixel.
512 / 3 = 170.667 or 170 2/3.
One of the rules: The 3 channels that control a pixel must be from the same universe.
There for: Only 170 pixels can be controlled by a universe.
Next rule: The maximum length of any string of pixels that can be connected to a E680 or E681 is 170.
The E680 & E681 have 4 outputs per universe (called clusters), so if you want to optimise the number of channels you can connect strings as follows:
1 x 170 = 170 of 170 available.
2 x 85 = 170 of 170 available.
3 x 56 = 168 of 170 available.
4 x 42 = 168 of 170 available.
But all the strings don’t have to be the same length.
So you could have:
3 x 40 + 1 x 50 = 170 of 170 available. The extra 10 (which can be controlled individually of the 40 on the 50 string) could form a feature on the top of your mega tree (I can see a star developing).
The E68x can control 4 universes. So 4 x 170 pixels.
Next rule: Strings cannot span universes. So you cannot have have 2 x 86 = 172 pixels on a pixels universe.
So you can have: 4 x all of the above, or any combination of the above.
Using 1 x E68x: you could build a mega tree with the following:
3 x 40 pixels & 1 x 50 pixels (10 extra) – universe 1
3 x 40 pixels & 1 x 50 pixels (10 extra) – universe 2
3 x 40 pixels & 1 x 50 pixels (10 extra) – universe 3
3 x 40 pixels & 1 x 50 pixels (10 extra) – universe 4
That would give you a 16 string tree with 40 pixels in each string & 40 ‘extra’ pixels for a star or feature on the top.
Hope that helps - feel free to PM me if it's messing with your head.

This much is correct:

The E680 & E681 can control 680 pixels or nodes (pixels from now on).
A universe is 512 channels or addresses (channels from now on), 3 channels are required to control a pixel.
512 / 3 = 170.667 or 170 2/3.
One of the rules: The 3 channels that control a pixel must be from the same universe.

You can have a string of more than 170 pixels, it just takes more than one universe of DMX data to run them, which may limit how many other strings or pixels you can connect.

All strings in a cluster are defined the same length, even if you don't use all of them.

Strings CAN span universes

In a given DMX universe, addresses 511 and 512 are not used, and will be skipped when assigning logical addresses to pixels.