Is SSC pixel count important? I now think think so...

[Steve Gase]

I originally thought that SSC pixel count setting was not importan unless you were numbering the pixels in reverse.

I thought if I set the max count of 128 to each SSC, then I'd be fine... If I actually have 16 pixels, 85, or 100... it would not make any difference because there would be no pixels to pick up the on/off command from the controller.  If I had 20 controllers, with 16 pixels -- but the SSCs each were programmed for 128 pixels, and all of the starting channels were closely packed (1, 17, 33, 49, ...)  then it still didn't matter, because only 16 pixels on each string would light up.

Today I recalled something that RJ talked about regarding performance -- and it took days/weeks to make sense to me in the above context.

If I have my 16-pixel SSC configured for 128-pixels -- then RJ's firmware will wait on the data for all 128 pixels to arrive before releasing the channel commands to the strings.  That means that the strings will be more sluggish compared to having the SSC accurately reflect the true pixel count.

Does anyone think this conclusion is wrong?

[peteandvanessa]

I'm not sure how the commands are sent to the strings or about waiting to release the commands to the strings, but I think you are correct.

I started with the concept that the S/W has limitations in terms of the throughput of the effects to the strings, so when I set up my Flexstrips, I made sure that a 24 node string was set up as a 24 node string, and a 120 node string was also set up as 120 nodes, so that the S/W and H/W only sent the data to the real channel count.

Now lets say you have two 20 node count strings, in my set up they appear as:
Controller 1 - channel 1 to channel 60
Controller 2 - channel 61 to channel 121

Now lets assume that Controller 1 was only say 10 nodes and the second controller was also only 10 nodes, but you just programmed then as 20 nodes then they appear as:

Controller 1 - channel 1 to channel 30 (but in reality the string responds to channel 1 to channel 60)
Controller 2 - channel 31 to channel 61 (but inreality the string responds to channel 61 to channel 121), so this controller would respond to the commands at channel 61
So if you do ignore the real channel count, you need to pad the spacing on the real channels to take into account the real versus virtual channel counts.

[dpitts]

Pete I think you are forgetting about the start channel that each controller must be given. With correct start channel no padding is needed.

Steve you are correct about small delay when having to wait for bytes that are not really needed. Although probably negligible.

[peteandvanessa]

Pete I think you are forgetting about the start channel that each controller must be given. With correct start channel no padding is needed.

Steve you are correct about small delay when having to wait for bytes that are not really needed. Although probably negligible.

I was forgetting about that 

[charles59]

If I have my 16-pixel SSC configured for 128-pixels -- then RJ's firmware will wait on the data for all 128 pixels to arrive before releasing the channel commands to the strings.  That means that the strings will be more sluggish compared to having the SSC accurately reflect the true pixel count.

Does anyone think this conclusion is wrong?

There are two times one has to consider, the time within a frame of data (4096) and the time between the same byte of data between frames.  Pixelnet is said to support 50msec.  So regardless of how much sooner within a frame, the maximum change it could support is 50msec.
Now, pixelnet is 1Mbps, 1 stop bit (or so I understand).  So there are 10 bits for each channel (one start bit, 8 data  bits, one stop bit).  The delta in time between sending it out after 16 channels versus sending it out after 128 channels is 112 channels (the delta between between 128 and 16) * 10 bits * 1usec (1 Mbit), or effectively 1.12 msec difference within a frame,  but the time for update either way is still 50msec.

[dpitts]

Charles great analysis. One correction. The difference in RGB channels is 112 but 3 bytes are sent per channel so your difference needs to multiplied by three.

If I have my 16-pixel SSC configured for 128-pixels -- then RJ's firmware will wait on the data for all 128 pixels to arrive before releasing the channel commands to the strings.  That means that the strings will be more sluggish compared to having the SSC accurately reflect the true pixel count.

Does anyone think this conclusion is wrong?

There are two times one has to consider, the time within a frame of data (4096) and the time between the same byte of data between frames.  Pixelnet is said to support 50msec.  So regardless of how much sooner within a frame, the maximum change it could support is 50msec.
Now, pixelnet is 1Mbps, 1 stop bit (or so I understand).  So there are 10 bits for each channel (one start bit, 8 data  bits, one stop bit).  The delta in time between sending it out after 16 channels versus sending it out after 128 channels is 112 channels (the delta between between 128 and 16) * 10 bits * 1usec (1 Mbit), or effectively 1.12 msec difference within a frame,  but the time for update either way is still 50msec.

[charles59]

Fair enough, forgot it was in terms of pixels, not channels. 

Either way, it is the update rate that is critical. The time difference within a frame shouldn't be a factor, or then one couldn't sync their display with elements on low starting addresses and devices on high addresses.  If that time difference is noticeable, then one has larger display issues.

[dpitts]

+1

 

Either way, it is the update rate that is critical. The time difference within a frame shouldn't be a factor, or then one couldn't sync their display with elements on low starting addresses and devices on high addresses.  If that time difference is noticeable, then one has larger display issues.

[keitha43]

So what you are saying you wouldn't see a difference? Because last year my megatree ran  spins smoother using hybrid mode and the first 3 channels than when I was in pixel node turning them all on . Of course I was doing it with usb dongle flashed for pixelnet as opposed to the etherdongle I will be using this year.

Sent from my Thunderbolt using Tapatalk 2.

[rm357]

There is a problem if the last address of an ssc is greater than 4096. The ssc waits until all data is received before sending out the pixel data, but the channel address is reset when the the sync byte is received. If the ssc start address  minus 1 + 3* the number of pixels is greater than 4096, you will never receive all of the data and no pixel data will be transmitted.