Hacking the Wii MotionPlus

So its been two days since I got my Nintendo Wii MotionPlus (henceforth simply ‘WM+’; yeah, I know I called it the ‘M+’ earlier :-|) clone from DealExtreme. And I’ve been itching to get some data off it.

The WM+ uses I2C to send and receive data from a host, which is normally a WiiMote, but in my case it is a PIC16F877.

The hacked WM+. I desoldered the pass-through port (normally used to connect a Wii Nunchuck) and used it as a mating female connecter for the WM+’s male connector.

On the net, I couldn’t find a single site that used a PIC as the host. And most sites had code specific to the microcontroller used by the site’s creator (which was more often than not an Arduino). So after cracking my nut trying to figure out what in the heck these Arduino chaps were doing, I decided to post pseudo-code so that others working with the WM+ can easily write code for their micros.

*        *        *

Pseudo-code:

//initialize the WM+
i2c_start
i2c_write(0xA6)
i2c_write(0xFE)
i2c_write(0x04)
i2c_stop
  
//read data
while(true)
{
    i2c_start
    i2c_write(0xA4)
    i2c_write(0x00)
    i2c_stop
   
    i2c_start
    i2c_write(0xA5)
    yaw_lo_byte = i2c_read(ack)
    roll_lo_byte = i2c_read(ack)
    pitch_lo_byte = i2c_read(ack)
    yaw_hi_byte = i2c_read(ack)
    roll_hi_byte = i2c_read(ack)
    pitch_hi_byte = i2c_read(nack)
    i2c_stop
   
    //this is necessary since the last two bits
    //in the high bytes are useless
    roll_hi_byte = roll_hi_byte >> 2
    pitch_hi_byte = pitch_hi_byte >> 2
    yaw_hi_byte = yaw_hi_byte >> 2
   
    //send to computer for displaying
    putc
    printf
}

A few words about the pseudo-code. You’ll find that the hex value that you write in line 3 is 0xA6. Some websites say the WM+ ‘starts off at address 0x53’. This is confusing since 0xA6 is not equal to 0x53. To figure this out you need to know a little about the I2C protocol.

*        *        *

A little about I2C:

Quite often, I2C devices use 7-bit addressing, and a 1-bit read/write indicator. 7+1=8 bits=1 byte. All I2C communications start with the host sending a ‘start condition’, followed by the 7-bit address, followed by a 1 or a 0, telling the device that data is either to be written to, or read from that address. This may be followed by additional reads or writes. Between reads and writes, an ‘acknowledge (1)’ or ‘not acknowledge (0)’ is sent. Communication is terminated with a ‘stop condition’.

*        *        *

Anyway, so how is 0x53 equal to 0xA6? Simple. 0x53 is the address that we want to write to. So the first seven bits are 0x53, and since we are writing the next byte, we send a 1. In C this is written as:

(0x53<<1)+0

Which, in plain English reads as: “Shift 0x53 to the left by one bit; set the least significant bit to 0”.

Now we see that (0x53<<1)+0 = 0xA6. Do it yourself if you’re not convinced!

So once the WM+ is initialized, one can start reading gyro data. Some sites recommend that you wait 38ms before reading data, since the WM+ needs to initialize fully, but I haven’t done that and yet my WM+ gives me ‘nice’ data.

Close-up of the pass-through port female connector. Only four wires are needed. Red – Vcc; Black – Ground; Blue – SCL; Yellow – SDA. The pins that go into the bread board are scavenged from a broken DB25 male plug.

Gyro data is stored in six consecutive address. In my while loop, I set the address from which to start reading data from – this is 0x52 (which becomes 0xA4, since we’re writing). I write 0x00 to the register to indicate I ‘want’ data. Then I read data into the ‘hi’ and ‘lo’ bytes of the roll, pitch and yaw variables. Data reads are ‘ack-ed’, ie, acknowledged. The last byte is ‘nack-ed’. This is NOT to say that it is not acknowledged, rather the word ‘not’ in ‘not acknowledge’ actually refers to Boolean inversion. Since an ack is binary 1, a nack becomes binary 0.

In my actual code, I have a for loop inside the while loop. The for loop runs 32 times to average out the roll, pitch and yaw readings. After averaging, the data is sent out using a string of putc statements. Alternatively, printf may be used to print to a terminal program – the choice is yours. Infact, I threw together a simple LabVIEW program to display the roll, pitch and yaw on a dial. You can see that I am simultaneously also graphing the results.

The LabVIEW frontend. Roll, Pitch and Yaw are depicted.

My setup is pretty simple – just a PIC16F877 with the TinyBootloader on it, running at 20MHz; a MAX232 for serial comms; the PICKit2 provides 5v power to the PIC and the MAXIM chip; a TI LP2950 regulates the 5v to a safe 3.3v for the WM+. A cheap USB-to-Serial dongle is used to receive data @ 115.2Kbaud.

  The current setup - WM+ connected to a PIC16F877. Power provided by the PICKit2. Serial data sent to LabVIEW through a MAX232 and USB-Serial dongle.

I still need to calibrate the WiiMote, and see how accurate the data is. In the next few days I’ll be making my data acquisition board wireless (by including the RF code from an earlier project, and using a Li-ion battery). I’ll be going around the place, sticking the board to swivel chairs, on the wheel of a cycle, on a treadmill, to a fan blade, and whatever else I can think of :-P.

Updates, more pics and videos will be up in a while.

 

Credits:

• WM+ using I2C on the Parallel Port (for those who have one on their systems). This was the most useful link, since code was in C, and therefore, the most understandable to me http://mtn.coolfactor.org/viewmtn.py/revision/file/9215fdc14d2c75cd9715068556c21b12f1266393/i2c.c
• Arduino-WM+ http://randomhacksofboredom.blogspot.com/2009/06/wii-motion-plus-arduino-love.html
• WM+ driver http://123a321.wordpress.com/2009/08/21/read-motion-plus-via-i2c/
• Wiibrew’s documentation http://wiibrew.org/wiki/Wiimote/Extension_Controllers#Wii_Motion_Plus
• Kalman filtering for the Nunchuck-WM+ combination http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1248889032/0