im-me hacking

I came across this blog describing hacking the im-me, a small wireless console. It looked interesting, so I went ahead and bought a couple.  For £8 you get a console and a USB radio dongle. It turns out that they are a bargain for what they contain, provided you can discover how to "re-purpose" the hardware.

I became much more interested when I discovered Travis Goodspeed's blog describing how to implement the debug port on a related processor.

The console

The console is really simple but powerful, containing:

• A CC1110F32 radio/processor: 32k flash, 4k ram, 900MHz transceiver, with a debug port exposed.
• An 8x24 LCD display, with backlight. The LCD has an SPI interface.
• A full qwerty keyboard.
• A piezoelectric sounder.
• A voltage regulator, and a small number of sundry SMD parts - transistors, Rs, and Cs.

The Wireless USB Dongle

The dongle contains:

• A CC1110 radio/processor identical to that in the console.
• A CY7C63803 processor with USB interface.

The FCC ID is Grantee code: PIY, product code: L7281D1

The Console Debug Port

The debug port on the CC1110 is conveniently wired out to some test pads that are accessible via holes in the bottom of the battery tray. Connections are (from left to right):

• (square pad) RESET_N
• P2_1 = debug data
• P2_2 = debug clock
• +2.5 volts
• Gnd

Here's a photo showing the wires I've soldered to the test pads that connect to the Arduino via a breadboard.  (I don't use the 2.5v connection as I supply power via the battery compartment, and rely on the on-board regulator to generate 2.5v.)

I wanted to drive this port via an Arduino, but couldn't drive it directly since the CC1110 runs off 2.5v as compared to the Arduino's +5volts.  The CC1110 is also intolerant of voltages more than 0.3v above VDD.  The solution was simple - the outputs from the Arduino are fed into voltage dividers (The DATA pin on the CC1110 is both an input and output so I decided to use relatively high value 3.3K resistors to present minimal load when it is an output).  To read the data line back into the Arduino, I wired the debug data pin to the Arduino's positive comparator input too, and set the comparator's negative input to about 1.7 volts.

(A word of warning - keep the lead lengths short - I had variable results when I initially just used test leads to connect everything.)

I wrote some Arduino interfacing code, using Travis's blog, the official documentation for the debug port, and CCFlasher (another implementation) for inspiration.  By executing the "READ_STATUS" command it became evident that the "DEBUG_LOCKED" bit is set.  This bit prevents the firmware from being read out, so it's not surprising that it is set.  However, a "CHIP_ERASE" can be executed, which erases the entire flash memory, and enables the full debug port capability, which is what I've done on one of my consoles.  I'm now able to download data to the chip and to execute programs in RAM or in flash.  The full hardware capabilities of the console are now at my disposal.

The Arduino code is still very much work in progress, but provides some basic facilities to allow me to experiment via the Serial Monitor interface of the Arduino IDE.  I'm now working on some facilities to allow me to download and flash programs more easily.  More later...

Console CC1110 Processor Development

Software development for the processor can be carried via this tool: http://supp.iar.com/Download/SW/?item=EW8051-KS4 This "kickstart" free version of the commercial tool can have its code size limits increased if you follow the guidelines in Section 9.1 of http://focus.ti.com/lit/ug/swru236a/swru236a.pdf.


The IDE can be configured to generate it's output in the simple Intel format, which is ideal for me to download to the processor with via the Arduino.


Console Keyboard


The 40 odd keyboard buttons are wired as a matrix, but the designers use some tricks to minimise the number of i/o pins.  The i/o pins used are:

• "row" pins: P0_1, P1_2, P1_3, P1_4, P1_5, P1_6, P1_7 - input and output.  Normally high, regular very short pulses to 0v.
• P0_6, P0_7 - input only.

The key connections are shown in the table below.

One keyboard sensing algorithm would be:

• Set all keyboard i/o pins to inputs, with pullups to Vcc.  Read all inputs, and if any pin is zero, it is because one of the keys connected to Gnd is pressed.  For instance, if P1_2 is zero, it means the "O" key is pressed.
• Set P0_1 as an output, and 0v.  Read all inputs (except P0_1 of course), and if any any pin is zero, it is because one of the keys on the "P0_1" row is pressed.  For instance, if P0_6 is zero, it means the "Menu" key is pressed.  Return the P0_1 to an input.
• In a similar manner, take each of P1_2, P1_3, P1_4, P1_6, P1_7 low in turn, checking each time for a key press.
• Add bebounce logic - e.g. repeatedly go through the steps above, and only report a key-press if the same key is pressed on 2 consecutive loops. 

Console Radio

Some information about the radio can be gathered from the FFC submission.  FCC submission details are found by searching for PIY/L7281H1 on the FCC site. There are internal photos, radio frequency details, and transmission spectra.

The standard unit transmits/receives on up to 16 different frequencies between 908.45MHz and 920.6MHz.

I've been using my trusty Tektronix 7L14 Spectrum Analyser to see how the units currently communicate.  On startup the console polls on all 16 channels to make contact with the wireless USB dongle.

Once communication has been established on one of the channels, the console and dongle continue to use just that channel thereafter.  The console polls the dongle about every 0.2 seconds.  Here's a typical sequence:

The console polls the dongle, and the dongle responds about 10 milliseconds later (the dongle is physically further away from the SA input and sothe signal is weaker).  The dongle then sends a message (a poll?) about 3 milliseconds later.  Finally the console replies to the poll after about 10 milliseconds.  This sequence repeats every 0.2 seconds, but the total transmission time for the console is 4 milliseconds, so the portion of time spent transmitting (and therefore consuming battery power) is just 2%.

If each poll/ack message is about minimal length, it corresponds to around 96 bits by the time you take into account the preamble, sync, length, address, data, and CRC.  96 bits transmitted in 2 ms is 50kbps.  So the minimum radio tx/rx data rate is 50 kbps, but could easily be higher.

The photo above also gives us a clue to the type of modulation being used.  The fact that the signal strength remains the same during the transmission period indicates that the amplitude modulation options supported by the CC1110 - On-Off Keying (OOK) and Amplitude Shift Keying (ASK) - aren't being used.

A plot of the transmission spectrum shows that transmission is on two frequencies 300kHz apart:

Zooming x10 into the twin peaks reveals this spectrum:

The smaller peaks at 50kHz intervals between the two main peaks are likely the result of the data rate setting, and gives further evidence that the data rate is 50kbps.  The very narrow peaks also hint that there is no modulation smoothing, which rules out the chip's Minimum Shift Keying (MSK) and the Gaussian filtering option available with  Frequency Shirt Keying (FSK).  This leaves just the 2-FSK modulation option, with the deviation set at +/- 150kHz.

LCD Interface

The LCD is connected via a 20 way ribbon cable.  The connector is on the left ofn the photo below:

The connections (from the top of the connector to the bottom) are, using ST7565S terminology:

• P0_4 - /CS -- hold low while transferring data (SSN in SPI terminology).
• P1_1 - /RESET (I think) -- Pulse low at power up, keep high all the time otherwise
• P0_2 - A0 -- Low for a command byte, high for a data byte
• P0_5 - SCL -- SPI clock (SCK in SPI terminology)
• P0_3 - SI -- Serial Data (MOSI in SPI terminology)
• +2.5v
• Gnd
• (the remaining 13 pins are connected via capacitors either together or to ground, and are part of a high voltage generator circuit in the LCD)

All the data connections are easily accessible via the test points between the connector and the processor.

Other Processor Connections

The only remaining i/o port connections on the processor are:

• P0_0 - decoupled voltage divider input (to measure 2.5v to detect battery low condition?)
• P1_0 - digital output to transducer
• P2_0 - digital input/output to backlight circuit?
• P2_3 - digital output to status LED (red?)
• P2_4 - digital output to status LED (green?)