Hexagl0w
The Hexagl0w is a modified IKEA FADO, with a Hexasense prototype board plus HexaHorst inside.
Currently it's controlled by writing data (color codes) to endpoint 20 -- via a state machine or using hexaswitch. Keep in mind you have to enter the codes into hexaswitch in decimal, not hexadecimal.
Endpoint 20 takes UINT8 data. Each byte has four parts: 2 bit to control blinking, and 2 bit for each red, green and blue.
Bit number | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
--------------------------------------------------------------------------
| blink control | red | green | blue |
If the blink control bits are set to 00, each color channel (red/green/blue) can be controlled in four levels: Off (00), 33% brightness (01), 66% brightness (10), and full brightness (11).
For instance, the value 00 01 00 11 (19 in decimal) sets no blinking (00), 33% red (01), 0% green (00), and 100% blue (11), which is approximately what you see in the photo above.
Right now a finer resolution of color values and fancy animations like slowly cycling through colors is available, but very likely will be in the future.
Setting bit #6 converts the 33% brightness into a blinking. Each color channel that has the brightness level 01 set will then blink.
Setting bit #7 will convert the 66% brightness into a faster blinking.
For instance, to make the Hexagl0w blink in red quickly, send it 10 10 00 00 (160 in decimal) on endpoint 20. It sets the fast blink bit, and sets red to 66% brightness, which is now "fast blinking".
The value 01 00 01 00 (68 in decimal) makes it blink in green more slowly, setting the "slow blink" bit (#7), which converts the 33% brigthness channel into a "slow blink" channel, and activates green for that channel.
A new version of the Hexagl0w software is being written at the moment. It will support MOAR color variations. It uses the HSV color model which is much better suited to be trimmed to the limitations of the LED driver chip (which can display only two brightness levels at the same time, in addition to full brightness and off).
It is also planned to implement fading or cycling between colors, so that you can make the Hexagl0w produce some nice colorful light effects.
Here's how the packet format's gonna look like:
Packet Type: 16Bytes (each of the fields is one byte wide)
uint8_t command;
uint8_t cycle_time_h;
uint8_t cycle_time_s;
uint8_t cycle_time_v;
uint8_t begin_h;
uint8_t end_h;
uint8_t begin_s;
uint8_t end_s;
uint8_t begin_v;
uint8_t end_v;
The firmware can be found in the bl-hexagl0w branch (along with a version of hexaswitch that's capable of sending 16byte packets, which you'll also need), so if you happen to have a PCA9532 LED driver chip and a Hexabus devboard, you can make your own Hexagl0w and give it a try.
If you just want it to glow in a constant color, just set cycle time to 0 and begin and end of each channel to the same value.
For nice glowy fading effects, you can use the cycle time: If begin and end of a channel differ and the cycling time for that channel is greater than zero, the hexagl0w will fade between those values (the time is cycle_time * 0.08 seconds for now) depending on the "command" byte. Each channel has a bit in the command byte: H has the LSB, S has bit 1, and V bit 2. If the channel's bit is set, its channel will fade back and forth between the begin and end values. If the bit is not set, the channel will fade from its begin to its end value, and then jump back to the begin value.
Keep in mind that due to the limitations of the LED driver chip and the way the HSV color coding is implemented, not all color combinations are possible. If you think of the HSV color space as a cone (black at the tip of the cone, and the colors at the round end, grey in the middle), the subset of this space which is supported by the hexagl0w is the surface of the cone, plus the central axis (from the tip (black) to the center of the round end (white)).
