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

Mudsculpter

Mudsculpter

New member
Trying to get my math right with maximum utilization of the pixel strings vs E68x's

From what I have learned thus far


E68x handles 4 universes,...2048 "channels"

based on on 85 pixels per strings,...32 strings.

85 pixels x 3(RGB) = 255 "channels" per string.

255 pixel strings x 32 = 8160 "channels"

8160 divided by 2048 "channels" = 4 E68x's


is this correct?
 
the e68x can handle 680 pixels. that is 3 channels per pixel times 680 = 2040 channels.

so yes your maths is off lol.
 
Then why is the documentation included with the E68x's say that 4 universes are supported ,...

I also think that before you answer look at what anwer I am trying to get.... Is the number of controllers I need, in fact, 4.


fathead45 said:
the e68x can handle 680 pixels. that is 3 channels per pixel times 680 = 2040 channels.

so yes your maths is off lol.
Click to expand...
 
Last edited:
b.c that is 4 univ worth. each univ is 512 channels. so you are actually short a few pixels but not much at all. 512 channels comes about to around 170 pixels.
 
You cant use the entire universe for a pixel string. A total of 170 pixels per universe can be used because 170 * 3 = 510 channels. You can not move the remaining 2 channels to another pixel string. So what you have is 170 pixels * 3 channels per pixel * 4 universe = 2040 channels
 
ok well after reading yes your math is pretty much there. just think that each univ can handle 170 pixels. also you will have to reinject power about every 50 pixels too. just a heads up.
 
The e68x will address 4 universes of dmx 512 , the math works best at 42 nodes per string of smart 3 channel pixels.

42 (nodes ) x 3 ( channels / per node ) = 126 ( addressable channels / per string )

@ 4 strings this would be 504 dmx channels 126 x 4 = 1 universe



Hope that is clear .
 
I was trying to squeeze out 8 more pixels per controller. Seems a waste not to use them.
I like the 4" spacing of my Megatree now. I do not want to go any wider so 3" spacing was the magic # for me to get started on my calculations. Which led me to 85 pixels per string and it plays well with the division of universes.
 
It is really just playing with the numbers to make it work for you and your application. While a e68x has 16 outputs (4 clusters with 4 outputs each - thus, 42 node strings work well), nothing says you have to use each individual output of a given cluster. Your 85 node strings are nearly, for lack of a better term, a multiple of 42. I imagine you will only be connecting to 2 outputs per cluster, yet still fully utilizing your e68x board. There should be nothing difficult about this type of application other than having to inject more power downstream.
 
I am looking at going with 16 strings of 42 and 16 strings of 43 - 8 of each on two E681's - this will completely utilize the E681. The extra pixels (there will only be 16 total) will be a ball or something on the top. It's probably not enough for a star but I'll figure out something. Doesn't really cost anything more to add them so why not...
 
angus40 said:
If all else fails ............ read the directions .

your math will not work well with the e68x.
Click to expand...

Not sure I follow you.

If you were referring to Mudsculpter, I believe most people use 42 pixel strings because it is the largest string length you can use *if* you want them to all be the same length and use all four connections per cluster. It is also less than the supported 680 pixel limit for each controller *if* you use each cluster in this manner ... 16 outputs x 42 pixels = 672

He wants to use 85 node strings, and what I pointed out was that he could easily run 2 of such strings from each cluster ... 8 strings x 85 pixels = 680

The "adding power downstream" situation is his and his alone to figure out, but the board will control it just fine given that you don't violate any of the other rules that the directions state pertaining to the need for similar strings on each cluster (voltages / ICs / etc.).

budude said:
I am looking at going with 16 strings of 42 and 16 strings of 43 - 8 of each on two E681's - this will completely utilize the E681.
Click to expand...

If you were referring to Brian's post, he stated "8 on each" ...
Contoller #1 = 8 strings x 42 pixels PLUS 8 strings x 43 pixels = 680 pixels :thup:
Contoller #2 = 8 strings x 42 pixels PLUS 8 strings x 43 pixels = 680 pixels :thup:
 
Last edited:
Sorry my bad

I was having tunnel vision moment :)

I thought he said 2 controllers @ 32 strings .

disregard last post

Cheers
 
I was hoping it was that ... I am still trying to fully wrap my brain around pixels and possibly make the jump. As of right now, <caution ... famous last words coming> I am pretty satisfied with regular old incan and LED strings with the addition of the dumb RGB strips I am adding in 2012. Time will tell ... in the Marine Corps, we have a saying - K.I.S.S. - that I try to adopt at all times!
 
Barnabybear, this kind of information is again most helpful. Thank you.
As for the reinjection of power downstream,.. I was not aware of this power loss issue over this seemingly short distance.
 
This is a whatif or is it possible or just brainstorming, instead of running 3 channels of 256 level (256 r 256 g 256b) to each pixel, what if we ran 2 channels of 256 for (172 r 172 g 172 b) or 1 channels of 256 for (85 r 85 g 85 b) to each pixle? Obviously both ends would need to know about this but I suspect the software on one side would be ez, it would just be hard to get pixels that could split the output to the three colors.
 
will it go further than 50 yes, but you start to have issues with them turning on, shuting off, or even responding. so its always best to redo power every 50.
 
gigogig said:
This is a whatif or is it possible or just brainstorming, instead of running 3 channels of 256 level (256 r 256 g 256b) to each pixel, what if we ran 2 channels of 256 for (172 r 172 g 172 b) or 1 channels of 256 for (85 r 85 g 85 b) to each pixle? Obviously both ends would need to know about this but I suspect the software on one side would be ez, it would just be hard to get pixels that could split the output to the three colors.
Click to expand...


Let's not go down that road, because the pixel chip protocol translation doesn't work that way. It certainly COULD be done, but that's not how it's done now.

A DMX universe has 512 channels. Each channel can be a value from 0 to 255. The E68x controller takes a DMX channel and maps it to the pixel chip protocol, which may or may not have 255 values. But you still have the one-to-one mapping of DMX channel to R, G or B level. 3 DMX channels => RGB of a single pixel or element.
 
You must log in or register to reply here.
Back
Top