Spyder Hack

I have been busy for the past couple of months so I haven’t been able to work on this project. However, Graeme Gill sent me some code today that properly communicates with the Spyder. Thanks Graeme! Attached is his code which he wrote for Argyll, released under GNU GPL v3. Most of the heavy work is done, and the next step is simply packaging it into a “libspyder”.

spyd2.zip

Some more progress on decoding the measurements packets. Klaus Karcher suggested that bytes 5-7, 56-58, 59-61, …, 77-79 (counting from 0), can be decoded as “nibble-swapped”. For example “9C 37 10″ decodes to 0x0173C9 or 95,177. He plotted these bytes and saw exponentially increasing curves. I was hoping that some of these curves would be the raw RGB measurements. Unfortunately, we know that the first three measurements are the red, green, and blue measurements independently, and therefore doesn’t fit the graph. Once we figure out the USB protocol, we can draw our own colored patches on the screen and get ground-truth measurements. That should help in figuring out the measurement packets.

It looks like the transfers are supposed to be interrupt transfers, as opposed to bulk transfers as I previously thought. Still, I am getting transfer errors on packets 1789. Below is the updated code. Instructions on how to compile and run on previous post.

spyder.c

Here is some code that attempts to access the device. The main thing I can not figure out right now are the bulk transfers, starting at packet 1788. I am probably calling the function incorrectly. If anyone can shed any light, that would be great.

setupbulkpackets.txt
spyder.c

Compile with gcc, linking with libusb
Run as root “./spyder setupbulkpackets.txt”

I have posted the measurement packets and complete session logs under “Pages” to the right.

I’ve started to hack a driver using libusb even though I don’t know what all of the fields mean. Unfortunately, I can only send a few control messages before a get a broken pipe error. It seems that I must be sending the wrong messages, even though I’ve copied them exactly from the logs. I’m also not clear why I have what seems to be duplicate messages in the log.  I think I need more log data to verify what I am doing.

My officemate Justin and I have been pouring over the 80 measurement bytes.  We found some structure in it, but haven’t decoded every byte yet.  It turns out that there are 23 measurements total — 3 for RGB and 17 for the gray levls.  My guess is that it goes from 0 to 240 in increments of 16, and then 255. There are 3 verification measurements which are called differently, which is why I did not pick it up the first time.  This is what I have so far.

Overall, the data is in big-endian format, unsigned short integers.  Every third byte is usually 00 or C4, which looks like delimiters, but are actually status bytes I think.  The 80 bytes are divided into four groups.  The first group goes from bytes 0-7.  The next three groups are from 8-31, 32-55, and 56-79.  Bytes 2-3 are inversely correlated with the intensity of the detected light (higher value means darker).  The next three groups are probably color measurements, but I haven’t figured them out yet.  Bjorn Helgaas (whom I found on the net) sent me some datasheets and suggested that the sensors are TAOS TSLx257 devices, which can sense RGB colors.  Bytes 7 and 8 seem highly correlated with each other, and similarly with 32-33 and 56-57.  They look like the initial bytes of the color measurements.

Looking through the USB traffic, it seems quite regular. On program startup, the calibration software takes a few seconds to exchange about 1800 packets with the device. Not sure what the packets mean exactly, but it looks like some sort of device verification and integrity check. There are two echo phases, where the computer echos data that the device sends, and then the device echos data that the computer sends.

When I start the measurements, there are very few packets exchanged. There are 26 packets exchanged per measurement and each measurement takes about 6 seconds to do. For each measurement, the computer sends a fixed sequence of bytes to the device, and the device spews back a total of 80 bytes. I am now trying to figure out what these bytes mean.

A total of 2413 packets are exchanged from when I plug in the device to completion of measurements. The program takes 20 measurements on a CRT monitor. It might be different for LCD’s. The first three measurements are for the red, green, and blue channels at full intensity. Then it goes from black to white, with probably 15 measurements. Finally, I think it does two verification measurements, where it says something about verifying the color temperature.

First, I need to snoop the USB port and log the traffic. I tried USBSniffer 1.8 and SnoopyPro 0.22 but they both failed to log the data. USBSniffer did not manage to intercept anything, and ColorVision’s calibration software couldn’t access the device while SnoopyPro was running. Running out of free tools, I found a beta version of USB Monitor and installed it. On the first run, it crashed and burned my system. I decided to try another computer and this time, I had better luck. I managed to log all of the USB traffic before it crashed the computer again. On to decoding the packets…

The goal of this project is to reverse engineer the USB protocol used to talk to ColorVision‘s Spyder colorimeter. ColorVision sells a device for ~$80 that is supposed to calibrate your monitor. It has worked well for me, but it does not work in Linux. Once the protocol is decoded, I plan to write a Linux device driver so I can use the colorimeter in Linux. As far as I know, there is no one else attempting this right now. I welcome all help from anyone who has expertise in Linux USB drivers or monitor calibration.