Getting started!

What's the first thing that pops into your head after you initiated a wiimote extension. Bingo, calibration. Wii games will usually try to initiate any extension that is plugged into either the Motionplus or resp. Wiimote by doing a regular extension init() handshake. If there's an active Motionplus device it will be disabled by doing so and a register swap will automatically be issued. The game will try to request encryption and read from 0x20-0x3f, so far so good. Afterwards if the game has everything that was needed or resp. there was no extension at all in the wiimote/passthrough port, it will try to activate the WM+ by writing 0x55 to 0xA600F0 and then 0x04/5/7 to 0xA600Fe, this will issue a register swap if a WM+ was present. Subsequently the game will try to verify if the extension register at 0xA4xxxx was changed by reading the new WM+ extensions ID at 0xA400FA - sometimes games already read data up from 0xA400F0 or only 0xA400FE, depending on it's internal game state and previous inquiries to verify certain flags. If all that is done, the game will request data from 0x20-0x3f just like for regular extensions that are plugged into the Wiimote resp. WM+ passtrough port. We will receive 32 bytes of calibration data.

Calibration Data:
What do we know. We know the Motionplus(wm+) consists of two gyro sensors with a total of 3 sensed axis(14bit vars). Each axis will require a neutral var, and a var for min- and max-ranges. Do not forget, the gyros are able to work in fast motion and slow motion mode to increase accuracy on slow motions, which means we will need 6 vars in the end for each axis to properly calibrate it. This makes a total of 18 vars for all 3 axis, which equals 252 bits. However we receive 256 bits /32 bytes. This means either 4 bits weren't used at all (unlikely tho) within the calibration data resp. just consist of dummy data or represent some kind of checksum similar to nunchuck calibration data, which is most likely.


If you analyze the calibration data, it looks like it got splitted like this:

ata at 0x20 consists of either just fast motion or slow motion related data(I couldn't determine yet which line holds which) and 0x30 the remaining one plus probably 4 unused or checksum-ish bits. The first 6 bytes of each line, consist of neutral values(X,Y,Z) separated by 2 bits, which are probably part of max/min values of the Y/Z Axis. What follows is the calibration data for min and max ranges for each eaxis, however due it's compact packing, quite a lot bits got moved around towards byte 15. I can't say yet which is which. But the calibration data for min/max(X/Y-axis) values seems to be consistent. 0x30 is splitted very similar to 0x20, however the bitsshifting occurs already around byte~12. But again, min/max x and min.y look fine and consistent. I still need to figure out the exact splitting of max.Y and min/max.Z plus the exact location of the remaining 4 bits. For that purpose I will probably need more calibration data,i I you want to help me, drop me a line and post me your motion plus calibration data at 0x20-0x3f.


I hope that was helpful in any way, and be kind to link to this blog when you spread the word. It was quite some work.

Best regards
Sanchez

---------------------------------------------------------
http://invensense.com/mems/gaming.html
http://invensense.com/mems/gyro/documents/whitepapers/Selection-and-integration-of-MEMS-based-motion-processing-in-consumer-apps-070809-EE-Times.pdf
http://invensense.com/mems/gyro/documents/ps-isz-0650b-00-04.pdf
http://invensense.com/mems/gyro/documents/PS-IDG-0650B-00-04.pdf