A comparison between WS2811 5v and GS8208 12v

Kent

Kent

Apprentice elf
Generous elf
Joined
Nov 21, 2020
Messages
81
I became quite interested in the GS8202 after having been originally motivated by this thread.

Now that it's really becoming urgent to get my pixel order in for 2022, I made the time to compare the sample GS8208 purchased earlier this year from Shenzhen Shiji Lighting with the 5V WS2811 purchased from Ray Wu and used in my display last year.

Google photo album
This shows the test setup used to compare the WS2811 5v (left) and GS8202 12v (right) pixels, measuring current, voltage drop, and brightness for 1, 2, and 3 colours. Single colour tests were green. Dual colour tests were red + blue. This was for consistent results as red and blue are swapped between the two strings. Each string has 50 nodes.

Associated spreadsheet with all of the interesting information

Voltage drop effects for white @ 100%:
WS2811 5v: To my eyes, the LEDs started to dim at 4.5v. From here they dimmed more dramatically and moved to a warmer colour.
GS8208 12v: There was no visible difference all the way down until 9.5v. From here they dimmed, but maintained the colour temperature. Interestingly, when set to green only, I could drop the voltage all the way to 6v before noticing any change at all.

The first photo shows the test setup. At the end of testing I randomly went back and re-ran some of the earlier tests to ensure the same current, voltage, and brightness values were obtained. Swapping the meters around gave results within 10mV of each other, and when measuring Vin at the bench supply terminals, I recorded 4.94V and 12.06V respectively.

The video shows the power up behaviour, and what happens when adding and removing power from the Quinled Dig Uno board. You'll notice that the GS8208 turn off shortly after removing power from the Quinled Dig Uno, whereas WS2811 maintain the last value sent out. When I applied power a second time, the Quinled board didn't start up correctly. Interestingly this made the GS8208 start a test mode where it cycles between R,G,B. After another power cycle the Quinled board starts up OK and everything goes back to normal. I had the board set to turn the LEDs on at 50% brightness.

The gamma correction built in to the GS8202 means that 50% brightness on the GS8208 is roughly equivalent to 25% brightness on the WS2811. Because of this, I wanted to grab some brightness measurements to compare the power draw per lumen. Whilst not a very scientific setup, I believe the values are good enough to give a bit of a comparison. The third photo shows my best effort to get consistent measurements between the two, with 23 nodes each. The light meter was a $50 cheapie off eBay, and when taking the measurements I had the room dark and only the relevant set of pixels turned on. Whilst it can't be seen in the photo, I had a reference line ~35cm from the LEDs. When taking measurements, I'd move the sensor around and recorded the maximum value.

I've drawn the following conclusions from my testing regarding the GS8208 (with respect to my other preferred option of 5v WS2811):

Pros:
  • Show can withstand single pixel failures due to the backup data line
  • Better consistency between brightness steps, particularly due to fact I limit brightness to ~50%, however the real world impact may be debatable
  • Lower peak power draw at typical max show brightness (For white GS8208 only uses 5.4W to produce 270 lux (75%), whilst WS2811 used 6W to produce 248 lux (50%))
  • Significantly less power injection (several hundreds of pixels with no noticeable colour change)
Cons:
  • Significantly higher idle power (~158W vs ~24W for my ~6000 pixel display)
  • Limited vendors
All in all, I think I'll go with the GS8208, primarily for the pixel failure tolerance. The other pros make up for the higher idle power :)
 
How does the redundancy work?

With a signal coming in the primary data line, the LED looks at the first pixel worth of data, strips off that first pixel, and passes the rest on.
If the primary line goes down (pixel prior is dead) then the LED will look at the backup line, discard the first pixel worth of data, look at the second pixel, and pass on the remaining (n-2).

Internally they are connected like this, where Green is the primary line, and Orange is the backup line. The Blue circle is the chip inside the pixel.
The light blue line is where the primary line input, is connected to the backup data output.
Power is not shown on the diagram.
1663553482791.png
For the first pixel - if you were to connect the incoming pixel data to both lines, and the first pixel was to die, then all data would be off by one - ie. Pixel 2 will be displaying pixel 1's data. Pixel 3 will display pixel 2's data, and so on,..... and if you were to ground it, the entire string will go blank, rather than be incorrect.
(Correction as per MOC below)

For the first pixel - if you were to connect the incoming pixel data to both lines, and the incoming feed line to the first pixel was to die, then all data would be off by one - ie. Pixel 1 will be displaying pixel 2's data. Pixel 2 will display pixel 3's data, and so on,..... and if you were to ground it, the entire string will go blank, rather than be incorrect.

So, it's 6 of 1, half a dozen of the other. It depends on how critical the run is. If it's a roof line, it might be acceptable for all pixels to be off-by-one should that the data line to the first pixel die. On something with more detail, like a singing face, then an off-by-one error would look really funny with eyes and mouths not lining up.

So between pixels, it's a four-wire connection. To the controller could be three or four, depending on whether the 4 wire error is an issue.
 
Last edited:
For the record, during my testing I had the backup input connected to ground. The primary input was connected together with the WS2811 input.

If the off by one problem is of concern, solutions could be inserting an unused pixel on the backup data line (or a null WS2811 pixel, but that'd limit you to the slightly slower data rate) or tying up a second controller port with a firmware patch that mirrors the primary port, but with one pixel delay.
[Edit 19/9/22 - removing fictitious solution to a non-existent problem]
 
Last edited:
I may be confused. The initial backup data line is only seen by the first pixel. If the first pixel dies, it isn't relevant, the primary data line will still circumnavigate it to become the second pixel's backup data line, and it will ignore the first pixel of data from it, as they all do if looking at the backup data line.

The initial backup data line could only work if you had a backup to the primary data line from the controller, and it wouldn't need a 1-pixel elimination, but rather a 1-pixel introduction, as the first pixel will discard one channel set from the backup input.
 
You're right Merry. I had it confused in my own mind.
If the primary feed was to die (wire failure) then you'd have the off-by-one error - the first pixel will be looking at pixel 2's information, and so forth.
I've corrected my post above.
 
@Kent What might come as no surprise ... I had another box of GS8208 bullet strings delivered to me earlier this month to expand on the strings I ordered last year (and at a more attractive price).

@LagoonLights Last month I was quoted US$0.22 per pixel in a 50 piece string with 10cm spacing, black insulation and 4-pin waterproof connectors each end from Shiji Lighting (the same supplier @Kent mentioned above). The standard configuration advertised on Alibaba is 8cm spacing and clear insulation (that I presume will go brown in the harsh summer sun).
 
You must log in or register to reply here.
Back
Top