Run Mbi6033 LED/Chip IC with WLED

[seyfettinkazanir]

I want to use neopixelbus with mbi6033 ic. I know there is a library that wled uses. They said to a question I asked from there, you can do it with neopixelbus, you have to ask to edit it.

I want to run mbi6033 with wled but I don't know how to proceed. I need help.
Mbi6033 is actually an economical solution. It runs 4 channels with 1 chip. It is an integrated that uses spi. I would like to share what we know about the mbi6033.

It has 2 different modes. with current Gain and without current gain. I want to use it without. Spi data contains a 48-bit header, and its channels consist of 16-bit and gray scale data. We have the header information. There is also a data string of a working device taken with a logic analyzer. If you need more information, please don't hesitate to ask.

MBI6033 Application Note V1.00-EN.PDF

[Makuna]

What uC are you using?

The issue here is that it uses the CLK to do the reset. Specifically, it wants to send a single 0 bit with delay before and after. This is not achievable with hardware SPI as it sends data by bytes and can't send a single bit. Can I manually toggle it when the hardware SPI controls the PIN, that can only be answered by trying.

With BitBang (which I support and implemented) theatrically it could be modified to send a single bit.

There is also this timing stuff mentioned based on number chips, but DotStars (3 wire chips like this that have Clk, Data, Gnd) this isn't uncommon, but it requires special coding for it.

The rest (header and 16bit elements) is already supported it would just need its header to be exposed as a feature setting (other chips have this also).

[seyfettinkazanir]

I use uC esp32 and some times wt01-eth (lan + esp32).

[seyfettinkazanir]

I read a topic about software spi in two-line chips, would it help? topic Aircoookie/WLED#2542 related setting: Aircoookie/WLED#2542 (comment)

[Makuna]

If you want to check out the rabbit hole:
Look at Sm1617 support (NeoSm168xxFeature.h & Sm1676GenericMethod.h) as an example of building custom settings and DotStarGenericMethod.h for the extra data based on count.

If you can wait, I will take a look at a frame work method for it just to test out that extra weird clock bit used for reset.

[seyfettinkazanir]

Thanks for your help, I'm waiting.

[Makuna]

Do you what LEDs are attached and what order?

Since each chip has 8 channels, this could be 3 RGB, or this could be 2 RGBW.

[seyfettinkazanir]

mbı6033.pdf

our design led strip is like this.

[Makuna]

From your circuit design, the color order is GRB, so use NeoGrb48Feature.
The first pixel will be group 3, so C3,B3,A3 from your circuit.

[Makuna]

https://github.com/Makuna/NeoPixelBus/tree/Mbi6033
This branch exposes a new method set for Mbi6033. You can clone this directly into your arduino libraries (see readme).

Assuming RGB pixel order in the following examples. (updated: 16 bits per element uses NeoRgb48Feature)

For bit bang, use Mbi6033Method like

NeoPixelBus<NeoRgb48Feature, Mbi6033Method> strip(PixelCount, ClockPin, DataPin);

For hardware SPI, use Mbi6033SpiMethod method like

NeoPixelBus<NeoRgb48Feature, Mbi6033SpiMethod> strip(PixelCount);

and if your platform is ESP32 the pins for the hardware SPI are define when you call Begin() like

strip.Begin(sck, miso, mosi, ss);

[seyfettinkazanir]

NeoPixelBus<NeoRgb48Feature, Mbi6033SpiMethod> strip(PixelCount);

I don't know if I did it right, but I got a data using this section. I am sending an attachment. I am also attaching the sample code.

logic anlyzer pic.

Yeni Metin Belgesi.txt
this is one mbi6033 strip

[seyfettinkazanir]

I think there is a deviation in the clock signal. approximately twice as long.

[Makuna]

Can you capture what you see before the header? Trying to see the reset clock pulse.

Also, let's try to slow it down some, so use Mbi6033Spi2MhzMethod, by default is trying to send at 10Mhz.

[Makuna]

The clock width shouldn't be a problem, this is why they have a clock signal as it is used to time and space bits. It can vary. If you use hardware SPI, it usually is pretty solid though.

You can't reuse the same SPI for two different busses like your sample is showing. The Arduino SPI object is used, it is a singleton and a single SPI must be dedicated to the NeoPixelBus. This statement from your sketch enables both at the same time.

#define USE_DEFAULT_SPI_PORT 1
#define USE_ALTERNATE_SPI_PORT 1

Further, the capture states 24 chips are being configured, but your sketch states 4 pixels or just One Chip. Are you sure you have the right sketch and capture?

I want to impress upon you to keep your initial test sketch small and clean as possible to help me read it and help us diagnose the issue.

[Makuna]

Ok, I tested that hardware SPI will not allow the manipulation of the clock to provide the needed reset, so this means only bitbang is supported. I pushed some fixes to the above branch so pick up those changes.

So, declare and construct your bus like...

NeoPixelBus<NeoGrb48Feature, Mbi6033Method> strip(PixelCount, ClockPin, PixelPin);

And here is a capture showing the reset at the front for a single pixel (but still outputs the full chip of 4 pixels).

[seyfettinkazanir]

I tried to create a file using the files you posted but the compilation failed. I am attaching the error message.

In file included from .pio/libdeps/esp32dev/NeoPixelBus/src/internal/NeoMethods.h:38,
from .pio/libdeps/esp32dev/NeoPixelBus/src/NeoPixelBus.h:43,
from src/main.cpp:10:
.pio/libdeps/esp32dev/NeoPixelBus/src/internal/methods/Mbi6033GenericMethod.h: In instantiation of 'void Mbi6033MethodBase<T_TWOWIRE>::Initialize(int8_t, int8_t, int8_t, int8_t) [with T_TWOWIRE = TwoWireBitBangImple; int8_t = signed char]':
.pio/libdeps/esp32dev/NeoPixelBus/src/NeoPixelBus.h:106:9: required from 'void NeoPixelBus<T_COLOR_FEATURE, T_METHOD>::Begin(int8_t, int8_t, int8_t, int8_t) [with T_COLOR_FEATURE = NeoGrb48Feature; T_METHOD = Mbi6033MethodBase; int8_t = signed char]'
src/main.cpp:93:67: required from here
.pio/libdeps/esp32dev/NeoPixelBus/src/internal/methods/Mbi6033GenericMethod.h:73:9: error: no matching
function for call to 'TwoWireBitBangImple::begin(int8_t&, int8_t&, int8_t&, int8_t&)'
_wire.begin(sck, miso, mosi, ss);
^~~~~
In file included from .pio/libdeps/esp32dev/NeoPixelBus/src/internal/methods/DotStarGenericMethod.h:33, from .pio/libdeps/esp32dev/NeoPixelBus/src/internal/NeoMethods.h:31,
from .pio/libdeps/esp32dev/NeoPixelBus/src/NeoPixelBus.h:43,
from src/main.cpp:10:
.pio/libdeps/esp32dev/NeoPixelBus/src/internal/methods/TwoWireBitBangImple.h:49:10: note: candidate: 'void TwoWireBitBangImple::begin()'
void begin()
^~~~~
.pio/libdeps/esp32dev/NeoPixelBus/src/internal/methods/TwoWireBitBangImple.h:49:10: note: candidate expects 0 arguments, 4 provided

[seyfettinkazanir]

no matching function for call to 'TwoWireBitBangImple::begin(int8_t&, int8_t&, int8_t&, int8_t&)' this is show error message.

[Makuna]

Calling Begin(clock, miso, mosi, cs) is only available and required for ESP32 Hardware SPI.

Since we can't use hardware SPI as it won't let us send a single bit for the reset, then the clock and mosi (data out) are supplied at the constructor (as the example above has) and the you need to remove the arguments to begin.

[seyfettinkazanir]

I was able to compile the code with the edits you specified. We have now observed that the data works. What kind of a way should be followed to add mbi6033 to wled with this prepared method. We observed that the first chip works when pixelcount is 4, and the second chip works when it is 8. I am sending a working video attached. Thank you for your help.

WhatsApp.Video.2023-06-17.at.12.48.56.mp4

WhatsApp.Video.2023-06-17.at.12.47.37.mp4

[seyfettinkazanir]

I'm trying to figure out how it works with a few changes.

pixelcount = 8 ;

 strip.SetPixelColor(0, red);
 strip.SetPixelColor(1, green);
 strip.SetPixelColor(2, blue);
 strip.SetPixelColor(3, white);
 strip.SetPixelColor(4, red);
 strip.SetPixelColor(5, green);
 strip.SetPixelColor(6, blue);
 strip.SetPixelColor(7, white);

Working video is attached.

WhatsApp.Video.2023-06-17.at.12.57.27.mp4

[seyfettinkazanir]

I managed to use it by integrating it into the programs in the sample files. animation images are very nice. I am attaching an animation. Same chip but a different strip.

WhatsApp.Video.2023-06-17.at.15.26.20.mp4

[Makuna]

I'm trying to figure out how it works with a few changes.

pixelcount = 8 ;

 strip.SetPixelColor(0, red);
 strip.SetPixelColor(1, green);
 strip.SetPixelColor(2, blue);
 strip.SetPixelColor(3, white);
 strip.SetPixelColor(4, red);
 strip.SetPixelColor(5, green);
 strip.SetPixelColor(6, blue);
 strip.SetPixelColor(7, white);

Of your videos, which end is the first pixel? From your code snippit, it would be the far end but it looks like those aren't lit.

I just want make sure you have the right color order so if you set the first pixel to red, you get red.

If everything looks good, then I will review the code for any cleanup and merge it into master today.

[seyfettinkazanir]

I think the first data is the last data of the spi data. I guess it's the opposite.

Where we log in with the white led esp32. the direction of the line is from white to red. In fact, I took the video from the end of the line in the 4 led video I sent last.

[Makuna]

Oh this means something is still wrong. The key problem is that White (no matter what color order for RGB pixels) should not change location unless it's really a RGBW pixel.
Could you try this for me?

 strip.SetPixelColor(0, red);
 strip.SetPixelColor(1, green);
 strip.SetPixelColor(2, blue);
 strip.SetPixelColor(3, black);
 strip.SetPixelColor(4, red);
 strip.SetPixelColor(5, green);
 strip.SetPixelColor(6, blue);
 strip.SetPixelColor(7, white);

And post a picture.

[seyfettinkazanir]

I am sending a video with the code you requested. Where the first spi data is sent in the section where the white led is lit. So uC is sending data from here.

WhatsApp.Video.2023-06-19.at.09.48.50.mp4

[Makuna]

Interesting. Not only is the order of pixels on the chip taken in reverse, but the order of the data for chips is read in reverse. So the first physical chip uses the last sent data. Since both are reversed, as long as you match the strip size correctly, it works fine if you consider the opposite end from the connection as the first pixel.

Is this a problem for you?

[seyfettinkazanir]

I think it will not be a problem since we will use it with wled. Because there is a reverse operation feature. We can use it.

[Makuna]

BTW: These chips support 16 bits per color element, so you can use Rgb48Color object to define your colors with more resolution.

[Makuna]

The key difference beyond 8bit/16bit internals is the ColorObject, NeoRgbFeature uses a RgbColor object. NeoRgb48Feature uses a Rgb48Color.

You would have to look at the lines the error is showing on (bus_wrapper.h line 991 & 992) to see what its doing. I suspect it's trying to assignment like rgbColor = rgb48Color, which you can't do as its a loss of information.

Check with the WLED guys, do they support 16bit per color elements and how to use it.

Did you search for Rgb48Feature to see if they had an example?

[seyfettinkazanir]

removed these two lines of error from the code. I compile with NeoRgb48Feature, but since the 2nd byte is assigned as 0x00, it seems to be dim all the time.

//case I_HS_DOT_3: col = (static_cast<B_HS_DOT_3>(busPtr))->GetPixelColor(pix); break; //case I_SS_DOT_3: col = (static_cast<B_SS_DOT_3>(busPtr))->GetPixelColor(pix); break; `

Could it be related to Fastled? I guess data preparations such as color selection were done there.
I wrote in forums with wled powers. I'm waiting for someone's reply. Someone referred to the official, I'm waiting for a reply. nickname @blazoncek.

[seyfettinkazanir]

Such a statement has been said on the forum. "WLED operates on 8-bit channels but it supports UCS890x 16-bit chipsets." Is it right to go this way to reach the solution?

[(https://www.led-stuebchen.de/download/UCS8903_English%202017-8-22.pdf)]

The data structure is 48 but I don't know exactly.

[blazoncek]

WLED uses on the fly conversion from internal 8bit color representation to 16bit.
As this chipset has been merged to NPB only 2 days ago, it will take some time to include it in WLED, if at all.
@seyfettinkazanir open an issue on WLED GH requesting support for the chipset and include released version and appropriate method of NPB where support has been added.

[seyfettinkazanir]

@blazoncek Thank you very much for your quick turnaround. I wrote the comment when "softhack" told me to reach you. I started a topic on the subject. https://wled.discourse.group/t/run-mbi6033-led-chip-ic-with-wled/8569

[Makuna]

#718 tracking issue
#719 merged into master

[seyfettinkazanir]

trying to resolve an issue. The led strip is a bit dim and I suspect the first high byte and low byte assigned the probability that I can see on the analyzer won't happen. Is conversion of 8 bit data to 16 bit done in NPB or WLED libraries?. Can I get your opinion on this? @Makuna

[Makuna]

Not a WLED expert, but if I remember correctly, they use FastLED for effects and draw directly into the buffer, bypassing SetPixelColor call.

If I am correct, then more than likely they are not taking Endianness into consideration. A 16bit Value stored in memory on the uC may have the bytes in an order that has the lower 8 bits of the 16bit value actually stored in the upper byte. This is the case with ESP32. This means you can't just copy a memory buffer of uint16_t to the buffer exposed by NPB.Pixels() call. The bytes in the word would be swapped.

If you look in my library file Neo3WordFeature.h at the applyPixelColor() method, you can see where I solve this issue.

[blazoncek]

I am sorry to correct you but WLED uses FastLED only for palettes and some pixel math in some effects. All other stuff is done using NeoPixelBus library (SetPixelColor and (if necessary) GetPixelColor).
We use NeoPixelBusLg class as we depend on global brightness.

Color conversion (in case of USC890x chipset) is done using RgbXXXXColor constructors.

[Makuna]

Thanks blazoncek for the clarification.

I think I spot the issue you found.
Rgb48Color::Dim takes a 16 bit value, but NeoPixelBusLg is only supplying a 8 bit value, so it is always dimmed dramatically.
The question is what is the right solution.

The "correct" solution is that NeoPixelBusLg be enhanced to support a matching type size to the base color object element size for the luminance. This would mean that WLED would need to handle having a luminance that goes up to 65535.

A "workable" solution is that NeoPixelBusLg retains the 8bit luminance and scales it based on the base color object element size.

thoughts @blazoncek ?

[blazoncek]

If you "demand" 16bit brightness in every situation then it is a simple change to set bus->SetLuminance(bri<<8); in case of WLED. I am not sure about other users.

So IMO it would be better to have implicit expansion within NPB in case the target has 16 bit luminance/brightness. I do not know if that is complicated on your side. So I leave final decision to you. ;)

[Makuna]

#720

no changes needed to WLED.