@Jurgen_Skrotzky I have my test strips. Will post results shortly
great to hear. Maybe you can post also a picture of the strip - to show off the quality?
The strips look good. the join pads, in between each pixel are naked coper and solder sticks really well to them. They cut perfectly and the SMD job is well done. Im actualy surprised considering the crap ive received previously from china
@Leon_Yuhanov Can you describe the test you performed? I’m particularly curious if they exhibit the same problem I described above in this thread, where the LEDs I tested show the previous frame of color data when sending FastLED.show(). The chips I tested were not branded, so I’m not sure if they were SK9822, but they were sold to me as APA102-compatible.
@Jeremy_Williams I performed the tests using my own APA102 driver not FastLED but ill test them out tonight using fastLED and report back. I cant see any difference at all in their protocol
@Leon_Yuhanov I’ve confirmed that the chips I tested were SK9822 before they were branded. @Daniel_Garcia has them now to tinker with. To be clear, if I ran the following, the prints and LED were not in sync (the LEDs were one “frame” behind).
void loop() {
// Red
Serial.println(“Red”);
leds[0] = CRGB::Red;
FastLED.show();
delay(1000);
// Green
Serial.println(“Green”);
leds[0] = CRGB::Green;
FastLED.show();
delay(1000);
// Blue
Serial.println(“Blue”);
leds[0] = CRGB::Blue;
FastLED.show();
delay(1000);
}
I’ll be very curious to hear if yours exhibit the same problem or if it’s been fixed.
The chips are not exactly compatible with the APA102 - they follow slightly different rules for latching the data (e.g. when the led takes the data that has been written to it and starts showing it). I’ve just checked in a fix for this on master@HEAD, adding an SK9822 led type that will do the right thing for end frames.