Arduino as Wiimote-Expansion

Hi,
I'm trying to use the arduino as an expansion for the wiimote. For starters I want to emulate a Nunchuk on a Arduino mega.
So to get things going I

  1. Accessed the Nunchuck directly from the Arduino. Thats a fairly basic task and worked out of the box.
    Connect the Nunchuck (Nintendo original wired) via I2C.
    Setup Communication via slave address 0x52 and everything works.
    I confirmed the encrypted com using
    0x40:0x00 and the well known 0x17 decoding function.
    Additionaly I tried encryptenless com via
    0xF0:0x55, 0XFB:0x00 which also worked, though I still dont quite understand what the second write is supposed to do. The nunchuck does behave exactly the same without this step and I cant find any difference the registers.

  2. I used the wiiuse-library on my pc to access the wiimote and simulated a nunchuk on my arduino.
    The library uses encrypted com. and after a few tries I succeeded in sending calibration data and the 6-byte buttonstates. So i can emulate a nunchuk on the arduino, and use it on a wiimote that is governed by a pc running wiiuse.

  3. So far so nice, but now its getting complicated. The final step is to emulate a nunchuk while the corresponding Wiimote is used for playing a wii game.
    The handshake with the
    0xF0:0x55, 0xFB:0x00, 0xFA routine from the wii.
    This should equal
    "deactivate encryption, move pointer to 0xFA where the ident-code starts" and then there should be a data request.
    But there aint one. The wii(mote) does not seem to request the data, or the call gets lost somewhere.
    It all works fine when using the wiiuse-library on my pc instead of connecting to the wii. But if I do the later, the callback where the data is sent to the wiimote does not get called. Not even once.
    I could understand problems due to worng implementation of the protocol, but since I dotn even send one byte to the wii, that cant be the case, right?

So my last idea is "something about timing", like the interrupt never gets called.
Via serial-output I confirmed that the handshake is repeated about 30 times. The receive-callback hits everytime but there never seems to be a data request.
Any ideas?

Hi sevensuns,

Ron Scharf did a capture of the communication between a real nunchuck and wiimote. Here you can find the annotated capture http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1259091426/113#109

In this capture you can see the read request after setting the register pointer to 0xFA and the exact timing of the request.

Maybe you do too much debugging output via Serial.print, so the timing is wrong?

MikeT

Hi there.
Yes I used this capture to check the behaviour of my wii.
I did not digg that much into the wire library of the arduino. Could the the request-callback get completely lost, if the receive-callback takes to much time?
Since the receive-callback ist hit first, theoretically the prints could delay the handling of the request-callback afterwards. (Not sure if thats possible)
Any delay inside the request-callback should still allow me to get it called once.

I reduced both callbacks to the point of just incrementing counters and printed the values from the main loop. The receive-callback got hit 99 times (33 times the full handshake) and the request-callback not even once. But I'll give it another try while looking deeper into the twi lib.

I noticed sth else. The Values are not communciated exactly as "F0" "FB" and "FA".
Printing them via Serial gives me "FFFFF0", "FFFFFB" and "FFFFFA" as the address . I first thought it was just a problem of interpretation over the serial connection, but I doublechecked and this only occurs with the real wii.
Could this be a hint that the twi-timing is off? (frequency ...)
That might also effect the communication of request notification.
(What else could be the reason that printing the address byte gets me 3 printed instead of one?)

Hi,

seeing FFFFF0 instead of F0 could be a sign-extension problem, but then you should see either FFFFFFF0 (32 bit) or FFF0 (16 bit), but not a 24-bit integer. The reason is, that the numbers are interpreted as signed integers depending on the datatype and 0xF0 (8-Bit) =-16 whereas 0xFFFFFFF0 (32-bit) is also -16.

MikeT