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.
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.
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.
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:
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.
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)|
| ?? Unknown (motion reports) ??;|
or Z Acceleration, bit 6 (report 3E) or bit 2 (report 3F)
| X Acceleration LSB (motion reports);|
or Z Acceleration, bit 7 (report 3E) or bit 3 (report 3F)
| Y Acceleration LSB (motion reports);|
or Z Acceleration, bit 4 (report 3E) or bit 0 (report 3F)
| Z Acceleration LSB (motion reports);|
or Z Acceleration, bit 5 (report 3E) or bit 1 (report 3F)
|? 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.
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.
The zero points, and gravity values, for the three accelerometer axes, are stored near the start of the Wiimote's flash memory.
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?
During R&D, Nintendo discovered the motion sensors were not accurate enough to use the remote to control an on-screen cursor. To correct this, they augmented the remote with an infrared image sensor on the front designed to locate two IR beacons within the controller's field of view. The beacons are housed within a device misleadingly called the Sensor Bar.
These two sources of IR light are tracked by a PixArt sensor in the front of the Wiimote housing. By tracking the locations of these two points in the sensors 2D field of view, the system can derive more accurate pointing information. Not much is known about this feature yet, but circumstantial evidence from the Nintendo/PixArt press release suggests that Nintendo is using a PixArt System-on-a-Chip to process the images on-board the Wiimote and sends the minimum information needed for tracking back to the base unit. Transmitting full 2D images constantly would require a prohibitive amount of bandwidth, especially when multiple remotes are in use.
Wiimote detects and transfers up to four IR hotspots back to the host. Various amounts of data can be requested, from position values only, position and size, to position, size and pixel value. The amount of different configurations are quite numerous, and also ties in with the connected peripheral device.
Communications with the camera module is performed via an I2C bus (or other 2-wire wired-or bidirectional serial bus). Pins 5 and 6 of the camera (see silkscreen for pin #s) are the clock and data respectively. The bit rate is slightly less than 400kbaud. These signals are also available at TP101 (data) down between the inductors, and TP26 (clock), right next to the B button pad (under the B button housing). The broadcom chip and camera are the only two devices on this bus. When the camera is active, it sends data at 100Hz to the broadcom chip.
Output format EXP is three bytes per dot recognized. Bytes 0 and 1 are X and Y, byte 2 is the MSBs of X and Y and a size value. In binary:
xxxxxxxx yyyyyyyy yyxxssss
No dot is indicated by 0xff data. This means you will not see any change in the output data even if you did do all the initialization correctly, unless you actually point the Wiimote at a (powered) sensor bar!
Output format for FULL is unknown, but we know the data is interleaved. Data sent to report 0x3e contains the data for the first two dots recognized, data sent to 0x3f contains the data for the next two dots recognized, if any.
Note that the original hidd patch has trouble with 0x00 bytes in commands. Make sure you're sending the right data.
It is beneficial to add a slight pause (1/100 sec) between sends when setting IR mode to let the remote keep up. Without these pauses the remote appears to get into an inconsistent state sometimes and will not reliably detect IR spots.
The IR sensor returns values in the range 0..1023 * 0..767. Measurements indicate that the horizontal field of view is approximately 41°, the vertical field of view approximately 31°. This means that one increment corresponds to 0.04° or 25 increments correspond to one degree both in horizontal and in vertical direction.
Note: Is the diagram to the right accurate? (Tilt: right and Tilt: left seem backwards, based on the images)
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.
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.
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.
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)
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.
|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.
Sound Data Format
The sound data format is still partially unknown. It seems to be 4-bit ADPCM sound.
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.
Reading and Writing
We can read data with the command:
(52) 17 FF FF FF FF SS SS
FF FF FF FF is the offset (big-endian format). SS SS (big-endian format) is the size in bytes.
It was once thought that this was the correct format:
(52) 17 0r 00 FF FF SS SS
The low bit of the first byte (of the address) is the usual rumble flag. The rumble flag is not part of the address. You should always set this bit to whatever the current rumble state should be. It does not affect the address. If you don't set this bit to the current rumble state you will accidentally change the rumble state just by reading (or writing) the memory.
There is only 5.5K of Flash RAM on the Wiimote, which is addressed between 0x0000 and 0x15FF. But there are also internal control registers which can be set, but only some of them can be read. The control registers begin with 0x04. The returned packets store addresses as only two bytes. And addresses wrap around after 0xFFFF.
The responses look like this:
btns? SE FF FF data vvvvv vv vv vv v------> (a1) 21 80 00 f0 11 f0 80 6c 8c c7 c2 5d 2e bd 40 00 4e 00 99 80 08 b1
E is the error flag. E is 8 if you try to read from bytes that don't exist (are greater than 5.5K, or 0x15FF), and 7 if you try to read from write-only registers, or 0 if no error. S (the high nibble, needs to be shifted right 4 bits) is the size in bytes, minus one, for the current packet. FF is the offset of the current packet (big-endian). Everything else is the data (16 bytes max, if there is an incomplete trailer S is set to something other than 0xF and the data is padded out with zeros.) If you requested more than 16 bytes, then you will receive multiple packets, unless you get an error where E is 8.
Writing data is as follows:
FF FF FF FF SS data vv vv vv vv vv v------> (52) 16 00 00 00 00 10 57 69 69 57 69 6c 6c 52 6f 63 6b 59 6f 75 21 21
FF,SS same meaning as reading (you can only write 16 bytes at a time here, so SS is only one byte). 16 bytes of data follow. It seems we get some kind of acknowledge on Input 0x22.
Note that only bit 2 (0x04) in the first byte (of payload) is considered part of the address. It causes the Wiimote to write to registers instead of flash memory. Bit 0 (0x01) of the first byte should be set to the current state of Rumble, otherwise it will accidentally turn rumble on or off. The second byte is only used for register addresses. Writing to flash memory ignores this byte, so 0x010000 is the same as 0x0000.
Communication with the Nunchuk
See the Wiimote/Extension Controllers/Nunchuk article for details about how the Nunchuk is to be comunicated with
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
|0||0x01||? 0 ?|
|1||0x02||any attachment plugged in|
|2||0x04||Speaker enabled ?|
|3||0x08||IR sensor enabled ?|
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
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.
- Wiimote Reverse Engineering
- Motion analysis
- Wiimote driver
- Wiimote/Extension Controllers/Nunchuk
- Wiimote/Extension Controllers/Classic controller
- Wiimote Priority
- Sensor Bar