I’ve been looking at Motion Plus support, though I can’t say it’s implemented in a few minutes in the current framework. At the moment school takes a lot of time, which doesn’t give me enough to setup the test-environment and implement the support. It would be a great addition though!

To not forget the feature I’ve added it to the issue-tracker: http://code.google.com/p/wiidevicelibrary/issues/detail?id=13 . If there are any other requests (or issues) please also add it to the issue-tracker.

Great job and thank you very much for the hard work !

Any chance to get Motion Plus support with pass thru mode for Nunchuck ?
Please see http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1248889032/45 for some hints about pass thru mode.

Regards….

I think there are a few changes which would make the MsHid interface usable — I have patched a local copy to include these changes, and I am including these patches (as I don’t know where else to direct said patched).

First, a patch to avoid a NullReferenceException if acceleration data arrives before calibration (this can happen if the Wiimote is already configured for reporting acceleration):

(see next comment)

First: sorry for the wait, we should really have some sort of notification when people comment on this site.

It really surprised me that you ran across the ‘Received an output report!’. When I added that exception I presumed no one was ever going to see that, because it would be almost impossible. I think one of the usb-devices (or hub) was registered as HID-device with the same Id’s as the Wii-devices have. WiiDeviceLibrary thought one of those devices was a Wii-device and tried to connect. The Wiimote normally sends and receives ‘reports’ and identifies the report-type with a single byte. This byte is checked by WiiDeviceLibrary. If it receives a byte that corresponds with a report-type that would normally be SENT to the Wiimote instead of RECEIVED it raises the exception you described.
I might just remove the exception and just try to disconnect the device, since raising an exception on a thread that is not managed by the user could cause great annoyances.

The TimeoutException is raised for WriteMemory and ReadMemory when there is no resulting-report sent back to confirm the operation succeeded (or failed) within 5 seconds.
We tested and covered calling Wiimote-methods directly from the Update-eventhandler. This should be no problem.
Though, invoking a call on the GUI-thread and at the same time blocking the Update-thread (which is what the ‘Invoke’ method does) -could- result in problems.

I can’t really clearly state where the problem lies without some more information. It would be great if you could send us a portion of your code so we can analyse, test and debug using that.
You can email me or Maato at info@softwarebakery.com.

My Updated event for a device invoked itself on the GUI thread to manipulate the GUI, and read from the wiimote at the same time (the rumble, battery, and led states). This reading could have been happening at the same time a ReportingMode was being set, which could have caused a problem.

I also had the same exception if I tried to enable the speaker while my same update code was running.

I noticed both use WriteMemory to poke at a number of addresses on the Wiimote, and it was WriteMemory that was failing to receive a return report.

I worked around both problems by unhooking my device’s Updated event handler while changing ReportingMode or IsSpeakerEnabled, and rehooking it after.