Datel Nunchuk throws an exception

This is the Datel Blade FX Nunchuk: MSN Shopping Wii Hardware

It does not work with the WiimoteLib and throws the exception: "Error reading data from Wiimote: Attempt to read from write-only registers."

Is there a workaround (or a solution) to this?

Others have reported issues with this controller as well.  I don't own one to test the library with it, so I don't have much information.  It appears that this controller doesn't follow the "standard" (though who knows that the standard really is) that the rest of the Wiimote controllers do.

The source for WiimoteLib is freely available, so if you have the time to dig in and determine what exactly is failing and when, perhaps we can work through it and get it fixed.  Or if someone can send me a controller for some testing, I could try to get it going.

 

Brian Peek:

Others have reported issues with this controller as well.  I don't own one to test the library with it, so I don't have much information.  It appears that this controller doesn't follow the "standard" (though who knows that the standard really is) that the rest of the Wiimote controllers do.

The source for WiimoteLib is freely available, so if you have the time to dig in and determine what exactly is failing and when, perhaps we can work through it and get it fixed.  Or if someone can send me a controller for some testing, I could try to get it going.

Yeah, I have been working through it to find something. Not going too well, but I'm still trying.

 

On another note how do you keep the buffer as a string of bytes rather than a string from bytes? (I hope that made some sense)

If you figure anything out, please let me know.

As for your question, I'm not sure I understand...

 It's okay thanks, I no longer need it.

@woody993

Version 1.7 *may* get that Nyko nunchuk working...

 Well it doesn't throw that exception, but the values are all over the place. In saying that, is the there a way to read the entire buffer?

Damn!

You can get at the data buffer by throwing in some Debug.WriteLine's in the ParseExtension method.  There's nothing in the test app/lib itself to get the data out though...

I was really hoping it would work with this fix.  :(

Hi Just to let you know that I have just had some joy with the Logic3 nunchuck and version 1.7 of the lib. You must start with the chuck turned off then once everything has been initialised hit the fc paring button and your all systems go.

The lib views the chuck as the unknown device: a42000000, thus, in order to get it working at this initial stage I have added the following hack/clause to the ExtensionType case poll:

if (type.ToString("x") == "a420000000") {
mWiimoteState.ExtensionType = ExtensionType.Nunchuk; }
else { throw new WiimoteException("Unknown extension controller found: " + type.ToString("x"));  }

An interesting detail at this point is that only the "raw" values are obtainable for both stick and accelerometer data, any Ideas?

I was wondering if this was the case with other chucks too. Are they in fact working but only detailing raw data.

I am planning to add the device to the lib as an extension type, are there any useful pointers to help me on my way.

Hello again. I have just tired again with the intec chuck, as before it seems to work ok, however this time the values data is also obtainable as well as the raw data.

So congrats Brian, as far as I can see the mod’s implemented within latest version seems to handle some wireless chucks ok.

Could someone attempt the hack with the Datel chuck and try to output just the raw data?

I may have made a bit of a piratical error that affected the testing of the origional Logic3 Freebird Thumbstick.

Since I first posted about my findings I have tested several additional sticks. The first being the intec chuck. As stated Unlike the logic3 stick the values data stream was unaffected.

This is also the case with the Logic3 Freebird Nunchuck Adapter. My guess is at this point that I have been using the adapter receiver for the thumbstick test (I seem to have one missing, humm). This may have caused the strange no values result.

I rushed straight in to implementing wireless chucks into my wiindows, wiimoteLib application, and was done in about 10 min's.

First of all you need to add the id definition to the ExtensionType enumeration within DataTypes.cs. I did this just below the Nunchuck definition as follows:

/// <summary>
/// Wireless extension
/// </summary>
Wireless             = 0x000000a420000000,

If you want your wireless devices to be seen as standard chucks within your application(s) then all you need to do next is add the following case within the InitializeExtension() function inside Wiimote.cs:

case ExtensionType.Wireless:
mWiimoteState.ExtensionType = ExtensionType.Nunchuk;
Console.WriteLine("wireless detected");
break;

However if like me you would like to display as a different extension type within your application then just add the Wireless case between the Nunchuck and ClassicController, to give the following:

case ExtensionType.Nunchuk:
case ExtensionType.Wireless:
case ExtensionType.ClassicController:
case ExtensionType.Guitar:
case ExtensionType.BalanceBoard:

With this done all you need to do is expand the ExtensionType cases within Wiimote.cs so that they read as Nunchuck or Wireless as follows:

case ExtensionType.Nunchuk:
case ExtensionType.Wireless:

So there you have it, working wireless Nunchucks. An interesting point to note is that so far the Logic3 adapter seems to give the best results. I say this as it is the only one that works inserted from application start up. Also I have not had to re-pair the device.

I will test the Thumbstick again as soon as I have tracked down the missing receiver.

Hope this is of some help to some folks.

Hello again... 

I'm surprised this is working due to the id bytes returned by the Nunchuk...the id *should* match that of the real Nunchuk but it doesn't.  I get the feeling the initialization is still not correct for all devices.

Have you been able to track down the receiver and test again?

Very strange....but what isn't with the Wiimote...

Thanks!

Normal 0 false false false MicrosoftInternetExplorer4 /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-parent:""; mso-padding-alt:0cm 5.4pt 0cm 5.4pt; mso-para-margin:0cm; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:10.0pt; font-family:"Times New Roman"; mso-ansi-language:#0400; mso-fareast-language:#0400; mso-bidi-language:#0400;} Hi,

I have still not managed to track it down yet, however I have had a bit more of a play whist integrating wireless chucks with my wiindows app.

To get things working nicely, I also needed to add the following code as the default case statement within the InitializeExtension():

if (type.ToString("x") == "1aeafb922e3") { mWiimoteState.ExtensionType = ExtensionType.Wireless; }
else { throw new WiimoteException(”Unknown extension controller found: ” + type.ToString(”x”)); }
break;

This new code caters for the chucks being detailed as an additional (even more fun) unknown extension type “1aeafb922e3″ (only) when the chucks are connected upon start up. As you can see all it does is to reassign the ExtensionType to that of the new Wireless type.

You can view the working chuck adaptor extension here: http://www.youtube.com/watch?v=kL_tcacJwC8&fmt=18

I will get some proper facts and figures to you as soon as I track the other receiver down but until then I will continue to investigate Logic 3 adaptor an intec chuck.

That ID is bizarre...

I think there's still a piece missing here with the initialization process.  It shouldn't report a different ID like that.  Weird.