From: broehl@coulomb.uwaterloo.ca (Bernie Roehl) Subject: CyberMaxx data format I've spoken with Max and Harold at VictorMaxx, and they're eager to see their protocol widely publicized. I've written a short, condensed version of their tracker interface spec, which I'm including below. I've also proposed an extension to the spec; I'd be interested in hearing what people on the homebrew list think of it. Obviously, the folks at VictorMaxx aren't bound by anything we come up with, but they certainly seem open to new ideas. Here goes... ========================================================================= The CyberMaxx tracker interface, and a proposed extension The CyberMaxx runs at 9600, 8 bit, no parity, 1 stop. To reset the unit, send it an ascii 'R'; it should respond with a copyright string. By default the tracker sends data in ascii, so send it an 'F' to go into binary mode. By default it sends data continuously; if you want to poll it, send it a 'G', then send an 'S' whenever you want to request a packet. In binary, the packets consist of 8 bytes. The first two are 0xFF (to mark the start of the packet). These are followed by 3 16-bit words (sent high-byte first) giving the yaw, pitch and roll. The top bit of each 16-bit word is zero, so they're really 15-bit words; the fact that the top bit is zero means that you don't have to worry about two consecutive 0xFF's occurring in the data and looking like the start of a new packet. The yaw is 0-360 degrees (i.e. 0 is zero, and 0x7FFF is 359.959 degrees). The pitch and roll are from -45 degrees to +45 degrees (i.e. 0 is -45, and 0x7FFF is +45). That's it. Pretty simple. To summarize, the packet is: 1111 1111 1111 1111 (16 bits of 1's) 0yyy yyyy yyyy yyyy (15-bit yaw) 0ppp pppp pppp pppp (15-bit pitch) 0rrr rrrr rrrr rrrr (15-bit roll) Software-wise, you send an 'R' followed by an 'F' to initialize the tracker and put it into binary mode. Your serial interrupt routine should check for two consecutive 0xFF's; when it sees them, it should reset its buffer pointer to zero. After the number of bytes in the buffer hits 6, just pick up the yaw/pitch/roll and convert. *Really* simple stuff. Here's what I propose to do to extend the packet format: Add additional 16-bit words (with the top bit clear, for backwards compatability). In other words, after the "roll" value, just add more data; old parsers will ignore everything up to the next double 0xFF, and new parsers can use the additional data. New parsers should probably check the copyright message, to see if they've got an old-format device (like the current CyberMaxx), in which case they read only the yaw/pitch/roll. The first additional word (after the roll value) would be: 0knn nnnn cccc cccc where the 6-bit 'n' value is the number of 16-bit values that follow, and the 8-bit 'c' value is a channel id (in case the serial devices are daisy-chained). The data for the additional channels would follow, 15 bits for each channel. The first three should be reserved for position information, the rest will be device-specific (e.g. finger flexion). If the 'k' bit is set, the software should expect a 16-bit (really 15-bit) checksum to follow the data; the checksum would be the unsigned sum of all the data values (not including the 0xFF's). -- Bernie Roehl University of Waterloo Dept of Electrical and Computer Engineering Mail: broehl@sunee.uwaterloo.ca Voice: (519) 888-4567 x 2607 [work]