Talk:Wiimote
From WiiLi
[edit] Maintenance
[edit] Page is devoid of data now
so who erased all the useful information? i'll try and revert back to what was the earliest full page with all the information
[edit] restored to may 12th version
i restored the data to it's may 12th version
[edit] Hardware discussion
[edit] Report ID 0x10 ?
There seems to be an (output) report ID 0x10 (see [Wii_bluetooth_specs#HID_Descriptor]) as well, which isn't listed in the table of report IDs yet. Does anyone have a clue what it is for?
[edit] Buffer overflow bug?
Could someone that owns a Wii check if the part under "Random findings" (concerning a possible buffer overflow bug) is correct?
You can do this by setting the Wiimote to discoverable mode and running the Wiimotecomm script:
> wiimotecomm discover "52 1A 00 0E" "52 12 04 31" [Searching for Wiimotes...] [Found Wiimote at address 00:19:1C:2B:C9:A3] [Connected to Wiimote at address 00:19:1C:2B:C9:A3] Sent: (52) 1A 00 0E Received: (A1) 20 00 00 02 00 00 9D Received: (A1) 30 00 00 (Until here, messages from the Wiimote are preceded by 0xA1 (= DATA_INPUT)) Sent: (52) 12 04 31 (But from now on, messages are preceded by 0x0E:) Received: (0E) 31 40 00 84 82 9A Received: (0E) 31 20 00 84 82 9A Received: (0E) 31 00 00 84 82 9A Received: (0E) 31 00 00 84 82 9A Received: (0E) 31 00 00 84 82 9A Received: (0E) 31 00 40 84 82 99 Received: (0E) 31 60 00 83 82 9A Received: (0E) 31 00 00 84 82 9A Received: (0E) 31 00 40 84 82 9A Received: (0E) 31 00 20 84 82 9B [Disconnected]
If the output looks similar (= the last messages were preceded by 0x0E values) then please try now to connect the Wiimote to your Wii and see if you can still use it like expected.
To restore the old behaviour, run wiimotecomm again with the following parameters:
> wiimotecomm discover "52 1A 00 A1" "52 12 04 31" [Searching for Wiimotes...] [Found Wiimote at address 00:19:1C:2B:C9:A3] [Connected to Wiimote at address 00:19:1C:2B:C9:A3] Sent: (52) 1A 00 A1 Received: (0E) 20 00 00 02 00 00 9C Received: (0E) 30 00 00 (Until here, messages from the Wiimote are preceded by the value set before, 0x0E Sent: (52) 12 04 31 (But from now on, messages are preceded by 0xA1 (= DATA_INPUT) again:) Received: (A1) 31 40 20 84 82 9A Received: (A1) 31 20 20 84 82 9A Received: (A1) 31 20 20 84 82 9A Received: (A1) 31 60 20 84 82 9A Received: (A1) 31 40 20 84 82 9A Received: (A1) 31 20 20 84 82 9A Received: (A1) 31 20 60 84 82 9A Received: (A1) 31 60 00 84 83 9A Received: (A1) 31 60 00 84 83 9A Received: (A1) 31 20 20 84 82 9A [Disconnected]
If the output looks similar (= the last messages were preceded by 0xA1 values again), default behaviour is restored.
[edit] Hardware Hacking Tidbits
- Camera is definitely on an I2C bus
- in the configuration screen and main menu, the camera returns data at 200Hz (not 100Hz as we get when just turning it on as we do now)
- I'm going to check out an FPGA board and write an I2C sniffer in verilog so we can see what actually gets sent to the camera.
Inio 03:15, 1 February 2007 (EST)
[edit] Expansion port
I noticed a Gameboy Advance Link Cable fits well (including the 6 contacts) in the expansion port. The two longest contacts are Vcc and Ground. It delivers a 3,2V current when the Wiimote in "turned on" (when connected, when in discovery mode, and when pressing button).
|~~_____~~| | | | 6 4 2 | | ----- | | 5 3 1 | \_________/
| Pin | Color | Name |
|---|---|---|
| 1 | Red | 3.3V |
| 2 | Green | SDA. I2C Serial Data |
| 3 | Red | Connected to 3.3V inside attachment connector |
| 4 | - | Not connected |
| 5 | Yellow | SCL. I2C Serial Clock |
| 6 | White | Ground |
- I did some continuity testing on the Wiimote and the present WiiLi listing of expansion port pin outs (2 and 5) looks flipped when compared to my testing (and Sparkfun's pictures). Can anyone confirm? The EEPROM's (spec sheet) shows that its pin 5 is SDA and pin 6 is SCL. And the EEPROM's pin 5 goes to expansion output pin 5. The EEPROM's pin 6 goes to expansion output pin 2. Meaning:
- pin 2 of expansion output is SCL - connects to pin 6 of U3 which is SCL.
- pin 5 of expansion output is SDA - connects to pin 5 of U3 which is SDA.
--Stoph 22:33, 28 May 2007 (EDT)
[edit] Internal address-space research
[edit] ROM dumps and other such things
It seems to me that figuring out how the Wiimote works would be a lot easier if we had access to the data stored on the BCM2042 ROM. Even rudimentary schematics would also likly be useful. These would also be useful in replicating the Wiimote, should the need arise. Netdroid9 21:31, 31 December 2006 (EST)
[edit] Cadex' findings
I tried to read all addresses in the 32 bits of address space - once with, once without Nunchuk attached - and here is what I found out:
For read access, the 32 bits of the address seem the have the following meaning:
----MM-F CCCCCCC- AAAAAAAA AAAAAAAA
Meaning:
- : Don't care (= can be 0 or 1 without changing the result)
MM : Mode:
00 : Read flash memory
01 and 10: Read control registers
11 : ???, always returns errorcode 6, except for addresses 0x0CA0---- which return errorcode 8
F : Force Feedback bit - Enable (1) or disable (0) Force Feedback
CCCCCCCC : Don't care when reading Flash Memory (MM == 11)
Relevant when reading control registers (MM == 01 or 10) when upper four bits must be 1010 (0xA)
AAAAAAAA AAAAAAAA : Lower 16 Bits of the address
Control registers: Access to the control registers is selected by setting MM (Bits 2 and 3 of Byte 1) to 01 or 10 (-> Byte 1 == 0x04 or 0x08). Furthermore, the upper 4 bits of Byte 2 must be set to 1010 (0xA), otherwise errorcode 7 is returned. Since the lowest bit of Byte 2 doesn't seem to care for read access, this leaves the following address spaces:
0x04A0---- / 0x08A0---- : Return errorcode 8
0x04A2---- / 0x08A2---- : All 0xFF except for addresses 0x04A2xxFF / 0x08A2xxFF, which have value 0x00
0x04A4---- / 0x08A4---- : Nunchuk attached: 0xFF / Nunchuk not attached: Errorcode 7
0x04A6---- / 0x08A6---- : Errorcode 7
0x04A8---- / 0x08A8---- : Errorcode 7
0x04AA---- / 0x08AA---- : Errorcode 7
0x04AC---- / 0x08AC---- : Errorcode 7
0x04AE---- / 0x08AE---- : Errorcode 7
So it seems that only the following regions of the address space are interesting for read access; all other address ranges return an error when trying to read them, or are mapped to these:
0x00000000 - 0x000016FF : Flash memory content
- In contrast to the information in section "Flash Memory", the readable area of the flash memory of MY Wiimote doesn't end at 0x15FF. Instead, it ends at address 0x16FF, and this is a hexdump of that extra region in my Wiimote:
00001600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 (00001610 - 000016d0: all zeros) 000016d0: 00 00 00 FF 11 EE 00 00 33 CC 44 BB 00 00 66 99 000016e0: 77 88 00 00 2B 01 E8 13 00 00 00 00 00 00 00 00 000016f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x04A20000 - 0x04A2FFFF : Data registers of the Wiimote, default 0xFF (except for addresses ending on FF which contain value 0x00), meaning not yet known
0x04A40000 - 0x04A4FFFF : Data registers of the Nunchuk (if attached!), default 0xFF, meaning not yet known
- Just as Cadex has observed, I too find the flash memory of my Wiimotes to be readable through 0x16FF. And the data in that region of my Wiimotes is the same as above, with one exception. At address 0x16E6, instead of seeing bytes 0xE8 0x13, I find 0xD8 0x14 on one Wiimote and 0x20 0x15 on the other. The only reason I might attribute any special significance to these values is because all other readable values in flash memory (0x0000-0x16FF) are identical between both of my Wiimotes except for the block of data from 0x0000 to 0x0029, which are rather different from one another. All other bytes on both Wiimotes from 0x002A to 0x16D2 are zeros. (Note that these are not "new" Wiimotes, but I've never knowingly saved data to either of them.) Porcus
[edit] Remaining button state bits
I see some indications that the remaining bits of the button status bytes are actually the least significant bits of the acceleration data for the three axes. To be precise, I think that
- Bit 6 (bitmask 0x40) of the first button status byte is the LSB of the X axis
- Bit 5 (bitmask 0x20) of the second button status byte is the LSB of the Y axis
- Bit 6 (bitmask 0x40) of the second button status byte is the LSB of the Z axis
To illustrate this, I made a small script that prints the acceleration values as provided by report 0x31, as binary values. Note that the value for each axis has 9 bits; the least significant (=rightmost) bit of each value is taken from the button status bytes using the algorithm mentioned above. The Wiimote was standing still, but (maybe due to errors of measurement of the A/D-converter) the acceleration values slightly changes even when standing still.
X:011101111 Y:011100011 Z:100011110 X:011101110 Y:011100100 Z:100011111 X:011101111 Y:011100011 Z:100011110 X:011101111 Y:011100100 Z:100011111 X:011101111 Y:011100011 Z:100011111 X:011101111 Y:011100100 Z:100011111 X:011101111 Y:011100011 Z:100011111 X:011110000 Y:011100011 Z:100011111 X:011101111 Y:011100011 Z:100011110 X:011101111 Y:011100100 Z:100011111 X:011101111 Y:011100011 Z:100011110 X:011101111 Y:011100100 Z:100011111 X:011110000 Y:011100100 Z:100011110 X:011110000 Y:011100011 Z:100011110 X:011101111 Y:011100100 Z:100011110 X:011110000 Y:011100100 Z:100011110 X:011101111 Y:011100011 Z:100011110 ... X:011110111 Y:011111000 Z:100101110 X:011110111 Y:011110111 Z:100101110 X:011110111 Y:011111000 Z:100101111 X:011110110 Y:011111000 Z:100110000 X:011110110 Y:011111001 Z:100101111 X:011110110 Y:011111000 Z:100101110 X:011110110 Y:011110111 Z:100101111 X:011110110 Y:011111000 Z:100110000 X:011110111 Y:011111001 Z:100101111 X:011110110 Y:011111000 Z:100101111 X:011110110 Y:011111000 Z:100110000 X:011110110 Y:011111000 Z:100101111 X:011110110 Y:011111000 Z:100110000 X:011110110 Y:011110111 Z:100101111 X:011110110 Y:011110111 Z:100101110 X:011110110 Y:011111000 Z:100101111 X:011110110 Y:011111000 Z:100110000 X:011110110 Y:011111001 Z:100101111 X:011110110 Y:011111000 Z:100110000 X:011110111 Y:011111000 Z:100101111 X:011110110 Y:011110111 Z:100101110 X:011110110 Y:011111000 Z:100101111 X:011110110 Y:011111001 Z:100110000 X:011110111 Y:011111001 Z:100101111 X:011110110 Y:011111000 Z:100101111 X:011110110 Y:011110111 Z:100101110
I know this example doesn't prove anything, but you can see that the additional, least significant (rightmost) bit of each value fits in quite well, especially when the last bits of a value change from 01111 to 10000 and back to 01111 again.
Cadex 10:01, 31 December 2006 (EST)
I can confirm this: the acceleration data became much more accurate after implementing the least significant bits mentioned by Cadex.
I can also confirm this, and that there are 10 bits of acceleration data for the X axis
- Bit 5 (bitmask 0x20) of the first button status byte is the penultimate LSB of the X axis
- Bit 6 (bitmask 0x40) of the first button status byte is the LSB of the X axis
You can check this yourself by spinning a wii-mote at greater than 3g in different orientations, all of the acceleration bits of an axis that is +ve out of range will be set to 1.
So what are the LSBs for the other axes? If I'd have to guess, I'd say (assuming 10 bits):
- Bit 5 (bitmask 0x20) of the first button status byte is bit 1 of the X
- Bit 6 (bitmask 0x40) of the first button status byte is bit 0 of the X
- Bit 5 (bitmask 0x20) of the second button status byte is bit 1 of the Y
- Bit 6 (bitmask 0x40) of the second button status byte is bit 0 of the Y
- Bit 7 (bitmask 0x80) of the second button status byte is bit 1 of the Z
- We don't get the last LSB of the Z ('cause we're out of bits)
Can anyone test this?
--Cha0s 17:13, 19 March 2007 (EDT)
I guess it would be just a matter of repeating the centrifuge test with the proper axis pointing outwards....
--TiagoTiago 15:03, 29 March 2007 (EDT)
[edit] Other Talk
I cannot confirm this since I don't have Wii controllers, but seams like gravity is a thing what Nintendo developers haven't though of gravity while making drivers for controllers. If power of gravity would be considered with controllers could controllers be more accurate. --Sorsis 11:16, 24 June 2007 (EDT)
- That is a software issue, not a hardware issue. Besides, the gravitational pull is actually required to properly operate many of the games, since they use it to determinate the angle the Wiimote is held. Please read the Motion analysis article for an in-deep discussion.--henke37 17:18, 24 June 2007 (EDT)
The pointer calibration screen in the Wii menu and Zelda are the same, and both use the +/- buttons on the controller to adjust the IR sensitivity. I think that the controller itself processes the image it takes, and records the center of every IR source that is within its sensitivity range, and then passes this info on to the Wii itself for processing. This is somewhat backed up by the info released by Nintendo a while ago.
The article could probably use a cleanup in terms of channel vs. report, as well as in terms of 0x00 and 00H number forms. It's not really uniform at all. --Fashnek 08:46, 1 December 2006 (PST)
- I vote for "report" and "00H", on the grounds that they are the correct terms. When the original article said "channel" I didn't know what they were talking about. 0x00 is unique to C and Java (Delphi uses $00, Basic uses &H00). CarlKenner 05:06, 2 December 2006 (PST)
I'm hoping for someone to finally figure out the IR, then the whole input section needs to be revised. It's clear the input works in a much more unified way than we present. Volsung 13:44, 1 December 2006 (PST)
I will also second "report," but vote for 0x00, although hex notation is mostly a matter of taste. Arguing which is more correct is pointless. After a few more days, we can see which has more votes and just switch. I am in favor of leaving the packet examples in hex without either 0x or h, just to reduce clutter in a long sequence of bytes. Volsung 12:41, 2 December 2006 (PST)
I vote for "report" and 0x00. --Fashnek 18:08, 2 December 2006 (PST)
"report" is definitively the commonly used term (I didn't know for "channels"). If all values > 9 are hexadecimals, there is no need to argue about hex notation. I mainly program in C, so I'm more used to 0x, but I don't vote... --Thoduv 14:49, 5 January 2007 (EST)
[edit] Windows XP pointer
A bit of search just lead me to this demonstration of how Wiimote can be used in game programming using a SDK which was running on Windows XP. http://digg.com/videos_gaming/Demonstation_of_Wii_remote_on_Windows_XP_SDK I somehow suspect this video to be the one which is rumoured to be a "Wiimote Windows XP pointer demonstration", but I could be wrong. Altough, I didn't find any other video/news/blog/etc. of the Wiimote being used as Windows XP pointing device.
[edit] Unknown Buttons
reserves for extra controllers? think about it: there are 4 button values. what if they're used for C, Z, and the X and Y axis of the analog stick on the Nunchuk? --65.175.198.184 10:51, 4 December 2006 (PST)
- Sorrry they are the Z acceleration CarlKenner 20:36, 17 December 2006 (EST)
[edit] Nunchuck Device ID.
The page entry says that the Nunchuck always reports its ID as 0x63. This is not true with the Wiimote and Nunchuck I have.
Using a variation of Cliff's RVL Enabler for OS X I echo all the data that comes in on the interrupt channel. I spent a few minutes plugging and unplugging the Nunchuck from the Wiimote. I've seen 0x5F, 0x60, 0x5E, and 0x5D. The value on the plugin and pull out don't always match.
The first two bytes are the button states.
- Actually this was the battery level! Nothing to do with identifying the attachment! It has been fixed now.
- I still haven't found the bitmask for the battery level information. Maybe you have? I do not actually plug or unplug anything, I sent 0x15 to request an status report. Do you know the bitmask for the battery level? Levia
[edit] Sequence for Enabling IR
I've noticed that there's a debate about whether to start by first setting 0x04b00030 to 0x01 and then setting it to 0x08 at the end. It is possible to set 0x04b00030 to 0x08 first (right after sending 0x04 to 0x13 and 0x1a); however, if you do this, you will need to make sure that you finish the rest of initialization really really fast. I assume this is because there is some delay between this register being set and the Wii remote actually starting to get IR data. If you finish writing the settings by the time the IR chip needs to get at the settings, then you're good; otherwise, it doesn't work at all. Testing with my Java library, it only worked about 25% of the time for me when I used the "0x08 first" method. When I started by setting it to 0x01 and then finished with 0x08, it worked every time. I think for the sake of clarity, we should remove the information regarding the "0x08 first" method, or at least explain what's going on.
--Cha0s 19:36, 16 February 2007 (EST)
[edit] Holding Wii's Sync Button Erases Wiimote Connections
If I hold down my Wii's red sync button for about 8 seconds, my Wiimote is disconnected from the Wii and the Wiimote will no longer autoconnect when I press a button, turn the Wii on with the power button, or connect when I press 1+2. If I press the Wii's red sync button, then the Wiimote's red sync button, the pair again and everything works like expected. What I find interesting is that, even if the Wiimote is off, and I reset the Wii's sync by holding down the Wii's sync button for 8 secs, I still can't turn the Wii on. That tells me that Wii will only turn on for Wiimotes that it has recorded. It should mean that the wiimote probably doesn't store a bluetooth address for the wii. I'd like to test this by trying to pair it with different Wiis and seeing if it 'forgets' about the old pairing. If so, then it stores the old Wii's info in the wiimote. If not, then the wiis store all the information.
Daemon 18:51, 2 April 2007 (EDT)
[edit] haptic instead of force feedback
here is the link to it he wikipedia article with the reason why I made the change [1] (edit: oops, sorry, I never realised I didn't signed, this wqas originally written by TiagoTiago
Sorry, but that's just ridiculous. No one has a clue what "haptic" means. The best approach would be to simply call it "vibration," as this is both correct and widely understood.
--Cha0s 18:05, 6 April 2007 (EDT)
If there are no objections within the next few days, I'm going to go ahead and change all references to "haptic feedback" to "vibration" or "rumble," so if you have objections, voice them here.
--Cha0s 21:54, 9 April 2007 (EDT)
I agree, the term haptic may be more scientifically accurate, but people understanding the text is more important. I think that the term "Force feedback" is the defacto standard for this and should be the term used on this wiki. But I do not mind one sentence like "also known as haptic feedback".--Henke37 07:33, 11 April 2007 (EDT)
Why not "vibration" or "rumble," the more colloquial terms? They are both accurate and well-recognized. --Cha0s 10:40, 17 April 2007 (EDT)
I like the idea of using "laymen terms" instead of (pseudo)scientific ones, and perhaps have a note about haptic feedback and if the need is percieved also mention that "force feedback" is sometimes wrongly used to refer to this kind of functionality--TiagoTiago 02:40, 4 May 2007 (EDT)
If we want to be scientificaly accurate, it is not haptic feedback nor is it force feedback, it is merely rumble. Both haptic- and force feedback implies it is trying to emulate another world. Rumble is just some vibrations, not any kind of detailed feedback.--Henke37 02:54, 4 May 2007 (EDT)
[edit] Input/Output Reports
After reading this article and trying around a little bit. I was really counfused about how to change what input report is used. I know you have to send a output report 0x12, but what is the contained Data? There should be a Payload of 2 Bytes, one of these bytes is the input report like 0x30, but what is the other byte? And which is which? The second thing what is unclear is, do you have to send the 0x12 report each time before you try to receive a input report or just once? If someone who understands that could make that clear, it would be great. --MrM 08:38, 15 April 2007 (EDT)
[edit] Extra bits
I'm starting to think that the acceleration data isn't only 8 bits per axis, but at least 9 and that the least significant bit of the acceleration data is stored in bits 6, 7, (14?) and 15 of the "button status bytes" explained above. This could explain:
- why these bits only contain values if a report is chosen that contains acceleration data
- why they change very often (errors of measurement seem to result in slight values even when the Wiimote is lying on a table, and this is the least significant bit)
- What the (not yet understood) fourth and the eighth byte of the calibration data stored in the flash memory means, since more than 8 bits of acceleration data per axis would require a fourth byte of calibration data for the 0G and 1G values. Maybe the meaning of these bits change when report 0x3E or 0x3F is used (like it says in the table above), but at least when using report 0x31 these bits contain data but they can't be bits 4-7 of the Z acceleration in that case, and my research suggests that they are the LSBs of the acceleration data. Someone else should have a look at this. Cadex 10:17, 31 December 2006 (EST)
- The bytes marked "unknown" in the callibrationdata are probably the 2 least significant bits of the zero/+1G-values for the three axes. The Wiimote seems to be capable of providing at least 9 bits of precision per axis (I suppose 10), and in this case the calibration data would probably include these bits as well. All values that I have seen so far for addresses 0x19 and 0x1D were below 0x40 - so only the 6 least significant bits seem to be used, which makes me suppose these are 2 extra bits per axis. Cadex 06:37, 19 January 2007 (EST)
[edit] marcan's info
Here are the reports you need to send to activate IR transmission:
(52) 12 00 33 (52) 13 04 (52) 1A 04 (52) 16 04 B0 00 30 01 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 (52) 16 04 B0 00 06 01 90 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 (52) 16 04 B0 00 08 01 C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 (52) 16 04 B0 00 1A 01 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 (52) 16 04 B0 00 33 01 33 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Python / pseudocode follows.
FEATURE_DISABLE = 0x00
FEATURE_ENABLE = 0x04
IR_MODE_OFF = 0
IR_MODE_STD = 1
IR_MODE_EXP = 3
IR_MODE_FULL = 5
CMD_SET_REPORT = 0x52
RID_LEDS = 0x11
RID_MODE = 0x12
RID_IR_EN = 0x13
RID_SPK_EN = 0x14
RID_STATUS = 0x15
RID_WMEM = 0x16
RID_RMEM = 0x17
RID_SPK = 0x18
RID_SPK_MUTE = 0x19
RID_IR_EN2 = 0x1A
MODE_BASIC = 0x30
MODE_ACC = 0x31
MODE_ACC_IR = 0x33
MODE_FULL = 0x3e
def send(cmd,report,data):
Send cmd, report, data to Wiimote. If cmd is CMD_SET_REPORT, this amounts to sending data to the specified report.
Interface code to Wiimote goes here.
def setmode(mode,cont):
aux = 0
if rmbl:
aux |= 0x01
if cont:
aux |= 0x04
send(CMD_SET_REPORT,RID_MODE,[aux,mode])
# size here is redundant, since we can just use len(data) if we want.
def senddata(data,offset,size): # see writing to data: [[#On-board Memory].
of1 = offset >> 24 & 0xFF #extract offset bytes
of2 = offset >> 16 & 0xFF
of3 = offset >> 8 & 0xFF
of4 = offset & 0xFF
data2 = data + [0]*(16-len(data)) # append zeros to pad data if less than 16 bytes
if len(data2) > 16:
data2 = data2[:16] # crop data if we have too much
# format is [OFFSET (BIGENDIAN),SIZE,DATA (16bytes)]
send(CMD_SET_REPORT,RID_WMEM,[of1,of2,of3,of4,size]+data2)
# this seems to be the minimal code to get it to work
setmode(MODE_ACC_IR,0)
send(CMD_SET_REPORT,RID_IR_EN,[FEATURE_ENABLE])
send(CMD_SET_REPORT,RID_IR_EN2,[FEATURE_ENABLE])
senddata([8],0x04B00030,1) # enable IR data out
senddata([0x90],0x04B00006,1) # sensitivity constants (guessed, Cliff seems to have more data, but this works for me)
senddata([0xC0],0x04B00008,1)
senddata([0x40],0x04B0001A,1)
senddata([IR_MODE_EXP],0x04B00033,1) # enable IR output with specified data format
# this is Cliff's version pythonified, probably more accurate as far as sensitivity. Works pretty much the same for me. setmode(MODE_ACC_IR,0) send(CMD_SET_REPORT,RID_IR_EN,[FEATURE_ENABLE]) send(CMD_SET_REPORT,RID_IR_EN2,[FEATURE_ENABLE]) senddata([1],0x04B00030,1) # seems to enable the IR peripheral senddata([0x02, 0x00, 0x00, 0x71, 0x01, 0x00, 0xaa, 0x00, 0x64],0x04B00000,9) senddata([0x63, 0x03],0x04B0001A,2) # this seems incorrect - for FULL IR mode, we must use FULL wiimote mode (0x3e). # otherwise the data is probably garbled. senddata([IR_MODE_FULL],0x04B00033,1) senddata([8],0x04B00030,1) # Enable data output. Can be specified first it seems, we don't really need to be in mode 1.
[edit] Cliff's info
Set the report 0x12 to a report number such as 0x33.
You need to start by setting reports 0x13 and 0x1a to 0x04 to enable transmission.
Then to activate the IR Sensor you need to write to the wiimote's memory. Set 0x04b00030 to 1, then set the sensitivity, then set 0x04b00033 to 5, then set 0x04b00030 to 8.
The sensitivity data is 9 bytes at 0x04b00000 and 2 bytes at 0x04b0001a. For midrange sensitivity, it's {0x02, 0x00, 0x00, 0x71, 0x01, 0x00, 0xaa, 0x00, 0x64}, and {0x63, 0x03}.
[edit] inio's info
The last byte of both blocks determines the intensity sensitivity, with increasing values reducing the sensitivity. The Wii Remote will return data for the dimmest objects possible when 0x04B00008 is 0x41, and 0x04B0001B is 0x00. <math>Insert formula here</math>
[edit] Bluetooth mac address
I think I remember having heard that the first three bytes of a bluetooth MAC address specify the manufacturer of the bluetooth device. This would mean that they are fixed values, and would explain why they aren't stored in the same place as the last three bytes. Cadex
[edit] Random Findings
Sending a byte to ID 0x15 returns the Extension status report (at 0x20, see above), besides setting rumble. Seems everything sets rumble if bit 0 of the first byte is set.
The third byte in the extension status report (00/02 above) can take other values. It seems only that bit is the status, other bits can take on other values depending on the bytes sent to 0x13 and 0x14. For example, sending 0x04 to ID 0x13 makes the values in byte 3 be 08/0a instead of 00/02.
By directly communicating with the Wiimote on the low level layer of L2CAP connections (using channels 0x11 (=output to the Wiimote) and 0x13 (=input from the Wiimote)) instead of using the higher level HID-layer, one can send command sequence "52 1A 00 ??" (0x52 = SET_REPORT, 0x1A = "IR sensor enable 2", 0x00, ?? = any byte value) to the Wiimote. "IR sensor enable 2" actually only has a 1 byte payload, but when a 2 byte payload is sent instead and the second byte is ??, then from that point on the Wiimote precedes all messages it sends with HID transaction header byte ?? instead of the usual 0xA1 (0xA1 = DATA_INPUT). This might be caused by a buffer overflow and might even prohibit proper communication of that Wiimote with the Wii, seeming like the Wiimote is broken (to be confirmed, I don't have a Wii yet so I can't try - See Talk:Wiimote for some more information on this). Removing and reinserting the batteries won't help, but normal behaviour can be restored by simply sending "52 1A 00 A1" which sets the normal value of 0xA1 again. Besides being a potential security problem (it's probably possible to send even more than only this 1 byte of additional data, so one might be able to change other stuff as well by sending even more data), this probably isn't of any help though.
It also seems to be possible to use HID command DATA_OUTPUT (0xA2) instead of SET_REPORT (0x52). for communication with the Wiimote, so sending sequence "(A2) 15 00" for example (0xA2 = DATA_OUTPUT, 0x15 = "Controller status", 0x00) is equivalent to using "(52) 15 00" (0x52 = SET_REPORT, 0x15 = "Controller status", 0x00).
[edit] Requests
- Can someone attempt to capture some of the communication that happens between the Wiimote and the Wii during synchronization? Using hcidump (from the bluez project) could be useful.
- Data regarding the Wii's bluetooth capabilities. Attempt to initiate a connection to the Wii acting like a Wiimote and see how it responds.
- Port to unix (for OS X) when linux driver is done
- Examine the Japanese WiinRemote software
[edit] Conflicting storage system on the flash
I just got a newsletter about Nintendo's golf game. One sentence in particular stood out: "Save your golfer on your Wii remote and show it off to your friends." This means the save data can be storaged on the Wiimote. With our current knowledge, this seems impossible, there is no such way to storage such data. If the newsletter is indeed true, I conclude there must be a filesystem of some kind on the Wiimote and we just have gotten lucky all the times we messed with the Miis.--Henke37 17:54, 5 June 2007 (EDT) Another note from the "Smash Bros. DOJO": "We’re also considering allowing you to save your name to the memory in your Wii Remote so you can bring your settings with you to your friend’s house..." This seems to futher support my theory that the wiimote might have some sort of file system.--henke37 07:10, 3 July 2007 (EDT)
[edit] Speaker audio format
[edit] ADPCM 4-bit Format Discussion
It's very well possible that the 4bit format is ADPCM encoded instead of plain PCM. ADPCM is quite popular in console-development.
- It seems that Wiimote has ROHM's ADPCM decoder LSI. Please see http://www.rohm.com/news/061107.html . demo-n
It's definitely ADPCM. Seems to be the Yamaha variant specifically. I'm using the following code to encode to ADPCM:
// Encode to ADPCM, on initialization set adpcm_prev_value to 0 and adpcm_step to 127, these
// variables must be preserved across reports
static const int index_table[16] = {-1, -1, -1, -1, 2, 4, 6, 8, -1, -1, -1, -1, 2, 4, 6, 8};
static const int diff_table[16] = {1, 3, 5, 7, 9, 11, 13, 15, -1, -3, -5, -7, -9, -11, -13, 15};
static const int step_scale[16] = {230, 230, 230, 230, 307, 409, 512, 614, 230, 230, 230, 230, 307, 409, 512, 614};
id->sound_next_cmd[0] = 0x18;
id->sound_next_cmd[1] = len << 2;
memset(&id->sound_next_cmd[2], 0, 20);
for (size_t i = 0; i < len; i++)
{
int value = (int)((short)(pcm_data[i] << 8)); // pcm_data is 8-bit signed char waveform
int diff = value - id->adpcm_prev_value;
unsigned char encoded_val = 0;
if (diff < 0)
{
encoded_val |= 8;
diff = -diff;
}
diff = (diff << 2) / id->adpcm_step;
if (diff > 7)
diff = 7;
encoded_val |= diff;
id->adpcm_prev_value += ((id->adpcm_step * diff_table[encoded_val]) / 8);
if (id->adpcm_prev_value > 0x7fff)
id->adpcm_prev_value = 0x7fff;
if (id->adpcm_prev_value < -0x8000)
id->adpcm_prev_value = -0x8000;
id->adpcm_step = (id->adpcm_step * step_scale[encoded_val]) >> 8;
if (id->adpcm_step < 127)
id->adpcm_step = 127;
if (id->adpcm_step > 24567)
id->adpcm_step = 24567;
if (i & 1)
id->sound_next_cmd[2 + (i >> 1)] |= encoded_val;
else
id->sound_next_cmd[2 + (i >> 1)] |= encoded_val << 4;
}
I'm still getting distortion, but I think it's just me not sending the reports at quite the right rate, as the only distortions are "pops". Someone should try this algorithm with their script to see if it works better. I have tested this will a couple Zelda remixes and some speech and it works reasonably well. RWagner
[edit] Various sound-playback research
But the 4-bit value doesn't behave quite the way I would expect. Repeating the same 4-bit value produces silence as one would expect. And alternating values such as 0xC and 0x3 produces a nice loud clear note. BUT changing it to 0xF and 0x0 makes it quieter, not louder. Perhaps it is a signed 4-bit number in twos-complement. But I don't know. I haven't worked it out yet.
- I haven't tested it yet, but when reading your description I thought it could be something like a PWM (Pulse-width modulation) Trooper 23:28, 11 April 2007 (EDT).
Here is a really bad sample recorded from the Wiimote by Marcan: [2]. Note that I have produced much better sound quality in individual notes, but haven't tried recorded samples.
Here is a GlovePIE script for producing sounds on the Wiimote: Speaker Script
- After a bit of testing I got the impression that bits 5-7 of the second byte of the initialization data (register 0x04A20002) specify the encoding of the sound data in some way. In particular, I suppose that writing value 0x40 to this register sets the sound data to 8 bit signed integers. Since (at the same sample rate) twice the amount of data must be sent to the Wiimote when using 8 bit instead of 4 bit, I had to increase the sample rate configuration value (thereby lowering the sample rate even more). Furthermore, this doesn't seem to be full truth: the music still sounded very distorted when I tried to play a piece of sampled music, but at least one could definitely tell that it should be music. Maybe someone else will find out more with this information. Cadex 04:24, 2 January 2007 (EST)
- I suggest to experiment with Logarithmic Sound Compression, as this has been used by Nintendo in the past. As the D/A converter specs are probably proprietary, this will come down to a trial and error process. Typically, for n bit samples, the n/2 high bits are used to select an intensity window corresponding to speaker amplitude on a logarythmic scale, while the remaining n/2 low bits subdivide the window in 2^(n/2) even parts. Reason being that fine sample granularities are more important towards the speakers resting position (quiet parts). Mostly this is joined with signed data. In which case only (n/2)-1 bits are used for amplitude window selection. Example for 8 bit: Bit 7: Sign Bit 6-4: Select one of 8 Windows, with 0 being used for small/weak amplitudes and 7 being very big/strong amplitudes. Bits 3 to 0: Sample/Amplitude in selected intensity window. soopahfly
[edit] What, no schematic(s) yet?
I did a quick search of this site, and the internet to try and find a schematic for the Wiimote. No such luck. I am sort of surprised that no one has tried to create one, and that there is no description of the Wiimotes physical board on here? (i.e. Double sided FR4, 4Layer FR4, etc...) I will be ripping mine apart to generate such information over the next few weeks, unless someone wants to save me the time and post a site or information regarding this. Jibberish
- I did find this actually, which is a pretty descent introduction to the innards of the device. Still no schematics yet, but given that the Broadcom chip is a BGA device, it would be hard to trace all of it's connections without lifting the chip. http://www.sparkfun.com/commerce/present.php?p=Wii-Internals Jibberish
- While you are doing this, maybe you can do the same thing for the main Wii?--henke37 06:53, 14 December 2007 (EST)
- I can be without a Wiimote for a while, but I cannot be without a Wii; as I am sure you can understand. :) I might consider doing this eventually with my Wii, but not for a while. Although I will agree that it is equally important to do this with the main console as well.Jibberish
- Update: I have taken some pictures of the board/parts, but haven't done anything else yet. I will post more complete information when I have it. --Jibberish 10:17, 18 December 2007 (EST)
[edit] Possible information for the BCM2042
Looky Looky what I found. Here is a nice demo board for the Broadcom BCM2042. It has a nice listing of the pinouts and such, and you can map the breakout pins on the side to the BGA via's on the underside. Not exactly the "true" datasheet by anymeans, but it has a whole lot of information regarding the chips I/O's. The one that sparks my interest is pin 35, "Debug UART receiver port. After power on reset, if UP RX=1, firmware download mode, UP RX=0, normal mode". Could be interesting? http://www.bluepacket.net/doc/BP20422.PDF --Jibberish 10:18, 18 December 2007 (EST)
[edit] IR camera details
Wasn't sure where to put this...
I did some experimenting and came up with the following, the IR camera appears to have a total horizontal field of 45deg and a total vertical field of 35deg. However it has problems locking around the edge so the reliably usable field is somewhat smaller. The horizontal data values come back in the range 0-1015 and 0-760 for the vertical, this works out as about 22pixels per degree. Testing shows that this relationship is pretty much constant across the ranges.
So everyone is clear on possible sources of error, this is my method. First I got the ranges by waving the Wiimote around for a while and recording the max and min values. Then I placed the Wiimote at increasing distances from the sensor bar (I was working in the 30cm - 90cm range) and recorded the two X offsets. I measured vertical in the same way but with the Wiimote on it's side. I then assumed that the light sources on the sensor bar were approximately 20cm's apart (really need to redo it with a custom sensor bar with a single led at each end). From there it's simple trig to work out the apparent angle between the lights given the range (2xtan(10cm/range)). Then if we take the pixel gap between the readings and divide by the angle we get numbers in the 21-22 range increasing slightly as the range increases, since you would normally have the Wiimote more than 90cms away I took the 22 figure.
[edit] "Unreadable" IR Camera Config Registers
The main page documents the IR Camera registers (the ones beginning at 0x04B00000) as returning an error, however I have found this to be incorrect.
Initially, this will be the case. However, if a report that includes IR data is selected, reads from this address will happily return the last-written sensitivity data:
0x04B00000: 02 00 00 71 01 00 AA 00 64 28 50 20 40 01 01 7F 0x04B00010: 04 00 80 60 10 00 00 0A 34 00 63 03 64 42 00 07 0x04B00020: 00 02 67 10 DC F0 04 00 03 00 00 32 12 04 14 00 0x04B00030: 08 00 00 03 00 00 00 FF FF FF FF FF FF FF FF FF 0x04B00040: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 0x04B00050: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 0x04B00060: FF FF FF FF
(Data pulled using wmgui)
