DiyLightAnimation
Hardware => Lynx Smart String => Topic started by: MrChristmas2000 on July 26, 2012,
-
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.
-
sounds more like you have a flakey node
When beta testing the new SSC and firmware I never saw that condition
Rick R.
-
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.
-
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.
-
the pic includes storage for configuration information.
when you change the config, the checksum changes.
-
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.
-
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):
http://diylightanimation.com/index.php?topic=9046.0
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.
-
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.
-
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:
http://diylightanimation.com/index.php?topic=8819.0
-
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.
-
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
-
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.
-
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
-
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.
-
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?
-
Only if both SSCs are set up exactly the same using the SSC utility. Same start address, same number of pixels, same type of pixels etc.
-
And if they are would you expect the same results?
-
Since your strings are only 85 nodes long use 85 in the address utility not 86 even in hybrid mode. By checking the hybrid button it automatically adds the extra 3 channels. Then 513, 514, and 515 are the whole string channels. Individual pixels start at 516. You might also try xlights hardware tester.
Sent from my Thunderbolt using Tapatalk 2.
-
ok, here is what i would do, start up the SSC util, config a V1 controller like you need it, then hook up a v2 controller and transmit again, changing nothing.
Then go into LSP and test how your V1 works, if it works as expected, then swich it over to a V2, it should act exactly the same.
By programming a V1 and then immediately a V2, you know they are setup the same way
Myk
-
Since a picture is worth 1000 words a video is worth 10000 words.
The first video here is when I am programming the SSC address with the SSC utility. Please note the first node acts differently from all the others.
http://www.youtube.com/watch?v=FmKi2V7MLhY&feature=youtu.be
The next video is me using the Hardware test from within LSP. I use on 2 of the color sliders, Red and Green. I also only use the ON and Off buttons under the sliders.
I first turn on RED then additionally turn on Green etc.
http://www.youtube.com/watch?v=X04zTdl_EXs&feature=youtu.be
I hope these demonstrate what I am seeing.
-
ok, here is what i would do, start up the SSC util, config a V1 controller like you need it, then hook up a v2 controller and transmit again, changing nothing.
Then go into LSP and test how your V1 works, if it works as expected, then swich it over to a V2, it should act exactly the same.
By programming a V1 and then immediately a V2, you know they are setup the same way
Myk
Been there done that. SSCv2 still behaves the same. See the above videos.
-
My money is still on the address being in-correct.
My strings did something very familiar to what you are seeing (1 st pixel off by one color). I reduced their addresses by 1 and all was well again.
Have you tried what keitha43 suggested?
I just checked my strings in the garage (now these aren't running in hybrid mode, but in full string mode)
My smart string for the test has 60 nodes (so 60 x 3LEDs = 180 channels) has a start channel of 613 and runs upto 792
(*Note this, you would assume logically that the channels would start at 613 and run to 793, because 613 + 180 = 793, but they don't, they actually start at 613 and run to 792). This is what gave me issues initially setting up my strings.
So the first three addresses are:
613 - Red
614 - Green
615 - Blue
If in LSP I move the slider on channel 613 I get red
Then I turn the slider off
Then I move the slide on channel 614 I get Green
Then turn the slider off
Then I move the slide on channel 615 I get Blue
Then I turn the slider off
If I then move the sliders for 613 and 614 I get a Yellow color
Then I turn the sliders off
If I then turn on sliders 614 and 615 I get a Light blue
Then I turn the sliders off
If I turn on all three sliders (channels 613, 614, and 615) I get all white.
This will repeat on the next set of three channels (channels 616, 617 and 618) and so on until I get to my last channel in the string which is channel 792
-
Pete,
BTW in hybrid mode all the pixels respond to what the first pixel is asked to do.
I started my addressing at 513 because I am having to reserve the first block of addresses for DMX because of the bug in the e-dongle firmware and I don't know when it will be fixed.
This leaves me with the following addressing:
The first three addresses are:
513 - Red
514 - Green
515 - Blue
Because I have set my strings to the Hybrid mode these three channels control the way the complete string responds to commands.
If I move over to Channels 516, 517, and 518 only pixel 1 will respond etc. Thats why you have to reserve 86 channels for hybrid mode vs 85 for string mode.
If in LSP I can either click the 'ON' button or move the slider on channel 513 I get red
Then I turn the slider off
Then I can click the 'ON' button or move the slider on channel 514 I get Green
Then turn the slider off or click the 'off' button
Then I can click the 'ON' button or move the slider on channel 515 I get Blue
Then I turn the slider off or click the 'off' button
If I click both the 'Red' and 'Green' 'ON' buttons I get a yellow color then I click both 'OFF' buttons.
If I click both the 'Green' and 'Blue' 'ON' buttons I get a cyan color then I click both 'OFF' buttons.
If I click both the 'Red' and 'Blue' 'ON' buttons I get a magenta color then I click both 'OFF' buttons.
Now I have 2 videos made with the same LSP program and the same pixel string in the other 2 videos.
The first shows the 'white' flashing of the string and that pixel 1 is not alternating colors like it did in V2 setup programing.
http://www.youtube.com/watch?v=ool6QR_CIM0&feature=youtu.be
The second video shows the LSP test of the various colors as described above and in the video.
http://www.youtube.com/watch?v=dUwsP3vSiGo&feature=youtu.be
This was done by simply switching out the SSC V2 with a SSC V1 unit. Nothing else changed. Both programmed EXACTLY alike.
-
BTW there is no difference in the v1 and v2 code that would cause this behavior. Only the pins controlled changed. it is one line of code different and this is the pin control command.
RJ
-
RJ
That's what makes this so strange.
The V2 should be a drop in for the V1 unit but something isn't the same.
I'll try something different tomorrow possibly use xLights as the testing program.
I'll go back and reprogam the PICs in both uints (V2 and V1) to a fresh start. Then use the Utility to set the address identically in both test units, then try my original LSP test sequence. If the results are not identical then I'll move on to try testing with xLights and post those results.
I need 8 of the SSC V2 for my expanded megatree this year. <fp.
-
I would double check your wiring on both ends of the ssc v2.
White/orange stripe in #1.
Orange #2
White/blue stripe, Blue, White/green stripe all in #3
Green, White/brown Stripe, Brown all in #4
On the other end I see where people have posted the wiring in the 3 pin connectors has changed so you might want to ohm it out to see if your data line hasn't switched with another line. Also when you programmed with the address utility did you choose 85 instead of 86?
-
I don't use the dongles anymore for connections. Both V1 and V2 are wired exactly alike.
The test I am going to do tomorrow will include 2 SSCv1s and 2SSCv2s configured EXACTLY alike.
Since pixenet works very simillarly to DMX, I can connect all 4 to the same hub. All 4 SSCs should respond EXACTLY alike. If not I will video it and post the video.
If the problem goes away I'll post that as well and chalk it up to gremlins. >:D
-
Both V1 and V2 are wired exactly alike.
How can this statement be true
Version 1 was wired like ->
1 - White with Orange Stripe
2 - Orange
3 - White with Blue Stripe
4 - Blue
5 - White with Green Stripe
6 - Green
7 - White with Brown Stripe
8 - Brown
Version 2 was wired like->
1 - White with Orange Stripe
2 - Orange
3 (Positive)
White with Blue Stripe
Blue
White with Green Stripe
4 (Ground)
Green
White with Brown Stripe
Brown
-
No what I mean is that I do NOT use the RJ45 dongles, I have replaced them with 4 pin connectors. There are 4 pads in each SSC that are Signal 1, Signal 2, Power, and Ground. The 4 pin connectors are waterproof and I have RJ45 to 4 pin adapters for attaching the SSC to the hub.
-
I was referring to the 3 pin connector that some people use to connect the ssc to the node string where you have power, ground, and data connections. If you are using that, and if you have an older version on the pixel string side, and a newer version 3 pin on the ssc v2 side, and an older version 3 pin on the ssc v1 side, it could explain why swapping the ssc could cause a problem as the 3 pin dongle on the ssc v2 side could have wires swapped.
-
how old are these pixel strings? early 2011? late 2011? (before/after sept/oct) or 2012?
it looks like the first pixel is malfunctioning.
i'd set up a v1, and a v2 ssc with test firmware, and run them, the differences between the two ssc's is about of power provided to the strings. the v2 might be just above, or below that threshold to make it act up.
-
I almost thought I had replicated your issue. I finished putting firmware on 8 V2 SSCs and programming them using the smart string utility and my red pixel 1 would not light up using xlights tester. I thought it might be the flexstrip so I tried two others and had the same pixel 1 red failure. I exited all programs on the PC and connected up a V1 SSC and ran the xlights tester again. This time the pixel 1 red worked. Swapped out the V1 SSC for a V2 SSC and the red continued to work. I have now hooked up 8 V2 SSCs connected to 8 flexstrips and all pixels are working as expected. The only thing I can think of is that I had both the SSC utility and xlights running at the same time which is supposed to be a no-no. I discovered that after I had exited the SSC utility and then tried to start it up again to change the V1 SSC for this test while xlights was minimized. I then made sure that all programs were exited and then started over with the xlights utility and I have had no failures at all since then.
-
I almost thought I had replicated your issue. I finished putting firmware on 8 V2 SSCs and programming them using the smart string utility and my red pixel 1 would not light up using xlights tester. I thought it might be the flexstrip so I tried two others and had the same pixel 1 red failure. I exited all programs on the PC and connected up a V1 SSC and ran the xlights tester again. This time the pixel 1 red worked. Swapped out the V1 SSC for a V2 SSC and the red continued to work. I have now hooked up 8 V2 SSCs connected to 8 flexstrips and all pixels are working as expected. The only thing I can think of is that I had both the SSC utility and xlights running at the same time which is supposed to be a no-no. I discovered that after I had exited the SSC utility and then tried to start it up again to change the V1 SSC for this test while xlights was minimized. I then made sure that all programs were exited and then started over with the xlights utility and I have had no failures at all since then.
Interesting Jim, this is what I thought I saw last year as well but I thought it was just a glitch of some kind. Just a +1 here.
-Paul
-
Mr. C -
I tried to duplicate your problem using xLights and Vixen but I could not
-
I was referring to the 3 pin connector that some people use to connect the ssc to the node string where you have power, ground, and data connections. If you are using that, and if you have an older version on the pixel string side, and a newer version 3 pin on the ssc v2 side, and an older version 3 pin on the ssc v1 side, it could explain why swapping the ssc could cause a problem as the 3 pin dongle on the ssc v2 side could have wires swapped.
Been there done that as well.
I had recently received another batch of 3 pin connectors this year and those were even different from some I had received earlier and ran into the problem of going by color codes instead of ohmin it out.
If you have the output wired incorrectly the pixels don't work period.
The output works but I am getting incorrect colors and the first pixel misbehaving incorrectly.
Well I tried this today.
I took 2 V1 and 2 V2 SSCs and reprogrammed the PICs, reset the address on each one never closing the utility.
Now I did do 1 thing different and this may have been part of the problem but it's weird if it is, I tightened each of the connectors instead of just plugging them together.
I hooked all 4 to the same hub so they all would receive the same commands and should respond identically.
The pixel 1 problem seems to have gone away in this setup BUT, yep there is that little word.
Each color alone looks ok BUT when you start to mix colors things are not all equal. Especiially when you turn on all colors to make white the white produced by the V1 is different from the white produced by the V2 SSCs.
The Yellows and cyan are close but there is some varriation.
I would have posted pictures but the pixels are so bright they just wash out any differences.
I'm going to put this to bed for now until someone with a mixed SSC V1/V2 environment complains about color differences.
Thanks to everybody for all the input.
-
I would venture to say the color difference is a product of the NODES
Each and every node is different ant there is no fool proof way to build rgb leds without variations.
Sitting them in a room if you look close enough they might all look different but outside during the show no one (but us) will see it.
just my 2 cents
Rick R.
-
There may certainly be reasons not to do this for your particular setup, but in my mind the best practice for a production environment, and particularly in a testing environment is to have a way to easily swap out elements of your equipment.
I recommend the 3-conductor water-proof connectors to join the SSC to the strings. Whether you go with 4-conductor or rj45 connectors to join the SSC to the hub, doesn't matter. Important is that when you suspect strings, you can easily swap a string for another. When you suspect SSC, you can easily do the same with the SSC. when you have questions about cables, hubs, and dongles, you have the same ability to perform swaps.
If you can get ONE setup to function as you intend, you make incremental swaps to verify one piece at a time to "bless" each element.
Knowing you from our conversations and from from your postings, I suspect that you have done all of this, Tom. So my purpose in mentioning this is to encourage others to think about decomposing their equipment into pieces to make it easier to perform this variety of debugging.
When it is suggested that the manufacturing of lights differ, and that explains the variation... I would expect you to test that theory by quickly swapping with another string -- and changing nothing else -- to see if the strings reflect a difference. If you think that the ssc v1/v2 difference is the cause, then swap out only the ssc but keep EVERYTHING else the same.
Eliminating variables is the surest way to isolate a problem.
Again, I am sure that all of this is obvious to most people in this forum, but for the one or two that are new to this hobby, it might have some benefit.
-
The color difference is not due to the difference in the strings.
First the strings are well broke in from last season having been used in the mega tree. I know sometimes a pixel fails but I have enough stand in strings if I suspect that.
Second if I swap the strings from the V1 SSCs to the V2 SSCs the color change follows the SSCs not the strings. Some of the color blends are subtle but the most aparent is with the white.
Since I am using them in the string mode (for these test and in my show) the whole string is the same color as pixel 1. This not only test the output of the SSC but the whole string.
Now there may even be something different with the SSC1s because a bird whispered in my ear that they were having color and flicker problems using I believe it was the square elements but when they got their SSC2s up and running that those problems stopped.
I do hope that this adventure is of some value to everybody. Sometimes something may work perfectly in one environment or configuration but behaves totally different in another setup. Even if a product has been beta tested for weeks by dozens of beta testers I bet I could come up with a way to 'breat' it or find the bugs. ;D
Just look at Microsoft and how many beta testers they have with their operating system and it seems like the minute that the product is released that updates start coming in.
-
The color difference is not due to the difference in the strings.
First the strings are well broke in from last season having been used in the mega tree. I know sometimes a pixel fails but I have enough stand in strings if I suspect that.
Second if I swap the strings from the V1 SSCs to the V2 SSCs the color change follows the SSCs not the strings. Some of the color blends are subtle but the most aparent is with the white.
Since I am using them in the string mode (for these test and in my show) the whole string is the same color as pixel 1. This not only test the output of the SSC but the whole string.
Now there may even be something different with the SSC1s because a bird whispered in my ear that they were having color and flicker problems using I believe it was the square elements but when they got their SSC2s up and running that those problems stopped.
I do hope that this adventure is of some value to everybody. Sometimes something may work perfectly in one environment or configuration but behaves totally different in another setup. Even if a product has been beta tested for weeks by dozens of beta testers I bet I could come up with a way to 'breat' it or find the bugs. ;D
Just look at Microsoft and how many beta testers they have with their operating system and it seems like the minute that the product is released that updates start coming in.
Try measuring the output voltage from the SSC using a digital meter and comparing that value for v1 and v2. I wouldn't bother measuring the data line, just the ground/12v lines.
maybe the visual differences you are seeing are due to voltage differences and their effect on intensity.
-
Now this I can confirm. On ssc v1 white is brighter(like a warm white). On the ssc v2 it has a more blueish color(almost a cool white). But just reducing blue won't make it match the color of the ssc v1. You can't tell on just red, blue, or green. With yellow it is really close. With red and blue on their is a big difference. scc v1 is more of a fusia color. SSC v2 is more a light purple so their is more red on ssc v1. With blue and green on, ssc v2 is more a true baby blue and the ssc v1 has a little too much green in it. These are all ip68 pixel nodes Ray replaced in Jan for me. Bottom line there are color differences between v1 and v2 probably due to the increased level they are being driven at. I am not saying the colors are bad but you may want to not mix versions in your display.
-
Try measuring the output voltage from the SSC using a digital meter and comparing that value for v1 and v2. I wouldn't bother measuring the data line, just the ground/12v lines.
maybe the visual differences you are seeing are due to voltage differences and their effect on intensity.
Ok,
V1 measured 9.70v feeding the string
V2 measured 9.30v feeding the string
Both strings are 85 pixels long.
I even tried using my hub with the largest 700watt supply I have.
It's good to see someone else sees the color difference between V1 and V2.
You may be correct, I may have to use all V2 in my megatree and disperse the rest among a copule other elements.
-
Now this I can confirm. On ssc v1 white is brighter(like a warm white). On the ssc v2 it has a more blueish color(almost a cool white). But just reducing blue won't make it match the color of the ssc v1. You can't tell on just red, blue, or green. With yellow it is really close. With red and blue on their is a big difference. scc v1 is more of a fusia color. SSC v2 is more a light purple so their is more red on ssc v1. With blue and green on, ssc v2 is more a true baby blue and the ssc v1 has a little too much green in it. These are all ip68 pixel nodes Ray replaced in Jan for me. Bottom line there are color differences between v1 and v2 probably due to the increased level they are being driven at. I am not saying the colors are bad but you may want to not mix versions in your display.
I don't know what you mean by level. What you need to check is the voltage output on the 12V side of the controller under load. If one is putting out less voltage,than the other, I would look at the one putting out a lower volage for bad solder joints and make sure that there are no broken wires in the dongle that could be limiting current flow. The controller has no control in the shading of the nodes other than sending the commands to the nodes an since both of them send out the exact same commands to the nodes, that can't be the issue. The V2 sends out a signal that can sustain a much higher load than the V1 but that is not what sets the color.
-
Now this I can confirm. On ssc v1 white is brighter(like a warm white). On the ssc v2 it has a more blueish color(almost a cool white). But just reducing blue won't make it match the color of the ssc v1. You can't tell on just red, blue, or green. With yellow it is really close. With red and blue on their is a big difference. scc v1 is more of a fusia color. SSC v2 is more a light purple so their is more red on ssc v1. With blue and green on, ssc v2 is more a true baby blue and the ssc v1 has a little too much green in it. These are all ip68 pixel nodes Ray replaced in Jan for me. Bottom line there are color differences between v1 and v2 probably due to the increased level they are being driven at. I am not saying the colors are bad but you may want to not mix versions in your display.
I don't know what you mean by level. What you need to check is the voltage output on the 12V side of the controller under load. If one is putting out less voltage,than the other, I would look at the one putting out a lower volage for bad solder joints and make sure that there are no broken wires in the dongle that could be limiting current flow. The controller has no control in the shading of the nodes other than sending the commands to the nodes an since both of them send out the exact same commands to the nodes, that can't be the issue. The V2 sends out a signal that can sustain a much higher load than the V1 but that is not what sets the color.
If one difference between v1 and v2 is the resistors being used, wouldn't that translate into the intensity of the pixels at some point?
if the SSC is providing 256 levels for each channel and v1 provides 256 levels over the voltage 0v-9.7v and v2 provides its 256 levels over 0v-9.4v -- wouldn't it be reasonable to expect the strings using v1 to look "brighter" than v2 when everything else is the same?
It was also my understanding that the voltage at the end of a string is lower than at the start -- because each pixel takes out its share of the current. as a result, there is a subtle difference between the intensity at the start of the string, and the intensity at the end.
isn't the same thing at work here?
The V2 sends out a signal that can sustain a much higher load than the V1 but that is not what sets the color.
I thought red, green, and blue each have different color characteristics when you compare them to the other... they do not evenly lower as the levels are decreased. so i'd expect voltage to again play a role with color. if you step "purple" down from level 255 to level 0 by decreasing the red and blue at the same rate, I'd expect the color to SLIGHTLY shift towards blue at one point, and towards red at another point because they are different in how power translates to visible light.
maybe i'm way off on these suppositions. :) my wife would tell you it wouldn't be the first time.
-
Mabey I'll just have to diagram out both units and see what the circuit differences is.
There is a difference in color and intensity with rectangles as you go down the line. RJ even suggested that injecting power from the opposite end from the SSC would help and it did correct the intensity and some color shift on my rectangle elements.
The Pixel strings did not demonstrate the same intensity or color shift up the string, the color was consistent on the string just different from strings connected to a V1 SSC and a V2 SSC.
-
9.7v vs. 9.3v?
I'd start looking for bad solder joints or something going on in the RJ45 pigtail.
The 12v for the strings flows through the ssc, but it should not be reduced or limited by the ssc. Whatever you have at the input should be present on the output.
I'm guessing that the increased drive may increase the current draw a very small amount, but to get a 0.4v drop in output voltage just by swapping a v2 for a v1 ssc tells me there is another issue like a broken wire or you are running it on a 500 ft cable... Which would be a bit excessive.
RM
-
9.7v vs. 9.3v?
I'd start looking for bad solder joints or something going on in the RJ45 pigtail.
The 12v for the strings flows through the ssc, but it should not be reduced or limited by the ssc. Whatever you have at the input should be present on the output.
I'm guessing that the increased drive may increase the current draw a very small amount, but to get a 0.4v drop in output voltage just by swapping a v2 for a v1 ssc tells me there is another issue like a broken wire or you are running it on a 500 ft cable... Which would be a bit excessive.
RM
keith's confirmation seems to question a cabling or soldering problem. also, I thought (but maybe assumed incorrectly) that MrC had multiple v2s which had the same issues.
-
The more I read this, it sounds like a voltage distribution problem. I measured a 0.25 volt drop from my SS Hub through a 6 foot CAT5 cable, to the output of a V2 SCC with 20 square nodes attached all on (white).
-
Now this I can confirm. On ssc v1 white is brighter(like a warm white). On the ssc v2 it has a more blueish color(almost a cool white). But just reducing blue won't make it match the color of the ssc v1. You can't tell on just red, blue, or green. With yellow it is really close. With red and blue on their is a big difference. scc v1 is more of a fusia color. SSC v2 is more a light purple so their is more red on ssc v1. With blue and green on, ssc v2 is more a true baby blue and the ssc v1 has a little too much green in it. These are all ip68 pixel nodes Ray replaced in Jan for me. Bottom line there are color differences between v1 and v2 probably due to the increased level they are being driven at. I am not saying the colors are bad but you may want to not mix versions in your display.
I don't know what you mean by level. What you need to check is the voltage output on the 12V side of the controller under load. If one is putting out less voltage,than the other, I would look at the one putting out a lower volage for bad solder joints and make sure that there are no broken wires in the dongle that could be limiting current flow. The controller has no control in the shading of the nodes other than sending the commands to the nodes an since both of them send out the exact same commands to the nodes, that can't be the issue. The V2 sends out a signal that can sustain a much higher load than the V1 but that is not what sets the color.
If one difference between v1 and v2 is the resistors being used, wouldn't that translate into the intensity of the pixels at some point?
Nope. Those resistors are in place to restrict the current being drawn from the outputs of the pic but that is the control signal. Since the new design uses 3 or was it 4 pins from the pic, more current is available so the resister value was reduced. The current here does not affect the color of the node, justhow much f a load they can put on the signal.
if the SSC is providing 256 levels for each channel and v1 provides 256 levels over the voltage 0v-9.7v and v2 provides its 256 levels over 0v-9.4v -- wouldn't it be reasonable to expect the strings using v1 to look "brighter" than v2 when everything else is the same?
Don't confuse smart and dumb nodes. The smart string controller simply send a command to the nodes that tells it what level tp go to and with PixelNet, it's really 255 since 170 is a reserved command and is never sent as a level to the nodes. Dumb string controllers are what sen actual levels of voltage to the device that they are controlling. As for brightness, that is a relative term, especially wit LED's. LED's have a very different dimming curve than Icans and in many cases wven withdiferent color LED's. A slight voltage change could affect one color LED more than another which would change the color of the node. If you are using only one color, then you might see a "brighness" change.
It was also my understanding that the voltage at the end of a string is lower than at the start -- because each pixel takes out its share of the current. as a result, there is a subtle difference between the intensity at the start of the string, and the intensity at the end.
isn't the same thing at work here?
That is due to voltage drop in the 12V wires. The same thing happens to landscape lights which have no control signal at all.
The V2 sends out a signal that can sustain a much higher load than the V1 but that is not what sets the color.
I thought red, green, and blue each have different color characteristics when you compare them to the other... they do not evenly lower as the levels are decreased. so i'd expect voltage to again play a role with color. if you step "purple" down from level 255 to level 0 by decreasing the red and blue at the same rate, I'd expect the color to SLIGHTLY shift towards blue at one point, and towards red at another point because they are different in how power translates to visible light.
maybe i'm way off on these suppositions. :) my wife would tell you it wouldn't be the first time.
You are correct here bu the voltage is the 12V not the signal.
-
in both situations (smart and dumb nodes), the leds are controlled by pulse width modulation, so there is no reduction in voltage. when it's on (even for a fraction of a second, it's full on, and when it's off, it's full off. The only thing that changes is the duration.
so, now that a lot of ideas have been thrown around, and lots of things have been tried.... does the first node still act up, or does that still happen now? (your original problem?)
-
I am going out of town for a few days and will try another set of both versions and on different pixel sets to see if they act similarly Tuesday if nobody else tries this before then.
Sent from my Thunderbolt using Tapatalk 2.
-
i appreciate the discussion, thanks guys.
-
Just a quick note this morning before I do further diagnosis.
The color difference problem does occur over multiple SSCs.
The first pixel problem with the hybrid programming seems to have stopped during my last test. Its one of those mysterous problems that couldn't quite be tied down to a source.
-
so.....
yay! first problem somehow is solved, and now you're dealing with color correction?
I'm assuming....
all your SSCv1's act the same with the leds...
all your SSCv2's act the same with the leds...
but...
your SSCv1's act differenly than your SSCv2's?
maybe RJ can chime in. does the SSCv2 produce a different voltage or amperage to the leds?
-
Nope,
The 12 volts is passed throught the controller from the input to the output with nothing in between.
The output of data with increased current capacity does not change the data. the chips on the leds themself create the level of light output based on the value sent to them. It should not be possible for the change on the SSC v2 to change the output. It outputs ones and zeros which can only be in one of two states and this is controlled from your software. There must be some other variable being missed.
Different input voltage will vary the level because it is based on PWM by the pixels chips and that means it is 60% of something if set there. 60% of 11 volts is different than 60% of 11.5 volt as an example.
RJ
RJ
-
I think they said the only 1 resistor value was changed. And resister was related to data line only. The other change of connecting four pins to data line was data only change also. So where is a change that would make colors different?
-
Rj beat me. I hate typing on my phone. :)
-
google voice to text is your friend on your android phone :)
-
With the LEDs off, you should have pretty close to 12 volts at the ssc. If not there is probably a wiring problem - the ssc by itself should not be drawing enough power to cause a significant power drop.
The cat 5 cables have some resistance - 25 ohms per 1000 feet for 24 gauge wire. Skipping all the math, with 3 wires for ground and 3 wires for hot on a 100ft Ethernet cable you would have about 1.6 ohms of resistance in the wires.
If you had a maximum length string all on, you could pull 4 amps, which would drop the voltage at the SSC to about 5.6 volts - which is still high enough to run things...
-
All I know is I saw color differences. When I get back from my mini vacation Tuesday I will try different v1 & v2 ssc's along with 2 different sets of equal number nodes if nobody else has tested theirs by then. It wasn't noticible on single red, green or blue and I probably wouldn't have noticed the difference until Mr Christmas mentioned it. I tested with both last years and this years ssc's programmed to the same start channel so I could have both nodes on side by side at the same time and tested both in xlights and lsp. It was most noticable in white and red and blue on. Anybody got any old and new ssc's to test besides me?
Sent from my Thunderbolt using Tapatalk 2.
-
Did you swap the string on the controllers and were both controllers set to the same addresses?
-
Did you swap the string on the controllers and were both controllers set to the same addresses?
If you were asking me both controllers were set to the same address but I didn't swap strings as I had errands to run before my vacation. Last year my strings were soldered directly to the ssc v1. This year I am changing how my tree will assemble by taping all my nodes to 1/2 x 3/4 strips of wood. So I am cutting off the old ssc's and attaching the new ssc v2's as I go along. I am still waiting on 3 pin connectors from Ray to make them quick change. When Mr Christmas reported this I just twist tied one of the old ssc v1 units that had the same address as one of my new units to a spare strand I had but it wasn't the exact same length. I will do everything exact with total different parts on Tuesday to see if I get the same results if nobody else that had v1 last year tries it before then. This changeover is taking much longer than expected. I have gone through 7 rolls of super 88 electrical tape and am only halfway done as it takes about 4 hours per strand. It is kind of a hybrid RJ Academy tree (except with pixel nodes) and Mr. Monkhouse colormotions tree.
Sent from my Thunderbolt using Tapatalk 2.
-
All the controllers were set to the same address.
Will test more today but family company may interfere with getting it done.
-
The only way to validate this issue is to use the same string on the two different controllers. Unlike icans, LED's actually generate the color of the light which is why many people see the light output from them as "cartoonish" when compared to icans. Different manufacturers have slightly different colors. Just because they may have all come from Ray doesn't mean that the LED's making up the nodes were all sourced from the same manufacturer. One of the ways to keep the costs down is to buy from whoever is selling for less at the time and since color consistancy between strings is not all that critical for Christmas lights, you may be seeing the results of that and not an issue of the SSC.
-
I agree tbone I have strips from Ray where white has more of a blueish tint and others that have more of a reddish tint to them.
-
Another thing is the voltage available for the last node of a long sting is lower than the first node. This will result in lower LED current and a difference in intensity and perceived color.
-
Okay after catching up some sleep after my mini vacation, I started testing again. The differences in color is the nodes themselves. My best guess is when mine started failing last Christmas season Ray sent me some extras nodes to replace as they failed. They look similar to the ip68 he replaced mine with after the season. They were the same width/circumference as opposed the the skinnier with flat sides as my originals and were sealed almost to the end where the wires go in. But there is a distinct difference in color between those and the ip68 version. Most noticable in white and purple(red & blue on). One interesting thing I noticed during testing is sometimes when you turn each slider off, then on, then off ect. you may get a different color occasionally if 2 strands are set to the same address. It is easier to see if you grab one slider and drag it down slowly you will see the strands pulse occasionally. If you use the keyboard and decrease one step at a time you will see the color change. Both version ssc's did it and it was random and only occasional. Since I never saw it happen during last years shows I am not going to worry about it.
-
OK, solved my problem. I converted some of my SSC2s back to SS1s and the problem went away. What can I say.
-
What exactly does that mean???
-
I just determined the differences between V1 and V2 and made some engineering changes.
It's fairly simple but I won't post them here because it might make someone a little unhappy.
-
I think I am seeing Mr. Christmas problem. I have just finished converting my pixel node mega tree to being attached to wood strips. 880 feet of electrical tape and weeks later I began testing my strips today. I have 12 strands 84 nodes long. Of the 12 only one performs correctly with a v2 ssc. The other 11 behave like this- I run my strings in hybrid mode so I test with the first 3 channels of the string to turn on all nodes of the strand at the same time. First I turn all 3 channels on to create white. I then turn off green and notice node 1 stays white. The rest are yellow but all should be purple. Turn them all back on then turn red off and the string turns red and the first node stays white. You can turn on and off each channel and the first node will usually be a different color. I have even seen node 1 be blue with all 3 channels turned off. With a v1 ssc the same string acts normally. I saw these same symptoms on 11 different strands and 11 v2 ssc's. I wonder if node 1 is being driven too strongly? Now part of the problem could be these ip68 nodes Ray replaced my original nodes I ran last year with. Although testing my original v1 ssc's fixed the problems I was seeing on v2 ssc's, I had 4 strands that still did strange things. 2 would lock on all white and on the other 2 had the last node turned white instead of the correct color. Taking the groung wire from the end of the string and connecting it to the ground at the beginning of the strand seemed to help that. Those 2 symptoms were with the v1 ssc's. I didn't not have to use any extra grounding on my original nodes last year but they did terrible with rain last year. Hence the replacement.
-
Tonight I will test the 1 v2 that was working with other strands to see if it works on those and some other ssc v2's on that particular strand to see what happens. Also I will try reflashing a pic just for grins.
Sent from my Thunderbolt using Tapatalk 2.
-
if the v2 ssc is overdriving the 1st pixel - one solution if you have the extra pixel is to set it as a null node?
Myk
-
Okay did more testing tonight, the problem is being caused by the ip68 nodes Ray replaced my original nodes with in January. I determined this by attaching and testing the other 11 v2 controllers to the 1 strand (out of 12) that worked with the 1 v2 controller. All v2 controllers worked with that single strand. For some reason the v1 controllers seem to be able to compensate for whatever the problem with the strands is better than the v2 ssc's. RJ will probably have to weigh in on this. The only exception is on 2 strands white would freeze or the last node (#84) of the strand would become the wrong color. I read somewhere where someone connected the ground wire from the end of the strand back to the beginning which seemed to help the v1 ssc's but not v2's. To test the symptom turn on all 3 channels in hybrid mode to get whole string white. Then turn off blue channel. First node turns blue(?) and the rest of the string turns baby blue(?). The whole string should be yellow. I tried replacing the 1st node with a known good one and the symptoms didn't change. Reflashing with 1 null node just moved the 1st node symptom to the 2nd node. I noticed even during the start channell white flashing the the 1st node color seemed off but I could be mistaken as it is white and rapid. As a last ditch effort I have flashed one of my ssc v1's to test firmware and will let it run overnight (on 1 string) to see if I get a clue as to a faulty node somewhere. After 30 minutes so far all nodes working normally with the test firmware so far. I wish I had a test firmware for the ssc v2 to try as v1 ssc's seem to compensate better for whatever is wrong with these 11 strands. I may have to give up and order flexstrips or something unless I can locate the problems. Any help appreciated as I spent 1000 on the original nodes and then 250 for shipping to send my old ones back and get the ip68's. I am sure the flexstrips will be even more expensive. :-X
-
Okay did more testing tonight, the problem is being caused by the ip68 nodes Ray replaced my original nodes with in January. I determined this by attaching and testing the other 11 v2 controllers to the 1 strand (out of 12) that worked with the 1 v2 controller. All v2 controllers worked with that single strand. For some reason the v1 controllers seem to be able to compensate for whatever the problem with the strands is better than the v2 ssc's. RJ will probably have to weigh in on this. The only exception is on 2 strands white would freeze or the last node (#84) of the strand would become the wrong color. I read somewhere where someone connected the ground wire from the end of the strand back to the beginning which seemed to help the v1 ssc's but not v2's. To test the symptom turn on all 3 channels in hybrid mode to get whole string white. Then turn off blue channel. First node turns blue(?) and the rest of the string turns baby blue(?). The whole string should be yellow. I tried replacing the 1st node with a known good one and the symptoms didn't change. Reflashing with 1 null node just moved the 1st node symptom to the 2nd node. I noticed even during the start channell white flashing the the 1st node color seemed off but I could be mistaken as it is white and rapid. As a last ditch effort I have flashed one of my ssc v1's to test firmware and will let it run overnight (on 1 string) to see if I get a clue as to a faulty node somewhere. After 30 minutes so far all nodes working normally with the test firmware so far. I wish I had a test firmware for the ssc v2 to try as v1 ssc's seem to compensate better for whatever is wrong with these 11 strands. I may have to give up and order flexstrips or something unless I can locate the problems. Any help appreciated as I spent 1000 on the original nodes and then 250 for shipping to send my old ones back and get the ip68's. I am sure the flexstrips will be even more expensive. :-X
EXACTLY!
It happened to me exactly the same way, even down to the first node blinking differenlty (blue n green n white) when doing the programming.
It was an extrememly frustrating experience and I too have a lot of $$$$ invested in pixels that behave differently with the v2 vs v1.
-
I think I found a fix (at least it worked on the 1st string). Last year I wired my ssc's directly to the nodes. And on the strands further from the hub I used longer runs of wire between the ssc and the first node but still under the 6 foot limit. Last night while trying to sleep I wondered if adding the 3 pin connectors could be knocking the signal down to the first node too much. So extremely early this morning I got up and noticed the length of wire between the 1st node and the connector and between the connector and the ssc were indeed the shortest of the 12. So I cut out the connector completely and shortened the wire length from ssc to 1st node and the problem disappeared. So I added back the 3 pin connector but kept the distance short between ssc and 1st node and it stayed gone. Right now I have 2 feet between the ssc and 1st node with the 3 pin connector included in the measurement and will use that as my standard length. Just will need longer ethernet cables. One thing I do different is my 3 pin connector was not soldered directly to the ssc so I have wire going from the ssc to the connector. This allows me to open the pvc housing and pull the ssc out far enough to access the entire board as the wire can fold up inside the housing. The 2 feet includes that length of wire also. If I don't post in this thread again it means it is working on the rest of my strands as I attempt repairs in the evenings.
-
I'll give that a try as well. Since I don't want to redo all my SSCs cabling I'll try a shortened distance to the first node by shortening up the pixel input wire, mabey even totally eniminating it. I'll just have to deal with the distance from the SSC to the hub on the megatree.
Thanks for your help on this.
Tom
-
Just an update I now have 3 functioning strands working perfectly (9 to go) by shortening the distance from the ssc to the first node to 2 feet with a 3 pin connector in the mix. It may work a little longer but I am sticking with what I know works. The ssc v1 allowed the distance to be a little longer for some reason. I assumed the ssc v2 would have more power but it doesn't appear to, so it must have been something else RJ was compensating for in designing the v2. I wish he would chime in on why the ss2 needs the shorter run. I am not complaining by any means. Apparently the suggested 6' is not doable if you use the 3 pin connector so I will be making use of null nodes in the future when I outline my house.
-
I am wondering if what you are dealing with is a soldering issue. In order to shorten these lines you are resoldering them. The issue may be with the wirre used for these connectors. If it was an issue with the SSC, then everyone should be dealing with it and it seem to jut be a few and not all with the same issues.
-
If it is truely a SSC v2 issue then I would have to ask if changing the resistor from 47 ohms to 150 ohm fixes the issue. This would give you exactly what a SSC v1 does. There is no firmware change that would effect it. If it changed based on this my only thought would be we might be seeing ringing on the data line from the increased drive but I feel that is a streght. The beta test did not show this issue but maybe the lines were just not the right lenght.
RJ
-
If it is truely a SSC v2 issue then I would have to ask if changing the resistor from 47 ohms to 150 ohm fixes the issue.
RJ
Perhaps this is what MrChristmas2000 did to get his to work. These 3 pin connectors I just got from Ray do have a larger diameter of wire than the bundle of wire I got from Ray last year with the silver colored wiring instead of copper which I used as a leader wire. My best guess is that adding the connectors (even though I was still under the 6 foot limit by a few inches) created too much resistance. Last year I direct wired without connectors. Plus these nodes are different than my original batch from early last year as white was a "warm white" on those and these are "cool white". I now have half of my 12 strands working. If these survive the rainstorms this year I will be buying more to outline the house next year. If not I will have to try flex strips. I hope the color doesn't change again.
-
Well I finally had some time to stop and check my pixel strings setup.
The length of my pigtail from the SSC to the first pixel is in total about 3 feet which includes the connector pair and 2 ft of 3wire flat cable.
The largest difference between V1 and V2 IMHO is that the V2 has 4 outputs paralleled together for more signal drive. I will not go into a engineering discussion here but I'm not sure that's going to accomplish the desired effect.
I got my resistors in yesterday and depending on my time I will be doing some more conversions for testing.
-
Been following this thread for a while now and running a few tests with my V1 and V2 SSC's. In looking at scope traces of the dataline output from both, I have not seen any evidence of any 'bug' or inconsistencies with the V2 SSC. Though conversely, in running my tests and watching my nodes - I haven't noticed the color issues mentioned in the thread cropping up either.
In reading the latest round of posts and summing the latest reported evidence, I have a suspicion as to what is going on, but will have to run some additional tests to confirm. If my suspicions prove true, I think the fix should be fairly simple, though may require a bit more testing to come up with something which would apply 'universally' to all configurations.
-
I wonder if RJ could create the "Test" firmware option for the V2 SSC like he has for the V1. It might help with testing and comparison. I know I used the V1 test firmware significantly last year while working through issues. RJ certainly has plenty on his plate so I'd understand if he didn't have the time to do it.
-Mike
-
Before shortening the length between the v2 ssc and the 1st node, I ran the test firmware on one of my v1 ssc's overnight to see if I could find a flacky node in a strand but all were still flashing the correct colors the next morning. So far shortening the length to the first node seems to be working for me.
-
I've completed the additional testing I mentioned above and basically confirmed my suspicions. Sadly, this is essentially the same issue I posted last year - but the post was deleted for being too technical.
I guess I will give it a shot again this year and strip it to the bare bones...
-->THE DATA LINE IS RINGING LIKE A BELL<--
To scratch the technical surface with basic analogies... the data is sent as square wave pulses on the data line. The PIC generates these pulses by switching on/off. But the current in the data line can't start and stop instantly, it take a fraction of a microsecond or two. When the PIC shuts off, the electric current is basically running into a brick wall and it bounces back and forth a bit. When the PIC turns on, a relatively huge amount of current rushes into the 'empty' data line. Both of these events leave the leading edge of the square wave data fairly frazzled. When the node can't read the square wave, it misinterprets the data.
Since the V2 SSC's move more current, they are actually more susceptible to ringing than the V1's. I'm seeing a huge amount of ringing with the V2 data line only 24 inches long. (got some great scope traces of it!)
So what to do about it?
The easiest thing to do is keep the data line as short as possible. I'd recommend 12 inches or less to stay on the 'more reliable' side.
The second possibility is to use 'null nodes'...but then you're wasting fairly expensive and pretty/blinky hardware.
A third option would be to put a resistor in the data line. I'd have to do a bit more testing here, too. But I suspect a 47 ohm resistor down by the first node would help 'impedance match' the node/line with the SSC. The downside is this also drops the 'signal' by a bit...but there may be some compromise between damping the ringing and lowering the signal level.
The fourth option - also may require a bit more testing - but just to see what would happen, I made a data line from 15 feet of 75ohm coax cable. The SSC V2 is driving the string 15 feet away without missing a color. The coax damped the ringing and actually boosted the signal a bit.
So to sum everything up, as far as I can tell, there is no SSC V2 bug. The V2 moves more current on the data line and is generating more square wave ringing. This is simply the result of sending high speed digital data down a plain wire. I would keep the wire to 12" or less to minimize the ringing. There may be other fixes available to get the length up to 15+ feet if needed, though.
Anyway, just my .02 - hope I have stayed on the non-technical side of a technical issue.
-
All 12 of my strings seem to be operating normally now with about 2 feet between the ssc v2 and the first node with the 3 pin connector within that 2 feet.
Sent from my Thunderbolt using Tapatalk 2.
-
As I already posted this was what I expected. No need for all the heavy modding. Increasing The resistor to say 100 ohms to 150 ohm should allow you to use longer feeds again.
Sent from my Charge by Tapatalk
RJ
-
RJ,
Are referring to the 47 ohm resistor on the V2 board?
-Mike
As I already posted this was what I expected. No need for all the heavy modding. Increasing The resistor to say 100 ohms to 150 ohm should allow you to use longer feeds again.
Sent from my Charge by Tapatalk
RJ
-
RJ,
Are referring to the 47 ohm resistor on the V2 board?
-Mike
As I already posted this was what I expected. No need for all the heavy modding. Increasing The resistor to say 100 ohms to 150 ohm should allow you to use longer feeds again.
Sent from my Charge by Tapatalk
RJ
yes
-
Loved your explanation Corey.
-Paul
-
Just received my shipment of 150 ohm resistors.
I will try a few by changing the resistor to 150 to see what happens.
My scope died a long time ago.
-
Would we keep the v2 firmware after modifying the resistors just to be clear? Also which would be better the 100 or 150 or would it matter?
Sent from my Thunderbolt using Tapatalk 2.
-
Yes
Sent from my Charge by Tapatalk
RJ
-
A new question. If you have a short run to the first node even with changing the resistor and let's say at node 40 you need to have a 4-5 foot run before node number 41, will this be a problem? Or is the ringing only between the first node and ssc v2.
Sent from my Thunderbolt using Tapatalk 2.
-
to expand keith's question, does the ringing settle down after the first node?
-
I only had 3 out of 9 version 2012 strings working initially with SSC v2. In my brief testing, switching from 47 ohm to 100 ohm, and shortening the length to the first node to less than 24" made a huge difference!! Thank you Keith and Corey for your persistence in tracking this down. It saved a lot of frustration.
Matt
-
Would it make sense to use cat5 between the SSC and the first node (along with changing to a 100R oe 120R resistor)? The twisted pair in cat5 has about 110R impedance.
/mike
-
A new question. If you have a short run to the first node even with changing the resistor and let's say at node 40 you need to have a 4-5 foot run before node number 41, will this be a problem? Or is the ringing only between the first node and ssc v2.
Sent from my Thunderbolt using Tapatalk 2.
to expand keith's question, does the ringing settle down after the first node?
Interesting questions. From what I see on the scope and experimentally, the answers are:
1) Once the data signal hits the first node, it is cleaned up, amplified and 're-broadcast'. You can have pretty ratty data into the node and a clean signal does come out. Though this output is based on what the node interpreted from the input. So if the data-in isn't interpreted correctly, you have a nice strong, but wrong, signal coming out. (This actually contradicts my earlier thought that the data is just 'piped through', so will try to find/edit that post)
2) The inter-node distance doesn't seem to have the same problem with ringing. I have an 8 foot gap set up here on the bench top and, while the signal does show some ringing, it's not nearly as bad as the SSC at even 2-3 feet, and the color changes are still being made 100% correct. Adding a 47 ohm resistor in that line damped the ringing, too, so I suspect dozens of feet might not be an issue.
I suspect the node input/output is matched for one-another, so not a lot of 'impedance mismatch' and a clearer signal transfer. Further the node output signal is stronger for some reason...seeing almost 5.7 volts peak between nodes. While the SSC output seems to be about 3.3volt-ish
I won't post here, but this is an album showing some traces:
'perfect' square wave reference, SSC output, 1, 2, 3, 4, and 5 foot intervals along the data line (colors begin to fail at 3 ft), 5 foot interval with 97 ohms to dampen the ringing (colors OK), the data out of the first node, and finally, the node-to-node data at 8 feet.
http://s178.photobucket.com/albums/w269/coreyonline/SSC%20Data%20Integrity/?albumview=slideshow
So in summary:
The data is cleaned and amplified by the node. If the first node does a good job, then all is well.
The node-to-node data is stronger, cleaner and less susceptible to ringing. 8 foot transmission seems to be no problem.
-
Would it make sense to use cat5 between the SSC and the first node (along with changing to a 100R oe 120R resistor)? The twisted pair in cat5 has about 110R impedance.
/mike
It's a good thought, but I don't suspect this will work well, and in actual testing it doesn't. The difference comes down to common mode vs differential mode signaling. The cat5 is meant to have a +data on one wire and a -data on the other wire of each twisted pair...equal and opposite signals. We only have a +data, with no equal/opposite, so cat5 / twisted pair doesn't really help us out.
-
So if your eyes aren't burnt out after 7 pages, cliff notes to this point:
=================================================
- No evidence of a firmware bug in SSC V2
- No evidence of 'on board' transmission issues in SSC V2
- Data line is susceptible to signal 'ringing' simply due to the physics of sending high speed digital data down a plain copper line.
- SSC V2 is slightly more susceptible due to sinking higher current compared to SSC V1
- Recommend keeping SSC-to-1st node spacing no more than ~18"... even shorter if practical. At this distance, NO MODIFICATIONS are needed for data transmission.
- If the SSC-to-1st node spacing line needs to be longer, changing the SSC resistor from 47 ohms to 100, 120 or 150 ohms seems to dampen ringing well, and should allow reliable line distances of 4-5 feet.
- The node-to-node transmission is cleaned, amplified and re-broadcast, so as long as the first node in the string can interpret the data correctly, data propagation through the string should not be an issue.
- Node-to-node spacing of 8 feet seems reliable and does not show nearly the ringing as the SSC-to-node line.
- The above listed distances are approximate but should be conservatively safe. All hardware...strings, nodes, SSC's, wire, etc is expected to have some variability, so your distances for acceptable data transmission may be longer. If you are experiencing issues which seem to affect the whole string or 'bad first node' syndrome, give consideration to the data line length bearing in mind the above guidelines.
-
Yes good summary. I think we need to bring the techno train to a station.
RJ
-
A new question. If you have a short run to the first node even with changing the resistor and let's say at node 40 you need to have a 4-5 foot run before node number 41, will this be a problem? Or is the ringing only between the first node and ssc v2.
Sent from my Thunderbolt using Tapatalk 2.
to expand keith's question, does the ringing settle down after the first node?
Interesting questions. From what I see on the scope and experimentally, the answers are:
1) Once the data signal hits the first node, it is cleaned up, amplified and 're-broadcast'. You can have pretty ratty data into the node and a clean signal does come out. Though this output is based on what the node interpreted from the input. So if the data-in isn't interpreted correctly, you have a nice strong, but wrong, signal coming out. (This actually contradicts my earlier thought that the data is just 'piped through', so will try to find/edit that post)
2) The inter-node distance doesn't seem to have the same problem with ringing. I have an 8 foot gap set up here on the bench top and, while the signal does show some ringing, it's not nearly as bad as the SSC at even 2-3 feet, and the color changes are still being made 100% correct. Adding a 47 ohm resistor in that line damped the ringing, too, so I suspect dozens of feet might not be an issue.
I suspect the node input/output is matched for one-another, so not a lot of 'impedance mismatch' and a clearer signal transfer. Further the node output signal is stronger for some reason...seeing almost 5.7 volts peak between nodes. While the SSC output seems to be about 3.3volt-ish
I won't post here, but this is an album showing some traces:
'perfect' square wave reference, SSC output, 1, 2, 3, 4, and 5 foot intervals along the data line (colors begin to fail at 3 ft), 5 foot interval with 97 ohms to dampen the ringing (colors OK), the data out of the first node, and finally, the node-to-node data at 8 feet.
http://s178.photobucket.com/albums/w269/coreyonline/SSC%20Data%20Integrity/?albumview=slideshow
So in summary:
The data is cleaned and amplified by the node. If the first node does a good job, then all is well.
The node-to-node data is stronger, cleaner and less susceptible to ringing. 8 foot transmission seems to be no problem.
So cool to see the technical discussion and the root causes so clearly shown. Loved the scope pictures!
Great job to all of you.
thanks