Air Series HD120 RGB, can I turn the led off?

Hi,

I recently bought the Air Series HD120 RGB LED 3-pack + LED-controller.

I like it, however I miss one important feature. I can't turn the leds off.

If for instance I want to watch a movie in a dark room I would like to turn the led on the casefans off.

Does anybody know a way how to turn the leds off ?

(I prefer with some kind of software) Removing the Sata power kabel from the Corsair HUB is not ideal.

Does anybody know a way how to turn the leds off ?

 

(I prefer with some kind of software)

I was wondering the same and AFAIK you can't :(:.

I suspect with a CORSAIR Lighting Node PRO you could, but I don't have one so can't confirm this.

I was wondering the same and AFAIK you can't :(:.

 

I suspect with a CORSAIR Lighting Node PRO you could, but I don't have one so can't confirm this.

Normal HD120 RGB controller: Cannot turn it off, no. That's why I started building a custom controller before the other thing existed.

LNP? Stand by... *Goes to hunt for his spare PSU since the LNP takes 3.3v from the SATA power connector and drive-runners always provide 12 and 5*

LNP has:

Brightness (Full to Off) for each channel.

Each channel can be Strip or Fans (through hub), or Disconnected

Fans are addressed by physical LED position so I'm happier with my controller

You need to manually tell it how many strips or fans you have

You can set each strip/fan manually between:

Rainbow ("Rotates" forward or backward)

Color Shift (Changes all LEDs at once between two colors or random colors)

Color Pulse (Slow on, then quick fade, two or random colors)

Color Wave (Two or random colors chaser in one direction)

Static (Color)

Temp (Three colors by temp and sensor)

LNP? Stand by...

I wonder what protocol it uses. I guess you have one and it should be good to know the USB VID + PID + REV, though I expect the VID will be 1B1C. Better still please will you post SIV port information screen shot which I am hoping will be as below. If it does then what does [Link Devices] report?

I wonder how tricky if will be to reverse engineer the protocol and/or device registers... I suspect I will have to get one then get some USB traces of what CL4 sends to it.

BTW can CL 4.5.0.55 upload new firmware?

I wonder what protocol it uses. I guess you have one and it should be good to know the USB VID + PID + REV, though I expect the VID will be 1B1C. Better still please will you post SIV port information screen shot which I am hoping will be as below. If it does then what does [Link Devices] report?

 

I wonder how tricky if will be to reverse engineer the protocol and/or device registers... I suspect I will have to get one then get some USB traces of what CL4 sends to it.

 

BTW can CL 4.5.0.55 upload new firmware?

Gift for you attached.

If CL4 4.5 can upload firmware, I have no idea how it would be convinced to do so. It has a lot fewer options than CL3. :\ That being said, I find it interesting that the LNP is on Bootloader version 0.2 and firmware version 0.1.46. Not even 1.0 releases. XD (That's fine for a bootloader if they used an industry standard one though).

Given the CPU on the board, it is very likely to be a pretty standard firmware update system.

Do you have the set up to get a USB trace?

Do you have the set up to get a USB trace?

Thank you. Looking at the USB descriptors I guess it's a totally different protocol to what the CL Mini LED uses, I just hope it's not encrypted ;):. At least it's a HID device :biggrin: rather then a COM port like the NZXT HUE+ :(:. I wonder what the HID details are, press the appropriate button on [HID Bus] and SIV should show them.

I usually use USBlyzer on one of my test systems, but as I don't have an LNP I can't. I am tempted to get one, but would like to feel I have a fighting chance of reverse engineering the protocol before I do.

Now I know the PID I have added the initial support to SIV. Now all I need to do figure out then send appropriate commands to it.

It looks like the device is returning "" as USB string one rather than "Corsair", but at least it has a serial number that looks like it will be unique.

Interesting discovery: It crashes more often than not when plugged in to USB, causing the device to not initialize correctly. Discovered this is because of the boot time of the chip timing out the USB communications. It really wants to get power first and then talk to the OS when it's ready. This is fine when normally installed, it just makes non-installed diagnostics a fun thing.

HID Bus info is attached for the device. You'll have to wait until after I'm finished with some normal work for me to look into possible USB sniffing, but if you have any other quick data requests I might be able to snag them before that.

 

Interesting discovery: It crashes more often than not when plugged in to USB, causing the device to not initialize correctly. Discovered this is because of the boot time of the chip timing out the USB communications. It really wants to get power first and then talk to the OS when it's ready. This is fine when normally installed, it just makes non-installed diagnostics a fun thing.

Thank you, it's not too exciting, but at least the LNP send a sends a sensible reply. I have just spotted the input length is 17, so I suspect I can only send the RID + 16 data bytes and get back a RID + 64 data bytes.

By it do you mean the LNP crashes? I feel this is in keeping with CL4 which is overly fond of crashing. When I was adding CL Mini support to SIV the firmware crashed quite often if I sent an incorrect message to it and in the end I added a toggle switch so I could restart the firmware without needing to power down the PC.

By it do you mean the LNP crashes? I feel this is in keeping with CL4 which is overly fond of crashing. When I was adding CL Mini support to SIV the firmware crashed quite often if I sent an incorrect message to it and in the end I added a toggle switch so I could restart the firmware without needing to power down the PC.

The LNP can just be plugged into a USB port, however the processor in it does not boot fast enough to be initialized by the PC all the time, so the USB device ends up with a windows error indicating it cannot be initialized. If I power up the back channel power first, it's fine.

Still makes me wonder about the 3.3v lead though... The processor on the LNP runs at 3.3v, but it's obviously talking when plugged into USB, which is 5v. The LEDs take 5v. So I don't know if the processor even really needs the 3.3v feed from the SATA power connector..

Still makes me wonder about the 3.3v lead though...

It's hard to know without looking at the windows event log and/or C:\Windows\inf\setupapi.dev.log.

I feel needing 3.3V is silly and the LNP should use a DC-DC converter. It claims to only take 50mA from the USB connection so I suspect it does not use much USB power at all. Maybe I will just order one and assume I will be able to deduce the protocol or at least most of it...

So I don't know if the processor even really needs the 3.3v feed from the SATA power connector..

I was never very good at being patient so now have an LNP. I tried it without +3.3 and it seems to work OK. I was wondering what the switch below the little hole did, so I unplugged the power + USB, pushed it then connected just the USB and an NXP device came up :eek:.

Which I assume is a recovery flash loader. There is a also a 128KB FAT12 USB drive that 100% full and contains a 128KB file called firmware.bin.

I have made a start on the protocol which is unencrypted :biggrin:. It's trivial to get the two version numbers and I have also managed to write a control temperature, but when I send the main setup packet I get an error code 0x12. I suspect I need to start an update transaction, but thus far I have not figured out what all the things CL4 sends do. CL4 also sends lots of noise packers that ask for the firmware version every second which are a PITA and I can't see why it needs to send them. Maybe they are there to make deducing the protocol trickier :roll:.