User:Marcan/Wiimote

This page is intended to be a technical guide to the Wii Remote.
For an excellent high-level overview of the Wii Remote (a.k.a. Wiimote), see the Wikipedia entry.

The Wii Remote (informally known as the Wiimote) is the Wii's main input device. It is a wireless device, using standard Bluetooth technology to communicate with the Wii. It is built around a Broadcom BCM2042 bluetooth System-on-a-chip, and contains multiple peripherals that provide data to it, as well as an expansion port for external add-ons. The Wiimote uses (and, at times, abuses) the standard Bluetooth HID protocol to communicate with the host, which is directly based upon the USB HID standard. As such, it will appear as a standard input device to any Bluetooth host. However, the Wiimote does not make use of the standard data types and HID descriptor, and only describes its report format length, leaving the actual contents undefined, which makes it useless with standard HID drivers. The Wiimote actually uses a fairly complex set of operations, transmitted through HID Output reports, and returns a number of different data packets through its Input reports, which contain the data from its peripherals.

Summary

Reverse engineering and documenting all of the Wiimote's features is a work in progress. Here are the known features and their status:

Bluetooth Communication		Connection to the Wiimote using the 1+2 sync sequence works.
Core Buttons		All working.
Accelerometer		All working. LSB bits unknown, but largely irrelevant.
IR Camera		Basic and Extended modes work, Full is pending, sensitivity settings need to be worked out.
Power Button		Pressing Power turns off the Wiimote and disconnects BT. Wii Power-on mechanism unknown.
Speaker		Enabling speaker works, but sound output is garbled. Need to figure out format and speed.
Player LEDs		Can be controlled by software arbitrarily. Even brightness modulation works.
Status Information		Battery and extension info in Status Report
Extension Controllers		All working. Calibration details need some work.
Legend Perfect or near-perfect Usable but not complete Unusable

Bluetooth Communication

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

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

The Wiimote does not appear to require any of the authentication or encryption features of the Bluetooth standard. In order to interface with it, it must first be placed in 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, a number of the player LEDs based on the battery level will blink.

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. However, no information regarding the actual data units within each report is returned, only the length in bytes.

Note: An "Input" report is sent by the Wiimote to the host. An "Output" report is sent by the host to the Wiimote.

These are the reports the Wiimote uses, and their use:

I/O	ID(s)	Size	Function
O	0x11	1	Player LEDs
O	0x12	2	Data Reporting mode
O	0x13	1	IR Camera Enable
O	0x14	1	Speaker Enable
O	0x15	1	Status Information Request
O	0x16	21	Write Memory and Registers
O	0x17	6	Read Memory and Registers
O	0x18	21	Speaker Data
O	0x19	1	Speaker Mute
O	0x1a	1	IR Camera Enable 2
I	0x20	6	Status Information
I	0x21	21	Read Memory and Registers Data
I	0x22	4	Write Memory and Registers Status
I	0x30-0x3f	2-21	Data reports

For clarity, the convention in this document is to show packets including the HID command (in parentheses), report ID, 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.

Force Feedback is accessible through the first byte of ALL output reports in the same way. This is not included above to avoid clutter.

Output Report common information

The first byte in many Output reports has a similar meaning. In every single Output Report, bit 0 (0x01) of the first byte controls the Rumble feature. Additionally, bit 2 (0x04) is used in several Output Reports as the ON/OFF flag for the specific feature controlled by it. For example, sending 0x04 to Report 0x19 (Speaker Mute) will mute the speaker:

(52) 19 04

Ssending 0x00 will unmute it:

(52) 19 00

These Output Reports share the above behavior: Data Reporting Mode (0x12), IR Camera Enable (0x13), Speaker Enable (0x14), Speaker Mute (0x19), IR Enable 2 (0x1a).

Data Reporting

The Wiimote has a number of different data reporting modes. Each of these modes combines certain Core data features with data from external peripherals, and sends it to the host through one of the report IDs, determined by the mode. The data format from the peripherals is determined by the peripherals themselves, all the Wiimote controller does is pull bytes from them and send them out to the host. Due to this, certain feature combinations are not available, as there are not enough bytes for them in any of the output modes.

The Data Reporting Mode is set by sending a two-byte command to Report 0x12:

(52) 12 TT MM

Bit 2 of TT specifies whether continuous reporting is desired. If bit 2 (0x04) is set, the Wiimote will send reports whether there has been any change to the data or not. Otherwise, the Wiimote will only send an output report when the data has changed.

MM specifies the Reporting Mode. Each Mode is specified by the Output Report ID that the data will be sent to. For example, this will set mode to 0x33:

(52) 12 00 33

Data will then arrive through Output Report 0x33.

Upon powerup, the Data Reporting Mode defaults to 0x30. Following a connection or disconnection event on the Extension Port, data reporting is disabled and the Data Reporting Mode must be reset before new data can arrive.

Modes which include Accelerometer data also embed part of it in the unused Buttons bits. In all modes except for 0x3e/0x3f, the Buttons data includes the LSBs of the Accelerometer data. In mode 0x3e/0x3f, the interleaved Buttons data includes the Z-axis Accelerometer data.

0x30: Core Buttons

This mode returns data from the buttons in the Wiimote:

(a1) 30 BB BB

BBBB is the core Buttons data.

0x31: Core Buttons and Accelerometer

This mode returns data from the buttons and the accelerometer in the Wiimote:

(a1) 31 BB BB AA AA AA

BBBB is the core Buttons data. AA AA AA is the Accelerometer data.

0x32: Core Buttons with 8 Extension bytes

This mode returns data from the buttons in the Wiimote, and data from an extension controller connected to it:

(a1) 32 BB BB EE EE EE EE EE EE EE EE

BBBB is the core Buttons data. The 8 EE bytes are from the Extension Controller currently connected to the Wiimote.

0x33: Core Buttons and Accelerometer with 12 IR bytes

This mode returns data from the buttons, accelerometer, and IR Camera in the Wiimote:

(a1) 33 BB BB AA AA AA II II II II II II II II II II II II 

BBBB is the core Buttons data. AA AA AA is the Accelerometer data. The 12 II bytes are from the built-in IR Camera.

0x34: Core Buttons with 19 Extension bytes

This mode returns data from the buttons in the Wiimote, and data from an extension controller connected to it:

(a1) 34 BB BB EE EE EE EE EE EE EE EE EE EE EE EE EE EE EE EE EE EE EE 

BBBB is the core Buttons data. The 19 EE bytes are from the Extension Controller currently connected to the Wiimote.

0x35: Core Buttons and Accelerometer with 16 Extension Bytes

This mode returns data from the buttons and accelerometer in the Wiimote, and data from an extension controller connected to it:

(a1) 35 BB BB AA AA AA EE EE EE EE EE EE EE EE EE EE EE EE EE EE EE EE

BBBB is the core Buttons data. AA AA AA is the Accelerometer data. The 16 EE bytes are from the Extension Controller currently connected to the Wiimote.

0x36: Core Buttons with 10 IR bytes and 9 Extension Bytes

This mode returns data from the buttons and IR camera in the Wiimote, and data from an extension controller connected to it:

(a1) 36 BB BB II II II II II II II II II II EE EE EE EE EE EE EE EE EE

BBBB is the core Buttons data. The 10 II bytes are from the built-in IR Camera, and the 9 EE bytes are from the Extension Controller currently connected to the Wiimote.

0x37: Core Buttons and Accelerometer with 10 IR bytes and 6 Extension Bytes

This mode returns data from the buttons, accelerometer, and IR camera in the Wiimote, and data from an extension controller connected to it:

(a1) 37 BB BB AA AA AA II II II II II II II II II II EE EE EE EE EE EE

BBBB is the core Buttons data. AA AA AA is the Accelerometer data. The 10 II bytes are from the built-in IR Camera, and the 6 EE bytes are from the Extension Controller currently connected to the Wiimote.

0x3d: 21 Extension Bytes

This mode returns data from an extension controller connected to the Wiimote:

(a1) 37 EE EE EE EE EE EE EE EE EE EE EE EE EE EE EE EE EE EE EE EE EE

The 21 EE bytes are from the Extension Controller currently connected to the Wiimote.

0x3e / 0x3f: Interleaved Core Buttons and Accelerometer with 36 IR bytes

Both 0x3e and 0x3f are equivalent, and return data alternately through report IDs 0x3e and 0x3f. The data is interleaved, and is returned at half the speed of other modes (as two reports are needed for a single data unit). This mode returns data from the buttons, accelerometer, and IR camera in the Wiimote:

(a1) 3e BB BB AA II II II II II II II II II II II II II II II II II II
(a1) 3f BB BB AA II II II II II II II II II II II II II II II II II II

BBBB is the core button data, as specified in the Buttons section. AA AA is the Accelerometer data, in a format specific to this mode described in the Interleaved Accelerometer Reporting section. The 36 II bytes are from the built-in IR Camera.

Memory and Registers

The Wiimote includes a built-in EEPROM memory, part of which is accessible to the user to store that. This user part is used to store calibration constants, as well as the Mii Data. Additionally, many peripherals on the Wiimote have registers which are accessible through a portion of the address space.

Both built-in memory and peripheral registers are accessed using the same reports, where a flag is used to select between the two.

Reading and Writing

To read data, commands are sent to Output Report 0x17:

(52) 17 MM FF FF FF SS SS

FF FF FF is the offset, and SS SS is the size to read in bytes (both in big-endian format). Bit 2 (0x04) of MM selects the address space. Clearing this bit results in reading from EEPROM Memory, while setting it results in reading from the control registers. Setting bit 3 (0x08) also works to access registers, but setting both results in errors. As with all other reports, it also includes the Rumble flag, which must be set to the current rumble state to avoid affecting it.

Data read is returned through Input Report 0x21:

(a1) 21 BB BB SE FF FF DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD

BB BB is the state of the buttons on the Wiimote. During data reads, regular input reporting is temporarily suspended. Button data is available through the data input reports, but no other input data can be collected while the transfer lasts. FF FF is the offset of the first byte of data returned (the high byte of the offset is not returned, and neither is which data memory is being used. Thus, this must be known from the read request). E (low nybble of SE) is the error flag. Known error values are 0 for no error, 7 when attempting to read from a write-only register, and 8 when attempting to read from nonexistant memory. S (high nybble of SE) is the size in bytes, minus one, for the current data packet. This is 0xf (16 bytes) for all but the last packet, where it might be less if the requested number of bytes is not a multiple of 16. The DD bytes are the data, padded with zeroes to 16 bytes. If more than 16 bytes are requested, multiple packets will be received, with FF FF offsets increasing by 16 each time.

To write data, commands are sent to Output Report 0x16:

(52) 16 MM FF FF FF SS DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD

The meaning of the bytes is the same as during reads, except that size can be a maximum of 16 bytes (as there is only space for that much data), and the actual data to write follows (the DD bytes), padded out to 16 bytes.

Some kind of acknowledgement is received on Input Report 0x22. This has not been investigated yet.

EEPROM Memory

There is a 128kbit EEPROM chip in the Wiimote. Part of its contents include code for the built-in microcontroller, and a generic section which can be freely read and written by the host. This section is 0x1600 bytes long, and part of this memory is used to store the Mii Data.

On a virgin wiimote, acquired separately (not bundled with a Wii), that has never communicated with any device (except the PC used to dump the memory contents), most of the memory is blank (0x00). However, the first few bytes contain some information:

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

This can be better visualized as two sequences, each one repeated twice:

0000:  A1 AA 8B 99 AE 9E 78 30 A7 74 D3
000B:  A1 AA 8B 99 AE 9E 78 30 A7 74 D3
0016:  82 82 82 15 9C 9C 9E 38 40 3E
0020:  82 82 82 15 9C 9C 9E 38 40 3E

The three bytes starting at 0x0016 and 0x0020 store the calibrated zero offsets for the accelerometer. Apparently, the three bytes at 0x001A and 0x24 store the force of gravity on those axes. The function of other data bytes is not known, and most of them differ between Wiimotes. Some or all of these bytes might not be used by the Wii. However, there has been a case of a Wiimote where Extension functionality was lost following a battery change, and restoring these bytes (which had been previously overwritten) fixed the problem. The Extension controllers did not work with a PC either (which did not explicitly use these bytes), suggesting some of these might be used by the Wiimote itself. This is unconfirmed, but it is advised that these never be overwritten, and recommended that they be backed up, just in case.

At 0x16D0, there is some more unknown data:

16d0:  00 00 00 FF 11 EE 00 00 33 CC 44 BB 00 00 66 99
16e0:  77 88 00 00 2B 01 E8 13 00 00 00 00 00 00 00 00
16f0:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

In contrast to the data at 0x0000, this data seems to differ in only a few bytes between different Wiimotes.

Known memory ranges are listed below. Note that the "user data" area is 0x0FA0 = 4000 bytes long, which seems to confirm the 4kB figure that has been mentioned (meaning 4000 bytes, that is, using the SI prefix meaning instead of the binary meaning).

Start	End	Length	Initial Value	Use
0x0000	0x0029	0x002A	See above	Calibration values / pre-set data
0x002A	0x0FC9	0x0FA0	Zeroed	User data / Unknown uses
0x0FCA	0x12B9	0x02f0	Zeroed	Mii Data block 1
0x12BA	0x15A9	0x02f0	Zeroed	Mii Data block 2
0x15AA	0x16CF	0x0126	Zeroed	Unknown / Unused
0x16D0	0x16FF	0x0030	Zeroed	Unknown data

The top byte of the address is unused, which means memory is mirrored every 0x10000 bytes. Reading from unused addresses where the low 16 bits are >= 0x1600 will result in error returns.

Control Registers

The Wiimote has several memory mapped register spaces corresponding to different peripherals in it. These include the Speaker, Extension Controllers, and the IR Camera.

The peripheral to access is selected by the first byte of the address, and the lower 16 bits specify the register to access within that peripheral. The lowest bit of the high byte is ignored, which means every peripheral is mirrored at its address + 0x10000. Known peripherals are listed below:

Start	End	Use
0xA20000	0xA20009	Speaker settings
0xA40000	0xA400FF	Extension Controller settings and data
0xB00000	0xB00033	IR Camera settings

Most of these are also mirrored across the high bits of the individual peripheral. For example, the second byte of the address is ignored in the Extension controller address, which means any address of the form 0xA4xx00 will work (as will 0xA5xx00).

Input Features

The Wiimote has two input features that are controlled directly by the Broadcom chip: a Three-Axis Accelerometer and 11 Buttons. Additionally, it has an IR Camera with an object tracking processor, and an expansion port that allows for external input features such as those contained in the Nunchuk and the Classic Controller (see Extension Controllers.

Buttons

The Wiimote has 11 buttons on its front face, and one trigger-style button on the back. Of these, the Power button is special and is treated differently by the Wiimote. All the other buttons are independantly accessible through a two-byte bitmask which is transmitted first in most Input Reports. A button will report a 1-bit if pressed, or a 0-bit otherwise. By default, these are sent only when the state of any button changes, in Data Reporting Mode 0x30. However, the Wiimote may be configured to report the state of the buttons continuously; see Data Reporting.

Core Buttons

The Wiimote has 11 buttons that are used as regular input devices: A, B (trigger), a 4-directional D-Pad, +, -, Home, 1, and 2. These are reported as bits in a two-byte bitmask. These are the assignments, in big-endian order:

Bit	Mask	First Byte	Second Byte
0	0x01	D-Pad Left	Two
1	0x02	D-Pad Right	One
2	0x04	D-Pad Down	B
3	0x08	D-Pad Up	A
4	0x10	Plus	Minus
5	0x20	Other uses	Other uses
6	0x40	Other uses	Other uses
7	0x80	Unknown	Home

Power Button

When the Wiimote is turned off, pressing the Power button will attempt to wake up the Wii that is synchronized to it. The mechanism for this is unknown. When the Wiimote is turned on and connected to a host, pressing and holding the Power button for a few seconds will turn the Wiimote off and request disconnection from the host, which may then use this event to power itself off, as the Wii does.

Accelerometer

Coordinate system used by Wiimote

The Wiimote includes a three-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.

Since the accelerometer actually measures the force exerted by a set of small proof masses inside of it with respect to its enclosure, the accelerometer measures linear acceleration in a free fall frame of reference. If the Wiimote is in free fall, it will report zero acceleration. At rest, it will report an upward acceleration (+Z, when horizontal) equal to the acceleration due to gravity, g (approximately 9.8 m/s²). This fact can be used to derive tilt from the acceleration outputs, although this will only be accurate when the Wiimote is reasonably still.

Normal Accelerometer Reporting

In all Data Reporting Modes which include Accelerometer data except for mode 0x3e/0x3f, the accelerometer data is reported as three consecutive bytes:

(a1) RR BB BB XX YY ZZ [...]

XX, YY, and ZZ are unsigned bytes representing the acceleration in each of the three axis, where zero acceleration is approximately 0x80. The coordinate system is shown in the diagram above. Additionally, the BB BB Buttons bytes also seem to include the LSBs of the acceleration values in the unused bits, although which is which is not very clear, and they are not needed for most applications.

Interleaved Accelerometer Reporting

In Data Reporting Mode 0x3e/0x3f, the accelerometer data is spread over two reports:

(a1) 3e BB BB XX [...]
(a1) 3f BB BB YY [...]

In this mode, the LSBs are not available. Instead, X and Y acceleration is reported as a single byte, and the Z value is encoded in the unused bits of the BB BB Buttons data as follows:

		Bit
Report ID	Byte	7	6	5	4	3	2	1	0
0x3e	0		Z<5:4>
0x3e	1		Z<7:6>
0x3f	0		Z<1:0>
0x3f	1		Z<3:2>

IR Camera

The Wiimote includes a 1024x768 monochrome camera, with an IR-pass filter in front of it. The camera includes a built-in processor capable of tracking up to 4 moving objects (raw pixel data is not available to the host). The Sensor Bar that comes with the Wii includes two IR LED clusters at each end, which are tracked by the Wiimote to provide accurate pointing information. The IR Camera can be used to track up to four objects that are bright at IR or near-IR wavelengths. If the filter is removed, it can track any bright object.

The IR Camera is enabled by setting bit 2 on output reports 0x13 and 0x1a:

(52) 13 04
(52) 1a 04

Initialization

The following procedure should be followed to turn on the IR Camera:

1. Enable IR Camera (Send 0x04 to Output Report 0x13)
2. Enable IR Camera 2 (Send 0x04 to Output Report 0x1a)
3. Write 0x08 to register 0xb00030
4. Write Sensitivity Block 1 to registers at 0xb00000
5. Write Sensitivity Block 2 to registers at 0xb0001a
6. Write Mode Number to register 0xb00033

Sensitivity Settings

Sensitivity is controlled by two configuration blocks, 9 bytes and 2 bytes long. The following settings are known to work:

Block 1	Block 2	Notes
00 00 00 00 00 00 90 00 C0	40 00	Suggested by Marcan
02 00 00 71 01 00 aa 00 64	63 03	Suggested by Cliff

Data Formats

The IR Camera can return different sets of data describing the objects it is tracking. When the IR camera identifies an object, it assigns it to the first available object slot. If an object moves out of view, its slot is marked as empty (returns 0xFF data), but other objects retain their slots. For example, if the camera is tracking two objects and the first moves out of view, the data returned will be [empty, second object, empty, empty]. With more than four objects visible, the camera is prone to rapidly switching between some of them. This could allow perception of more than four objects, at a reduced response speed and reliability.

Mode	Mode Number
Basic	1
Extended	3
Full	5

The data format MUST match the number of bytes available in the Reporting Mode selected. Even choosing a mode with space for more bytes than necessary will not work, it has to be an exact match.

Basic Mode

In Basic Mode, the IR Camera returns 10 bytes of data corresponding to the X and Y locations of each of the four dots. Each location is encoded in 10 bits and has a range of 0-1023 for the X dimension, and 0-767 for the Y dimension. Each pair of dots is packed into 5 bytes, and two of these are transmitted for a total of 4 dots and 10 bytes.

This is the data format for a pair of objects:

	Bit
Byte	7	6	5	4	3	2	1	0
0	X1<7:0>
1	Y1<7:0>
2	Y1<9:8>		X1<9:8>		Y2<9:8>		X2<9:8>
3	X2<7:0>
4	Y2<7:0>

Extended Mode

In Extended Mode, the IR Camera returns the same data as it does in Basic Mode, plus a rough size value for each object. The data is returned as 12 bytes, three bytes per object. Size has a range of 0-15.

This is the data format for each object:

	Bit
Byte	7	6	5	4	3	2	1	0
0	X<7:0>
1	Y<7:0>
2	Y<9:8>		X<9:8>		S<3:0>

Full Mode

In Full Mode, the IR Camera returns even more data, 9 bytes per object for a total of 36 bytes for all four. The data is split up between two input reports of 18 bytes each (see Data Reporting Mode 0x3e/0x3f). The data format for Full Mode hasn't been reverse engineered yet.

Feedback Features

The Wiimote sports three feedback features: Player LEDs, Rumble, and the Speaker.

Player LEDs

There are four blue LEDs on the front face of the Wiimote. During discovery and before initialization, these LEDs blink at a fixed rate. The number of blinking LEDs is proportional to the battery voltage, indicating battery charge (all four are lit for newly charged batteries, and only the first is lit if the batteries are low and should be replaced).

During gameplay with the Wii, one LED is lit to indicate the player number assigned to the Wiimote. However, the LEDs are independently controllable by the host, and can be set to display any pattern. They can also be modulated at a moderately high speed, enabling some brightness control at the cost of a lot of Bluetooth bandwidth. Sigma-delta modulation works reasonably well for this.

The LEDs can be controlled by sending a report with ID 0x11:

(52) 11 LL

The high nybble of LL controls the four LEDs. Bit 4 of LL controls the first LED, and bit 7 controls the last:

Bit	Mask	LEDs
4	0x10	· ■ ·· ■ ··· ■ ···· ■
5	0x20	· ■ ·· ■ ··· ■ ···· ■
6	0x40	· ■ ·· ■ ··· ■ ···· ■
7	0x80	· ■ ·· ■ ··· ■ ···· ■

Turning off all LEDs for an extended period of time is discouraged, as it might lead the user to believe the Wiimote is turned off and disconnected, when in fact it is active.

Rumble

The Wiimote includes a rumble feature, which is implemented as a small motor attached to an off-center weight. It will cause the controller to vibrate when activated.

The rumble motor can be turned on or off through any of the Output Reports. Setting the LSB (bit 0) of the first byte of any output report will activate the rumble motor, and unsetting it will deactivate it. For example, the following report will turn the rumble motor on:

(52) 13 01

However, this will also have the side-effect of turning off all LEDs. Since there is no output report that only affects the rumble motor, and all of them do affect it, an implementation might need to store both the rumble and LED values locally (for example), and use the same Output Report for both. Another possibility would be using the status request report (0x15). The rumble bit needs to be set properly with every single report sent, to avoid inadvertently turning the rumble motor off.

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, and will only produce seriously distorted sound currently.

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 fullfill the report length requirements, the data must be padded if it is less than 20 bytes long. Sound data must be sent at the proper rate.

Initialization Sequence

The following sequence will initialize the speaker:

1. Enable speaker (Send 0x04 to Output Report 0x14)
2. Mute speaker (Send 0x04 to Output Report 0x19)
3. Write 0x01 to register 0xa20009
4. Write 0x08 to register 0xa20001
5. Write 7-byte configuration to registers 0xa20001-0xa20008
6. Write 0x01 to register 0xa20008
7. Unmute speaker (Send 0x00 to Output Report 0x19)

Speaker Configuration

7 bytes control the speaker settings, including volume. The full purpose of these bytes is not known, but the following values seem to produce some sound:

00 00 00 07 40 00 00

The 0x07 value in byte 3 seems to specify the volume. 0x07 is probably the upper limit, and lower values correspond to lower volume.

Sound Data Format

The sound data format is currently unknown, although there have been mentions of 4-bit 6Khz sound. Experiments with 4-bit 6Khz PCM sound have resulted in a loud buzzing noise, but a hint of the original music can be heard. A sample recorded from the Wiimote is available here: [1].

Extension Controllers

The Wiimote includes a 6-pin proprietary expansion connector, which carries synchronous serial data to and from external add-ons, using a two-wire interface. Currently, Nintendo has released the Nunchuk and the Classic Controller. These addons map onto a portion of the Wiimote's register space, and can also stream data out through Output Reports (see Data Reporting for a list of modes which include Extension Controller data).

Registers

Extension Controllers are mapped at register address 0xa40000. The data is 0x100 bytes long, and it is mirrored across the entire 16-bit address space up to 0xa4FFFF. These registers are readable and writable. Communications are encrypted, using a key that is written to registers beginning at 0xa40040. Simply writing a zero to register 0xa40040 initializes the peripheral, and makes it use a very simple encryption scheme. Behavior with other keys has not been investigated. When using a zero key, all bytes must be decrypted by using the following transformation:

decrypted_byte = (encrypted_byte XOR 0x17) + 0x17

The result should be truncated to 8 bits (in languages such as C and Python, use &0xFF or work directly with 8-bit datatypes).

The Wiimote will stream data bytes from the Extension Controller starting at offset 0x08, and continuing for however many bytes the current Data Reporting Mode requires. Data streamed through the Input Reports must also be decrypted using the above transformation.

Identification

The last two bytes of the register block identify the connected Extension Controller. A two-byte read of register 0xa400fe will return these bytes. The Extension Controller must have been initialized prior to this (by writing 0x00 to the key register).

Encrypted	Decrypted	Meaning
0x0000	0x2E2E	Nothing inserted
0xFFFF	0xFFFF	Partially inserted
0xFEFE	0x0000	Fully inserted Nunchuk
0xFDFD	0x0101	Fully inserted Classic Controller

The "Partially inserted" condition occurs when the connector is loose or has a bad connection. Usually, this will correct itself upon full insertion. However, it has been known to "stick" in the partially inserted state rarely. This is a hardware glitch, the fix is to simply disconnect and reconnect the Extension Controller.

Checking one byte might suffice, as currently they just seem to be mirrors of one another. However, future attachments might use both, so it is advisable to check both.

Extension Controller Documentation

Individual Extension Controllers are described on the Extension Controllers page.

Status Information

The Wiimote can report its status, which includes the state of a few basic settings, the status of the Extension Controller (connected or disconnected), and the battery level.

To request the status report, send anything to Output Report 0x15. The Status Report will also be automatically sent when an Extension Controller is connected or disconnected.

This will request the status report (and turn off rumble):

(52) 15 00

The report will be returned through Input Report 0x20:

(a1) 20 00 00 FF 00 00 BB

BB is the current battery level, and FF is a bitmask of flags:

Bit	Mask	Meaning
0	0x01	Unknown
1	0x02	An Extension Controller is connected
2	0x04	Unknown
3	0x08	Continuous reporting enabled
4	0x10	LED 1
5	0x20	LED 2
6	0x40	LED 3
7	0x80	LED 4