Tag Archives: hardware

Chumby – A Hacker’s Microcosm

I got a Chumby as a holiday gift; it’s really cool and really hackable.

The good:

  • Hardware and software is open-source.
  • Runs Linux.
  • Very easy to hack: SSH, BusyBox, lighttpd, Ruby, etc.
  • Two USB ports.
  • Audio out (internal speakers sound amazingly good for their size).
  • Built-in microphone (haven’t figured out how to use it).
  • Can play FLAC files from USB drive.

The bad:

  • It’s very difficult to get it to show pictures off a USB drive. The only way apparently is to install a local HTTP server and use a widget: http://www.discarded-ideas.org/chumby/photoframeusb
  • Flash widgets/apps only — Flash is not open-source.
  • Switching between widgets and channels is fiddly.
  • One button is not enough considering widgets take up the whole screen modally.
  • It needs more RAM. 64MB is just barely enough.

Below is the “Virtual Chumby” showing my “Clocks” channel:

Overall it’s a very cool device. Right now it’s in the bedroom but it’s too useful to sit there as an alarm clock.

At some point I’d like to try to interface a small webcam to it.

Luxeed LED Keyboard Driver for Linux


Hardware Review

This is a really cool keyboard, except that the ESC and function keys do not light up and are strangely located and difficult to press. I also don’t understand why the spacebar does not light up; seems like it’s the most important key. The construction is not very good and the feel is a bit mushy. However, this keyboard is fun for hacking and could be really great for user training.

Device Driver and Source Code

After much troubleshooting, I have created a simple C driver library for the Luxeed deTA 100/200 keyboard using libusb. This driver allows the LEDs under each key to be set from C from most Unix-like operating systems. This is my first attempt at reverse-engineering the protocol of a USB device.

Source is located here: http://github.com/kstephens/luxeed/tree/master

Overview

There is a user-space single-threaded, non-blocking I/O daemon using libevent that accepts multiple TCP connections on port 12345 to execute pixel update commands. I’ve been able to get time between frames down to 0.025 seconds.

Commands

Commands sent from clients via TCP to the server:

set <RED> <GREEN> <BLUE> <KEY>...
update
wait <SECONDS>
get <KEY>

Keys can be specified using names (e.g.: “TAB”, “LSHIFT”, “A”), key IDs (e.g. “#20” same as “Y”) or positions relative to the top-left corner (e.g.: “2@1” same as “W”). The “get” command returns the current color of a key. The key colors are atomically uploaded to the keyboard with “update” command.

Building and Running the Server

 > cd luxeed/src
 > make install-prereqs
 > make
 > sudo ./luxeed --server & # start the server

Basic Commands

Make the number keys light up blue:

 > netcat localhost 12345
set 00 00 ff 1 2 3 4 5 6 7 8 9 0 
update
^D

Simple client that flashes keys:

 > sudo ./luxeed --server & # start the server
 > cat flash_keys 
#!/bin/bash

t=0.5
c="ff ff ff"
c2="00 00 00"
while [ $# -gt 0 ]
do
  case "$1"
  in
    -t)
      t="$2"; shift 2
    ;;
    -c)
      c="$2"; shift 2
    ;;
    -c2)
      c2="$2"; shift 2
    ;;
    *)
      break
    ;;
  esac
done
keys="$*"

while true
do
  netcat localhost 12345 <<END
set $c $keys
update 
wait $t
set $c2 $keys
update 
wait $t
END
done 
 > ./flash_keys ENTER # flash the ENTER key

Since the server can service multiple clients, we can flash multiple keys at different rates and colors using multiple clients:

  > ./flash_keys -t 0.2 -c 'ff 00 00' TAB &
  > ./flash_keys ENTER &

Maybe it’s time for a demo video.

Things left:

  • Pausing updates to the keyboard for a short time period after any keypress would allow animations but not let them interfere with the typist. The keyboard I/O channel is too slow to handle typing and animations (~10 frame/sec) at the same time.
  • A bulk update command that maps a PNM image representing the keyboard would be helpful.
  • udev rules to prevent the need for running the server as root.
  • Debian packaging.

There are some I/O throttling issues; sometimes the keyboard disconnects (or requires a power cycle) if data is sent to it too quickly. The only message I could decipher is a bulk keyboard update message of 5 65-byte blocks with an embedded checksum. Maybe there is a smaller differential update payload that will only update specific keys which would be more useful for faster animation. There may be a response message that needs to be read.

If you have this keyboard, give it a try!