UCS7604 and inconsistent applySettings data output

[exitrip]

I guess this is technically a feature request, as I'm working on adding code, but the behaviour is buggy. I developing on Ubuntu, using VSCode's PlatformIO plugin, to build WLED images for an ESP32 WROOM-32. I don't think WLED or PIO has anything to do with the output I'm seeing. I cross posted this as an issue to be annoying.

Based on chips with "applySettings" methods, I'm testing a simple extension the NeoRgbw64Feature class to include a hardcoded 8 byte header to try to bring up a custom strip of UCS7604s. Absent a real datasheet, both the drivers that work with the strip frame the data string with FFFF_FFFF_FFFF_0003h, which is probably 3 current output + 1 a mode setting, but all I want to test right now is if the chips will accept this header.

While I see consistent data output in pixel fields (pData after the 8 byte header, i.e. red is the red value, green is green value ), the 8 start bytes are oscillating back and forth between two values that have basically nothing to do with FFFF or 0003. I'll skip pictures of the LA captures for now, but is there some lower layer data mangling between applySettings() and the wire?

class NeoUCS7604Settings 
{
public:
    // NeoTm1914Settings(NeoTm1914_Mode mode = NeoTm1914_Mode_DinOnly)  :
    //     Mode(mode)
    // {
    // }

    // NeoTm1914_Mode Mode;
};

class Neo8ByteElementsUCS7604Settings : public Neo8ByteElements
{
public:
    typedef NeoUCS7604Settings SettingsObject;
    static const size_t SettingsSize = 8;

    static void applySettings([[maybe_unused]] uint8_t* pData, [[maybe_unused]] size_t sizeData, [[maybe_unused]] const SettingsObject& settings)
    {
        // settings are at the front of the data stream
        uint8_t* pSet = pData;
        // uint8_t mode = 0xff;

        // 0xFFFF, probably G max current
        *pSet++ = 0xff;
        *pSet++ = 0xff;

        // 0xFFFF, probably B max current
        *pSet++ = 0xff;
        *pSet++ = 0xff;

        // 0xFFFF, probably R max current
        *pSet++ = 0xff;
        *pSet++ = 0xff;

        // 0x0003, probably "field" mode (number of channels)
        *pSet++ = 0x00;
        *pSet++ = 0x03;
    }

    static uint8_t* pixels([[maybe_unused]] uint8_t* pData, [[maybe_unused]] size_t sizeData)
    {
        // settings are at the front of the data stream
        return pData + SettingsSize;
    }

    static const uint8_t* pixels([[maybe_unused]] const uint8_t* pData, [[maybe_unused]] size_t sizeData)
    {
        // settings are at the front of the data stream
        return pData + SettingsSize;
    }
};

// class NeoRgbTm1914Feature : public Neo3ByteElementsTm1914Settings
// ...
// class NeoRgbw64Feature : public Neo8ByteElementsNoSettings
class NeoRgbw64Feature : public Neo8ByteElementsUCS7604Settings
{
public:
...

[Makuna]

Yeah, there are some things you did wrong. Let's start at the top with chip, the UCS7604.

The only spec on found really doesn't describe the header in detail, mentions gain values and a mode setting; but not enough to even attempt defining it or even sizing it. It does sound like the header is optional though. Where did you get your information for what is in the header? From capturing from a functional controller?

You mention using the NeoRgbw64Feature, does this mean you plan to use the UCS7604 is a 16bit per color element? 0-65535 rather than 0-255? By that lackluster spec, it hints that it can accept bits of 8/12/14/16. Doesn't really mention which is the default; let alone how to set this.

The Tlc59711RgbwFeature is a better but simple example to start with. It is a 16bit per color feature that has a custom settings object. Copy it and the replace the code for updating the settings with yours. That part looked fine in your attempt.

If you plan to expose the current settings, then the settings object has to be derived from NeoRgbwCurrentSettings. There are examples using this, but most are more complex to support arbitrary pin outputs to color mapping. The UCS7604 has specific pin to color so it could be a little simpler.

[Makuna]

Not sure why, but I had seen you posted some screen shots from your scope for a notification email from github, but I don't see them or that post here in github.
BTW, you can just paste into your comment the images and they will appear.

[EdBear-Ae]

Thanks for the feedback I'll try the Tlc59711RgbwFeature class. I started modding the NeoRgbw64Feature, because WLED drives the "16b" RGBW UCS8904, with 8b color values shifted up to MSB. The signal output for the 8904s looks like it would work for the 7604s with the header settings.

These chips are woefully under-documented, even in Mandarin, but we have a test fixture from a CM and a cheap amazon controller (WT-SPI) that can drive the UCS7604s. I am working off captures from both those controllers, and that's where the FFFF_FFFF_FFFF_0003 comes from. Both controllers have a 8-16us space after the header, that MAY not be needed. Right now I don't really care about color space or the bit width, just want to see if the 7604 will accept this frame header with the default settings timing (no space)

I did try to post images of the ESP output, but realized I didn't have pictures of both states.

I'll see where I can get with the 5971 code, thanks again.
The output of the above code oscillates between these two states:

[exitrip]

For reference, here's the init data from a working controller :

[exitrip]

So a few notes, WLED (client's requirement) is using an ancient and/or heavily stripped down hardcopy of NeoPixelBus, so there's no Tlc59711RgbwFeature or Neo4WordElements or other classes.

I'm pretty sure that I'm not getting WLED's bus wrapper to ever call applySettings(), so I'm likely just looking at uninitialized memory / garbage in the settings header.

I'll post an update for posterity when I get it working, but it's my code, not yours... and thanks for the help.

[Makuna]

Yeah, the WLED team is working through some bigger changes for some next release that will move it forward. I have made a few updates and working on a final one to improve some things for them.

Settings are so chip specific, it's hard for them to support. Lots of branching already.

Today (master branch) the settings are not stored by NPB other than final translated bits in the output buffer. So if SetPixelSettings() is not called, that part of the output buffer might not get initialized. The near future (CoreShaderBeta branch) NPB will store the settings and there will be defaults. So even if SetPixelSettings is never called, at least it will have the default settings from the settings object constructor.

[exitrip]

That's good news about the WLED dev. I got some noisy strobes of life this morning, but the header data is still not constant, so it's not surprising that the strip flickers. The settings data is sometimes correctly what I've hardcoded, and other times its exactly as pictured in the first capture I posted this morning, by eye: 0000_1010_0000_0000.
I'll keep tracking down what over writes the settings, but it's also looking like the 7604 needs a space between settings data and output packets.

Is there any way in the library to add mark's or spaces, currently?

I love a good reversing project, so I'd be more than happy to wrap this up in a PR to support these chips if I get figure out what these settings values do...

[Makuna]

On the Topic of the oscillating header:
What platform? ESP8266/ESP32/ESP32C2/??
Simplify your sketch to the minimum that reproduces the problem. Share it here for review.
If you have made any changes to NeoPixelBus, share those changes also.

[exitrip]

It's an older ESP32-WROOM-32 module, with a ESP32-D0WDQ6 Xtensa chip.

Unfortunately I don't have a smaller test code base spun up yet, as the gig is basically "please hack our stips working with WLED in two days" right now. No changes to NeoPixelBus from WLED's:

#define B_32_RN_UCS_4 NeoPixelBusLg<NeoRgbwUcs8904Feature, NeoEsp32RmtNWs2812xMethod, NeoGammaNullMethod>

//elsewhere
typedef NeoRgbw64Feature NeoRgbwUcs8904Feature;

Hence I'm just adding the settings code on top of NeoRgbw64Feature in NeoRgbw64Feature.h right now.

past begin, and constructors, I suspect there's something in show(), canshow(), or the setPixels() that I'm not doing right / needs tweaking.

[Makuna]

First steps to tract down the problem is always simplify to narrow down the problem.
You can try using the NeoPixelTest.ino sketch from the examples and replace the methods and features and add the call to SetPixelSettings().

[Makuna]

Ok, I think I know what is going on. Due to the async nature of the RMT, it has two internal buffers, editing and sending. When you call SetPixelSettings() it updates the editing buffer. Now normally this isn't an issue, but I am sure that WLED is calling Show(false), which means to skip keeping the buffers consistent (copying between editing and sending). This means one of the buffers was not updated with the settings.

So, to test if this theory is it, change the Show(false) to just Show(), or Show(true).

This isn't the right solution, as this will incur some overhead.
The short-term solution, would be to call SetPixelSettings(), twice, before the first Show() call, and then after the first Show() call. This will update both. The long term solution is in the works as discussed above where the method will retain the settings and apply as needed.

[exitrip]

Thank for the callout about the double buffering, I won't go into the messy details of the WLED wrappers around show(), but hardcoding ->show(True) fixed it.

What's more, after "discovering" a whole second word of settings data, I've got the UCS7604s working with NeoPixelBus! The settings packet format could use more testing, but I've definitely fuzzed out the color bitdepth, and number of output channels fields, with a strong guess at channel current limit fields too.

Let me know if your not interested in adding support for these chips, otherwise look out for a PR this season.

[Makuna]

I welcome all changes. Especially if we discuss the solutions beforehand like we are doing now.
I am looking at how I can short term fix the double buffer issue not getting correct settings, so the show() doesn't have to change. The next big release already has a fix, but that is a big change in the methods architecture that is not ready for prime time yet.

[Makuna]

#842 to track this