BRG color order issue when controlling a LED strip with DDP (ledFX) ?

[psytraxx]

Hello - I managed to flash my cheap tuya wifi led strip controller (CBU) with openbk. I am very happy!
After some trial and error I fixed the wrong color output with SM16703P_Init 160 BRG

I was wondering if there is a way to change the DDP color order as well ? Right now i am getting the same color problems i had before i added BRG to the init command.

the relevant part in ddp parse is calling SM16703P_InitForLEDCount with rgb values

OpenBK7231T_App/src/driver/drv_ddp.c

Line 135 in 0efec12

SM16703P_setMultiplePixel(pixel, &data[10], true);

void DDP_Parse(byte *data, int len) {
	if(len > 12) {
		byte r, g, b;

		r = data[10];
		g = data[11];
		b = data[12];

#if ENABLE_DRIVER_SM16703P
		if (spiLED.ready) {
			// Note that this is limited by DDP msgbuf size
			uint32_t pixel = (len - 10) / 3;
			// This immediately activates the pixels, maybe we should read the PUSH flag
			SM16703P_setMultiplePixel(pixel, &data[10], true);
		} else
#endif

the led strip driver recognises the color order if i directly use it with the build-in gui and also homeassistant

OpenBK7231T_App/src/driver/drv_sm16703P.c

Line 55 in 0efec12

void SM16703P_setMultiplePixel(uint32_t pixel, uint8_t *data, bool push) {

void SM16703P_setMultiplePixel(uint32_t pixel, uint8_t *data, bool push) {

	// Return if driver is not loaded
	if (!spiLED.ready)
		return;

	// Check max pixel
	if (pixel > pixel_count)
		pixel = pixel_count;

	// Iterate over pixel
	uint8_t *dst = spiLED.buf + spiLED.ofs;
	for (uint32_t i = 0; i < pixel; i++) {
		uint8_t r, g, b;
		if (color_order == SM16703P_COLOR_ORDER_RGB) {
			r = *data++;
			g = *data++;
			b = *data++;
		}
		if (color_order == SM16703P_COLOR_ORDER_RBG) {
			r = *data++;
			b = *data++;
			g = *data++;
		}
		if (color_order == SM16703P_COLOR_ORDER_BRG) {
			b = *data++;
			r = *data++;
			g = *data++;
		}

My complete init command

backlog startDriver SM16703P;SM16703P_Init 160 BRG;startDriver DDP;

I dont know how multiple drivers work together but the code looks ok for me - is there an issue with the my init command?

[openshwprojects]

Your command looks okay, it's strange that it's not working. I will need to check that in OBK simulator. From a brief glance, it seems that SM16703P_setMultiplePixel should respect the chosen colour order.

[psytraxx]

Thank you - The code responsible to send the DDP data is https://github.com/LedFx/LedFx/blob/main/ledfx/devices/ddp.py Is there a way to dump the incoming data ? This way I could confirm that the problem is not on the side of the. sender

[openshwprojects]

You can manually download DDP-Dump branch here:
https://github.com/openshwprojects/OpenBK7231T_App/pull/1457/files
or just copy code....

[openshwprojects]

You seem to know coding., I pushed self test for setPixels function. It seems to respect colour order:
d0b4168

[psytraxx]

thank you - i uploaded your rom with the debug statement and i it shows that the RGB order is correct in the DDP data - still its shown in the wrong colors on the rgb strip

sending blue --> show as red on strip
Info:DDP:Packet: 410301010000000000180000FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF, Length: 34

sending red  --> shown as green on strip
Info:DDP:Packet: 41040101000000000018FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF0000, Length: 34


sending green -> shown as blue
Info:DDP:Packet: 410A010100000000001800FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF00, Length: 34

could it be that
we are not hitting the

SM16703P_setMultiplePixel

and end up with

 else {
			LED_SetFinalRGB(r,g,b);
		}

instead ?

if SM16703P_setMultiplePixel has the correct behaviour and regcognizes the the RGB order its not using it or the DDP packet parsing doesnt return the correct data

i dug a bit deeper into the DDP format and it looks ok ....

http://www.3waylabs.com/ddp/#Design%20Philosophy

410301010000000000180000FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF

byte 0: 41 - 01000001 - version 1 
byte 1: 03 - 0011 - sequence number
byte 2: 01 - 01 - RGB data
byte 3: 01 - default output device
byte 4 to 7: 000000000 - data offset (0)
byte 8 and 9: - 0180 -data length in    16-bit number, MSB first
byte 10 onwards - data.

[psytraxx]

this is my autoexec.bat

startDriver DDP
startDriver SSDP
startDriver NTP
startDriver SM16703P
SM16703P_Init 160 BRG
# set to green
SM16703P_SetPixel all 0 255 0
SM16703P_Start

[openshwprojects]

I think it should enter SM16703P_setMultiplePixel, but if you are not sure, maybe add a print statement there to check?
Or send a multi-pixel DDP packet to check...

[psytraxx]

i don't understand sorry - SM16703P_setMultiplePixel - this is not registered as a command right? -is there an easy way i can create debug builds similar to the one you send me initially ?

[openshwprojects]

anyone can make debug builds easily, you should check out our forum https://www.elektroda.com/rtvforum/topic4033833.html

[openshwprojects]

also this guide: https://www.elektroda.com/rtvforum/topic4056286.html you can make your own pr/fork and use online builds to get binaries

[psytraxx]

I successfully implemented a custom firmware fix that resolves the issue where LEDFX sends a DDP stream to OpenBK while recognizing a custom color order ( BRG) set via the SM16703P_Init function.

psytraxx#1

Key Changes:
I modified the SM16703P_setPixel function to be reused in SM16703P_setMultiplePixel.

While I'm not an expert in C development, I believe that this optimization reduces complexity without introducing a significant performance hit.

[psytraxx]

thanks for merging!

[psytraxx]

there seems to be a build issue for the simulator build - https://github.com/openshwprojects/OpenBK7231T_App/actions/runs/12903516445/job/35978928965 -

D:\a\OpenBK7231T_App\OpenBK7231T_App\src\driver\drv_sm16703P.c(78,6): error C2371: 'SM16703P_setPixel': redefinition; different basic types [D:\a\OpenBK7231T_App\OpenBK7231T_App\openBeken_win32_mvsc2017.vcxproj]

i dont understand this error message - maybe you want to revert the PR in the meantime