Wiimote

From WiiLi

(Redirected from WiiMote)

Wii Remote

This page needs an infobox listing the subpages for this article, if you know how to make one, please do so.

This page is intended to be a technical guide to the Wii Remote. For an excellent high-level overview of the Wii Remote (aka Wiimote), see the Wikipedia article. New information and status updates should be posted to the talk page, and will eventually be digested and summarized here. For more info about the physical hardware be sure to check out the hardware page.

[edit] Communication

The Wiimote communicates with the Wii via a Bluetooth wireless link. The Bluetooth controller is a Broadcom 2042 chip, which is designed to be used with devices which follow the Bluetooth Human Interface Device (HID) standard, such as keyboards and mice. The Bluetooth HID is directly based upon the USB HID standard, and much of the same documentation applies.

When queried with the Bluetooth Service Discovery Protocol (SDP), the Wiimote reports back a great deal of information, listed at Wii_bluetooth_specs#sdp info. In particular it reports:

Name	Nintendo RVL-CNT-01
Vendor ID	0x057e
Product ID	0x0306

The Wiimote sends reports to the host with a maximum frequency of 100 reports per second.

The Wiimote does not require any of the authentication or encryption features of the Bluetooth standard. In order to interface with it, one must first put the controller into discoverable mode by either pressing the 1 and 2 buttons at the same time, or by pressing the red sync button under the battery cover. Once in this mode, the Wiimote can be queried by the Bluetooth HID driver on the host. If the HID driver on the host does not connect to the Wiimote within 20 seconds, the Wiimote will turn itself off. Holding down the 1 and 2 buttons continuously will force the Wiimote to stay in discoverable mode without turning off. This does not work with the sync button, however. When in discoverable mode, the Player LEDs will blink. The number that blink will correspond to the remaining battery life, similar to the meter on the Wii home menu where # of bars = # of lights.

[edit] HID Interface

The HID standard allows devices to be self-describing, using a HID descriptor block. This block includes an enumeration of reports that the device understands. A report can be thought of similar to a network port assigned to a particular service. Reports are unidirectional however, and the HID descriptor lists for each port the direction (Input or Output) and the payload size for each port. Like all Bluetooth HID devices, the Wiimote reports its HID descriptor block when queried using the SDP protocol. A human-readable version of the block is shown at Wii_bluetooth_specs#HID_Descriptor, and is summarized in the following table:

Output

Report ID	Payload Size	Known Functions
0x11	1	Player LEDs, Rumble
0x12	2	Report type / ID
0x13	1	IR Sensor Enable
0x14	1	Enable speaker
0x15	1	Controller status
0x16	21	Write data
0x17	6	Read data
0x18	21	Speaker data
0x19	1	Mute speaker
0x1a	1	IR Sensor Enable 2

Input

Report ID	Payload Size	Known Functions
0x20	6	Expansion Port
0x21	21	Read data
0x22	4	Write data
0x30	2	Buttons only
0x31	5	Buttons \| Motion Sensing Report
0x32	16	Buttons \| Expansion Port \| IR??
0x33	17	Buttons \| Motion Sensing Report
0x34	21	Buttons \| Expansion Port \| IR??
0x35	21	Buttons \| Motion Sensing Report \| Expansion Port
0x36	21	Buttons \| Expansion Port \| IR??
0x37	21	Buttons \| Motion Sensing Report \| Expansion Port
0x38	21	Buttons \| Motion Sensing Report \| IR
0x3d	21	Buttons \| Expansion Port \| IR??
0x3e	21	Buttons \| Motion Sensing Report \| IR??
0x3f	21	Buttons \| Motion Sensing Report \| IR??

Note that "Output" refers to packets that are sent from the host to the Wiimote, and "Input" refers to packets that are sent from the Wiimote to the host. For clarity, the convention in this document is to show packets including the Bluetooth header (in parentheses), report ID (also called channel ID in some places), and payload, as described in sections 7.3 and 7.4 of the Bluetooth HID specification. Each byte is written out in hexadecimal, without the 0x prefix, separated by spaces. For example

 (a1) 30 00 00

is a DATA input packet (0xa1), on channel 0x30, with the two byte payload 0x00, 0x00.

It actually seems that Force Feedback is accessible through ALL output channels the same way.

Note: On some wii-motes, IR wont start transmitting until a read-report 0x38 has been sent.

[edit] Inputs

[edit] Buttons

There are 12 buttons on the Wiimote. Four of them are arranged into a directional pad, and the rest are spread over the controller.

By default, whenever a button is pressed or released, a packet is sent to the host via HID input report 30H, with a payload containing a 2-byte bitmask with the current state of all the buttons.

The button state also seems to be included in the first two bytes of all other input reports.

Some of the bits in the first two bytes don't seem to be directly related to button presses, and are somewhat unknown.

For example, when the A button is pressed, this HID DATA input packet is received:

 (a1) 30 00 08

and when it is released, this is packet received:

 (a1) 30 00 00

The bit assignments (in big endian order) for the buttons are:

Button	Number (dec)	Value (hex)
Two	1	0x0001
One	2	0x0002
B	3	0x0004
A	4	0x0008
Minus	5	0x0010
?? Unknown (motion reports) ??; or Z Acceleration, bit 6 (report 3E) or bit 2 (report 3F)	6	0x0020
X Acceleration LSB (motion reports); or Z Acceleration, bit 7 (report 3E) or bit 3 (report 3F)	7	0x0040
Home	8	0x0080
Left	9	0x0100
Right	10	0x0200
Down	11	0x0400
Up	12	0x0800
Plus	13	0x1000
Y Acceleration LSB (motion reports); or Z Acceleration, bit 4 (report 3E) or bit 0 (report 3F)	14	0x2000
Z Acceleration LSB (motion reports); or Z Acceleration, bit 5 (report 3E) or bit 1 (report 3F)	15	0x4000
? Unknown ?	16	0x8000

The power button is unusual in that it sends a disconnect request when held down instead of emitting a normal button code.

[edit] Motion Sensor

Coordinate system used by Wiimote

The motion of the remote is sensed by a 3-axis linear accelerometer located slightly left of the large A button. The integrated circuit is the ADXL330 (data sheet), manufactured by Analog Devices. This device is physically rated to measure accelerations over a range of at least +/- 3g with 10% sensitivity.

Inside the chip is a small micro mechanical structure which is supported by springs built out of silicon. Differential capacitance measurements allow the net displacement of the tiny mass to be converted to a voltage, which is then digitized. It is important to note that the sensor does not measure the acceleration of the Wiimote, but rather the force exerted by the test mass on its supporting springs. Due to the sign convention used, this quantity is proportional to the net force exerted by the player's hand on the Wiimote when holding it. Thus, at rest on a flat table, the accelerometer reports vertical force of +g (the mass can be normalized away into the aribitrary units), and when dropped reports a force of nearly zero.

The sensor uses a right-handed coordinate system with the positive X-axis to the left, and the positive Z-axis pointing upward, when the remote is held horizontally, as shown in the diagram at the right. Forces on each axis are digitized to 8 bit unsigned integers, with the zero scale set to 0x80. Manufacturing and calibration defects of course cause some intrinsic zero offsets. However, the Earth's gravitational field and a flat, level surface upon which to rest the remote, in principle, allow any offsets or chip skew to be measured and calibrated away in software. The calibration values are stored near the start of the Wiimotes flash RAM. Decomposing the force measured by the sensor into rotation and linear components is tricky, and discussed further on the Motion analysis page.

The Wiimote does not normally report motion sensor readings to the host, but can be requested by sending SET_REPORT request to channel 0x12:

 (52) 12 00 31

The 3rd byte is a bitmask. 0x01 turns on the rumble, and 0x04 turns on continuous output. If 0x04 is not set, packets are only output when the values change (almost always when the motion sensor is enabled). If 0x04 is set, values are output continuously. In continuous mode, the device will send data at 100 packages per second. It's obvious when channel/mode 0x30 is chosen, which disables motion readback. With byte3=0x04, the button values are output multiple times a second. With byte3=0x00, they are output only when you press or release a button.

The 4th byte specifies which HID channel to which log sensor output should be sent. After receiving this command once, the Wiimote will send back stream of DATA INPUT packets on the requested channel/mode (0x31 in the above example), where in reports 0x31, 0x33, 0x35, and 0x37 the 5th, 6th and 7th bytes contain the X, Y, and Z readings of the accelerometer. A sample packet when the Wiimote is at rest, face up, on a table is:

 (a1) 31 40 20 86 8a a5

where 0x86 is the X-axis measurement, 0x8a is the Y-axis measurement, and 0xa5 is the Z-axis measurement. The first two bytes of the payload, 0x40 and 0x20, are the button values and some other bits. These bits are important in reports 0x3E and 0x3F. The button values are still in the same place and have the same meanings as in the Buttons section.

Other channels can be selected for motion sensor reports, including 0x31, 0x33, 0x35, 0x37, 0x3e and 0x3f. If either 0x3e or 0x3f are selected then sensor readings will alternate between the two channels. 0x3E contains the X Acceleration in the third byte of the payload, wheras 0x3F contains the Y Acceleration in the third byte of the payload. The Z Acceleration is stored in the button flags, as shown in the button table above. 0x3E and 0x3F use the remaining 18 bytes for what we think is IR data.

The length of the report payload will depend upon the channel, as show in the table in HID Interface section. Channels which have payloads longer than needed for the motion sensor will apparently pad the end of the packet with 0xff bytes:

 (a1) 33 40 00 86 8a a5 ff ff ff ff ff ff ff ff ff ff ff ff ff

Motion sensor reports can be stopped by setting the output channel to 0x30:

 (52) 12 00 30

It seems that the channel mode is actually a mode selection / bitmask. Button output is always enabled. Mode 0x30 is just buttons, 0x31 is motion sensor, 0x32 is IR camera (???), and 0x33 is both IR camera and motion sensor. The two sets of data are tacked onto each other, first the button values, then the three motion sensor bytes, then the camera bytes. Other modes seem to include motion data and / or IR data in different ways.

[edit] Calibration

The zero points, and gravity values, for the three accelerometer axes, are stored near the start of the Wiimote's flash memory.

[edit] Calibration Data

Calibration data for the onboard accelerometer is stored in the Wiimote's memory, starting at address 0x16. This information is repeated at 0x20.

0x16      zero point for X axis
0x17      zero point for Y axis
0x18      zero point for Z axis
0x19      unknown
0x1A      +1G point for X axis
0x1B      +1G point for Y axis
0x1C      +1G point for Z axis
0x1D      unknown
0x1E-0x1F checksum?

[edit] Outputs

[edit] Player LEDs

The bottom edge of the remote body contains 4 blue LEDs. These LEDs are used during normal play to indicate that the remote is in Bluetooth discoverable mode (indicating the battery level, while blinking), or to indicate the player number of the controller (one light illuminated). The LEDs are independently controllable, however, using SET_REPORT output packet to channel 11, which has a payload size of 1. The most-significant 4 bits control each LED, with bit 4 corresponding to the player 1 LED. Channel 11 also can control the rumble feature, so it is best to keep the 4 least-significant bits zero in order to avoid vibrating the controller. For example, this packet turns on the player 1 LED only:

 (52) 11 10

Since each LED has its own bit, any combination of LEDs can be illuminated. Updating the LED mask rapidly (multiple times a second) will cause all four LEDs to blink as if the remote is in pairing mode. Once there has been a short delay since the last LED mask update, the most recently set mask will appear again though, and the blinking will stop.

The WiiFit balance board acts like a Wii Remote. It only has 1 LED, labelled "power", which is set like you would set the player 1 LED on a Wii Remote.

[edit] Rumble

Rumble is provided via motor with an unbalanced weight attached inside the Wiimote which can be activated to cause the controller to vibrate. The motor can be activated by sending a SET_REPORT output packet to channels 0x11, 0x13, 0x14, 0x15, 0x19 or 0x1a with the least significant bit set:

 (52) 13 01

And the vibration can be turned off by clearing the bit:

 (52) 13 00

So far, it appears all channels are equivalent, though using channel 0x11 is not advised because it also controls the player LEDs.

[edit] Speaker

The Wiimote has a small low-quality speaker, used for short sound effects during gameplay. The sound is streamed directly from the host, and the speaker has some adjustable parameters. The speaker is not fully reverse engineered yet.

The speaker is controlled by using three output reports, together with a section of the register address space of the Wiimote.

Report 0x14 is used to enable or disable the speaker. Setting bit 2 will enable the speaker, and clearing it will disable it. For example, to enable the speaker, send:

(52) 14 04

Report 0x19 is used to mute or unmute the speaker, and works identically to report 0x14. 0x04 will mute the speaker, and 0x00 will unmute it.

Report 0x18 is used to send speaker data. 1-20 bytes may be sent at once:

(52) 18 LL DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD

LL specifies the data length, shifted left by three bits. The DD bytes are the speaker data. To fulfill the report length requirements, the data must be padded if it is less than 20 bytes long. Sound data must be sent at roughly the proper rate. You can choose the rate by setting the sample rate during initialization.

[edit] Initialization Sequence

The following sequence will initialize the speaker:

Enable speaker (Send 0x04 to Output Report 0x14)
Mute speaker (Send 0x04 to Output Report 0x19)
Write 0x01 to register 0x04a20009
Write 0x08 to register 0x04a20001
Write 7-byte configuration to registers 0x04a20001-0x04a20008
Write 0x01 to register 0x04a20008
Unmute speaker (Send 0x00 to Output Report 0x19)

[edit] Speaker Configuration

7 bytes control the speaker settings, known to include sample rate and volume at this time. The gray bytes in the following example sequence are unknown bytes at this time: 0x00 0x00 0x00 0x0C 0x40 0x00 0x00

The red 0x0C value in byte 3 specifies the sample rate divisor, based on approximately a 48000Hz starting rate. This means that higher values are lower sample rates, with the 0x00 value acting in a (currently) unknown/undefined state meaning the divisor is taken directly and literally.

Value	Sample Rate
11 (0x0B)	4000/4364Hz (~4200Hz)
12 (0x0C)	3692/4000Hz (~3920Hz)
13 (0x0D)	3429/3692Hz (~3640Hz)
14 (0x0E)	3200/3429Hz (~3360Hz)
15 (0x0F)	3000/3200Hz (~3080Hz)

Assuming 40 samples per report, you would need to send 100 reports per second to use the value 12 (0x0C). That is about the limit of what has been gotten to work.

The blue 0x40 in byte 4 appears to be the volume-control byte at this time. Any value from 0(0x00) to 255(0xFF) seems to work, with 64(0x40) being generally accepted as a good 'default' volume for most purposes.

[edit] Sound Data Format

The sound data format is still partially unknown. It seems to be 4-bit ADPCM sound.

[edit] Onboard Memory

[edit] Flash Memory

On a blank Wiimote, which was bought separately and has never been connected to a Wii, and has never received a report other than 0x17 (read memory) with the first byte as 00; the memory is structured like this:

Addresses 0x0000 to 0x003F:

 A1 AA 8B 99 AE 9E 78 30 A7 74 D3 A1 AA 8B 99 AE
 9E 78 30 A7 74 D3 82 82 82 15 9C 9C 9E 38 40 3E
 82 82 82 15 9C 9C 9E 38 40 3E 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

This is basically two sequences, each repeated twice:

 A1 AA 8B 99 AE 9E 78 30 A7 74 D3
 A1 AA 8B 99 AE 9E 78 30 A7 74 D3
 82 82 82 15 9C 9C 9E 38 40 3E
 82 82 82 15 9C 9C 9E 38 40 3E

The three bytes starting at 0x16 and 0x20 (the first 3 bytes of the 3rd and 4th line above) store the calibrated zero offsets for the accelerometer. Presumably the 9C 9C 9E stores the force of gravity on those axes.

Addresses 0x0040 to 0x0FC9: all zeros on a newly bought Wiimote.

Address 0x0FCA to 0x12B9: Mii Data block 1, all zeros on a newly bought Wiimote.

Address 0x12BA to 0x15A9: Mii Data block 2, all zeros on a newly bought Wiimote.

Address 0x15AA to 0x15FF: all zeros on a newly bought Wiimote.

Addresses 0x1600 to 0xFFFF: Don't exist. They return an error if you try to read from them. You won't get the error if you start reading from at or before the 0x15FF boundary, but you will just get zeroes for the invalid bytes in that case.

For the Flash memory the address is only 2 bytes. So address 0x010000 is the treated the same as address 0x0000. This is true all the way up to 0xFF0000. That byte (0x00FF0000) is always ignored unless the most significant byte (0xFF000000) has bit 2 (0x04) set.

Spark Fun's EEPROM dump of their Wiimote seems to suggest that the Bluetooth-readable portion of the EEPROM starts at 0x0070 on the physical device. More interesting is the fact that Spark Fun claims that unencrypted 8051 code is on the same chip. Device names are also present ("Nintendo RVL-CNT-01") that show up when scanning for the device on a PC. The first three bytes of the Wiimote's BD address do not appear in the dump, suggesting that the Bluetooth chip has some storage itself for such things.

It is still unknown if there is a filesystem or not in the flash chip, but considering that multiple games claims to save data on it, it is not unsurprising.

[edit] Reading and Writing

We can read data with the command:

(52) 17 FF FF FF FF SS SS

[edit] Expansion Port

The expansion port on the bottom of the unit is used to connect the remote to auxiliary controllers which augment the input options of the Wiimote. Auxiliary controllers use the Bluetooth interface of the remote to communicate with the Wii base unit, allowing them to be much simpler and cheaper to build. Currently available controllers are the Nunchuk, the Classic Controller, the Guitar Hero III Controller, and the Wii Fit Balance Board.

The Wii Fit Balance Board appears to the computer or Wii, as though it was a Wiimote and an expansion controller joined together inside a single box. But you can't seperate the two parts or connect it to a real Wiimote.

The expansion port on an actual Wiimote is a custom connector with 6 contacts. Two of the contacts are slightly longer, which allows them to make contact first when a plug is inserted. The connector is not suitable for charging the remote. More information is needed on the electrical specifications of this connector.

The communication between the Wiimote and the Extension Controllers is 400kHz "fast" I2C, with the slave address 0x52.

The status of the expansion port is indicated with report 20H. This report is sent whenever the status of the expansion port changes, or when the computer sends output report 15H to request the status.

After an attachment is plugged in or unplugged, no other reports are sent except 20H. The computer needs to send an output request (report 12H) to retrieve new input reports.

The format of input report 20H consists of the report number, then two bytes which are presumably the button state like in other reports, then a status flags byte, then two unknown 00 bytes, then the battery level.

Status byte flags

bit	Value (hex)	Flag
0	0x01	? 0 ?
1	0x02	any attachment plugged in
2	0x04	Speaker enabled ?
3	0x08	IR sensor enabled ?
4	0x10	LED 1
5	0x20	LED 2
6	0x40	LED 3
7	0x80	LED 4

Note that bit 2 (0x04) above is turned on by sending report 0x14 with the flag 0x04 in the payload. It is turned off by sending report 0x14 without the 0x04 flag. Bit 3 (0x08) above is turned on by sending EITHER report 0x13 with the flag 0x04 in the payload, OR report 0x1A with the flag 0x04 in the payload. You can turn it off by sending EITHER report 0x13 or 0x1A without that flag. You can, for example, turn it on with report 0x13 and then off again with report 0x1A.

For example, when the classic controller or nunchuk or guitar is plugged in, input report 20H is sent:

(a1) 20 00 00 02 00 00 C0

The 02H indicates the classic controller, nunchuk or guitar is plugged in. The C0H is the battery level, and has nothing to do with the nunchuk or classic controller or guitar. It will slowly decrease the more you use up the batteries, but sometimes it increases.

When the classic controller or nunchuk or guitar is unplugged, input report 20H is sent again, but with 00 instead of the 02:

(a1) 20 00 00 00 00 00 C0

[edit] Batteries

You can read the battery level with report 0x20. It is received when something is plugged in, or unplugged from, the expansion port. Or you can request it by sending report 0x15 with the payload set to anything without bit 1 (rumble) set.

(a1) 20 00 00 02 00 00 C0

The 0xC0 at the end is the battery level (in this case, for the brand new alkaline batteries that come with it). Other batteries tested have yielded battery levels as high as 0xC6 (198 decimal), suggesting that in theory a "fully charged" battery might register 0xC8 (200 decimal).

Note that you may receive this message unsolicited. Whether this occurs or you request this message, you will need to send report 0x12 with the report number again before you will receive more data.