Changes

The wiimote communicates with the host via standard bluetooth protocol. The wiimote can be placed into discoverable mode for 20s by pressing the '''''sync''''' button on its back under the battery cover. Holding down the 1 and 2 button continuously will force the wiimote to stay in discoverable mode without turning off. This does not work with the ''sync'' button, though. When in discoverable mode, a number of the player LEDs based on the battery level will blink. With full battery all four LEDs will blink, the lower the battery the less LEDs will blink. During device inquiry the host will find all discoverable nearby wiimotes. Now the host can establish a bluetooth baseband connection to the wiimote, '''no bluetooth pairing is needed''', however, if bluetooth pairing is performed, the wiimote is able to reconnect to the host if disconnected.

The wiimote communicates with the host via standard bluetooth protocol. The wiimote can be placed into discoverable mode for 20s by pressing the '''''sync''''' button on its back under the battery cover. Holding down the 1 and 2 button continuously will force the wiimote to stay in discoverable mode without turning off. This does not work with the ''sync'' button, though. When in discoverable mode, a number of the player LEDs based on the battery level will blink. With full battery all four LEDs will blink, the lower the battery the less LEDs will blink. During device inquiry the host will find all discoverable nearby wiimotes. Now the host can establish a bluetooth baseband connection to the wiimote, '''no bluetooth pairing is needed''', however, if bluetooth pairing is performed, the wiimote is able to reconnect to the host if disconnected.

After a bluetooth baseband connection is established (with or without pairing) the [[#HID Interface | HID channels can be opened]] and used for reading and writing reports from/to the wiimote.

After a bluetooth baseband connection is established (with or without pairing) the [[#HID Interface | HID channels can be opened]] and used for reading and writing reports from/to the wiimote.

== Bluetooth Pairing ==

== Bluetooth Pairing ==

== HID Interface ==

== HID Interface ==

Establishing a HID connection with the Wii Remote can be done on PSM 0x11 for writing and PSM 0x13 for reading using the Bluetooth L2CAP protocol. On Windows you don't need to deal with L2CAP yourself, and can use high-level windows HID functions. Wii Remote Plus controllers which that identify as "Nintendo RVL-CNT-01-TR" use PSM 0x13 for writing, as opposed to PSM 0x11; they also use PSM 0x11 for reading.

Establishing a HID connection with the Wii Remote can be done on PSM 0x11 for the control pipe and PSM 0x13 for the data pipe using the Bluetooth L2CAP protocol. On Windows you don't need to deal with L2CAP yourself, and can use high-level windows HID functions.

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 Wii Remote 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.

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 Wii Remote 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 Wii Remote to the host. An "Output" report is sent by the host to the Wii Remote. When using a Wii Remote, all input reports are prepended with 0xa1 and all output reports are prepended with 0x52; this is the "(52)" in many example reports below. When using a Wii Remote Plus that identifies as "Nintendo RVL-CNT-01-TR", all output reports must be prepended with 0xa2 instead of 0x52.

Note: An "Input" report is sent by the Wii Remote to the host. An "Output" report is sent by the host to the Wii Remote. When using a Wii Remote, all input reports are prepended with 0xa1 and all output reports are prepended with 0xa2; this is the "(a2)" in many example reports below. Output reports are sent over the data pipe, which is also used to read input reports (thus, the control pipe is essentially unused).

 

The original Wiimotes (RVL-CNT-01) allowed sending commands using SET REPORT (0x52) over the control pipe, instead of using the data pipe; however, this form does not work on the newer RVL-CNT-01-TR, and as such is not recommended.

These are the reports the Wii Remote uses, and their use:

These are the reports the Wii Remote uses, and their use:

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:

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

  (a2) 19 04

Sending 0x00 will unmute it:

Sending 0x00 will unmute it:

  (52) 19 00

  (a2) 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).

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).

This will request the status report (and turn off [[#Rumble | rumble]]):

This will request the status report (and turn off [[#Rumble | rumble]]):

  (52) 15 00

  (a2) 15 00

This report is sent either on request (in response to report 0x15), or in response to an expansion being plugged in or unplugged (or synced if wireless). If this report is received when not requested, the application 'MUST' send report 0x12 to change the data reporting mode, otherwise no further data reports will be received.

This report is sent either on request (in response to report 0x15), or in response to an expansion being plugged in or unplugged (or synced if wireless). If this report is received when not requested, the application 'MUST' send report 0x12 to change the data reporting mode, otherwise no further data reports will be received.

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

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

  (52) 12 TT MM

  (a2) 12 TT MM

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

Bit 2 of TT specifies whether continuous reporting is desired. If bit 2 (0x04) is set, the Wii Remote will send reports whether there has been any change to the data or not. Otherwise, the Wii Remote 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:

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

  (a2) 12 00 33

Data will then arrive through Input Report 0x33.

Data will then arrive through Input Report 0x33.

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

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

  (52) 17 MM FF FF FF SS SS

  (a2) 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 | EEPROM Memory]], while setting it results in reading from the [[#Control Registers | 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.

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 | EEPROM Memory]], while setting it results in reading from the [[#Control Registers | 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.

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

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

  (a2) 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.

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.

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

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

  (52) 13 04

  (a2) 13 04

  (52) 1a 04

  (a2) 1a 04

The first enables a 24MHz pixel clock on pin 7 of the camera.  The second pulls pin 4 low - probably an active-low enable.

The first enables a 24MHz pixel clock on pin 7 of the camera.  The second pulls pin 4 low - probably an active-low enable.

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

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

  (52) 11 LL

  (a2) 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:

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

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:

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) 11 01

  (a2) 11 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.

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.

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:

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

  (a2) 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 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:

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

  (a2) 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.

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.