Talk:Wiimote
I'll second 84.144.102.151's suggestion that this page be locked from anonymous edits. -- inio 01:09, 21 December 2006 (CST)
After undoing 2 spam-edits I second the suggestion too. FrozenCow
This idea gives me the creeps. If the english wiki would lock every page for a simple spam/vandalism like that one, everything would be blocked in a few days. I believe this is definetly too drastic: there's been only a few edits in total. Please consider unlocking.
MaxDZ8 06:14, 8 August 2007 (PDT)
Splitting into several pages
How about splitting this page into a general page about the wiimote, one page about the hardware of the wiimote and one about the communication protocol used? It will make the pages more structured. Dvdhrm 11:44, 13 February 2011 (CET)
Speaker media format
Could it be that they perhaps used IMA/DVI ADPCM to compress 16-bit wave files to 4-bit for the wii-mote. The source to the implementation can be found here [1] and here [2] I hope someone can check into this as have too little knowledge but it popped to mind reading about the 4-bit soundformat.Galantir 9 sept 2008
Incoming Report Report ID: 0020: Data: 00 00 02 00 00 95 FF FF FF FF 00 00 00 00 00 00 00 00 00 00 00 Outgoing Report Report ID: 0012: Data: 00 32 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Outgoing Report Report ID: 0016: Data: 04 A4 00 40 03 3F 3F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Incoming Report Report ID: 0032: Data: 00 00 FF FF FF FF FF FF FF FF 00 00 00 00 00 00 00 00 00 00 00 Outgoing Report Report ID: 0011: Data: 00 00 03 47 00 9C 79 41 00 90 FD 12 00 15 00 00 00 00 00 00 00 Incoming Report Report ID: 0022: Data: 00 00 16 00 FF FF FF FF FF FF 00 00 00 00 00 00 00 00 00 00 00 Incoming Report Report ID: 0032: Data: 00 00 5D DE 6F 0B FF FF FE 97 00 00 00 00 00 00 00 00 00 00 00 Outgoing Report Report ID: 0011: Data: 00 00 03 47 00 9C 79 41 00 90 FD 12 00 15 00 00 00 00 00 00 00 Incoming Report Report ID: 0032: Data: 00 00 5D DE 6F 0B FF FE FE 97 00 00 00 00 00 00 00 00 00 00 00 Outgoing Report Report ID: 0011: Data: 00 00 03 47 00 9C 79 41 00 90 FD 12 00 15 00 00 00 00 00 00 00 Incoming Report Report ID: 0032: Data: 00 00 5D DE 6F 0B FF FF FE 97 00 00 00 00 00 00 00 00 00 00 00 Outgoing Report Report ID: 0011: Data: 00 00 03 47 00 9C 79 41 00 90 FD 12 00 15 00 00 00 00 00 00 00 Incoming Report Report ID: 0032: Data: 00 00 5D DE 6F 0B BF FF FE 97 00 00 00 00 00 00 00 00 00 00 00 Outgoing Report Report ID: 0011: Data: 00 00 03 47 00 9C 79 41 00 90 FD 12 00 15 00 00 00 00 00 00 00 Incoming Report Report ID: 0032: Data: 00 00 5D DE 6F 0B FF FF FE 97 00 00 00 00 00 00 00 00 00 00 00 Outgoing Report Report ID: 0011: Data: 00 00 03 47 00 9C 79 41 00 90 FD 12 00 15 00 00 00 00 00 00 00 Incoming Report Report ID: 0032: Data: 00 00 5D DE 6F 0B FF FD FE 97 00 00 00 00 00 00 00 00 00 00 00 Outgoing Report Report ID: 0011: Data: 00 00 03 47 00 9C 79 41 00 90 FD 12 00 15 00 00 00 00 00 00 00 Incoming Report Report ID: 0032: Data: 00 00 5D DE 6F 0B FF FF FE 97 00 00 00 00 00 00 00 00 00 00 00 Outgoing Report Report ID: 0011: Data: 00 00 03 47 00 9C 79 41 00 90 FD 12 00 15 00 00 00 00 00 00 00 Incoming Report Report ID: 0032: Data: 00 00 5D DE 6F 0B 7F FF FE 97 00 00 00 00 00 00 00 00 00 00 00 Outgoing Report Report ID: 0011: Data: 00 00 03 47 00 9C 79 41 00 90 FD 12 00 15 00 00 00 00 00 00 00 Incoming Report Report ID: 0032: Data: 00 00 5D DE 6F 0B FF FF FE 97 00 00 00 00 00 00 00 00 00 00 00 Outgoing Report Report ID: 0011: Data: 00 00 03 47 00 9C 79 41 00 90 FD 12 00 15 00 00 00 00 00 00 00
List of things not yet complete
Purpose of Output report: 0x10
- Good question. CarlKenner 07:42, 5 January 2009 (UTC)
- Looking through captured traces of communication with actual games, this seems to be a method for turning the rumble on and off without affecting anything else. Swdshchf 16:12, 17 June 2010 (UTC)
Section Reading and writing: Some kind of acknowledgement is received on Input Report 0x22. This has not been investigated yet.
- I have documented this report. It has nothing to do with reading and writing. It acknowledges any output report. It is 22 BB BB RR TT, where RR is the output report number, and TT is either 00 or 03 (we don't know what TT's value means). CarlKenner 07:42, 5 January 2009 (UTC)
- If a motionplus is currently active when the wii begins talking to the wiimote, then the initial status report 0x20 will report that there's an extension attached. The system will then attempt to send the extension init sequence: writing 0x55 to 0xa400f0 and then 0x00 to 0xa400fb. However, when the first byte is written, it swaps the motion plus into the 0xa60000 range, which leaves the 0xa40000 range empty (unless you have a pass-through device). This means there's nothing to write to when you send the byte to 0xa400fb. The resulting input report comes back: 22 xx xx 16 07. Also, input report 0x22 seems to automatic for a write report, it only comes if requested by setting bit 0x02 in the first byte of most other output reports (similar to how setting bit 0x01 turns the rumble on and off). Swdshchf 16:12, 17 June 2010 (UTC)
Use of bit 7 of the first byte of button information.
- I have observed this bit occasionally being set, but I can't work out why. CarlKenner 07:42, 5 January 2009 (UTC)
- I think it is set when the power button is pressed. I know pressing the power button while being connected does not send anything, but if I use single-press reconnection with the power button, an input report is sent with the buttons that were pressed to trigger single-press-reconnection. I currently implement single-press-reconnection and will try to investigate that. Dvdhrm 13:29, 13 February 2011 (CET)
How power button works
- The Wii remote turns on the Wii in much the same way it turns it off--sending an HCI disconnect command with the reason set to 0x15. The remote must have already been paired with the Wii. The complete sequence a 3rd party Wii remote emits is below. It was captured via a remote based on the RDA5875 chip by connecting UART_TX (pin 32) and UART_RX (pin 1) to an ESP32's UART1 RX and UART2 RX with a baud rate of 460800. This board had test points to those pins via TP33 & TP34 on the flip side of the main board near the speaker connections.
CMD: (0a) 01 1a fc 06 XX XX 01 62 04 2a vendor HCI command set BDA 2a:04:62:01:XX:XX EVT: (07) 04 0e 04 01 1a fc 00 vendor HCI command set BDA complete CMD: (04) 01 09 10 00 HCI_READ_BD_ADDR EVT: (0d) 04 0e 0a 01 09 10 00 XX XX 01 62 04 2a read local address complete, status 0x0 addr 2a:04:62:01:XX:XX CMD: (04) 01 05 10 00 HCI_READ_BUFFER_SIZE EVT: (0e) 04 0e 0b 01 05 10 00 fd 03 b4 08 00 08 00 buffers status 0 HC_ACL_Data_Packet_Length 1021 HC_Total_Num_ACL_Data_Packets 8 CMD: (08) 01 37 0c 04 32 00 80 0c HCI_WRITE_LINK_SUPERVISION_TIMEOUT EVT: (09) 04 0e 06 01 37 0c 02 32 00 HCI_WRITE_LINK_SUPERVISION_TIMEOUT command complete CMD: (06) 01 18 0c 02 00 10 HCI_WRITE_PAGE_TIMEOUT EVT: (07) 04 0e 04 01 18 0c 00 HCI_WRITE_PAGE_TIMEOUT command complete CMD: (18) 01 13 0c 14 4e 69 6e 74 65 6e 64 6f 20 52 56 4c 2d 43 4e 54 2d 30 31 00 HCI_WRITE_LOCAL_NAME EVT: (07) 04 0e 04 01 13 0c 00 write_local_name complete status 0x0 CMD: (08) 01 1e 0c 04 00 08 12 00 HCI_WRITE_INQUIRY_SCAN_ACTIVITY EVT: (07) 04 0e 04 01 1e 0c 00 HCI_WRITE_INQUIRY_SCAN_ACTIVITY command complete CMD: (08) 01 1c 0c 04 00 08 13 00 HCI_WRITE_PAGE_SCAN_ACTIVITY EVT: (07) 04 0e 04 01 1c 0c 00 HCI_WRITE_PAGE_SCAN_ACTIVITY command complete CMD: (05) 01 47 0c 01 01 HCI_WRITE_PAGE_SCAN_TYPE EVT: (07) 04 0e 04 01 47 0c 00 HCI_WRITE_PAGE_SCAN_TYPE command complete CMD: (05) 01 43 0c 01 01 HCI_WRITE_INQUIRY_SCAN_TYPE EVT: (07) 04 0e 04 01 43 0c 00 HCI_WRITE_INQUIRY_SCAN_TYPE command complete CMD: (08) 01 3a 0c 04 01 00 8b 9e HCI_WRITE_CURRENT_IAC_LAP EVT: (07) 04 0e 04 01 3a 0c 00 write_current_iac_lap complete status 0x0 CMD: (07) 01 24 0c 03 04 25 00 HCI_WRITE_CLASS_OF_DEVICE EVT: (07) 04 0e 04 01 24 0c 00 write_class_of_device complete status 0x0 CMD: (11) 01 05 04 0d XX XX 22 1d 19 00 1e ff 01 00 00 80 01 HCI_CREATE_CONNECTION EVT: (07) 04 0f 04 00 01 05 04 HCI_CREATE_CONNECTION status 0x0 EVT: (09) 04 17 06 XX XX 22 1d 19 00 HCI_EVENT_LINK_KEY_REQUEST CMD: (1a) 01 0b 04 16 XX XX 22 1d 19 00 07 c4 a3 ce cc b0 81 f4 aa 35 14 06 1e 77 d8 16 HCI_LINK_KEY_REQUEST_REPLY EVT: (0d) 04 0e 0a 01 0b 04 00 XX XX 22 1d 19 00 hci_link_key_request_reply addr 00:19:1d:22:XX:XX status 0x0 EVT: (0e) 04 03 0b 00 32 00 XX XX 22 1d 19 00 01 00 connection complete addr 00:19:1d:22:XX:XX status 0x00 con_handle 0x32, link_type 1 encrypted 0 CMD: (07) 01 06 04 03 32 00 15 HCI_DISCONNECT reason 0x15 EVT: (07) 04 0f 04 00 01 06 04 HCI_DISCONNECT status 0x0 EVT: (07) 04 05 04 00 32 00 16 disconnected handle 0x0032 status 0x0 reason 0x16
- More information from the host's perspective follows. It does nothing to turn the Wii on as as the Wii will not reply to any L2CAP/HID packets while in an off state.
- We know how the power button works now when held down to turn the Wii off, except we still don't know how it works for turning the Wii on. CarlKenner 07:42, 5 January 2009 (UTC)
- I spoofed my Wii's mac adress and then pressed power button wiimote this is the dump from hcidump
user@user-laptop:~/wii$ sudo hcidump -VX
[sudo] password for user:
HCI sniffer - Bluetooth packet analyzer ver 1.42
device: hci0 snap_len: 1028 filter: 0xffffffffffffffff
> HCI Event: Connect Request (0x04) plen 10
bdaddr 00:17:AB:25:BE:D6 class 0x002504 type ACL
< HCI Command: Accept Connection Request (0x01|0x0009) plen 7
bdaddr 00:17:AB:25:BE:D6 role 0x00
Role: Master
> HCI Event: Command Status (0x0f) plen 4
Accept Connection Request (0x01|0x0009) status 0x00 ncmd 1
> HCI Event: Role Change (0x12) plen 8
status 0x00 bdaddr 00:17:AB:25:BE:D6 role 0x00
Role: Master
> HCI Event: Connect Complete (0x03) plen 11
status 0x00 handle 42 bdaddr 00:17:AB:25:BE:D6 type ACL encrypt 0x00
< HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2
handle 42
> HCI Event: Page Scan Repetition Mode Change (0x20) plen 7
bdaddr 00:17:AB:25:BE:D6 mode 0
> ACL data: handle 42 flags 0x02 dlen 12
L2CAP(s): Connect req: psm 17 scid 0x0048
< ACL data: handle 42 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0048 result 1 status 0
Connection pending - No futher information available
< ACL data: handle 42 flags 0x02 dlen 10
L2CAP(s): Info req: type 2
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 42 packets 1
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 42 packets 1
> ACL data: handle 42 flags 0x02 dlen 16
L2CAP(s): Info rsp: type 2 result 0
Extended feature mask 0x0004
Bi-directional QoS
< ACL data: handle 42 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0048 result 0 status 0
Connection successful
> HCI Event: Command Status (0x0f) plen 4
Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 1
< HCI Command: Remote Name Request (0x01|0x0019) plen 10
bdaddr 00:17:AB:25:BE:D6 mode 2 clkoffset 0x0000
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 42 packets 1
> HCI Event: Read Remote Supported Features (0x0b) plen 11
status 0x00 handle 42
Features: 0xbc 0x02 0x04 0x38 0x08 0x00 0x00 0x00
> ACL data: handle 42 flags 0x02 dlen 16
L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 4
MTU 185
< ACL data: handle 42 flags 0x02 dlen 18
L2CAP(s): Config rsp: scid 0x0048 flags 0x00 result 0 clen 4
MTU 185
< ACL data: handle 42 flags 0x02 dlen 12
L2CAP(s): Config req: dcid 0x0048 flags 0x00 clen 0
> HCI Event: Command Status (0x0f) plen 4
Remote Name Request (0x01|0x0019) status 0x00 ncmd 1
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 42 packets 1
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 42 packets 1
> ACL data: handle 42 flags 0x02 dlen 18
L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 4
MTU 185
< ACL data: handle 42 flags 0x02 dlen 5
L2CAP(d): cid 0x0048 len 1 [psm 17]
HIDP: Control: Virtual cable unplug
< ACL data: handle 42 flags 0x02 dlen 12
L2CAP(s): Disconn req: dcid 0x0048 scid 0x0040
> ACL data: handle 42 flags 0x02 dlen 12
L2CAP(s): Connect req: psm 19 scid 0x0049
< ACL data: handle 42 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0041 scid 0x0049 result 1 status 2
Connection pending - Authorization pending
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 42 packets 1
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 42 packets 1
> ACL data: handle 42 flags 0x02 dlen 12
L2CAP(s): Disconn rsp: dcid 0x0048 scid 0x0040
> HCI Event: Remote Name Req Complete (0x07) plen 255
status 0x00 bdaddr 00:17:AB:25:BE:D6 name 'Nintendo RVL-CNT-01'
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 42 packets 1
< ACL data: handle 42 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0041 scid 0x0049 result 0 status 0
Connection successful
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 42 packets 1
> ACL data: handle 42 flags 0x02 dlen 16
L2CAP(s): Config req: dcid 0x0041 flags 0x00 clen 4
MTU 185
< ACL data: handle 42 flags 0x02 dlen 18
L2CAP(s): Config rsp: scid 0x0049 flags 0x00 result 0 clen 4
MTU 185
< ACL data: handle 42 flags 0x02 dlen 12
L2CAP(s): Config req: dcid 0x0049 flags 0x00 clen 0
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 42 packets 1
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 42 packets 1
> ACL data: handle 42 flags 0x02 dlen 18
L2CAP(s): Config rsp: scid 0x0041 flags 0x00 result 0 clen 4
MTU 185
< ACL data: handle 42 flags 0x02 dlen 12
L2CAP(s): Disconn req: dcid 0x0049 scid 0x0041
> ACL data: handle 42 flags 0x02 dlen 8
L2CAP(d): cid 0x0041 len 4 [psm 19]
HIDP: Data: Input report
0000: 30 00 00 0..
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 42 packets 1
> ACL data: handle 42 flags 0x02 dlen 12
L2CAP(s): Disconn rsp: dcid 0x0049 scid 0x0041
> HCI Event: QoS Setup Complete (0x0d) plen 21
status 0x00 handle 42 flags 0
Service type: 1
Token rate: 0
Peak bandwith: 0
Latency: 10000
Delay variation: -1
< HCI Command: Disconnect (0x01|0x0006) plen 3
handle 42 reason 0x13
Reason: Remote User Terminated Connection
> HCI Event: Command Status (0x0f) plen 4
Disconnect (0x01|0x0006) status 0x00 ncmd 1
> HCI Event: Disconn Complete (0x05) plen 4
status 0x00 handle 42 reason 0x16
Reason: Connection Terminated by Local Host
The important part of that is:
> ACL data: handle 42 flags 0x02 dlen 8
L2CAP(d): cid 0x0041 len 4 [psm 19]
HIDP: Data: Input report
0000: 30 00 00 0..
-- bear24rw
The IR camera configuration data is definitely not fully understood.
- Indeed. 07:42, 5 January 2009 (UTC)
More information on the peripheral encryption could be interesting.
Note: This is very likely not intended to be an encryption, but more likely a means of reducing bit transitions over busses to conserve power. Bus Encoding for Low Power
What is with the two enable bits for the IR Camera? That seems odd.
Why is the peripheral data encrypted but the main data not?
Wiimote on XP thuru WM_INPUT message
I played a bit with a Wiimote using WM_INPUT messages and I want to post the results so other people don't waste their time on this.
The Wiimote is correctly enumerated as a source of WM_INPUT messages and can be registered as a WM_INPUT producer. Vendor and product id are enumerated correctly (0x57e and 0x306 respectively).
For simple applications, this may be enough. The wiimote reports 22 bytes foreach packet, which looks like an extended 0x33 mode but I'm not sure.
0] 33 1] 0 2] 20 3] 81 4] 68 5] 82 6] ff 7] ff
8] ff 9] ff 10] ff 11] ff 12] ff 13] ff 14] ff 15] ff
16] ff 17] ff 18] 0 19] 0 20] 0 21] 0
Byte0 is always 0x33 (uncluckly, this doesn't seem to be mode 0x33)
Byte1,2 are the core buttons exactly like described in the wiki.
Byte3,4,5 are accelerometer data matching the wiki.
Byte6,7,8,9 and byte10,11,12,13 have been tested to be IR objects. I haven't checked out the layout but I predict to match the wiki as well.
Byte14,15,16,17 and byte 18,19,20,21 seems to be the other 2 IR object but I can't say for sure. (assuming my observations are correct this makes for 16 IR bytes so it can't be mode 0x33 - win32 is mangling this data in some way)
.
As said, it seems rather nice for simple applications. Unluckly, once the nunchuk is connected the remote will stop reporting continuously. It will only report when a wiimote button is pressed and only partially. Even disconnecting and re-handshaking with the BT stack won't work.
Unluckly, this is a fatal issue so don't waste your time on WM_INPUT!
MaxDZ8 06:46, 8 August 2007 (PDT)
This has nothing to do with WM_INPUT. You tried to register the wiimote as generic HID device using the raw-hid backend of WM_INPUT which is known to fail because the wiimote does not entirely follow the HID standard. To support WM_INPUT you need to write an WM_INPUT backend that uses a fake-HID protocol to communicate with the wiimote, however, I think WM_INPUT is not suitable for that because it does not allow any output events from the application to the device and the wiimote at least needs some force-feedback event mechanism to misuse it to control the wiimote (like rumble (actually this would be force feedback) and LEDs and extension/IR/etc. configuration). Dvdhrm 13:20, 13 February 2011 (CET)
Extension controller identification
"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."
This is apparently not true, since the Guitar Hero ID is 0x0103, but the article is locked for some reason so I can't fix it. 142.59.172.116 10:57, 27 February 2008 (PST)
The article is only locked from anonymous edits. Log in and you can edit it inio 12:25, 28 February 2008 (PST)
Auto-Syncronization
Is anyone currently working the wiimote libraries to remove the sync on start up requirement? It will get old having to sync wiimotes everytime you go into homebrew that uses one (or more) wiimotes. Seems like if you saved sync information to a sys file you could just have all homebrew auto-sync wiimotes using that same file. (Assuming the same wiimote library is used across homebrew). Also, it would make sense to have the sync button on the wii (Or some other combo of buttons) put the wiimote back into sync mode incase it needs to be resynced for any reason (regenerating the sync sys file). beardface 15:56, 3 May 2008 (CST)
Firmware/hardware reverse-engineering
Here is the information about firmware/hardware reverse-engineering of the Wiimote.
All addresses in hexadecimal.
Link map
EEPROM 8051 Description 0000-006f ? 0070-176f Host data (MII data, calibration) 16f1-16ff The last 15 bytes of report 0x22 FrozenCow 1770-3fff 7f35-a7c4 8051 code/data
I believe the link map is much more complex. Also perhaps some 8051 code is not stored in the EEPROM. For example, there are ljmp to address e0f7, e0ee, etc at location 8407.
Bluetooth HID descriptor block is at EEPROM address 18f7 (more or less).
Memory map
The following are variables, 34xx-35xx should be mapped to RAM.
3445 ? 3446 ? 344c ? 344d ? 344e ? 3452 1 if speaker is enabled, 0 if disabled 347a request status info flag (1=request pending, 0=none) 347c request data read flag (1=request pending, 0=none) 34b9 ? 34ac ? 34fa (...) Bluetooth input report message buffer 353a LED state bit 3 1=LED on, 0=LED off bit 2 1=LED on, 0=LED off bit 1 1=LED on, 0=LED off bit 0 1=LED on, 0=LED off
Area 7xxx - system calls?
741c ?
7175 Routine uses registers r3-r7 (5 registers)
7f3f Bluetooth class ID (0x002504)
8714 Jump table, 32 entries 8774 Call routine indexed by r7 (0-31) of jump table at 8714 8781 Jump table, 32 entries (Bluetooth input report handlers) 87e1 Call routine indexed by r5 (0-31) of jump table at 8781 87ee Jump table, 11 entries (Bluetooth output report handlers) 880f Call routine indexed by r5 (0-10) of jump table at 880f
8e94 Enable/disable LEDs (bits 0-3 of r7) 8eb0 Store register a at address pointed by dptr, calls 8eb1 8eb1 Load address pointed by dptr to register r7, calls 8eb5 8eb5 Enable rumble motor (r7=1), disable (r7=0) 8f2e Enable speaker 8f4c Disable speaker 8f25 Mute speaker (r7=0), unmute (r7=8)
9421 Initialize variables (notably request flags)
9980 Bluetooth input report handler (ID 0x20)
Status information message formatting
Very interesting, contains a lot of hints on the usage of variables
in the 34xx-35xx area
9a40 Bluetooth input report handler (ID 0x21)
9c68 Bluetooth output report handler (ID 0x10) 9c87 Bluetooth output report handler (ID 0x11) 9ca7 Bluetooth output report handler (ID 0x12) 9d05 Bluetooth output report handler (ID 0x13) 9d2a Bluetooth output report handler (ID 0x14) 9d4f Bluetooth output report handler (ID 0x15) 9dc8 Bluetooth output report handler (ID 0x16) 9e2a Bluetooth output report handler (ID 0x17) 9ea5 Bluetooth output report handler (ID 0x18) 9ed8 Bluetooth output report handler (ID 0x19) 9efe Bluetooth output report handler (ID 0x1A)
(helper routines)
a4c7 dptr = r6:r7, a = r5^3 a567 r7 = @dptr, a = (@dptr>>2) & 0x3f
Bluetooth command handlers
Bluetooth input report handlers parameters
Input r5 ? r6:r7 Bluetooth report data offset 0 ? offset 1 report number offset 2 first byte of data Return value r7=0, ok r7=3, error
Special function registers
7f00 ?
7f01 ?
7f03 ?
7f04 ?
1:0 10 when speaker enabled
00 when speaker disabled
7f05 ?
7f07 ?
7f0a GPIO port bit 5 enable/disable LED bit 4 enable/disable LED bit 3 enable/disable LED bit 2 enable/disable LED bit 1 1=enable rumble motor, 0=disable rumble motor
7f0b ?
7f0d ?
7f0f ?
7f5d ? bit 7 1 when speaker enabled, 0 when speaker disabled
On-board EEPROM hardware
EEPROM is TSSOP8 chip ST M24128 or equivalent type (128Kbit).
This is an I2C memory with a Write Control input (WC#) that allows protecting the entire contents of the memory against unwanted writes. When WC#=1, memory cannot be written (read-only), when WC#=0, memory can be read or written.
The WC# pin is pulled up by a 0402 10K resistor (R38) located nearby. WC# must also be connected to the Broadcom chip because the contents of the EEPROM are modified by some Bluetooth commands. Anyway the pin tied to WC# on the Broadcom chip is an open-collector output, which means that WC# can safely be forced to ground externally (through the test point) to enable temporary EEPROM memory writes.
Location of test points:
SCL Test point TP102 SDA Test point TP101 WC# Test point TP01
Questions
- Is there a CRC in the EEPROM firmware?
- Where is the entry point of the firmware? Is there one actually?
- How does 8051 core communicate with the Bluetooth stack?
Beeloot 12:42, 27 May 2008 (PDT)
Wii Balance Board Battery Level
I have been using the Wii Balance Board as input device for a PC, but cannot read the battery level. I have tried this with the wiiuse library and the wiidevicelibrary, with the same results.
Since the Board appears as WiiMote, I have been using status requests to read the battery level in the same way as you would use on a normal WiiMote. On the Wiimote it works, on the Board I always get a constant level (about 95%), independently of how low the battery voltage is.
When I request a status report from the board, I do not get the same response as from a Wiimote. Instead I get a 22 bytes long message, which contains a byte at offset 12(dec), which corresponds linearly to the measured battery voltage:
Volts = msg[12] / 25.3 (approximately)
I have used an extended version of the wiiuse library to test this.
Can anyone confirm this?
--Alf red 13:22, 26 July 2011 (CEST)
Wii Remote
Since the ACTUAL name is Wii Remote ("Wiimote" is just something lazy idiots started calling it), shouldn't the article be at called Wii Remote. TJ Spyke (talk) 02:56, 4 December 2012 (CET)