This is alternative firmware for the Girl Tech IM-Me USB dongle. (http://www.girltech.com/electronics-imMe.aspx) that implements a basic command shell for control of the CC1110. It is a work-in-progress. A fairly generic messaging framework is provided, but not much actual functionality, yet. Directories =========== /linux PC side application for sending messages to the dongle. Loosely based on im-megpldrivers (http://sourceforge.net/projects/im-megpldrivers/) /cc1110 Dongle firmware Status ====== "It works for me". All of my testing has been with Debian running under VMWare on OSX - this may be the cause of some of the USB issues. My understanding of the protocol between the Cypress and Chipcon chips comes from what I've gleaned using an Open Logic Sniffer. There are probably bugs, please help to fix them. Building and using ================== Type make. You'll need a GoodFET/SmartRF or some other Chipcon flasher to load dongle.hex into your USB dongle. (See this picture for where to make the connections: http://www.flickr.com/photos/travisgoodspeed/4323094248/) Connect the dongle and run ./imme-shell (as root) Type "led 1" Type "led 0" The dongle LED should respond. Type "getreg 0xDF36" to read the PARTNUM register. Being a CC1110, it will respond with 0x01. Load the spectrum analyser firmware onto your IM-me console. Type "setchan n" into ./imme-shell where 0 <= n <= 255, see the dongle transmit a modulated carrier wave with a base frequency of 868MHz using the given channel offset Type "exit" to quit. Protocols ========= CY7C63803 <--> CC1110 --------------------- The link between the Cypress and Chipcon devices is SPI-like. * The clock is driven by the CC1110 at 100kHz * MISO and MOSI behave as you'd expect * There are two "ready to receive" lines, which go high to request data. Once a valid 3 byte header (0xFA, 0xFB, len) is received, the requester drives the line low * On sending 0xFA in the first header byte, the receiver responds with > 0 if it has data which needs to be polled for * It seems to be important to wait for ~500ms between transmit and receive, else the Cypress device crashes More pinouts and timing information here: http://www.flickr.com/photos/54388270@N04/sets/72157625159026076/ PC <--> CC1110 -------------- Each message starts with a command byte, eg. CMD_LED or CMD_SETCHAN, this is followed by a command specific number of bytes containing the args. When no message is queued to be sent, each end of the link sends CMD_NULL packets repeatedly. The top bit of the command byte is the ACK request flag. If set, the receiver should respond with a CMD_ACK packet. No sequence numbers are used, so only one message can be "in flight" at a time. Author ====== Joby Taffey http://blog.hodgepig.org/ http://twitter.com/jobytaffey