|
|
#91
10-18-2014, 02:38 PM
|
|||
|
|||
Thanks for the cross-link to reddit.
I scanned through the thread and saw one thing that I think is still a misunderstanding of how light works, so I wanted to clarify. Most people on the reddit thread are agreeing that 512 colors is not enough but that 16.8 million is not necessary. The truth of the matter though, is that it really is... and here's why. The image below is the full color space. all 16.8ish million colors. When doing effects for keyboards and the like, it's very unlikely that we'll use the whole space, which is probably why people think we don't need all of it. However, the size of the entire space is simply a bi-product of the space that we actually will use. The common animations we're going to do on our keyboard are 1. Rainbow wipes 2. Fades to/from black 3. Fades to/from white 4. Rainbow wipes to/from black/white 16.8 million colors means you have 256 levels of brightness for any channel. That means that if you're doing a fade to/from white/black (2 or 3 in the image), you only have 256 steps of color. Assuming we want 60Hz (60 fps), that means the fade can't take any longer than 4.2 seconds (256/60). Sure, we're not using the whole colorspace, in fact, we're only using 256 colors, but if we had less than 16.8 million colors, then we'd have less than 256 steps for that fade. This would mean the fade would have to go faster or else it would be less smooth. This is why having 24 bit color is so important; not so we can use millions of different colors on a whim, but so fades have enough 'resolution' to transition smoothly. Here's another example, reversed. Imagine they somehow were able to double what the keyboard can currently do from 8 steps to 16 steps. we go from 512 colors to 4096. Seems like quite a few colors, right? It is... if you're not animating them. That's still only 16 steps for a channel though. In the above example of a fade to white/black at 60Hz would require the fade to be 0.26 seconds long (16/60). Any longer and you're less than 60Hz. Lets say you're alright with 30Hz (30 fps), that's still only going to allow you to go to 0.53 seconds. Make it a second long and you're at 15Hz (15 fps). You're definitely going to notice the stepping then if you haven't already. So in the end, we won't be using the whole 16.8 million point color space for static lighting, but we will be using it for the animations. 
|
|
#92
10-18-2014, 03:33 PM
|
|||
|
|||
|
Here's the video of the WS2812 next to the keyboard. The thing is so bright that even covered by a key-cap it's blowing out the camera. I originally tried to capture it uncovered, but with the exposure high enough to see anything on the keyboard they were just pure white. Anyhow, this is a 50s rainbow which is about 60Hz for a 24bit colorspace. You can clearly see the popping on the keyboard and the smoothness on the left.
https://dl.dropboxusercontent.com/u/...%20Rainbow.mp4 Here are the WS2812 by themselves with the exposure cranked completely down. https://dl.dropboxusercontent.com/u/...%20Rainbow.mp4 Edit: p.s. for the makers out there, the breakouts are made by Adafruit. They're their NeoPixels line of products that have a bunch of different shapes and sizes, since dealing with SMD components usually require special tools and such. These are all breadboard friendly. Last edited by Digital.Zilla; 10-18-2014 at 03:39 PM.
|
|
#93
10-18-2014, 04:02 PM
|
||||
|
||||
|
I'm incredibly enraged by this. I was already put off by the tramp stamp and now this. So many delays and this product isn't even capable of delivering what Corsair is advertising.
I'm a new customer of Corsair and I have to say that they don't live up to their reliability and quality reputation. I like the K95 I have, but my LED's are dying after just a few months. And that isn't an uncommon issue. That's not quality in my eyes. I was really excited for the RGB version as well. Not so much anymore, unless Corsair addresses this issue, I will skip buying it. 512 != 16.8 million, Corsair. I really hope this can be fixed by Firm/Software updates, but as it seems it is not and that is either an incredible, irresponsible oversight by the engineers, or Corsair wants to hoax their customers. And both are unacceptable. </rant> Last edited by Powerpuncher; 10-18-2014 at 04:06 PM.
|
|
#94
10-18-2014, 04:12 PM
|
|||
|
|||
|
Quote:
It is sad to see that it has gone this way. (Yes that might be putting down conclusions too fast)
|
|
#95
10-18-2014, 04:23 PM
|
|||
|
|||
|
Quote:
The issue here is that "16.8 million colors" is a mathematically provable fact. In this case its been proved to be incorrect so far.
|
|
#96
10-18-2014, 04:30 PM
|
|||
|
|||
|
Quote:
I consider that normal advertisement to make customers more interested. The 16.8m colors is one of the 4 main features listed for the rgb lines, and has been a very heavy point in the advertisement of this keyboard line. The things you mentioned are usually just sticked on the box, or even subtly named. And if we hit down now we might be able to stop companies from doing these things overall.
|
|
#97
10-18-2014, 04:42 PM
|
||||
|
||||
|
Quote:
|
|
#98
10-18-2014, 05:23 PM
|
|||
|
|||
|
Quote:
0 members found this post helpful. |
|
#100
10-18-2014, 11:18 PM
|
||||
|
||||
|
Official Response from Corsair
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.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
1 members found this post helpful. |
|
#101
10-18-2014, 11:42 PM
|
|||
|
|||
|
I really hope you can make this happen! Best of luck to you all. It seems to be a very difficult task from reading the documentation for the AN32181 IC due to the tight timings required to feed 8-bit data into the limited set of PWM/constant current drive registers for every LED. I understand it will take a major rework of the software architecture to make this possible. I do wonder, however, why the product was even released in its current state. It had to have taken time to divert from the implementation of 16.8 million colors and write the current 3-bit protocol and firmware, build CUE around it, etc. Surely just delaying the product a bit longer and perfecting the software would've made for less havoc upon release?
|
|
#102
10-19-2014, 12:44 AM
|
|||
|
|||
|
James, when you say it will enable your most resourceful customers access to the advertised 16.8m colours, does this include "regular" customers like myself who are just trying to create slow effects in the existing software interface, or will I need additional scripting knowledge to access this? And will the new system be fast enough to animate with, or just allow for finer control on a static level?
CalcProgrammer, does the approach James has suggested sound practical to you?
|
|
#103
10-19-2014, 01:18 AM
|
|||
|
|||
|
Quote:
I certainly echo pirateguy's question. That is, what kind of 'customizing' would be needed? As a 'regular' consumer or user, I don't have programming/scripting knowledge. Wondering what you mean by 'resourceful.' Thanks in advance.
|
|
#104
10-19-2014, 01:22 AM
|
|||
|
|||
|
I had another look at the datasheet, and from what I can tell the only way you're getting proper arbitrary 8-bit color out of this is to update the chip really fast.
If you remember back in the 90s, video game consoles like the NES and Sega Genesis used color palettes, i.e. you picked a fixed set of colors to draw the screen with. You may have 256 levels of blue available but at any given time you can only use maybe 10 of those colors. This chip is pretty much the same idea, you have a palette of 8 brightness levels to apply to all the LEDs. The only way I can see this working is if you rapidly edit the palette mid-scan to update it with new colors before it actually sends them to the LED outputs. If the palette has 8 colors in it, you could update every 8 LEDs scanned rather than every single LED. Still demands very precise timings as well as some level of synchronization to the scan rate of the IC, but if they think they can get that level of output timing then I think they can do it. I was very skeptical that they can hit windows on the order of tens of microseconds with a 50MHz processor, but if they have some form of interrupt and timer driven update function maybe they can. I was wrong when I said the maximum frequency is 1MHz. That is true if they are using I2C, but digging deeper into the text of the datasheet shows that in SPI mode (which they are likely using, SPI generally supports higher speeds) SCL can run up to 10MHz (see page 42). This means tighter timing may be reasonable if the CPU supports it. On the other hand, I just did a test by hooking up a photoresistor to my oscilloscope and holding it against the LED as I commanded a voltage. It showed a scan (pulse) rate of 200 Hz, significantly higher than the 60Hz I assumed before. The 200Hz figure lines up with what is shown on page 49, which specifies 194 Hz.
|
|
#105
10-19-2014, 01:25 AM
|
|||
|
|||
|
So... there's a reasonable chance they can pull it off?
|
 |
|
|
Reputation: 13
Linear Mode
