Results 1 to 3 of 3

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

Threaded View

Previous Post Previous Post   Next Post Next Post
  1. #1
    Join Date
    Sep 2013
    Location
    Seattle, WA
    Posts
    1,090
    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

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
  •