SM16714 Pixel IC

I’ve got a new strand of pixels for testing, they are RGBW and I’d like to drive them from WLED, I haven’t so far been able to get them to work properly yet.

Anyone had any success with pixels of this type?

I’d like seeing a picture of those :upside_down_face:

I just purchased some of these as well. They are part of a set of patio lights that I’d like to get working with WLED. I’ve included a picture of both the front and back of each “bulb”. The controller had a Black/White/Green to the lights.

These are the lights, however, I have seen other similar builds with the same controller.
https://a.co/d/dtzvbjg

Happy to help move this forward with testing, just new to WLED and not sure where to start. :slight_smile:

This is the front…

Looks like a 12V version of RGBW.
Standard DIn-Dout daisy chain with 3 RGB pixels in series for 12V and a separate W LED.

I’d try driving it w/WLED using SK6812 for a start and move to TM1814 if necessary.

Wire as 12V PS to 12V, Ground to GND, and Data in to (surprise) DI.
I’d advise starting with a levleshifter and a separate 5V supply for an ESP32 (make sure ground is common between the 2 supplies).

Thank you! I will order another controller and report back!

Did you have any luck with this? I am also trying to drive an LED with an SM16714 controller and didn’t have any luck with the SK6812 or TM1814 settings. I am new to WLED, so I might have overlooked something.

The LED is this:

FYI for future readers. I was able to drive these without any issues. It was a setup issue and I needed to change from RGB to RGBW.

Some RGBW clones won’t work with 3,3V logiclevel only. In best case it’s unstable, but it ca be, that it’s do nothing. Try it with a levelshifter, to translate to 5V level :wink:

Hi - I have exactly the string of lights described in this thread. I’m running WLED 0.14.4 which is the latest non-beta. I’ve poked around with this for several hours but have been unable to get “stable/smooth” operation (I can get color rendition kinda close, but I get this strange flickering artifact followed by a dimmer value of light). I’ve tried a number of chipsets - none of them work “right”.

What LED settings are you using? Could you share a screenshot of your settings perhaps?

Moin everyone,
I also ran into the same trouble with the Adafruit 4W RGBW NeoPixel. The so called manual of the SM16714 states that it is " Adopt single line return to zero code SID data protocol", see Landscape decorative lighting driver chip. The best fit for me was the “SK6812/WS1814 RGBW”, but the line would stay high if no data is sent. So it needed to be inverted.
So I did a dirty hack and changed the Neo Pixel method from Non-inverted to inverted, build and flashed than binary.

In bus_wrapper.h:
//RGBW
#define B_8266_U0_NEO_4 NeoPixelBusLg<NeoGrbwFeature, NeoEsp8266Uart0Ws2813InvertedMethod, NeoGammaNullMethod> //4 chan, esp8266, gpio1
#define B_8266_U1_NEO_4 NeoPixelBusLg<NeoGrbwFeature, NeoEsp8266Uart1Ws2813InvertedMethod, NeoGammaNullMethod> //4 chan, esp8266, gpio2
#define B_8266_DM_NEO_4 NeoPixelBusLg<NeoGrbwFeature, NeoEsp8266DmaInverted800KbpsMethod, NeoGammaNullMethod> //4 chan, esp8266, gpio3
#define B_8266_BB_NEO_4 NeoPixelBusLg<NeoGrbwFeature, NeoEsp8266BitBang800KbpsInvertedMethod, NeoGammaNullMethod> //4 chan, esp8266, bb (any pin)

Question is now, how to integrate this. I guess easiest would be to create a new chip variant with its own setting.

According to that page, the SM16714 also support 5 bit of current setting. I could not find any information on that, and it most probably not relevant for the 4W adafruit Neopixel. My best guess here is, that the current setting is shared amongst all controllers connected as one line. The data is sent after all RGBW data has been sent, similar to the SM16804 (see SM16804 IC Protocol and datasheet-【JIAANDA Optoelectronic】- LED Pixels strip,360 degree LED TUBE,LED CONTROLLER,Digital COB Flex strip,LED ACCESSORIES for the protocol). But as stated wild guessing and I cannot test it.

Moin everyone,
I got the extended pdf datasheet from china asic. My assumption was more or less right. After all RGBW data has been sent, 20 Bits of current adjustment is sent.
I have attached screenshots of the datasheet sections as it is not allowed for me to attach pdf files.
As I have not the right LEDs to adapt the current, for a first implementation either no current data could be sent, or just max current could be sent.

And here is the current setting:

Getting RGBW pixels to work with WLED can be a bit tricky, but many users have had success with them. Here are some steps to help you troubleshoot and set them up:

  1. Check Compatibility: Ensure your RGBW pixels are compatible with WLED. Common types like WS2815 or SK6812 are usually supported.

  2. Wiring: Make sure your wiring is correct:

    • Connect the data line to the appropriate pin on your microcontroller.
    • Ensure power and ground connections are secure.
  3. Firmware Configuration:

    • In WLED, go to the LED settings.
    • Set the LED type to RGBW (e.g., SK6812RGBW).
    • Adjust the number of LEDs correctly.
  4. Power Supply: Ensure your power supply can handle the total current of the LED strand, especially if you’re using a long strip.

  5. Testing: Use a simple test pattern to see if the pixels light up correctly. You might want to start with basic colors to confirm functionality.

  6. Update WLED: Ensure you’re using the latest version of WLED, as updates may include fixes or improvements for specific LED types.

  7. Community Forums: If you’re still having issues, checking forums like the WLED Discord or GitHub page can provide additional insights from users with similar setups.

If you’re still facing issues, let me know what specifically isn’t working, and we can dive deeper!