Wiimote

From Wiili

Jump to: navigation, search
Wii Remote
Enlarge
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.

Contents

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.

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, Force Feedback
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.

Inputs

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.

Motion Sensor

Coordinate system used by Wiimote
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.

Calibration

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

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?

IR Sensor

What the Wiimote IR sensors see, and how it relates to where the pointer is placed.
What the Wiimote IR sensors see, and how it relates to where the pointer is placed.

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)

Outputs

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.

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.

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.

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 0x04a20009
  4. Write 0x08 to register 0x04a20001
  5. Write 7-byte configuration to registers 0x04a20001-0x04a20008
  6. Write 0x01 to register 0x04a20008
  7. Unmute speaker (Send 0x00 to Output Report 0x19)

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.

Sound Data Format

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

Onboard Memory

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.


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

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

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.

See Also:


Linux
WiiLi Link | GameCube Linux | Artwork | Wiimux

Hardware
Wiimote (Drivers, Extension Port, Mii Data) | Wii balance board | Classic Controller | Nunchuk | GameCube Controller (Keyboard, GBA) | Nintendo DS
Bluetooth (BlueZ, Devices) | Ethernet Adapter | USB Devices | Modchips

Homebrew
GameCube | Wii | Action Replay

Specs
Wii | Comparison

File System
Wii Optical Disc | Wii Flash Memory | SD Card
GameCube Optical Disc | GameCube Memory Card

Wiimote | Communications | BlueZ

Drivers (BlueSoleil) | Devices

How-To: BlueSoleil | Kensington | Widcomm

Wiimote Drivers

Windows
cWiimote | GlovePIE | RMX Automation | Wiim | wiimote-api | WiinRemote | WiimoteLib

Linux
CWiid | WMD | Perlwiimote | libwiimote | lg3d-wii

OSX
DarwiinRemote | Remote Buddy | The Wiinstrument

Multiplatform
OpenPIE | Wiimote_Simple | WiiremoteJ | wiiuse | WiiJuce | WiiuseJ

PyBluez Scripts: Wiiewer | Wiimotecomm


Personal tools
Sedo - Buy and Sell Domain Names and Websites project info: wiili.org Statistics for project wiili.org etracker® web controlling instead of log file analysis