FAQ
TL;DR: The Feit Electric 20-ft strip uses 7 channels per segment, and one expert found that “data is always P16” for the pixel output on this BK7231N design. This FAQ helps OpenBK users safely back up, flash, and map the controller while avoiding the older SPI DMA bug that broke SM16703P-style LEDs. [#20803289]
Why it matters: This thread turns a hard-to-drive Costco light strip into a documented OpenBK target with known pins, channel layout, and practical firmware limits.
| Approach |
Hardware reuse |
Known result in thread |
Main limitation |
| Keep BK7231N + OpenBK |
Reuses original controller |
Web UI access, GPIO discovery, partial light control achieved |
7-channel support needed for clean control |
| Replace with Pico W |
Replaces controller entirely |
Considered as a fallback |
Loses the convenience of the original BK7231N board |
Key insight: The core blocker was not the strip hardware. The real issue was BK7231N SPI DMA instability, and later thread updates report that this driver bug was fixed, making SM16703P-class LEDs usable again. [#20966214]
Quick Facts
- The controller was identified as BK7231N, the strip length was 20 ft, and the retail price mentioned was about $25 at Costco. [#20791392]
- The strip sends only three signals over its fake USB-C-style connector: +24 V, DOUT, and GND. [#20791392]
- Confirmed GPIOs are P16 = DOUT, P22 = 24 V power enable, and P24 = button, with the button reading low when pressed and high when released. [#20804661]
- Actual per-segment layout is 7 channels: R, G, B, WW1, WW2, CW1, CW2. RGB runs 0–255, while each white pair effectively reaches 0–510 combined. [#20804661]
- Bit-banging hit a timing wall: the shortest observed pulse was 2 µs, while the target protocol needed about 0.3 µs. [#20807690]
How do I flash OpenBK onto a Feit Electric Smart Color Chasing Strip Light with a BK7231N and make a safe 2MB firmware backup first?
Start by making a full 2 MB flash backup, then flash OpenBK with the Python command-line tool. The thread’s suggested path is: 1. Connect to the BK7231N test pads and read a 2 MB backup first. 2. Flash OpenBK using the Python CLI; one user did this successfully on a Mac. 3. Boot into the OpenBK web interface and verify access before changing GPIO roles. CRC errors were reported during backup extraction, so keep the raw dump even if parsing fails.
[#20803236]
What are the GPIO pin assignments for the Feit Electric chaser strip controller, including the button, LED data output, and 24V power enable?
The confirmed pinout is P16 for LED data output, P22 for 24 V strip power enable, and P24 for the button. The button is active-low, so it reads low when pressed and high when idle. That mapping was explicitly tested on the Feit controller after flashing OpenBK. If you need only one starting point, use P24 first because it was verified through the GPIO finder before the full map was posted.
[#20804661]
Why does the SM16703P driver on OpenBK show channel bit-shift or misalignment issues on this Feit Electric strip?
The driver showed misalignment because SPI output did not match the buffer layout during early testing. One tester saw channels shift by about two positions, values wrap around, and reset pulses appear in the middle of the transmission. He also noted the buffer was not cleared cleanly at initialization, which left random startup values. Those symptoms pointed to the transfer path, not only to the 7-channel strip format.
[#20804661]
What is the actual channel order on the Feit Electric RGBCW chasing strip that uses both SM16703 and SM16704 chips?
The actual order is Red, Green, Blue, Warm White 1, Warm White 2, Cool White 1, and Cool White 2. That means each segment exposes 7 controllable channels, not standard RGB or RGBW. The white channels are paired per color temperature, so warm white and cool white each use two slots. In practice, RGB behaves like 0–255 per channel, while each white pair acts like an effective 0–510 range.
[#20804661]
How can I configure OpenBK or drv_sm16703P.c to support 7-channel LED segments like RGB WW WW CW CW on this strip?
Use a modified drv_sm16703P.c that adds configurable channel count and channel mapping. The proposed patch introduced a maximum of 8 channels, dynamic buffer sizing, and a channel_map array so the driver no longer assumes fixed RGB. The example initialization was
SM16703P_Init 10 7 0 1 2 3 5, intended for 10 pixels and a 7-channel layout. Later discussion in 2025 also suggested extending PixelAnim and accepting a clean pull request for broader strip support.
[#20804661]
Why did SPI DMA on BK7231N cause random transfer lag or reset pulses appearing in the middle of the data stream, and what fixed it?
BK7231N SPI DMA had an instability that caused random lag during LED transfers. That lag moved the reset pulse into the middle of the stream and broke patterns even when the memory buffer looked correct. Later testing confirmed the same behavior on WS2812B, not only on this Feit strip. The thread then reported that the SPI DMA driver bug was fixed, and users were told to update because SM16703P, WS2812B, and similar LEDs should work correctly afterward.
[#20966214]
What is SPI DMA, and why is it used to drive SM16703P, WS2812B, and similar addressable LEDs on BK7231N devices?
“SPI DMA” is a hardware data-transfer method that feeds SPI output from memory without constant CPU timing, which helps generate tightly timed LED bitstreams. It matters here because the pixel data line on this controller uses P16 as the SPI output, and OpenBK relies on that path for addressable LEDs. That approach is used because software bit-banging on BK7231N struggled to hit the required sub-microsecond timing. In this design, P16 was identified as the pixel data path used for SM16703P-class output.
[#20869629]
What is a ramfunc on BK7231N firmware, and why does it matter when trying to bit-bang very fast LED protocols?
“ramfunc” is a function placed in RAM so it executes directly from RAM, avoiding flash-fetch delays that disturb precise timing. It matters on BK7231N because the platform’s flash instruction cache introduces effectively random timing jitter. One developer said bit-banging was not feasible on this platform for that reason, even after trying
nop delays. He noted that a working RAM-resident implementation would be the only plausible route for stable, very fast LED pulses.
[#20807800]
What’s the difference between SM16703 and SM16704 in these Feit Electric strip segments, and how does that affect driver support?
SM16704 was described here as the same basic protocol family as SM16703, but with an extra channel. That matters because each strip segment contains both chips, creating a total of 7 channels instead of the 3 or 4 that many drivers expect. As a result, a plain RGB-oriented SM16703P implementation can light the strip, but it cannot represent the full per-segment layout cleanly. Driver support must handle arbitrary channel counts and mapping.
[#20792424]
Pico W replacement vs keeping the original BK7231N with OpenBK — which approach makes more sense for controlling this Feit Electric strip?
Keeping the original BK7231N with OpenBK makes more sense if you want the fastest path to a working controller. The strip was flashed successfully, the web interface worked, and the key pins were identified without replacing hardware. A Pico W replacement was considered at first, but that became less attractive once OpenBK showed promise. Choose Pico W only if you want a full custom controller stack; choose OpenBK if you want to reuse the board and stay close to the existing hardware.
[#20792424]
How do I identify the button pin and data pin on a BK7231N board using the OpenBK web interface and GPIO finder?
Use the OpenBK web interface first, then test pins with the GPIO finder. The practical sequence in the thread was: 1. Flash OpenBK and open the web UI. 2. Use the GPIO finder to locate the button; it identified pin 24. 3. Check the LED data line next; for individually addressable LEDs on this platform, the guidance given was that data is always on P16. That method quickly narrowed the controller to P24 for the button and P16 for pixel output.
[#20803289]
Why is bit-banging the LED protocol on BK7231N so difficult compared with using hardware SPI, especially for 0.3 µs timing?
Bit-banging is difficult because the measured pulse width was about 2 µs, while the target timing was roughly 0.3 µs. That is almost seven times slower than needed. The platform also suffers from flash-cache timing jitter, which makes instruction timing unstable even if the code looks tight. Hardware SPI avoids much of that CPU timing problem by shifting data from a peripheral instead of relying on precise software loops.
[#20807690]
What’s the best way to use PixelAnim or Home Assistant with a Feit Electric strip that has 7 channels per segment instead of standard RGB?
The best path is to extend the SM16703P driver, then expose that support to PixelAnim. A 2025 user reported that basic control worked on OpenBK 1.18.94 with repeated
SM16703P_SetPixel commands, but that method was awkward because the strip uses 7 channels per segment in an R G B WW WW CW CW pattern. The maintainer said he wanted PixelAnim to cover more strip types and was open to a pull request that preserves existing behavior. That makes driver extension the clean route for Home Assistant use.
[#21540498]
How should I map the fake USB-C style connector on the Feit Electric controller to GND, +24V, and DOUT when soldering the strip directly?
Map the connector by measurement, not by USB-C assumptions, because it is explicitly not real USB-C. The thread confirms that only three signals are present on that connector: GND, +24 V, and DOUT. It also confirms that DOUT originates from P16 on the controller. For direct soldering, first trace P16 with a multimeter, then identify the +24 V rail and ground on the board. Do not plug this connector into a computer because the thread warned that the pin mapping is nonstandard.
[#21315812]
Why do some Feit app scenes look offset or behave as if two strips are connected together on this Smart Color Chasing Strip Light?
Some Feit app scenes appear offset because the app seems to assume two strips are chained together. One user said that realization explained why several scenes looked wrong all night. He also observed that even patterns that should have stayed symmetrical still showed an offset, which suggests the stock effect logic may not line up perfectly with the strip’s actual addressing. That behavior is useful evidence when comparing app behavior against OpenBK pixel mapping.
[#20810671]
Generated by the language model.
