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

I Love the Mailman

I think certain clarifications are in order - I am completely heterosexual; its just that today, one of the mailmen brought me a few parcels, which I have been eagerly waiting for. One of those parcels was a Sensiron SDP610 sample, which is a CMOS differential pressure sensor; the other parcel is the subject of this blog.

 
Left: The Sensirion SDP610 differential pressure sensor
Right: A Nintendo Wii MotionPlus clone

I’m building a quadrotor, and after doing a bit of searching online, found that IMUs cost a bomb. Not wanting to spend $$$ on commercial units I decided to go the DIY way. I got onto DealExtreme and purchased a Wii MotionPlus clone (hereafter simply ‘M+’). The original M+ was made by Nintendo (of the Super Mario/Contra/Space Invaders fame), as an accessory for its Wii gaming console.

The Wii revolutionized the way the world played video games. Nintendo introduced a motion controlled gaming device that took the world by storm. However soon, gamers wanted more, and when they found that the WiiMote controller gave inaccurate results when moved vigourously, they decide to add a piggy-back module to the controller.

The M+ is a 3 axis gyroscope to complement the 3 axis accelerometer already in the WiiMote. Simple maths says 3+3=6; the M+ coupled with the WiiMote gives a complete 6DOF motion controller, using which you can 'swing’ a simulated golf club, or ‘throw’ punches at the world’s deadliest boxer, maybe even ‘play’ a game of pool.

So I spent USD12~INR550, and DX shipped me the M+ along with a complimentary rubber sleeve to protect my (inexistent) WiiMote. Shipping was free, and was done via registered mail. The package took 23 days to ship from HK to Gurgaon, India.

Packaging was good – the M+ came plastic wrapped in a product box. The outer packaging was a bubble mailer. No damage other than a few wrinkles on the box’s surface.

Good packaging by DX 

Also included in the product box were ‘documentation’ and leaflets – they’ll go straight to the raddi pile to be sold as scrap paper since I can’t read Chinese. Thoughtful of the manufacturers, but useless to me :-|

Decent build quality

The M+ itself looks solid, and build quality is good – no loose bits or clamps (not that it really matters since I’m gonna tear it apart anyway). The M+ presented me with a small problem – it was held together by tri-wing screws. Not one to be outsmarted by two screws, I took a small flathead screwdriver and gently got the screws out.

 
The tri-wing and the flathead that got it out.

The pieces

Here are the innards of the M+:

 
The upper side of the PCB. Visible on the top left corner is the IXZ650 gyro. The black epoxy in the centre covers the microcontroller, in a CoB construction style. The connector is to the left, while the expansion port is to the flat cable on the right.

The bottom side of the PCB. In the centre is the IDG650. On the top right is what seems like an EEPROM chip.

It seems funny why the clone would have two 2-axis gyros when just a 2-axis and a 1-axis would suffice. I guess I’ll have to get my hands dirty to see if there’s any difference in its functioning.

Updates in a bit.

No Strings (or Wires), Attached

It’s been a while since I’ve blogged. Its not like I haven’t been trying – my drafts pane in Windows Live Writer is full of half-finished posts. Maybe I’ll complete them and post them before the summer ends. Or maybe not.

This post is about using those cheap 300-bucks-a-pair modules. For international readers, INR300~USD6. If you look around where you live you’ll find the same or similar modules which do the same thing. Sparkfun carries these variants:
http://www.sparkfun.com/commerce/product_info.php?products_id=8946
http://www.sparkfun.com/commerce/product_info.php?products_id=8947

SeeedStudio stocks these:
http://www.seeedstudio.com/depot/433mhz-rf-link-kit-p-127.html?cPath=101_103

The difference between Sparkfun’s and Seeed’s is that the former has a receiver that is PLL synthesized, and the latter uses a relatively cheaper, albeit less reliable LC circuit. I have both types of modules, bought locally. Both types use a SAW resonator for transmission.

These dirt cheap RF modules work at 433MHz (you’ll also find the 315MHz variety), which puts them squarely in the ISM transmission band. They use ASK modulation to send data across. You can mix and match PLL/LC transmitters and receivers without a problem, just so long as they’re all on the same frequency (duh!).

A lot of people use these modules for low cost wireless control mainly because they’re a breeze to interface. The easiest way to work with the modules is to buy the HT12-E and HT12-D encoder-decoder pair. These chips are essentially parallel-to-serial shifters and output a user set 8-bit ‘address’ along with 4-bits of useful data.

But what if you want to send more that just 4 bits? Suppose you want to send an arbitrary text string? Or maybe the 8-bit brightness value of a wireless night lamp? In such situations these chips are useless. You could buy the HT640-HT648 encoder-decoder pair, but again, that would limit you to 8-bits of data at a time.

The best option (IMHO) is to use microcontrollers as the encoder and decoder. Using a micro will, in a manner of speaking, allow you to kill several birds with one stone. You can use the same micro to decode the received data, as well as perform control functions at the RX end.

So how do you go about using a micro? I’ll start at the beginning:

The reason why these modules are cheap is because they are very simple. They are, at most, just a crude pipe through which RF data passes. There is absolutely no form of error correction, no data protocol whatsoever, and certainly no guarantee of data transmission.

One of the biggest problems these modules suffer from is that of DC-drift. Think of digital data being passed through a series capacitor. Let us say that you try to send several 1s, the capacitor will soon charge up until it is saturated. Once it gets saturated you can’t transmit data any longer, since there is no charge mobility. Similarly if you send a long string of 0s the capacitor will get discharged, and again, you won’t be able to transmit data. The trick is to send a balanced number of 1s and 0s. Over a short period of time, if the number of 1s is equal to the number of 0s transmitted, then the ‘DC level’ of the RF module remains balanced.

Clever, you say. But how do I put this into practice? You could use the Manchester encoding scheme to transmit data. Put very simply, in Manchester encoding, each bit is encoded as two bits. A 1 is encoded as binary 01, and a 0 is encoded as a binary 10. Thus, regardless of what data is sent, the transmission is DC-balanced.

A very obvious disadvantage is that the data rate is immediately halved (or one can say that the bandwidth doubles). There are more complex coding schemes which are more bandwidth efficient such as 8B/10B encoding, but I’ve stuck with Manchester encoding, since it’s much easier to do.

Now I didn’t really do any Manchester coding or decoding – I used a bit of a cheat. Most micros have a UART as well, so I included that too in my ‘hack’ – using built-in hardware to do dirty work greatly reduces my effort :-) Since I’m using the UART, I can only send 8-bit chunks of data. The data transmitted must satisfy these conditions:

• Data is to be balanced, so each byte should have four 1s and four 0s.
• There should be no more than two consecutive 1s or 0s. This is a constraint which ensures that data is Manchester-like.

Of the 256 possible numbers, there are 26 8-bit binary strings that fulfil the above criteria. I’ve arranged the numbers in Gray-code-like order.

00110011   0x33 00110110   0x36 00110101   0x35 00101011   0x2B 00101101   0x2D 01100110   0x66 01100101   0x65 01101010   0x6A 01101001   0x69

01010011   0x53 01010110   0x56 01010101   0x55 01011010   0x5A 01011001   0x59 01001011   0x4B 01001101   0x4D 10100110   0xA6 10100101   0xA5

10101010   0xAA 10101001   0xA9 10110010   0xB2 10010011   0x93 10010110   0x96 10010101   0x95 10011010   0x9A 10011001   0x99

 

Each yellow number corresponds to a particular hexadecimal number from 0x0 to 0xF. Thus there are 16 ‘yellow numbers’. Each byte that I want to transmit can be broken into two nibbles. Each nibble is encoded using one of the numbers highlighted in yellow. So, for each nibble, I transmit a DC-balanced byte. At the receiving end the nibbles are collected and ‘re-formed’ into bytes. Clearly, the transmission rate is half of the data rate.

When using this scheme a few other things need to be kept in mind. The transmitter will only be turned on when transmitting data. However, the receiver is always on. And that’s a problem. The receiver will happily ‘lock-on’ to the strongest RF signal it can find. It doesn’t care if that signal is meaningless data – it will demodulate whatever it finds. So as it sits there, the receiver is demodulating junk. Suppose we now start sending data, how does the receiver UART know that this infact, is actual data, and not junk?

The way to solve this is to first send a ‘look-at-me’ sequence. The LAM sequence is just a series of balanced numbers sent by the transmitter to ‘wake’ it up. By doing this, the transmitter establishes itself as the strongest signal source. The LAM also serves as a kind or reference for the receiver’s UART to ‘lock’-onto. After much trial and error, and forum searching, I found that the LAM sequence of 0xBA 0xBE 0xFA 0xCE (or hex BABE FACE) works wonderfully, though it is NOT balanced!

After the LAM, a ‘start’ code is sent (I use the numbers in green, but any sequence may be used). Only once the ‘start’ is received does the receiver accept further data.

The data is followed by a simple checksum. The checksum is the 8-bit sum of all the data. If the checksum calculated at the receiver is not the same as the checksum transmitted, then it implies that some data has been lost in transmission.

Transmission ends when the number 0x99 (red) is received.

I am still working on error checking using data prediction. I’m also working on making this code adaptable to use in a multi-transmitter setup using arbitration.

The code in its current form is very robust and works very well. My setup has two transmitters and one receiver. One transmitter causes a red LED to blink on the receiver side; the other make a white one blink. Understandably, there are times when the transmitters interfere, but this doesn’t cause spurious results.

As testament to the robustness of the protocol (and maybe even the transmitter modules!) here is some data: though the datasheet specifies using a λ/4 monopole antenna (approx 17cm of wire @433MHz or 23cm of wire @315MHz), both transmitters and receivers are happily TX-ing and RX-ing without any external antennae. I suppose I could increase range and reliability by sticking on a wire, but I’m getting a 10m range with a 1.5v battery!

If you want the code ask in the comments. I’ll be posting pics of my setup soon.