Results 1 to 3 of 3

Thread: WS2813/WS2818 - how 'backup input' works

  1. #1
    Join Date
    Sep 2013
    Location
    Seattle, WA
    Posts
    1,082
    Post Thanks / Like

    Default WS2813/WS2818 - how 'backup input' works

    We've speculated on this a bit, but I finally pulled apart a WS2818 string to analyze it.

    For each pixel:

    a) "Backup Output" is directly connected to "Data Input".
    This connection does not pass through the WS2818/WS2813 chip - it's a trace on the pixel's motherboard from one point to the other.

    b) If a chip received data on "Data Input" it works exactly like a WS2811/WS2812.

    c) If a chip does not receive data on "Data Input", it looks for data on "Backup Input". If it receives data on there, it drops the first pixel data in the stream, and responds to the second pixel data. Thus it consumes 2 pixels from the stream and relays pixel #3 onward through "Data Output".

    So e.g. if pixel 25 receives no Data signal, it will assume pixel 24 is bad, and will take the pixel 24 input (pixel 23 output) which it receives through its BI, and drop the pixel 24 data, display the pixel 25 data, and relay pixel 26 onward. Neat.


    The "Boo" part is that on the strings I have "Backup" is placed between "Ground" and "V+", which is literally the worst place they could have placed it. This means that if water & impurities enter the pixel it is very likely to take out Backup Output.

    Keep in mind that most rain-related failures we encounter isn't generally microchip failures - it's impurities that bridge 2 points on the pixel motherboard and keeping Data high or low as a result. That's why Corrosion X reverses the damage. Would have made more sense if the wiring was G/V+/D/B. Still lots of failure opportunities, but not as much. I've proved this theory by experiment - I have injected several WS2818 pixels with a saltwater/iron solution, and once a pixel goes down as a result, it takes out everything down the string as well. It's pretty hard getting a WS2818 to fail in a way that the rest of the string still work. So far I've only been able to do this by cutting the Data wire - but that's not a general problem I need to protect against. I know in theory if the chip actually fails the string will still work, but on pixels I don't think chips actually fail. On strips however, chips tend to unsolder themselves from the strip, and for those it WOULD make a difference.


    To answer another question: Does it make sense to connect both "Data Input" and "Backup Input" of the first pixel to "Data Output" of the controller?

    This protects against an edge case of the "Data Input" wire becoming damaged or lose on either the plug side or pixel side. However, in the event of such a failure, all of the pixels will shift by one since the first pixel will start responding only to the second pixel's data. But this can be fixed quickly by adding a null pixel on the controller to "undo" the shift, which is easier than getting onto the roof to fix the problem.

    Perhaps one day SanDevices can support WS2813/WS2818 more directly by repeating its "Data" output on the "Clock" output, but with an implicit null pixel in front of it.
    Last edited by deonb; 12-16-2016 at 06:22 PM.
    2017: 33069 pixels, 24 E682's. 50 A/C with 2 LOR
    2016: 21500 pixels, 24 E682's. 6 A/C with 2 LOR
    2015: 7500 pixels, 11 E682's. 35 A/C with 3 LOR
    ...
    2011: 64 A/C channels with 5 LOR

  2. Likes Verrous, BirdingPix liked this post
  3. #2
    Join Date
    Dec 2013
    Posts
    356
    Post Thanks / Like

    Default Re: WS2813/WS2818 - how 'backup input' works

    Quote Originally Posted by deonb View Post
    We've speculated on this a bit, but I finally pulled apart a WS2818 string to analyze it.

    For each pixel:

    a) "Backup Output" is directly connected to "Data Input".
    This connection does not pass through the WS2818/WS2813 chip - it's a trace on the pixel's motherboard from one point to the other.

    b) If a chip received data on "Data Input" it works exactly like a WS2811/WS2812.

    c) If a chip does not receive data on "Data Input", it looks for data on "Backup Input". If it receives data on there, it drops the first pixel data in the stream, and responds to the second pixel data. Thus it consumes 2 pixels from the stream and relays pixel #3 onward through "Data Output".

    So e.g. if pixel 25 receives no Data signal, it will assume pixel 24 is bad, and will take the pixel 24 input (pixel 23 output) which it receives through its BI, and drop the pixel 24 data, display the pixel 25 data, and relay pixel 26 onward. Neat.


    The "Boo" part is that on the strings I have "Backup" is placed between "Ground" and "V+", which is literally the worst place they could have placed it. This means that if water & impurities enter the pixel it is very likely to take out Backup Output.

    Keep in mind that most rain-related failures we encounter isn't generally microchip failures - it's impurities that bridge 2 points on the pixel motherboard and keeping Data high or low as a result. That's why Corrosion X reverses the damage. Would have made more sense if the wiring was G/V+/D/B. Still lots of failure opportunities, but not as much. I've proved this theory by experiment - I have injected several WS2818 pixels with a saltwater/iron solution, and once a pixel goes down as a result, it takes out everything down the string as well. It's pretty hard getting a WS2818 to fail in a way that the rest of the string still work. So far I've only been able to do this by cutting the Data wire - but that's not a general problem I need to protect against. I know in theory if the chip actually fails the string will still work, but on pixels I don't think chips actually fail. On strips however, chips tend to unsolder themselves from the strip, and for those it WOULD make a difference.


    To answer another question: Does it make sense to connect both "Data Input" and "Backup Input" of the first pixel to "Data Output" of the controller?

    This protects against an edge case of the "Data Input" wire becoming damaged or lose on either the plug side or pixel side. However, in the event of such a failure, all of the pixels will shift by one since the first pixel will start responding only to the second pixel's data. But this can be fixed quickly by adding a null pixel on the controller to "undo" the shift, which is easier than getting onto the roof to fix the problem.

    Perhaps one day SanDevices can support WS2813/WS2818 more directly by repeating its "Data" output on the "Clock" output, but with an implicit null pixel in front of it.
    Thought i would chime in here, I contacted San Devices, Jim says a firmware upgrade can be done for the 6804, but not possible for the 682.

  4. Thanks deonb thanked for this post
    Likes deonb liked this post
  5. #3
    Join Date
    Sep 2013
    Location
    Seattle, WA
    Posts
    1,082
    Post Thanks / Like

    Default Re: WS2813/WS2818 - how 'backup input' works

    Another user sent a PM of how to do this properly and how I've done it. User - your mailbox is full so I can't reply!


    The preferred solution would be for the controller manufacturer to change the unused clock to do the off-by-one backup. Other than that would be to have a null pixel up front for the backup but not the primary wire.

    I've tried both tying primary and backup together on some of my strands, as well as just leave backup floating. However, I don't believe I had any failure in which the backup wire made any difference. No off-by-one failures on the whole strand, nor full pixel out where the rest are still working.

    Overall the quality of the WS2813/WS2818 lights are MUCH MUCH MUCH worse than the WS2811/WS2812's. At least for the strands and strips I have. Most of mine have single-color-out issues, so e.g. Red goes dead but Green and Blue still work. So backup wire obviously doesn't help with that case since the chip is still working. Out of 120 strands I have, I only have 15 strands or so remaining after 2 season that have no outs, and another 20 or so that only have one LED out over the strand that I can black out the pixel with tape. All other strands have between 2 and 20 LED's out (not full pixels, just individual LEDs).

    It's the pixel output pin on the IC that seems to fail (or the motherboard connection) - if you manually put voltage on the LED leg it still lights. I haven't been able to successfully isolate and remove an IC from a pixel motherboard to really test it due to the waterproofing.


    It's always just one LED color that fails, sometimes two - there are no whole pixel failures anywhere (which could validate a backup wire).


    I also have the general issue where an entire strip or pixel strand sometimes becomes more sensitive to EMF interference and it starts flickering bright whites. Same thing happens with WS2812 of course. But again, shows that the backup wire doesn't help to solve this.


    I spoke to Ray about that, and asked him if newer manufactured strips are better, and he says he doesn't really know because almost everybody buys the WS2812's over WS2818's.


    In my opinion the backup wire is a great solution to a problem that we don't have in practice. Whole pixel outs followed by non-repeats are of course an issue, but from my original post, it doesn't really help that case either since it's mostly the motherboard that fails/shorts, and not the IC.

    I won't get these again - even if they were cheaper than good old WS2812's. YMMV.
    2017: 33069 pixels, 24 E682's. 50 A/C with 2 LOR
    2016: 21500 pixels, 24 E682's. 6 A/C with 2 LOR
    2015: 7500 pixels, 11 E682's. 35 A/C with 3 LOR
    ...
    2011: 64 A/C channels with 5 LOR

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •