git.rot13.org Git - imme-dongle/blob - README

   1 This is alternative firmware for the Girl Tech IM-Me USB dongle.
   2 (http://www.girltech.com/electronics-imMe.aspx) that implements a basic command shell for control of the CC1110.
   3
   4 It is a work-in-progress. A fairly generic messaging framework is provided, but not much actual functionality, yet.
   5
   6 Directories
   7 ===========
   8
   9 /linux
  10     PC side application for sending messages to the dongle. Loosely based on im-megpldrivers (http://sourceforge.net/projects/im-megpldrivers/)
  11
  12 /cc1110
  13     Dongle firmware
  14
  15 Status
  16 ======
  17
  18 "It works for me".
  19 All of my testing has been with Debian running under VMWare on OSX - this may be the cause of some of the USB issues.
  20 My understanding of the protocol between the Cypress and Chipcon chips comes from what I've gleaned using an Open Logic Sniffer.
  21 There are probably bugs, please help to fix them.
  22
  23 Building and using
  24 ==================
  25
  26 Type make.
  27
  28 You'll need a GoodFET/SmartRF or some other Chipcon flasher to load dongle.hex into your USB dongle.
  29 (See this picture for where to make the connections: http://www.flickr.com/photos/travisgoodspeed/4323094248/)
  30
  31 Connect the dongle and run ./imme-shell (as root)
  32
  33 Type "led 1"
  34 Type "led 0"
  35
  36 The dongle LED should respond.
  37
  38 Type "getreg 0xDF36" to read the PARTNUM register. Being a CC1110, it will respond with 0x01.
  39
  40 Load the spectrum analyser firmware onto your IM-me console.
  41 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
  42
  43 Type "exit" to quit.
  44
  45 Protocols
  46 =========
  47
  48 CY7C63803 <--> CC1110
  49 ---------------------
  50
  51 The link between the Cypress and Chipcon devices is SPI-like.
  52  * The clock is driven by the CC1110 at 100kHz
  53  * MISO and MOSI behave as you'd expect
  54  * 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
  55  * On sending 0xFA in the first header byte, the receiver responds with > 0 if it has data which needs to be polled for
  56  * It seems to be important to wait for ~500ms between transmit and receive, else the Cypress device crashes
  57
  58 More pinouts and timing information here:
  59 http://www.flickr.com/photos/54388270@N04/sets/72157625159026076/
  60
  61
  62 PC <--> CC1110
  63 --------------
  64
  65 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.
  66
  67 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.
  68
  69
  70 Author
  71 ======
  72
  73 Joby Taffey <jrt@hodgepig.org>
  74 http://blog.hodgepig.org/
  75 http://twitter.com/jobytaffey
  76
  77