Jump to content
Corsair Community

K70 RGB keyboard incapable of displaying full color range


Digital.Zilla

Recommended Posts

Hey Corsair,

 

I just received my k70 RGB and am having a bit of a problem with the lighting capabilities. As the title would suggest, my keyboard is short a few colors. It was immediately obvious as I set up some slow color transitions. At first, I set my keys jump to a color on press and fade back to the background color over 4 seconds. I then set up my keys to slowly cycle through the rainbow over a period of 20 seconds. What I see is color stepping/popping instead of a smooth transition from one color to another.

 

As someone who works with arduino LED projects I'm very familiar with the software and the hardware going on under the hood. I figured I'd test this systematically just to make sure I had some hard data. For those reading this thread that aren't aware, you can generate any color of the spectrum with the three primary light colors - red, green and blue. "True color", what we use in computers, is 24 bit color; that is to say each light has to produce a value between 0 and 255 (8 bits) giving us a total of 24 bits for all three channels. Thus, 256 * 256 * 256 = 16,777,216 or the 16.8 million colors advertised on the box.

 

Testing each color was a matter of clearing every key (turning their background color to off) then making a simple fade from 255 of that color (0 on the other channels) to 0, running it over 10 seconds and counting the unique steps of brightness it produced. If a light could produce a full 256 levels of brightness I shouldn't be able to count them in real time. I could.

 

Testing each channel produced the same results: 8 steps of brightness each. 8 * 8 * 8 = 512 colors. That leaves us a whole 16,776,704 colors short of the advertised color range.

 

Now, either I'm doing something terribly wrong in CUE or the proverbial ball was dropped on this product. I really hope that I'm just missing something in CUE but assuming I'm not... IF this is indeed a limitation of the product (software or hardware)... I find it impossible to believe that the engineers building the keyboard and software didn't notice it and, if that's the case, how could you release the product like this? How can you put a giant label on the side of the box touting 16.8 million colors when it can only produce five hundred and twelve?

 

Please Corsair, I want to love this product. I love my standard k70 at work and have been holding out months on buying a second one for home so I get this bitchin' RGB version. I want to do smooth color fades and cycles over long periods of time. Sadly though, as it currently stands, that's impossible.

 

Am I doing something wrong?

If not, is this something that can (and will) be fixed in software or firmware updates?

If not... I'm sadly going to be returning this *almost* amazing product... and that makes me very sad.

 

 

Here's the test

 

All keys cleared

LED_Test_Profile.jpg

 

Simple fade from 255 to 0 over 10 seconds.

LED_Test.jpg

 

Anyone can run the same test to verify it yourself. If you want video proof, i can put some together, even next to one of my arduino projects that is capable of producing true color. But really, it'll take you a few seconds to set this up and see it in person; no possibility of lag or video compression or anything to taint what your eyes see.

 

 

 

 

::pirate:: UPDATE POSTED BY CORSAIR JAMES ::pirate::

 

During development of the keyboard and prior to the release of the RGB keyboard, we came across an issue regarding the possible color combinations. In an effort to get the product out to our customers as committed, we made the tough decision to resolve the issue in a future software release as we believe our customers would enjoy the product as-is.

 

Here are the specifics that detail the issue:

 

Due to USB stack size and performance issues, we had to reduce MCU processing overhead in the best and quickest manner. The LED controller gives us greater than 8 bits of color depth but we use the 8 bits that give us what we believe to be the best color granularity.
Our controller architecture provides for over 100 million color combinations out of which we select 16.8 million to display.
We devised a color palette scheme to encode and compress the RGB color data and the data to select and control the “current sources” that drive the LED array. An unfortunate side effect is that it prevented us from utilizing the full color depth available from the LED controller.

 

We are in the process of making the necessary improvements so that we can send the uncompressed RGB data to the keyboard. Additionally, we are optimizing the data protocol and LED driver/display algorithms through the display control firmware to handle the uncompressed data, and to more efficiently program the “current sources” that drive the LED array. This should give our most “resourceful” customers an easy way to identify the data and be able to easily send standard RGB 8 bit values.

 

This enhancement had already been planned and will be implemented in a few weeks by the release of a software update, which will be announced and be made available to download here and at Corsair.com.

 

- Corsair Team

Link to comment
Share on other sites

  • Replies 621
  • Created
  • Last Reply

I too was curious about this. Whatever the restriction is would definitely be beyond the profile level. I programmed a quick gradient as seen below with one step per color and it had about 7 color transitions.

 

Turns out the only difference between an exported lighting and one created by the software is like one outer "lightings" tag. Don't really get why they aren't the same, but whatever.

 

http://i.imgur.com/v3UV9fO.png

 

Beyond this, also found the Corsair software attempting to access "FAKE" and "FAKE.jpg", etc. files in the logged-in user folder. Kind of weird, integration debug code not removed? Calls into the Qt libraries are also being spammed generating tons of "color out of bounds" exceptions.

 

If I get a chance to check out the I/O messaging, it might give a good idea as to if the problem is a hardware or software limitation.

Link to comment
Share on other sites

Huh, interesting. I was able to replicate what both of you reported -about 8 levels of brightness, some with bigger jumps than others - at least, that's what it looked like to me.

 

I won't be returning my keyboard, i don't think, since i simply like being able to change to general colors for different things and am not so much into animation and whatnot, but certainly disappointing for the price they're charging.

 

Maybe it'll be fixed with an update to the firmware and software, since in their current states both are extremely buggy. ****ing crashes. So annoying.

Link to comment
Share on other sites

Just to be clear up any possible confusion, each LED can actually display 7 (not 8 as I said above) levels of brightness. I was including 'off' as a brightness above because you use it to calculate the total range (e.g. purple is R:max, G:off, B: max). Therefore, the total range is still 512 colors, but the levels of *brightness* each LED can generate is only 7, not 8.
Link to comment
Share on other sites

Based on some reverse engineering (credit to poster on reddit) the CUE software apparently spams LED data to the keyboard, so it might be the software.

 

Also a bit odd how the lua52.dll is loaded into CUE, yet there isn't any lua functionality (as far as we can see, but maybe the xml is translated into lua)

 

In addition to the lua dll there is also these commands.

sub_561AE0(&a2, "Lua source editor", 0, -1);

sub_561AE0(&a2, "Execute", 0, -1);

execute is a button and the "lua source editor" is the title of the window.

 

Hopefully a corsair dev will pop in here.

Link to comment
Share on other sites

Based on some reverse engineering (credit to poster on reddit) the CUE software apparently spams LED data to the keyboard, so it might be the software.

 

 

Well that would probably explain some of the instability between the keyboard and the software. Would love to hear some dev input.

 

 

Wish they'd release the source code so we could have a crack at fixing what they've apparently failed to fix.

Link to comment
Share on other sites

Well that would probably explain some of the instability between the keyboard and the software. Would love to hear some dev input.

 

 

Wish they'd release the source code so we could have a crack at fixing what they've apparently failed to fix.

 

Well it does allow a lot of customization with really fast lights. (Though it is limited in the software currently)

Though it isn't very effective when the keyboard is just a static color.

The usb port itself should keep up fine with the bandwidth.

 

Yeah I also wish they gave their sdk, api, lua, or even gave sourcecode.

 

Guy on reddit are now able to send packets on linux:

[ame]

[/ame]

There's also a link to his reddit thread in the video description.

Link to comment
Share on other sites

Yeah, my reverse engineering shows 3 bits per LED, i.e. 8 brightness steps including off. OP is thus right in saying 8*8*8 = 512 possible colors. I haven't tested to see if the global brightness setting (or the hardware brightness key) can generate more than these 8 levels but from what I found in the protocol, there is not 16.8 million colors per key like the box claims. That would require 8 bits per LED. Considering the framing is 72 bytes per color total, that is room for 144 LEDs at 4 bits a piece, but for some reason they only appear to use 3 of those bits (0111 as full off and 0000 as full bright).
Link to comment
Share on other sites

If not fixable by SW this will get a real issue - think on all the packages they have to redesign stating "with 512 colors".

Of course severe lack of reputation might be the bigger issue.

 

Just out of curiosity - maybe other RGBs suffer from the same - might be some technical specs of the LEDs not allowing more than 8 states.

Link to comment
Share on other sites

Although I haven't seen it myself the keyboard has the "Rainbow Demo" built in:

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

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

 

I saw this demo mode also in several promotion and preview videos. It seemed like the full color range was used. Together with Corsairs' statement that the rainbow demo cannot be replicated with CUE at the moment, the restriction to 512 colors could be a software problem (or missing feature).

Link to comment
Share on other sites

That's my guess as well, the controller on the keyboard most likely can physically drive 8 bits per LED but the USB protocol was cut down to 3-bits for size reasons. As they're stuffing the entire LED array into 64-byte USB control messages they already have to use 5 messages in rotation, going up to 8-bit levels would double that and use double the bandwidth. Perhaps there is a second method of setting the LEDs that supports full 8-bit samples that CUE hasn't implemented yet, or it could require a firmware update as well.
Link to comment
Share on other sites

That's my guess as well, the controller on the keyboard most likely can physically drive 8 bits per LED but the USB protocol was cut down to 3-bits for size reasons. As they're stuffing the entire LED array into 64-byte USB control messages they already have to use 5 messages in rotation, going up to 8-bit levels would double that and use double the bandwidth. Perhaps there is a second method of setting the LEDs that supports full 8-bit samples that CUE hasn't implemented yet, or it could require a firmware update as well.

 

The onboard memory saving function doesn't seem to work correctly yet, so it might be to save the profile to the memory and get the keyboard to run it instead of sending constant packets to the keyboard.

You can see the rainbow if you only plug the power usb in and wait a bit, but that doesn't seem overly smooth to me either.

Link to comment
Share on other sites

Although I haven't seen it myself the keyboard has the "Rainbow Demo" built in:

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

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

 

I saw this demo mode also in several promotion and preview videos. It seemed like the full color range was used. Together with Corsairs' statement that the rainbow demo cannot be replicated with CUE at the moment, the restriction to 512 colors could be a software problem (or missing feature).

 

Nah, you can definitely replicate that rainbow demo on the keyboard. The trick is it's going quick enough so you don't notice the stepping. It's all about number of color values over a range of time.

 

We watch video at 30 frames per second (24 fps in cinema) and prefer to play games at 60 fps. Anything in that range generally looks smooth to our eyes.

 

When doing a full-saturation rainbow wipe you have 7 key frames:

 

red -> red+green (orange) -> green -> green+blue (cyan) -> blue -> blue+red (magenta) -> red.

(See chart below)

 

Fading between those key frames is a simple linear transition, which means one channel starts at full brightness and the other starts at zero brightness, then you swap the colors. Thus, the number of steps you have per channel * 6 gives you the number of unique colors in the full rainbow cycle. At 24 bit color (8 bits per channel) that's 256 per transition. 256 * 6 = 1536 unique colors to display. Thus, at 30 Hz (30 'frames' per second), we could run that color transition over 51 seconds and the steps would be happening smoothly enough.

 

You can reverse this math too. Since we seem to only have have 9 bit color on our keyboard (3 bits per channel) or 8 steps per channel, that means instead of 256 between keyframe, we have 8. 8 * 6 = 48 unique colors per rainbow cycle. Thus, if we wanted 30 fps, we'd have to do a transition 1.6 seconds. If you look closely at that video, look closely at one key, it's going red to red in about one second. Which means it's actually running at about 48 Hz (or 48 fps in common terms). That's plenty fast to look good. However, if you slow that down to, say, 10 seconds. 9 bits (48 colors) / 10 seconds is 4.8 Hz, or 4.8 frames per second. Or worse, that 50 second transition that 8 bit color could do at 30 Hz would be 0.96 Hz on this keyboard... Less than one color step per second!

 

24 bit rainbow - This is what we should have

rainbow.png

 

9 bit rainbow - This is what we actually have...

rainbow9.png

Link to comment
Share on other sites

  • Corsair Employee

Hi all,

 

In the picture with the green slope:

 

http://i.imgur.com/v3UV9fO.png

 

It is not displaying a gradient from green to black. What you're actually setting it up for is 1 single color green to go down in brightness over a duration of 10 seconds. The X axis is the time line for duration and Y axis is the intensity (brightness). If you want to test the entire range of green as a gradient you should add all 255 variations of green as a color at full intensity and then have it be done over 10 seconds (to mirror the original duration you tested the single color at).

 

It should look like this:

 

First color:

R:0

B:0

G:0

 

Second Color:

R:0

B:0

G:1

 

Third Color:

R:0

B:0

G:2

 

and up to 255.

Link to comment
Share on other sites

Hi all,

 

In the picture with the green slope:

 

http://i.imgur.com/v3UV9fO.png

 

It is not displaying a gradient from green to black. What you're actually setting it up for is 1 single color green to go down in brightness over a duration of 10 seconds. The X axis is the time line for duration and Y axis is the intensity (brightness). If you want to test the entire range of green as a gradient you should add all 255 variations of green as a color at full intensity and then have it be done over 10 seconds (to mirror the original duration you tested the single color at).

 

It should look like this:

 

First color:

R:0

B:0

G:0

 

Second Color:

R:0

B:0

G:1

 

Third Color:

R:0

B:0

G:2

 

and up to 255.

 

Hi James,

 

I did what you suggested originally, though I didn't post a screenshot of it. The difference between zero brightness green and full brightness black is the same as far as hardware is concerned (you're emitting zero light). Also, In my test both setups gave the exact same results: 8 steps of actual brightness on the key.

 

More importantly, as CalcProgrammer1 one points out

Yeah, my reverse engineering shows 3 bits per LED

If he is indeed correct (and it lines up with what we're seeing in practice), it doesn't matter what you tell QUE to do, 3 bits is 3 bits... 8 levels of brightness (including black).

Link to comment
Share on other sites

Hi all,

 

In the picture with the green slope:

 

http://i.imgur.com/v3UV9fO.png

 

It is not displaying a gradient from green to black. What you're actually setting it up for is 1 single color green to go down in brightness over a duration of 10 seconds. The X axis is the time line for duration and Y axis is the intensity (brightness). If you want to test the entire range of green as a gradient you should add all 255 variations of green as a color at full intensity and then have it be done over 10 seconds (to mirror the original duration you tested the single color at).

 

It should look like this:

 

First color:

R:0

B:0

G:0

 

Second Color:

R:0

B:0

G:1

 

Third Color:

R:0

B:0

G:2

 

and up to 255.

 

If that were the case, then instead of it being the green channel that doesn't support 256 colors, it is the alpha channel (which I'm pretty sure isn't present, just uses HSB) - still the same issue of not having a smooth transition. I'm pretty sure I also tried what you described to no avail, as well.

 

Based on what I'm seeing, a byte sent to the device covers two keys instead of one. Take "0x77" for example with keys "F8" and "8":

 

When it is set to "0x07", the "F8" key will have one of its channels maxed out while the "8" key will be 0.

 

When it is set to "0x70", it is the opposite.

 

Now, had it been that "0xFF" (for example) was a value for ONE key, it would indeed support 16.7 million colors. As it stands, we don't even know if the device itself can support 16.7 or if it is a firmware limitation.

Link to comment
Share on other sites

Tested it out this tonight, I adjusted the value of green on a single key from 255 down to 0 in increments of 10 (should see a difference. Instead of changing each increment the color only changed 7 times (8 including off). Looks like the above methods of testing is correct, and currently the keyboard only accepts 512 colors/3 bit per led. Hopefully this will be fixed with a firmware update. When changing colors in CUE, the color will not actually change until it goes past one of the steps, all of the colors in between are the same.
Link to comment
Share on other sites

Any update on this James?

 

You guys are currently supporting %0.000031 of your advertised color range. And we all know how users love false advertising.

I love it so much that this new cherry brown will be returned if this poor gradient situation isn't fixed in short order.

Link to comment
Share on other sites

Well it was certainly full 16.8m colors at one point. @ 1:12

It even looks brighter, but that might just be the camera.

 

There's definitely still some stuttering in that video, but it's way more than 8 steps for sure. The interesting question is, was that CES demo was real production hardware or just a prototype? If it's real hardware, than hopefully this is indeed on the software side. However, if it's a prototype, then that could also explain why the keys look way brighter (though cheap digital camera's don't have nearly the exposure range that the human eye does, so lights tend to always look brighter).

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.


×
×
  • Create New...