SSC V2 has an output problem (prev - code has a bug)

[MrChristmas2000]

I discovered a bug in the SSC v2 code yesterday while testing.

The SSC was programmed with the following:
Using etherdongle
Start Address 513
Hybrid Mode
Forward
86 nodes (85 + 1 for Hybrid)

Then I tested the programming using LSP and it's hardware test module.

I had been testing the hybrid mode by turning on and off each of the colors, Red, Green, Blue one at a time.
I discovered the bug when I accidentally clicked the Red, then Green and tried to turn the Red off.
The first node in the string diid not change green but changed to blue. Tried this several times and sometimes when I turned the Red off the whole string would stay Blue even though the Green slider had not moved. The only pixel that consistenlty was the incorrect color was pixel 1.

Even when running the programming program and all the LEDs were blinking, the pixel 1 was randomly turning blue, green and white.

I ran the same test with my SSC v1s and this behavior did not occur with those units.

[rrowan]

sounds more like you have a flakey node

When beta testing the new SSC and firmware I never saw that condition

Rick R.

[MrChristmas2000]

I have 30 SSCv2s in a pile.

I have 11 strings of  85 pixel nodes laid out in a mini grid.

I can randomly pick one of the SSCs and every one of them demonstrate similar color problems with pixel 1 allways doing something different than the rest of the string.

I have tested these strings with my SSC V1 with NO color differences. I have only used one of my SSC v1 to test with but I will go back and reprogram some of the other SSC v1 identically as I previously used with the SSC v2 and see if they consistently behave correctly as my first SSC v1 is behaving.

I will update as the test progresses.

[MrChristmas2000]

This is even stranger that when I started this.

I thought ok, mabey the PICs didn't program correctly.

I took one of the SSCv2s that I had tested this morning and read the PIC code and the checksum was incorrect. Well mabey that was the problem. So I reprogrammed the PIC. Closed the PIC programmer. Reopened the programmer and had it read the PICs code for a checksum. The checksum was correct.

I went back to my test setup and using the SSC programming utility I used the above specifications to set the SSC address, mode etc.
The SSCv2 still had problems with pixel 1 not allways being the same color as the rest of the string and even staying on after clicking off on all sliders.

I next took the same SSCv2 back to the programming station and read the PIC and low and behold the checksum had changed! OOPS.

Seems like when using the Lynx string programming utility there is a change in the PICs checksum.

BTW I pulled another of my SSCv1 and ran the EXACT same test WITHOUT and varriation in color when testing.

[Steve Gase]

the pic includes storage for configuration information.
when you change the config, the checksum changes.

[MrChristmas2000]

Ok, I didn't realize that the CS included the storage locations. Seems like the first question out of a lot of people is to check the PIC.

Still the SSCv2 responds differently that the SSCv1.

I can video the output if necessary but it would be a long video showing multiple SSCv2 doing the same thing.

[peteandvanessa]

I had a similar situation with the latest SSC version 2, where my LED Flexstrip was exhibiting the same issue (see your other thread here):
You are not allowed to view links. Register or Login

When you flash the firmware to the SSC (Before you set the address with the utility)

The checksum must match what's in the Wiki:

The checksums are:
Checksums Pickit2 - 19F3 Pickit3 - 1A6B

I was using the Pickit 3 and the checksum never matched 1A6B, even though I thought it programmed correctly. Turned out to be the red USB cable was bad that came with the Pickit 3.

Swopped out the cable, reporgrammed the SSC, and it all started to work correctly.

After that, I still had a issue  of the LED pixels being out by one, turns out that I had missed numbered them in LSP.
After reseting the numbering in LSP, each string reponded to the different color commands in LSP.

*Note My strings are NOT operating in Hybrid mode, they are programmed for individual Pixel mode

Double and triple check you numbering in LSP (try renumbering the channels in LSP by reducing the addresses by one and see if the issue goes away)

If that dosen't work you might have an issue with the string.

[MrChristmas2000]

Pete,

There is no problem in LSP. Otherwise why would my V1 SSCs behave correctly?

The way I confirm this is to have LSP open with my test program loaded and the hardware test window open with the sliders.

Then I connect a SSC v1 to the output of the hub and the SSC v1 output to any of my 11 strings.

That works just fine. Red is red, Green is Green, Blue is Blue and mixing Red and Green then turning one of the colors off like Red for example leaves the pixels turned green. HOWEVER if I disconnect my SSC v1 and replace it with one of my SSC v2s when I turn both Red and Green on then turn Red off the First pixel changes to Blue usually and stays on even after I click 'OFF' for both colors.

When I use the address setting utility with a V1 SSC and the lights blink 'White' they ALL blink 'White from 1 to 85. When I use the utility to set the addressing info on a V2 SSC the first pixel alternates blue, green, white etc and the rest blink 'White' like they are defined to do.

This could be a problem with programming the SSC V2 in the hybrid mode. I'll go back and program them in the pixel mode to see if the problem still exsist but I have my show designed around the alternating use of the various modes.

[peteandvanessa]

Arh, I understand now.

My guess is that there is something set up incorrectly in Hybrid mode.

Here's how the utility defines the different modes (from the help section in the utility):
Set the type of control you want with the Smart String Controller you are programming.

1. In Individual Pixel Mode each node of the string is totally independant of each other.

2. In 3 Channel String Mode The whole string acts as one and is controlled with only 3 channels per strings.

3. In Hybird Mode you can have Both types, the first three channels control the whole string as one and the fourth channel is the first channel of the first node as independant. So if you leave the first three alone and skip them the string acts as if it is Independant Mode. As soon as you set channel one, two, or three to anything but zero the string follows that as if it is in String mode.

As a side note, I have seen issues with the LSP Hardware tests (but only when I've been using the Hardware test on some DMX channels, where I broke out a single universe of DMX on my second Hub)
The issue with the hardware test shows up when I use the test to turn on all the channels on a DMX controller attached to the second hub, if you click on "turn bank on" it doesn't always work correctly. If I use the slider to turn the channels on by slowly moving the slider from off to on, they do respond correctly.
Then if I hardware test to chase the DMX channel, some channels sometimes get skipped.

e.g If I'm chasing 16 DMX channels, then it should chase from 1, 2, 3, 4......... etc until it reaches 16, then it should start back at DMX channel 1.

But what happens sometimes, is that the chase will go something like 2, 4, 5, 7, 8 upto 16.

But this is a known bug that was reported here:
You are not allowed to view links. Register or Login

[MrChristmas2000]

Yes, in LSP I am testing the first node which then controls the whole string.

Ok, now I have tested the SSCv2 in the string mode.

I set the node count to the actual length of the pixel string which is 85 pixels and mode to string mode, forward.

I then using the LSP hardware test, turned on the first 8 pixels first to Red then added in the Green component. That was strange. The First and Last pixel in that group were TOTALLY different colors than the expected cyan color.

The one thing to note is that during the programming is that the first pixel demonstrated the alternating color as before.

All pixels would turn completely off as expected but there were different color problems depending on which primary color you had turned on.

[peteandvanessa]

The one thing to note is that during the programming is that the first pixel demonstrated the alternating color as before.

Do you mean when flashing the firmware to the SSC controller you see the first pixel demonstrating the alternating color?

If you do, I've seen that when the firmware does NOT get flashed correctly to the SSC and the checksum does not match that in the Wiki

[MrChristmas2000]

No the flashing occurs when using the SS utility. There is two programming steps when using the SSC, first programming step is the PIC. I am not refereing to that programming. The PIC is programming with the correct CS.

It is when you hook the string up to do the Pixelnet Address programming when the first pixel is doing the color dance.

[peteandvanessa]

Understood.

I do have one string where the first pixel is faulty (it stays on Blue constantly, but I can change it's color with the LSP H/W test).

What happens if you program it as individual pixels, with the SS utility?

If it works as individual pixels, then it would verify that the SSC and the LEDs are working correctly

[keitha43]

All my pixels program and behave the same using v2 as they did with v1. If you have a 100 count string whether you use hybrid or not you choose 100 as the node count in the address utility. In lsp to make it easier let's say the 1st channel of the first hybrid string starts at 1. I create a controller called string #1. This takes channels 1-3. I then I  create 2 more controllers called 1 up and 1 down with 1 up beginning with channel 4. As it is a megatree with strands running from the ground to the top and back down.

Sent from my Thunderbolt using Tapatalk 2.

[MrChristmas2000]

Ok,

Let me ask this question.

If I have a working SSC, Hub, Pixel string and software program performing as expected shouldn't I expect to be able to replace the SSC with another one no matter what version and expect the same output results?