Controlling the HD120 RGB and SP120 RGB colour from a Commander Mini

DO NOT connect the 5V 4pin LED connector to your Commander mini LED port as those ports runs on 12V.

I feel that not being able to connect the HD120 RGB and SP120 RGB Fans to a Commander Mini is rather poor :(: as is them being 3-pin voltage rather than 4-pin PWM :p:.

• I like the idea of being able to control the colour from a CL Mini/Lighting node and wonder it this is possible.
  
• If they are +5 Volt common anode then I suspect that if the anode pin is connected to the +5 of a molex connector and the three control pins to the CL Mini this should work :idea:.
  
• Can anyone think of a reason that this could cause issues? (I don't really care about warranty).
  
• If this will work then I feel I should be able to get an adapter cable from Corsair :nodding:.
  
• Maybe I will have to get one and try...

The commanders operate as Analog controllers. That is, their wires output "Red, Green, Blue, Ground" and they perform 12V PWM on each channel to make an entire strip or all the lights connected to one output be the same color.

By comparison, the HD120 RGB uses Individually-Addressable LEDs that use 5V and a digital control signal. As such, the Commander will never be able to drive these.

But never fear! The fox has come to the rescue!

Details in a new post, Coming Soon™.

The commanders operate as Analog controllers. That is, their wires output "Red, Green, Blue, Ground" and they perform 12V PWM on each channel to make an entire strip or all the lights connected to one output be the same color.

No, the CL Mini and Lighting Noes are digital PWM devices, the connections are "Red, Green, Blue, +12 volts" and the LEDs are common anode. See http://forum.corsair.com/forums/showthread.php?p=838470

Looking at http://forum.corsair.com/forums/showthread.php?t=162617 the HD120 LEDs also have four connections and I guess are +5 volt common anode.

If so then I expect I will have the HD120 LEDs being controlled by a CL mini by 17-Jan-2017.

I probably should have said "Strip-Addressable" rather than "Analog", though in the LED world a lot of people consider strip-addressable (RGBV) to be analog regardless of the fact that they are PWM driven.

In any case, the LEDs on the HD120 are 5V (as you surmised) but not RGBV.

In summary:

The LEDs are WS2812 Individually-addressable SMC modules.

The wiring going to them is "Ground - Data - Data Return - +5V" and they use a stable-clock, single-wire serial programming.

In greater detail, see:

http://forum.corsair.com/v3/showthread.php?t=165029

I wrote up the results so far of controlling them with an Arduino Mega as well as a video of a quick prototype of controlling six fans simultaneously.

Can you get the CL or Lighting Node to spit out serial data at the necessary nanosecond timing for the WS2812 data?

Can you get the CL or Lighting Node to spit out serial data at the necessary nanosecond timing for the WS2812 data?

Thank you for the information here and in your linked post. Getting data from the CL Mini or Lighting Node with nanosecond timing would not be possible without changing the firmware and even then may not be.

Pondering this I wonder, would be possible/sensible to connect the Arduino Mega 2560 to one on the CL Mini C-Link (SMBus/I2C) ports and have firmware in it that makes it look like a "H100i" with 72 LEDs + 0 Fans + 0 Temps? If it presented as defined in http://forum.corsair.com/forums/showthread.php?p=673781 + http://forum.corsair.com/forums/showthread.php?p=663107 then CL4 might even just work and even if CL4 does not I am sure I could easily make SIV control all 72 LEDs.

I'm currently looking into an approach with Arduino Micros that should, if all goes well, fit much better.

The tricky part about the Arduino control though is that it's an AVR and the hefty timing requirement of the LEDs requires the interrupts to be disabled in all the stock WS2812 libraries while it's updating the LEDs. Serial data coming in will only buffer one byte, which makes it easy to miss data coming over the wire when it's updating the LEDs. I'll have to look up the duration of an update call for all 72 LEDs, but I do know that sending 72 LED values real time from software control would be an absolute minimum of 216 bytes, so for the sake of math round up to 230 for a header. Running serial at 57,600 bps 8N1 is just shy of 160 microseconds per byte, so that's just a bit shy of 40ms to send a full update and write it to the LEDs assuming it was listening from the start. That equates to 25 FPS on the LEDs at best. We can do 115,200 baud in half the time and twice the FPS, but still slow by comparison, especially in less-than-ideal cases.

So at that point, having per-LED control on the computer software side becomes an issue with just communication speed on the Arduino unless you use custom hardware controls and data processing. Therefore it's looking very likely that setting up most of the per-LED logic on the controller might be a better idea, but that obviously means more limits unless you have a non-static firmware on the Arduino controller.

Also, I meant to ask:

Being a software engineer, can you think of a good algorithmic way to handle at least the start offset for the LED addressing, if not also arbitrary rotation of the fans, short of creating a mapping lookup array? I dread sitting down to try to think on that but handling a lookup array might be too slow.

I had a look at the hardware today and the box with the 6 x LED connectors is noting more than a distribution board and contains no active components. The HD Lighting Controller contains two chips, one is an AMTEL 542 24C02N, the other has 8 pins, no visible markings at all and is connected to the D0 signal line.

I also discovered that once I have selected a colour then I can unplug the HD Lighting Controller and the LED colour remains unchanged. This means if we just want static colours then we only need to send them once. This could be done synchronously with the I2C/SMBus command requesting the change so there would not be an issue with data overrun/underrun.

The only issue would be if you wished to have cycling patterns, but I don't. I would just like static and temperature defined. For temperature defined I would do this totally within SIV and just set the desired colour rather than having the firmware do this.

It's also irritating that using the HD Lighting Controller it's impossible to turn all the LEDs off.

Being a software engineer, can you think of a good algorithmic way to handle at least the start offset for the LED addressing, if not also arbitrary rotation of the fans, short of creating a mapping lookup array?

Let me have a ponder about this for a while.

This is correct, as described in my other thread. The unmarked chip will be some kind of processor-type item capable of running code and using the EEPROM for the source of this most likely.

You are also correct about the color "lock". The control chip built into each LED holds one triplet of data and takes information based on signal timing. LED 1 gets a set of data and when it does, it spits its old data out to LED 2, which spits old data out to LED 3, and so on. The LEDs in the series just hold on to this information until a complete pause in the data stream occurs for a sufficient time to cause them to latch, which means "Start showing this color". As long as they don't get new data, they continue to PWM the prior color. They can, of course, also be told to be 0x000000 color in which case they will be off, but the included controller doesn't handle that.

For the timing/frame rate, changing between pre-defined modes via software on the computer to the controller would be substantially easier. If the controller has the necessary logic to translate sparse information, it can work just fine. It's also possible to wire up sensors to the controller, though reading analog sensors would be a quick sample compared to reading digital ones. In general though, sending a one-byte mode code followed by a small amount of data would be better than trying to send full pixel frames over serial. Please do keep in mind that the Arduino won't handle synchronous input from the PC and output to the LEDs though. Talking to the LEDs for the most part requires its undivided attention unless the code it's running in between digital out manipulation points is extremely fast to avoid malforming the signal or causing an unintentional latch.

On the addressing, the library that I intended to use (FastLED - I'm open to other suggestions) houses per-LED data in a structure, but then also has an (experimental) container class to "make things easier" (and faster in execution). Worst case I'll end up seeing if I can code some setup that uses a pointer array to the original structure or modifying the container class to handle arbitrarily-sorted pointer arrays. IIRC, I can't just pass the pointer array to the class and have it work since it would not dereference it normally. Gah, dredging up old C++ knowledge shows that if you don't use it, you lose it.