NXT wii NunChuck interface with NXC

[mattallen37]

I bought two non-OEM nunchucks to try to interface with the NXT. However, so for no go. I removed the pullups, and have 47k pullups (on the NXT end of the cable). I also have diodes to drop the voltage (Xander, I measured before connecting this one ). I am trying to get this program to work:

Code: Select all

byte CMDNunchukInit[] = {0xA4, 0x40, 0x00};
byte CMDNunchukWrite[] = {0xA4, 0x00};
byte CMDNunchukRead[] = {0xA4};

byte outbuf[];
byte count = 6;
byte nByteReady;

task main()
{
  SetSensorLowspeed(S1);
  while (true)
  {
    while (I2CStatus(S1, nByteReady) ==  STAT_COMM_PENDING); //Wait until bus is free
    I2CWrite(S1, 0, CMDNunchukInit);                         //When the I2C bus is ready, send message

    while (I2CStatus(S1, nByteReady) ==  STAT_COMM_PENDING); //Wait until bus is free
    I2CWrite(S1, 0, CMDNunchukWrite);                        //When the I2C bus is ready, send message

    while (I2CStatus(S1, nByteReady) ==  STAT_COMM_PENDING); //Wait until bus is free
    I2CBytes(S1, CMDNunchukRead, count, outbuf)              //Read the registers

    if (ArrayLen(outbuf)==count) {
      ClearScreen();
      for(int i=0; i<ArrayLen(outbuf); i++ ) {
        NumOut(0, LCD_LINE2-(i*8), outbuf[i]);
      }
    }
    Wait(100);
  }
}

The code is based off of one that I have seen floating around on the web for a while. However, I have almost completely rewritten it.

It always displays (returns) 255 (0xFF) for all six bytes.

It doesn't work at all if I do either of the following:

• switch the serial lines (I don't have them mixed up).
  Remove either or both of the pullups.

It doesn't make any difference to have the supply voltage 2.9v, or 3.5v. It also doesn't make a difference to have the pullups 10k, 33k, 47k, 100k, or 470k.

I am sure the nunchuck is sending some sort of data, but it sure doesn't seem to be anything other than 0xFF.

Any ideas?

Any code you know works that you want to share?

Could someone with a working NXTified nunchuck please try my code, and tell my what happens?

[hergipotter]

This is my Nunchuk Test Code that i've written some time ago and which is based on the code from sparramc (https://sourceforge.net/apps/phpbb/mind ... 283&p=2383) :

Code: Select all

#define PORT S4

byte CMDNunchukInit[] = {0xA4, 0x40, 0x00};
byte CMDNunchukWrite[] = {0xA4, 0x00};
byte CMDNunchukRead[] = {0xA4};

byte nbytes;
byte outbuf[];

void readNunchuk()
{
   LowspeedWrite(PORT, 0, CMDNunchukInit); //ask for 0 bytes
   while(LowspeedStatus(PORT, nbytes)>0);

   LowspeedWrite(PORT, 0, CMDNunchukWrite);   // write Nunchuk register address
   while(LowspeedStatus(PORT, nbytes)>0);


   LowspeedWrite(PORT, 6, CMDNunchukRead); //ask for count bytes
   while(LowspeedStatus(PORT, nbytes)>0);

   if(nbytes == 6){
      LowspeedRead(PORT, 6, outbuf)  //read data from buffer
      for(int i=0; i<6; i++ ){
         outbuf[i]=(outbuf[i]^0x17) + 0x17;
      }
   }
   else {
      ArrayInit(outbuf,0,0);    //error
   }
}

task main()
{
   SetSensorLowspeed(PORT);

   while (true)
   {

      readNunchuk();
      if (ArrayLen(outbuf)==6) {
          string Nunchuk="aXaYgXgYgZCZ";
          if ((outbuf[5]&0x01)!=0) {Nunchuk[11]=122;}  //Show Z-Button
          if ((outbuf[5]&0x02)!=0) {Nunchuk[10]=99;}   //Show C-Button
          ClearScreen();
          for(int i=0; i<ArrayLen(outbuf); i++ ) {
            TextOut(15*i, LCD_LINE3, SubStr(Nunchuk, 2*i, 2));
            TextOut(15*i, LCD_LINE5, FormatNum("%02X", outbuf[i]));  //hex: enhanced firmware
            //NumOut(15*i, LCD_LINE5, outbuf[i]);  //dez: lego firmware
          }
          CircleOut((outbuf[0]-0x1E)/2, (outbuf[1]-0x1E)/3, 3);    //analog stick
          RectOut((outbuf[2]-0x46), (outbuf[3]-0x46)/2, 6, 6);    //acceleration value
    }
    //Wait(1);
   }
}

I think the main difference is, that you have these while-statements before your write-commands, while mine are after them. I have to admit, that i don't really know what they do, but my code works

Sadly i can't test your code right now because i'm not at home, but maybe i can do it this evening.

Another thing i've noticed with your code, the bytes you'll receive are "encrypted" (http://wiki.wiimoteproject.com/Extensions#Encryption) so you have to decrypt them by doing

Code: Select all

for(int i=0; i<6; i++ ){
         outbuf[i]=(outbuf[i]^0x17) + 0x17;
      }

But first of course you have to get proper readings.

[pbenco]

hello mattalen37
non OEM nunchucks have their own way to deal with data protocole, you can find informations here:http://wiibrew.org/wiki/Wiimote/Extension_Controllers, find

Wireless Nunchuks

It looks like third-party Wireless Nunchuks operate differently than the original Nunchuk-Extension. Anyone have a clue?
Nyko Kama

The Nyko Kama is just a simple wireless Nunchuk, with a Sync and Power button. It uses two AAA batteries.

The Nyko Kama does not work with current homebrew or PC Wiimote software. It is unknown how to make it work.

I was able to initialize the Kama and get data from it. My procedure is as follows: Write 0x55 to a400f0, write 0x00 to a400fb; then set up the encryption key (without it, the Nunchuk doesn't work) at a40040 (16 bytes). As a last step, set Data Reporting Mode to 0x37 (my Kama does not work when I set Data Reporting Mode prior to setting up the registers).
This way, buttons are reported correctly, but the joystick values seem to be wrong. Do I need to decrypt the values? The original Nunchuk still works with this altered initialization sequence (unencrypted!).--Andyboeh 23:45, 19 April 2009 (UTC)

Snakebyte Wireless Motion XS

Snakebyte is a German company that makes 3rd party Wii Remotes, Nunchuks, Classic Controllers, and Sensor Bars.

On the Discussion page, the user "Grid" supplied the following information: (Abridged. Spelling and grammar have been corrected.)

"I am using a wireless Nunchuk controller by some third party company (Snakebyte), 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 from the Nunchuk. I've got no idea, my Wii accepts the wireless Nunchuk without any problem.

I don't see any problem with any Wii game. Some WiiMote libs, which support the original Nunchuk perfectly, toggle between "nothing inserted" and "partially inserted" when the wireless Nunchuk is plugged in. Also no Data is streamed from the Nunchuk. It's extremely strange!!!! I've got no clue!

I'm still trying to run a Wireless Nunchuk. One problem is that the address areas where the calibration data is normally stored is write-only on the wireless Nunchuks. But the weird thing about this wireless Nunchuk from Snakebyte [1] is that I got no response at all until I played Metroid Prime 3 or Zelda with it. I am not kidding!!! After playing one of these games, I get all the data, only without the calibration, so I can't really use the data because I don't know how to calibrate the accelerometers and the joystick."

That appears to be similar behaviour to what I observed with the Datel Blade-FX as documented below. It returns 0xFF 0xFF as the extension type, but then when you try to read the calibration data it disconnects and then reconnects later, thus producing the observed "toggle between "nothing inserted" and "partially inserted" when the wireless Nunchuk is plugged in". CarlKenner 04:20, 28 November 2008 (UTC)
Datel Blade-FX

This wireless Nunchuk can emulate either a Nunchuk or a Classic Controller. At startup it behaves like a Nunchuk, but pressing the "Classic" button puts it into Classic Controller mode. While in Classic Controller mode, the FUNCTION LED will be solidly lit (red). Classic controller emulation allows it to be used in the Wii system menu, with the joystick controlling the cursor, and the Z button selecting, and the C button having no visible effect. It also allows it to work (according to the instructions) with some Virtual Console games.

This wireless Nunchuk also has a cheat feature that remembers a motion that you do and repeats it continuously without you having to keep doing the motion. That is done with the "FX" button.

There is also a "SYNC" button where the cord would be. Pressing it once connects the wireless nunchuk. While connected, the STATUS LED will slowly flash.

When the wireless adapter is plugged in, but the wireless nunchuk has not been synced or turned on, then it behaves as though nothing was plugged in. No status report is generated when the wireless adapter is plugged in or unplugged, unless the nunchuk is synced. Querying the status report returns 0 for the extension flag (instead of 2).

But when the wireless nunchuk is synced, then it sends a status report indicating that an extension is connected. Trying to read the 16 bytes from 0xF0 of the expansion (to identify the expansion) successfully returns "FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF", which isn't particularly helpful. Trying to read any 16 byte block has the same effect, it returns success, but it is all FFs.

BUT... trying to read the calibration data from 0x20 or 0x30 (although it still returns success as above) causes the Nunchuk to disconnect, sending a status report to indicate no extension is plugged in. It will automatically reconnect 0.5 seconds later. While disconnected, attempting to read from the Nunchuk returns error 7.

Expansion data (in the input reports that include expansion data) is all 0xFF, just like trying to read the Nunchuk memory.

As soon as the "Classic" button is pressed, a status message is sent saying that the extension has been unplugged. It will stay "unplugged" until the status button is released again, however long they hold down the button for. Once the "Classic" button has been released, it will wait about half a second and then send a status message saying the extension has been plugged in again. If the Classic button is pressed twice before it sent the released message, then it may send another disconnect and connect message after the connect message. It is not currently possible to tell whether it is in Classic Controller or Nunchuk mode. But we can use this method to read when the "Classic" button is held down (although it will always look like it was held down longer than it really was).

Actually unplugging the adapter will give the same disconnect message, so after a few seconds one should assume that they did a real disconnect instead of holding down the "Classic" button. In one case, after unplugging and replugging the adapter, the BladeFX started returning all 00 instead of FF when reading the expansion type from 0xF0. The data returned from report 0x34 also had 00 00 00 as the last 3 extension bytes, even though the first 16 (starting from 0x08 in extension memory) were all FF. Trying to read the calibration from 0x20 still returned all 0xFF and then disconnected as usual. Pressing buttons on the BladeFX had no effect on the data returned in report 0x34. I have not done any additional experiments with this state yet.

Clearly the current method of turning on an expansion doesn't work for the Datel Blade-FX, and we need some way to turn it on. Perhaps then the calibration can be read without an error, and we can get real data.

It is not yet known how to make the Datel Blade-FX work, although it can be detected when it is synced, due to its strange behaviour, and the "Classic" button can be read. Nothing else is readable yet.

CarlKenner 03:50, 28 November 2008 (UTC)
Datel Wireless Duo-FX

Using the standard initalization sequence, this nunchuck does not work. However, it works perfectly well with the sequence posted above for the Nyko Kama. The data is streamed unencrypted and the Datel can be fully read. However, the Nunchuk must be synced before initalizing the Extension Controller, otherwise, strange errors occur. For now, simply repeat the initialization sequence. After some tries, the Nunchuk works correctly (can be up to 10). "

So, non OEM nunchuck behave strangely in protocole point of view, so you have to adapt the code you used, which has been design for OEM nonchuk, to fullfil the non OEM protocole. A question is, how the Wii and games retrieve the right infos???
Hope this help
Ben

[hergipotter]

I think there's only a problem with wireless non OEM nunchuks, isn't it?

[nxtreme]

I think it could also be a problem for wired non-OEM Nunchuks. I have a wired Nyko Kama, and was never able to get it working with the basic "this should work" code. You might find this page of interest, even if you've stumbled upon it before.

[mattallen37]

Mine is a wired one, not wireless. How would I find info on how to use it with the NXT? The only thing it responds with is 0xFF, and doing/not-doing the initialization process doesn't seem to make any difference. Does that mean my initialization process is wrong? Any ideas how to make it right?

[hergipotter]

Ok bad news for you mattallen ^^
I've just tested your code with my original nintendo nunchuk and it works flawlessly...

But i dont really understand why non oem nunchuks can have a different interface than oem ones. How does the Wiimote know that theres a original or non-oem one connected?


edit: Seems like there are some timing issues with non oem nunchuks:

One other thing, I did try the code on a Non-Nintendo Nunchuk I have and it just gave me max values for all the data.
I have read there are minor differences that prevent some aftermarket hardware from working the same. My guess is it has something to do with either the I2C speed or the delay between certain stages of communication. For the OEM Nunchuks I changed the I2C speed from 400kHz to 300kHz and had to add a 500us delay at one spot to get them to work reliably. So if you have a non-OEM nunchuk that doesn't work with the code, try poking in some delays or changing the I2C speed. That may or may not get it working, but that's the fun part... figuring it all out!

http://www.nerdkits.com/forum/thread/972/

[sparramc]

Hi,

This link may be of some interest/help to you Matt? I used a cheap Chinese Clone which works well....

nxt-nunchuk-mindstorms-nxt-sensor/

[mattallen37]

Yea, I saw that. Unfortunately, it seems to be a program (initialization) issue for my specific HW. My program has been confirmed to work with an OEM nunchuck.

[afanofosc]

It always displays (returns) 255 (0xFF) for all six bytes.

The original NXC Wii Nunchuck code set the sensor type and mode every time it read from the device. When I posted saying that it probably only needs to be done once the response I got said that moving that bit of code out of the function that read the data made it stop working. Perhaps you could try moving your SetSensorLowspeed call inside your while loop?

Does Robert's code also return all 0xFF's with your hardware?

Also, I added the LowspeedWriteEx function and the corresponding firmware changes based on the original wii nunchuck thread on the nxtasy forums. Perhaps using it instead of LowspeedWrite (aka I2CWrite) it might change the way your hardware responds?

John Hansen