ssc v3, a bit at a loss...

[fyb2000]

Second try to mod a v2 to a v3, and exact same result.
Setup:
-windows 7 running on a bootcamp formatted Mac
-Lynx USB dongle, flashed pixelnet+DMX
-Lynx active smart string HUB
-3 ssc, 2 were functional v2 now v3, the last one has not been modified
-vixen, lsp, xlights

The v3 have been flashed with the test firmware and both are working as expected.

I did the modif of the first one earlier this week, and was not successful making it work. When running a tester within xlights, vixen or LSP I saw the same result. All the nodes on the string are controlled by the same channel (1st channel control all the red, 2nd all the blue and 3rd all the green). Due to lack of time during the week, I decided to start the mod from scratch, on another functional v2, and I have the exact same result showing.
When I run the tests with the old v2 attached to the HUB at the same time than the new one(s), the old v2 is still working well, and all the channels are responding correctly. But on the string(s) controlled by the moded ssc, al the nodes are behaving the same than the first one.
I swapped the cable, the strings, the pics, the 485s. I programmed and reprogrammed all the pcbs down the chain, I changed the jacks being used on the HUB, re-solder all the points, checked for shorts...and I have no clue what is going on.
Both of the v3 were functional v2, the strings used are 128 nodes or 100 nodes, everything flashed using pickit3, and checksums are always verified.
The only thing I am not 100% sure of, is the swap of the resistor. I could not find a place where it specifically says:
'on the v2 pcb, replace the 47ohms resistor by a 220~330ohms one'
It just says 'replace the top resistor by...'
I am pretty sure that I am replacing the correct one, but I am running out of idea and reaching at straws.
I definitely can believe I made a mistake somewhere when doing the first mod, but I can't get how I made the exact same one with the second mod and it gives me the exact same result.
My next canditate as far as what is wrong is the HUB, but again, it works well with the v2s.
I know some of you will want pictures, I will try to get some clean shots as soon as I am done banging my head on the desk.

[chrisatpsu]

if it comes on, and acts like one string, it just sounds like you choose String mode, instead of hybrid, or pixel mode inthe ssc config utility.

[RJ]

Are you using the new version of the SS utility?

What mode are you setting "string", "Hybird" or "indiviual pixels" ?

What are you using for Grouping ? should be "1" for normal use.

As posted you likely are puting them in String or Hybird mode which means it is work perfect. This is what they do in those modes.

Make sure you downloaded the new version of the utility. It should have a shoice for Grouping if you have the new version.

RJ

[fyb2000]

In the first few times I used the latest version of the utility (the one with the grouping option) I didn't change any of the default options, except for the starting channel, and even that I eventually left at '1'. I must have reprogrammed both of them more than 20 times, and started to doubt that what I was seeing was actually what was programmed (was running out of options...) I did a few reprogram with toggling that option to string or hybrid but always put it back to individual pixels before actually transmitting. I just wanted to make sure that the UI was actually in sync with the internal data, again was reaching at straws...
To make a long story short, 90%+ of the time I tested them, it was with 'individual pixel' selected.

[mokeefe]

OK, I think I may have found the issue here (or least point RJ in the right direction).  I made the mod to a V1 SSC and ended up with the same results as fyb2000.  Actually what I saw was that turning channel 1 on turned the first 121 pixels red, turning 2 on turned first 121 to green, likewise for blue with channel 3.  Turning channel 4 on turned pixels 121-128 (i.e. the rest of the string) to red, channel 5 turned them green, etc.  It was like they were set to groupings of 121 (maybe 120 if I miscounted the nodes). This type of consistency in counts and colors really told me this was not a hardware issue with the mod, or cables, or solder joints etc.  It had to be either firmware or programming. Since a number of people posting here and in the other thread indicated that the mod was working fine for them, fyb2000 and I must have been doing something different.

When I tested I used a USB dongle flashed with Pixelnet firmware.  I noticed that fyb2000 said he used the same. So...I switched over to my Etherdongle, reprogrammed the modded SSC with the SSC Utility (new version), and, voila, the strings now behave exactly as they should (i.e. individual pixel control).  I switched back to using the USB dongle to run the lights (not program) and they still behaved properly.

So unless I'm really off base, I believe there is a bug in the new SSC Utility when using the USB dongle to program the V3 SSC's (not sure if it affects V1 or V2).  Hope this helps.

-Mike

[fyb2000]

Mike,
This is big help for me, I really thought I was going crazy and being the only one seeing that problem was really a tough spot to be at. Thank you for sharing the pain woke up this morning after spending most of the night trying a bunch of stuff, and got back at it right away. Always seeing the same issue. The last string I am using is a 100 nodes, so I did not see the grouping that you saw, but I am sure mine would be similar.
I do not have an etherdongle, at least yet, hopefully in the next weeks...

[tbone321]

What do you mean that you did not see the grouping?  If you are not seeing the grouping option, then you are not using the correct utility, you are still using the old one.

[fyb2000]

Read Mike's post and it will make sense. Because my string was 100 nodes, and the 'grouping issue' he saw was for 121 nodes, I could not 'see the grouping that he saw'
I am using the correct utility. That is  a 100%.

[tbone321]

If you can, take a picture of the back of the board where you put the jumper in and if you have a board that you modified without components, take a picture of the front.

[mokeefe]

I really think we're barking up the wrong tree looking for a hardware issue.

The modded SSC fails as described above when programmed via a USB dongle while the exact same modded SSC behaves perfectly fine when programmed via the EtherDongle.  Both fby2000 and I are using the latest NEW SSC Utility.

-Mike

[fyb2000]

With now 2 different users seeing the same thing, and one of them having been able to confirm that there was nothing wrong with the boards themselves, but that the problem seem to be some sort of incompatibility between the new ssc utility and the Lynx USB dongle (the same setup ->works<- with etherdongle), I will wait for either a confirmation that something on the software side cannot handle the USB dongle, or my etherdongles once I'll receive them. Whichever comes first.
I will work my halloween display with v2 and switch to v3 once I get my etherdongle.

[RJ]

Ok that makes sense. It should be easy to fix so give me a day or two to look at it.

RJ

[zwiller]

Glad to see some progress on this issue and it appear to be mostly resolved.  Thanks RJ!

On a similar theme, does this mean that if the test firmware runs successfully that it doesn't necessarily mean a SSC is fully functional?  Would it be prudent to flash the actual pixelnet firmware, program a start channel, and test with a hub to make sure the SSC is 100% after soldering each?

[fyb2000]

What it looks like is that if you are using a etherdongle, you should not be be having any problem at all. If you are using a lynx USB dongle, then you might see the problem, which might hopefully be fixed by a software change, not an hardware one. The SSCs seem to be functional.
As far as the test firmware is concerned, it does not check the whole 'chain'. It is a stand alone that will work and test the output part of the SSC: SSC->smart nodes
The problem, Mike and I have been running into cannot be seen with the test firmware. It looks like it is coming from the input part of the SSC (not tested with the test firmware), and more likely a communication protocol between the PC and the dongle that is behaving strangely with the latest utility.
Thanks RJ for looking into it.   

[rrowan]

I think basically the problem lies with the Smart String Utility program when using the usb dongle. Its a different section of the code to send out data by either the usb or ethernet. Should be a easy fix for RJ once he has a second to look at it.

Rick R.