add support for Gen2 Addressable RGB multi-layer mode

[FreezyExp]

Gen2 has the ability to sense the number of leds and is able to detect and adress the individual lights. This sounds like amazing tech to add to WLED as single pins multi segments as well as auto-sensing led.

Gen2 capable devices also support being used as regular ws281x led strips.

It seems like a one-wire interface, possibly also using the 5V and Ground for additional data signals. I will see what I can figure out, but if anyone wants to pitch in, please do 😄

Product page of the device I am analyzing: https://landing.coolermaster.com/pages/addressable-gen-2-rgb-led-controller/

TODO:

With regular arduino:

• [x] is it just one-wire or i2c? report the data captured

nope, the silkscreen has the Ground and 5V directly wired to the output pins, no data there

If that does not work, then tap the wire(s) between a Gen2 RGB controller and the Gen2 RGB products:

• [ ] figure out the protocol

[FreezyExp]

Looking at the controller pinout, it does not seem like the 5V or Ground is being used as part of the data. I used a OneWire scanner with no results :-(

[blazoncek]

You should check with NeoPxelBus for support since WLED uses that to drive LEDs.

[cnn123666]

The IC controlled by GEN1 and Gen 2 is different. Gen2 has a two-way communication function, which can exclusively adjust the output current gain of the chip RGB port, and change the display synchronization setting. In addition, the two-way mode returns the number of chip links and controls individual light beads

.

[cnn123666]

@FreezyExpI think need to disassemble a Gen2 fan to see how it is implemented

[cnn123666]

At present, there is very little information about Gen2

[cnn123666]

https://www.chiphell.com/thread-2378335-1-1.html

[blazoncek]

@FreezyExp @cnn123666 WLED does not provide a driver for LED chips. It uses NeoPixelBus for that. If you want Gen2 support in WLED please open an issue with NeoPixelBus and request support there. Once support for Gen2 is included in NeoPixelBus, WLED may use it if someone would implement it. None of the devs currently have Gen2 LED samples to test.

[cpldcpu]

@FreezyExp
Sorry to comment on this old issue. I have analyzed and reverse engineered the ARGB GEN2 protocol quite a while ago and am trying to write it up now, as it seems there is no information on the web.

Curiously, copilot is suggesting blocks of text that indicate it learned somewhere about ARGB GEN2. Example below. I am super confused now, but cannot find the source for the hell of it.

Example:

"The ARGB Gen2 protocol is an extension of the WS2812 protocol. It is fully backwards compatible, meaning that a Gen2 controller can drive a WS2812 LED, and a WS2812 controller can drive a Gen2 LED. The protocol is still based on a single wire, but it now supports bidirectional communication. This allows the controller to autodetect the number of LEDs on the bus, and to monitor the health of the LEDs. The LEDs can also send data back to the controller, which can be used to implement more complex topologies."

[FreezyExp]

as suggested by blazoncek, please do provide NeoPixelBus with your code, information and/or insights

[blazoncek]

@cpldcpu please contact @makuna and provide your findings to him or, better yet, open a PR to NeoPixelBus with the implementation.

[cpldcpu]

Sorry, maybe i was not clear on the question: The fact that copilot knows details about ARGB GEN2 could suggest that there is documentation out there, somewhere. I wonder whether anybody is aware of any docs? I don't want to spend time one something that is already there.

(NeoPixelBus implementation aside, contributing there was not really in my scope so far)

[Makuna]

@cpldcpu Help find the documentation. A quick search it seems that it is not easily found. https://gameplustech.com/aura-addressable-gen-2-header/#:~:text=AURA%20Addressable%20Gen%202%20headers%20are%20a%20type,designed%20to%20work%20with%20standard%20RGB%20lighting%20systems. "a proprietary protocol developed by ASUS, the manufacturer of the AURA lighting system, to communicate with aRGB lighting devices and control their behavior." "... compatible with WS2812 ..." Without having one of these motherboards (controller) and the fan (Gen2 supported) to reverse engineer the protocol, it doesn't seem likely to happen.

[LiFE1688]

IMO, there really isn't a need for WLED to implement ARGB gen 2, but depending on what you are using it for. If you are using it as a LED strip controller, the generic LED strips and WLED is more than enough. You count the number of LEDs, and enter it into the config for WLED.

If you are planning to create a ARGB gen 2 controller box for your ARGB gen 2 motherboard, then that's a different thing. Connect motherboard to WLED then to the strips (fan, strips, etc) I don't see why you can't mod WLED to take information and reply back to the motherboard.

ESP32 has 10 channels, you can use each channel for 1 strip or multiple chained strips of ARGB (doesn't matter gen 1 or gen 2) Inside WLED you enter the number of LEDs per channel

Channel 1 : 10 LED Channel 2 : 16 LED Channel 3 : 32 LED

If you know how the protocol works, you can pretty much reply back as a single strip or multiple strips. This is a screen capture of ARGB gen 2 with gen 2 fans and a gen 2 LED strip. (Aura Creator)

[FreezyExp]

My use case would be more control while retaining easier daisy chaining all the Gen2 RGB strips in a PC case.

My controller currently has 6 groups, each group having 1 or more strips, each additional strip being a duplicate of the first strip on the group (this limits the effects, but reduces the amount of pins needed). Each group requires additional cables and connectors, which clutters up the build. As all the LEDs support Gen2, I could have added all of then to a tidier single loop.

It would allow for more effects without even more cables and connectors for this use case.

[LiFE1688]

Ah, then I guess ARGB gen 2 isn't really required in your use case. ARGB gen 2 requires data line to be daisy chained serially. One end in, the other end out. If you parallel connect them, only one string will show up, the other won't, so no, it wouldn't help in your use case.

Current ARGB controllers connect the strips in parallel, so I can understand if you want to customize a light show, it can be annoying, since it isn't per pixel controlled.

My suggestion would be: 1) connect the strips in serial, connect them to a ESP32 (faster) or ESP8266 (slower), power the LED strips and ESP32 with a 5VDC (keep note of total power consumption and get the adapter accordingly). Inject power to the strips, if required. You can use something like Signal RGB or OpenRGB to control the WLED to sync, customize the lighting.

or

2) Use the ARGB on the motherboard, and get ARGB gen 2 devices, but you will have to make sure they can chain serially, and not exceed the 500 LED limit. Again, if you connect the ARGB gen 2 devices in parallel, only 1 device will show up during detection, and the customization is parallel.

[cpldcpu]

Hi,

Actually ARGB gen2 does indeed allow controlling several parallel strings in some configurations. I am halfway through writing it up.

This could be added to WLED, but will require additional GUI.

• Bidirectional communication: Enables automatic detection of the number of LEDs on the bus and allows reading information from the LEDs.
• Configuration: A special mode allows writing configuration data to the LEDs, which allows to change PWM frequency, driving current, and other parameters.
• Y-Cable mode: Allows to connect multiple LEDs strings in parallel to the controller using a single wire. There are mechanisms to detect individual strings, uniquely identify them, and control them independently.

While the first two items are somewhat logical extension of the WS2812 protocol, the Y-Cable is the most curious feature. It allows for easy connection of multiple ARGB GEN2 devices to a single controller port.

[LiFE1688]

That's weird, I I used a ARGB splitter, and it will only detect one or the other device, but not both. Maybe the Y cable is a different type than what I have.

[cpldcpu]

That's weird, I I used a ARGB splitter, and it will only detect one or the other device, but not both. Maybe the Y cable is a different type than what I have.

Are you certain you are using GEN2 LEDs then, and also the controller? It's not really that obvious. There are also some variants of GEN2 that do not support the Y-splitter.

[LiFE1688]

They are detected, you can see on the picture above, but that's in serial, not parallel.

[cpldcpu]

They are detected, you can see on the picture above, but that's in serial, not parallel.

ok, so you have not tried using a y-splitter.

[LiFE1688]

Tried, it didn't work, it detected 1 out of the 2 connected. So I went back to connecting it in serial. If I just connect the data in to a splitter, only 1 device is detected out of the 2 connected to the splitter. Same goes for 3 devices.

The device has 1 in, 1 out for LED connector, those are detected properly without issues.

Which is why I just use the 1 in and 1 out and connected them in serial. Which is why I am wondering whether the Y Splitter is a different type, like gen 2 splitter.

[ghost]

I took 4 gen 2 fans I used it with a distributor all four operate as separate fans

[LiFE1688]

Weird...

[ghost]

led strip what brand?

[cpldcpu]

Here is a full analyis of the Gen2 Addressable RGB Protocol.

https://github.com/cpldcpu/Gen2-Addressable-RGB/blob/main/docs/Gen2_ARGB_protocol_analysis.md

Have fun! It will require quite some changes to implement everything.

[blazoncek]

@cpldcpu please talk to @Makuna of NeoPixelBus (as discussed above) if you haven't already.

[Makuna]

With @cpldcpu new repo for the investigation and reverse engineering, all further "detailed" discussions should be on the discussions area on that repo. Summary and workable direction will be brought back here when available.