GS8208 Pixel – Trusted Suppliers?

[ryanschristmaslights]

Just to make things clearer for anyone looking back on this discussion later, when you all say ETOP they would be WS2811 (or other WorldSemi ICs) and not GS8208, is that right? Thanks.

 

[merryoncherry]

Just to make things clearer for anyone looking back on this discussion later, when you all say ETOP they would be WS2811 (or other WorldSemi ICs) and not GS8208, is that right? Thanks.

Right. The problems I had in 2022 were with WS2811 (or knock-off, I should check one more closely) 12V resistor designs... so there are 4+ differences between that and what we all want to try instead. (Different chip, different board design, different factory, different distributor.)

 

[orchidman33]

Thank you for all the useful info !

Are you running 50pixel or 100pixel strings ?

I am running strings of 200 at 40% brillance and no power injection.
As for the self test- yes, but I find as the power supply does my FPP and outputs 9-16 of the F16V3 it lasts a very very short time due to the F16V3 power up time.

I changed the input plugs to the start of the string to a three wire with data 2 shorted to the 0V line

 

[merryoncherry]

TLR - Only tangentially related to trusted suppliers of GS8208... Some of the YPS Duo Adapters for the GS8208 pixels are defective from the factory... if you are going nuts because things are one pixel short it is probably not you, but the adapter.

I just installed these insane poles with stars today (bad idea, being show launch day, but I digress) and noticed a pixel acting up.


Then I realized it is the last pixel in the string, and several other poles had the same issue, across 3 different controllers (which I reset anyway, to no avail). The strings were off by 1 entirely.


Now, of course even if the xLights channels are off, the controller will send SOME data down the string if the number of pixels is configured properly, but no data going to the last pixel... and the one thing that would cause that is the first pixel reading the controller connection as "backup data" instead of regular data. Backup data comes from 1 pixel farther up string, so it suppresses the first pixel worth of data, which would shift everything.

I swapped 2 of the adapters and the issue moved with the adapter. I tested the adapters with the multimiter and found that backup data out and data out were both connected to data in on the good adapter, but only backup data was connected to data on the bad adapter. I found that the first pack of 20 adapters I used was good, and the 2nd pack of 40 was all bad.

I was out of good ones, I hacked up a few of the bad ones: Black(V-) goes to Black, Brown(V+) to brown, yellow(data) to blue+yellow for data (this is not the only suboptimal thing to do, you could tie backup data to V-), and then I put input backup data to V- because it is already tied to V- in the plug (and I didn't want to leave it hanging). You could also just swap blue/yellow instead of tying them together like that.

Now, I don't recommend my marine grade solder tube construction approach, but I was in a hurry, and the show's running fine now:


I have contacted the company and hopefully they send working replacements and I can ditch these hacked ones soon.

 

[Jase]

TLR - Only tangentially related to trusted suppliers of GS8208... Some of the YPS Duo Adapters for the GS8208 pixels are defective from the factory... if you are going nuts because things are one pixel short it is probably not you, but the adapter.

I just installed these insane poles with stars today (bad idea, being show launch day, but I digress) and noticed a pixel acting up.
View attachment 24554

Then I realized it is the last pixel in the string, and several other poles had the same issue, across 3 different controllers (which I reset anyway, to no avail). The strings were off by 1 entirely.
View attachment 24555

Now, of course even if the xLights channels are off, the controller will send SOME data down the string if the number of pixels is configured properly, but no data going to the last pixel... and the one thing that would cause that is the first pixel reading the controller connection as "backup data" instead of regular data. Backup data comes from 1 pixel farther up string, so it suppresses the first pixel worth of data, which would shift everything.

I swapped 2 of the adapters and the issue moved with the adapter. I tested the adapters with the multimiter and found that backup data out and data out were both connected to data in on the good adapter, but only backup data was connected to data on the bad adapter. I found that the first pack of 20 adapters I used was good, and the 2nd pack of 40 was all bad.

I was out of good ones, I hacked up a few of the bad ones: Black(V-) goes to Black, Brown(V+) to brown, yellow(data) to blue+yellow for data (this is not the only suboptimal thing to do, you could tie backup data to V-), and then I put input backup data to V- because it is already tied to V- in the plug (and I didn't want to leave it hanging). You could also just swap blue/yellow instead of tying them together like that.

Now, I don't recommend my marine grade solder tube construction approach, but I was in a hurry, and the show's running fine now:
View attachment 24556View attachment 24557

I have contacted the company and hopefully they send working replacements and I can ditch these hacked ones soon.

Good deducing and fix!