SSC programming does not take for some reason retains old range

[taybrynn]

Hmm

So I was taking a v3 modded SSC and reprogramming it for LESS channel ... I flashed with latest v3 firmware and checksum matches, then I programed it using the latest SS utility for channel range 11-20 but it still keeps the original 1-10 for some reason.

When I program it ... I put on the program jumper, program it, it flashes, click stop, exit program, I remove cat5, remove pgm jumper, re-connect cat5 ... go into xlights tester ... it does not respond to new range, it DOES respond to old range.  HMMM

any ideas ?

[bcstuff]

I remember having problems with this...

The way i found to have the least amount of problems was

When I program it ... I put on the program jumper, program it, it flashes,

remove cat5, then

click stop, exit program, , remove pgm jumper, re-connect cat5

I have also had a couple that didn't take the first try.

Hope it helps.

[rdebolt]

How about erasing the pic and starting over.

[fyb2000]

My experience with the latest firmware and the 'channel program utility' is that the number of channels you give it does not matter. If you hook a string with more pixels than you are telling it has, the extra pixels will still respond to any command send on those channels.
For example, if you program a SSC and tell it, it is controlling a 100 nodes string, but attach a 128 nodes string to it, any effect (using LSP, Vixen or a test program) that does send commands to pixel 101 to 128 will be received and passed to the nodes.
At least that is what I am seeing with SSC v3 programmed with the latest firmware (0xed60 picket 3) and the latest utility (allowing grouping, null node...)

[chrisatpsu]

My experience with the latest firmware and the 'channel program utility' is that the number of channels you give it does not matter. If you hook a string with more pixels than you are telling it has, the extra pixels will still respond to any command send on those channels.
For example, if you program a SSC and tell it, it is controlling a 100 nodes string, but attach a 128 nodes string to it, any effect (using LSP, Vixen or a test program) that does send commands to pixel 101 to 128 will be received and passed to the nodes.
At least that is what I am seeing with SSC v3 programmed with the latest firmware (0xed60 picket 3) and the latest utility (allowing grouping, null node...)

i dont think that would happen, if you revered the order, or used some other setting where the ssc had to rearrange the information to the pixels.

[fyb2000]

It does happen. No reverse order, all the default options except for selecting the etherdongle, and the starting channel number.

[chrisatpsu]

that's what i'm saying though, if you reversed the order, i don't think the extra pixels would respond anymore

[rdebolt]

I've been using a 128 node set of SS to test SSCs and when I program 60 nodes that is all that is lighting for me.

[fyb2000]

It doesn't bother me too much, but reversing the order would. The first time I caught it was due to a bad cutting of a flex. I needed 60 pixels but had cut 63. When I did setup my display, the bottom 3 were receiving the commands for the next string, somewhere else in the display and with completely different effects. It actually helped me finding my bug, so I would call it a feature.
After that I did some test with programming a SSC with less channels than there was on the physical string attached to it. And tested it with the tester in xlights, the one in LSP and some basic effects in LSP. The 'ghost' pixels were receiving commands.