Talk:Wiimote/Extension Controllers

Wireless Nunchuks

I am using a Wireless - Nunchuk Controller by some Third Party company, and I was trying many, many times to get the wireless nunchuk running on any Lib out there. But anytime I plug it into my WiiMote my Application slows down and I don't get any response form the Nunchuk. I got no Idea, my Wii accept the Wireless - Nunchuk without any Problem.

Is there really such a big difference between the Wireless and the original Nunchuk ?

In terms of operation, there should be no difference. If there were a difference then games that require the nunchuk would not work unless they were hardcoded with explicit support for the new expansion type. My first thought would be to check to see if it's slow in any Wii games. If it's not then that's strange; if it is then the nunchuk must be doing something internally with the wiimote that it probably shouldn't be doing. This response was probably no help to you, but the bottom line is if it's slow the root cause is most likely in the way the receiver device is interacting with the wiimote internally. -- Para 12:18, 29 May 2008 (PDT)

No, I don't see any problem with any Wii-Game. Some WiiMote Lib's, which supporting the original Nunchuk perfectly, toggle between Nothing inserted and Partially inserted when Wireless Nunchuk pluged in and no Data is streamed from the Nunchuk. Its extrem strange!!!! I got no glue !

Hi, I'm still trying to run a Wireless Nunchuk. One problem is that the address areas where the calibration data normaly stored is for write-only on the wireless nunchuks. But the weird thing about this wireless nunchuk from snakebyte [1] is that I get no response at all until I played MetroidPrime3 or Zelda with it. I am not kidding !!! After playing one of this Games I get all Data only without the Calibration, so I can't really use the data because I don't know how to Calibrate the Accs and the Joystick.

I would render a guess that the wireless nunchuck is designed to respond to the series of reports sent to the wiimote by official games, and that homebrew libs aren't doing things in exactly the same order, so something isn't quite working right. In any case, are we able to read actual input from them, and just not calibration data? In this case, it might be possible to provide limited support, especially if it were just for the analog joystick and the buttons. (I don't know of any homebrew that uses the nunchuck's motion sensing.) --Thegamefreak0134 05:40, 7 January 2009 (UTC)

(Moved to new topic below) -- death_au

– I thought so to when I got this behavior in Wiiuse, 0x20-0x40 was 0xff (I have a Logic3 Wireless Nunchuck). But when I try it in the Dolphin emulator with real Wii games I see the same problem, it actually sends the Wii game 0xff for 0x20-0x40. However it still works, probably because Wii games ignore bad calibration values (unlike Wiiuse 0.12 which I had to manually give my actual Nunchuck calibration values before the nunchuck_event() function worked). My nunchuck neutral values are close to

Stick calibration: X:0x7d Y:0x7e and Accelerometer: X:0x7b Y:0x86 Z:0xb5

(The reason X and Y are different, 0x7b and 0x86, may be that I didn't hold the Nunchuck correctly horizontal). If there is a default value in the Wii SDK that all games use it could be plausable that it never sends any calibration data ever, even in normal circumstances. It seems unlikely however, I would want to confirm that it behaves the same way on the real hardware and with regular games before I'm certain that it actually doesn't tell the Wii about its neutral values and calibration. -- John Peterson 01:33, 6 February 2009 (UTC)

Tilt Sensor

Does the guitar have a separate tilt sensor, or do they use the Wii Remote accelerometer? inio 13:57, 2 March 2008 (PST)

It does not have an accelerometer. The guitar is very similar in operation to the classic controller with a couple major differences: (1) obviously it's in a guitar-like housing, (2) it does not have any calibration data (at least it would appear not to) which is necessary to accurately use with whammy bar and joystick, and (3) it has two bytes changed for its unique device identifier. -- Para 07:17, 13 March 2008 (PDT)

Wii Motion Plus

I'd imagine that this would get its own page once it's released and we know more information about it.

I suppose we can calculate orientation data on the motion plus by correcting the drift with data from the accelerometers. Correct me if I'm wrong, but when the accelerometers are reporting a net force from all three sensors that roughly equals real gravity, this would indicate that no additional force is being applied to the wiimote. In these instances, the values read could be used to "snapshot" the current orientation of the wiimote, or at least as much as we can tell using the accelerometers. You would then be able to use this information to correct any disagreements between the accelerometers and the gyro sensors.

Assuming one of the sensors detects yaw, it makes sense for the other sensor to detect roll, not pitch. I say this because of the way I've seen the wiimote used in games like raving rabbids. It seems more common to ask the player to put the wiimote in a vertical position, which makes it impossible to measure roll using the accelerometers. (for instance, if you were holding the wiimote straight over your head, the game would be unable to detect a twisting motion made with your hand.) The position of the wiimote that makes it unable to detect pitch is more commonly seen in driving games. In this position, pitch is less important and yaw has the emphasis (but then again yaw is easily calculated from the accelerometers in these cases.) In fact, I think it would be rather weird to play a game requiring me to twist the wiimote left and right while driving, although this would allow for a bit of flexibility in that it would be able to detect when the player had turned in their chair. Why asking the player to face away from the TV screen during a *video* game makes sense is beyond me, but who knows.

The issue that comes to mind for me is how to calibrate the yaw sensor to the front of the TV. I guess when the wiimote is flat you could calibrate it based on when the sensor bar came into view, but I'm not sure I can see this working for all orientations, or working for a long time with games that don't require the sensor bar. Perhaps the gyro sensors won't produce enough drift to actually make this an issue, so that a game could reasonably calibrate one time during a menu sequence, and then not ever again for the duration of play. This may be even less important if the game uses more gesture recognition than actual direct motion sensing, as gesture recognition doesn't need an accurate measurement. Still, the prospect of a true sword-fighting game for Wii (which I'm surprised hasn't happened yet) still makes me wonder how this attachment is going to be put to use. --Thegamefreak0134 05:40, 7 January 2009 (UTC)

When will the wiimote or the game change the slow or fast of the yaw/pitch/roll? Or what data send from wiimote indicate i should send fast or slow data collected from analog output of gyro sensor. Does the adc resolution of the mcu used in motion plus is 14bit?Thanks! chris —Preceding unsigned comment added by Cgha (talk • contribs) 03:12, 29 June 2009 (UTC)

WMP Nunchuck passthrough mode

Where is the zero to be sent? WMP Init addres? A special report number? I'm working on adding passthrough mode on the WiiYourself! lib, the sooner I get the passthrough part done, the sooner I can get to work on a gesture recog lib.

--Freezy 13:12, 3 August 2010 (UTC)

Answer: the zero is not required for the lib I am using (wiiyourself). The issue was caused by faulty initialisation.

--Freezy 14:45, 16 August 2010 (UTC)

Guitar Hero: World Tour instruments

The issue with wireless Nunchucks seems similar if not identical to the issues with Guitar Hero: World Tour instruments. Personally, I've been trying to get the World Tour extensions to connect to a PC, as opposed to Wii Homebrew, but working out how it is they connect could be beneficial for both. We haven't got much so far, but there were some I/O logs (created with USBTrace) posted here: [2]. Also in that same thread were logs that were created when the controllers were connected to the actual game (running in dolphin, I believe). Hopefully posting this here will give more chance of people seeing it and (fingers crossed) knowing what to do with it. -- death_au

The thread linked above now has a lot more information on it. World tour instruments can now be initialised and a fair portion of the input can be interpreted. -- death_au

I tried this new initialization (also found in the latest libogc) on my Guitar Hero Metallica controller, and it didn't work. The Metallica controller looks the same as a World Tour guitar, but I don't have a WT guitar so I cannot test that one. --Daid 12:24, 4 June 2009 (UTC)

Ok, got it. All the calibration data for a Metallica Guitar is 0xFF, and then libWiiUse sees this as a fault condition in which it retries to get the calibration data. A quick patch in the guitar_hero_3_handshake function solves this. --Daid 22:31, 5 June 2009 (UTC)

Motion Plus Passthrough Motion Plus

What do we know about how the remote reacts to 2 WMPs? Would it not work because they both want to use the same Addresses? Also, what about hard-wiring a Motion Plus/Nunchuck to a Balance Board? Xnamkcor 23:44, 5 December 2010 (CET)

Changing the I2C Address for the Nunchuck

Is it possible to change the I2C address for the Nunchuck so that the WM+ and Nunchuck can exist on the same I2C bus without the passhtrough or supporting hardware? Thank you. —Preceding unsigned comment added by Reverendrichie (talk • contribs) 15:01, 15 January 2011 (CET)

Voltage

can't input this decently on the page, so will just add as a note here: with nothing else happening (no clue if there's a way to control it via the protocol) voltage on the connector is 3.2VDC —Preceding unsigned comment added by Gcb (talk • contribs) 05:20, 27 May 2012 (CEST

More info about protocol

Nintendo's code of their controller driver for NES/SNES Classic is open source: https://www.nintendo.co.jp/support/oss/index.html

So seems like only byte at address 0xFF is code of accessory type and byte at 0xFE is data format. And it's possible to select data format since address 0xFE is writable on some controllers. So nunchak supports only data format 0x00 and classic controller supports data formats 0x01 (described on this wiki), 0x02 and 0x03. NES/SNES Classic uses 0x03. Many early 3rd party classic controller clones supports only 0x01, that's why they are not supported on NES/SNES classic without driver modification.

There is source code of my modified driver that only tries to change data format to 0x03 and supports both 0x01 and 0x03: https://github.com/ClusterM/hakchi2/blob/stable/clovercon/clovercon.c

There is source code of my device which imitates classic controller: https://github.com/ClusterM/nes2wii --Cluster (talk) 18:56, 22 September 2018 (CEST)