Use the new Wiimote controller with motion plus Inside (bluetooth problems)

[ludo6577]

Hello,

I have some pain to make your library working with the Wiimotion plus inside controller. I saw that you use different provider for the bluetooth and that the last one (MsHid) contains some commentary very close to some in WiiMote lib (but this library is not cross plateform). I use the toshiba bluetoot stack as i know that the default windows bluetooth stack don't support the new wiimote controller.

My question is, what do i have to implement to make your library to work with MsHid ? It seems that it detect well the wimote but then he don't try to connect to and don't even list is in the testing form.

I hope i'm clear enough, and you will help me to understand what is missing. I will make a pull request as soon as i will solve this problem.

Thx.

[FrozenCow]

The toshiba bluetooth stack is not really supported. I didn't have a dongle at the time and the Toshiba Bluetooth SDK was a paid SDK, so I haven't invested any time into this.

That said, you say you run into problems with the motion plus connected. Are you saying things do work without the motion plus?

A pull request is greatly appreciated!

[ludo6577]

No i said i have the new Wiimote with the motion plus integrated in it ("Wiimotion plus inside": http://www.amazon.com/Wii-Remote-Controller-Motion-Inside-Nintendo/dp/B0064IAZJ8?SubscriptionId=AKIAJ32XBJUETKS4M4CQ code: RVL-CNT-01-TR).
I tested a lot of library and the only one who worked with my controller was the wiimotelib: http://wiimotelib.codeplex.com/ (but as i said it is not cross platform, that's why i really want to improve yours)

I saw that the code is very similar to your in the MsHid bluetooth provider. But i can't have your code working that's why i'm asking if it worked with your controller and if not what i need to implement in order to work.

[FrozenCow]

Ah sorry, I misinterpreted your comment. I haven't tested this with the Wiimote with integrated motion sensor. Since you say the Wiimote (with motion sensor) isn't recognized at all with MsHid, I would guess it has something to do with the detection code. Both WiimoteLib and WiiDeviceLibrary use VID/PID to detect the device. It seems Wiimotelib has one additional PID it checks. Maybe that's the motion plus:
https://github.com/simphax/WiimoteLib/blob/master/WiimoteCS/WiimoteLib/Wiimote.cs#L39
https://github.com/simphax/WiimoteLib/blob/master/WiimoteCS/WiimoteLib/Wiimote.cs#L189

You can find similar code in WiiDeviceLibrary:
https://github.com/FrozenCow/wiidevicelibrary/blob/master/WiiDeviceLibrary/Bluetooth/MsHid/MsHidDeviceProvider.cs#L31
https://github.com/FrozenCow/wiidevicelibrary/blob/master/WiiDeviceLibrary/Bluetooth/MsHid/MsHidDeviceProvider.cs#L75

If you could give this change a try and make a PR, that would be awesome!

[ludo6577]

Ok thank you very much for your help, i finally solved the problem but it may cause other problems, i will need a little more of your help in order to make the pull request (i don't want to make any regression in your library).

This is what i did:

• First i removed the first Update in MsHidDeviceProvider because the event DeviceFound must be registered before calling the Update method. See commit: ludo6577@f8a9006 (I don't think this modification may cause any problem)
• Then as you suggested i added the new Wiimote PID: https://github.com/ludo6577/wiidevicelibrary/blob/master/WiiDeviceLibrary/Bluetooth/MsHid/MsHidDeviceProvider.cs#L32 https://github.com/ludo6577/wiidevicelibrary/blob/master/WiiDeviceLibrary/Bluetooth/MsHid/MsHidDeviceProvider.cs#L76
• Finally i needed to reorder the List of DeviceProvider in DeviceProviderRegistry because the MsBluetoothDeviceProviderFactory don't work with this new remote. (that the point in which i need your help. May it cause some trouble? How can i do to improve this?). See this commit for the last two point: ludo6577@c7e5640

What i still need to do

• All the bluetooth devices are detected and prompted (even not wiimote controller), there is still no verification of the PID in this provider. I will see where the check is done in the other library and add it in yours but maybe you can give me some help on this.
• I don't have an old wiimote controller to test if my modifications works with it. I'll try to borrow one in the next few week.
• Maybe including in the readme the procedure to install the new Wimmote controler and the Toshiba Bluetooth Stack may be a good idea. I followed these tutorials: https://wiki.dolphin-emu.org/index.php?title=Wii_Remote_Plus_%28RVL-CNT-01-TR%29_Connection_Guide and this one http://touchmote.net/wiimotetr

Tell me if theses modifications are convenient for you and i will do a Pull request. I also made a migration to .NET 4 for VS 2013 x86 (i switched from x64 because it didn't worked for me as it won't recognize any devices). But i will maybe not include it in the pull request what do you think?

Thank for your help. I hope your library will become more popular in the futur :)
I will now try to add the Android support if it's not already the case.

[FrozenCow]

Tell me if theses modifications are convenient for you and i will do a Pull request. I also made a migration to .NET 4 for VS 2013 x86 (i switched from x64 because it didn't worked for me as it won't recognize any devices). But i will maybe not include it in the pull request what do you think?

Separate pull requests focusing single issues/problems/features would be ideal for me. If you first want .NET 4 support merged, that would be trivial for me to accept.

First i removed the first Update in MsHidDeviceProvider because the event DeviceFound must be registered before calling the Update method. See commit: ludo6577/wiidevicelibrary@f8a9006 (I don't think this modification may cause any problem)

That sounds alright. MsHidDeviceProvider is the black sheep of the providers, I hoped to make it work without special attention, but the update function is exposed for others to use it.

Then as you suggested i added the new Wiimote PID: https://github.com/ludo6577/wiidevicelibrary/blob/master/WiiDeviceLibrary/Bluetooth/MsHid/MsHidDeviceProvider.cs#L32 https://github.com/ludo6577/wiidevicelibrary/blob/master/WiiDeviceLibrary/Bluetooth/MsHid/MsHidDeviceProvider.cs#L76

Looks good to me!

Finally i needed to reorder the List of DeviceProvider in DeviceProviderRegistry because the MsBluetoothDeviceProviderFactory don't work with this new remote. (that the point in which i need your help. May it cause some trouble? How can i do to improve this?). See this commit for the last two point: ludo6577/wiidevicelibrary@c7e5640

Ya, reordering this isn't the way to go, because MsBluetooth will be disabled entirely this way. If you want to use MsHid explicitly, you can use it explicitly (by creating it manually, instead of automatically discovering providers).

That said, I have a hunch it's still possible to support the new Wiimote with MsBluetooth. Are you absolutely sure MsBluetooth can't recognize the new Wiimote at all? MsBluetoothProvider filters the devices based on their name (not PID/VID). You could debug this filtering by checking these lines.

[ludo6577]

Thank you for your answer. I didn't know that the MsHidDeviceProvider was not a good provider, as you suggest i will try to make it works with MsBluetooth. At least i will try to find out why it can't/don't work with it.

I just tryed to make it work with MsHidDeviceProvider because the only working library i found use a very similar code.

Thank you for your reactivity on this issue
I saw that you work on a lot of kernel library, do you think it will be hard to make your library working in android?

[FrozenCow]

I haven't used C# on android yet. So I'm not sure what the implications
are. However, if you can use Bluetooth in C# on Android, it must be
possible to write another provider to support it.

MsHid is kind of a fallback for when the rest does not work. That's why
it's lowest in the provider list. The others can automatically connect with
the wiimote when the wiimote is turned on. For MsHid this is not possible,
because MsHid does not operate on Bluetooth level, but on hid level (higher
level). It can only operate on already installed wiimote devices.

On Wed, Mar 25, 2015, 23:54 Ludovic Feltz [email protected] wrote:

Thank you for your answer. I didn't know that the MsHidDeviceProvider was
not a good provider, as you suggest i will try to make it works with
MsBluetooth. At least i will try to find out why it can't/don't work with
it.

I just tryed to make it work with MsHidDeviceProvider because the only
working library i found use a very similar code.

Thank you for your reactivity on this issue
I saw that you work on a lot of kernel library, do you think it will be
hard to make your library working in android?

Reply to this email directly or view it on GitHub
#1 (comment)
.

[birbilis]

at ludo6577's repository I don't see an Issues area, so I post this here (and just closed the pull request I had made to pull from his repo, till this is fixed):
"ludo6557's version mistakenly recognizes wii balance board as wiimote device, whereas the original code (the one from Google code that is the same as the one here [as it is currently] from what I understand) recognizes it correctly"

[birbilis]

btw, we managed to have your code work with the balance board on Windows 8 64-bit, by switching all projects in the solution to 32-bit (there is an option at the Properties/Build that says "Prefer 32-bit"). This is since bthprops.cpl that you use for the Microsoft stack (at NativeMethods.cs) seems to be 32-bit and exist in SysWoW64 folder on Windows 64-bit.

Not sure what is the proper way to access the Microsoft Bluetooth stack in 64-bit. Maybe there's some other DLL or you can somehow mark the native method as being 32-bit and .NET can handle loading a 32-bit DLL inside an 64-bit app and call it?

[FrozenCow]

@birbilis About 64 vs 32 bit:
It could be that the NativeMethods aren't defined correctly. Some int should be int32 or int64. It's hard to find documentation about Microsofts bluetooth stack. Compiling for 32-bit seems like an alright solution for now.

Fixing NativeMethods would be a next step.

Alternatively, it would be nice to use a library that supports a .NET library that handles Microsofts bluetooth stack. I couldn't find one at the time, but looking around now, it seems that http://32feet.codeplex.com/ fits the bill. It supports a range of Windows bluetooth stacks. A new provider could be made that uses 32feet and is used instead of MsBluetoothProvider or even Bluesoleil.

[birbilis]

do you have any insight on which change from the ones ludo6577 did causes the misrecognition of the balance board as "wiimote device"? Is it the "•Prioritizing MsHid above MsBluetooth seems wong. MsBluetooth will never be picked on Windows, since all machines always support MsHid" that you mention at #2 ? Sounds like that is the issue. After the wrong recognition the GUI example doesn't show the balance board UI, but other

[FrozenCow]

If the Wiimote is recognized and the Balanceboard isn't, then I would think it's an issue with the PID. (even though I first thought that is a good candidate for a merge)

However, if both are not recognized, I'd think the change in priority for MsBluetooth could be the trouble-maker.

[birbilis]

my partners don't have a wiimote available for testing, just a balanceboard. The problem is the wrong recognition of the balanceboard as wiimote device

I think this code of yours from https://github.com/FrozenCow/wiidevicelibrary/blob/master/WiiDeviceLibrary/Interface/DeviceProviderRegistry.cs is correct. However my assumption means the MsHidDeviceProviderFactory has problem with detecting the balance board. Will ask the partner who has the balance board to try putting Ludo's version of the following code

32 static DeviceProviderRegistry()
33 {
34 Factories.Add(new WiiDeviceLibrary.Bluetooth.Bluez.BluezDeviceProviderFactory());
35 Factories.Add(new WiiDeviceLibrary.Bluetooth.Bluesoleil.BluesoleilDeviceProviderFactory());
36 Factories.Add(new WiiDeviceLibrary.Bluetooth.MsBluetooth.MsBluetoothDeviceProviderFactory());
37 Factories.Add(new WiiDeviceLibrary.Bluetooth.MsHid.MsHidDeviceProviderFactory());
38 }

btw, at Ludo's version
https://github.com/ludo6577/wiidevicelibrary/blob/master/WiiDeviceLibrary/Interface/DeviceProviderRegistry.cs
I see a comment about new wiimote with embedded motion plus not being supported next to the MsBluetoothDeviceProviderFactory. So one either breaks the balance board or the new wiimote if they change the order.

32 static DeviceProviderRegistry()
33 {
34 Factories.Add(new WiiDeviceLibrary.Bluetooth.Bluez.BluezDeviceProviderFactory());
35 Factories.Add(new WiiDeviceLibrary.Bluetooth.Bluesoleil.BluesoleilDeviceProviderFactory());
36 Factories.Add(new WiiDeviceLibrary.Bluetooth.MsHid.MsHidDeviceProviderFactory());
37 Factories.Add(new WiiDeviceLibrary.Bluetooth.MsBluetooth.MsBluetoothDeviceProviderFactory()); //This provider don't support new wiimote with motion plus inside
38 }

[FrozenCow]

They both should work with both with proper fixes. MsHid looks at VID/PID of the HID device. The HID device is only added to Windows once you have manually connected to the device through the bluetooth GUIs of the stack you use. That's why MsHid is the 'black sheep' of them all: it doesn't automatically connect. That also means it shouldn't be higher prioritized than a full-features (auto-connecting) provider.

The proper providers do not use VID/PIDs to identify Wii devices, since bluetooth doesn't use VID/PID directly. You can see that MsBluetooth looks for the devices based on names:

wiidevicelibrary/WiiDeviceLibrary/Bluetooth/MsBluetooth/MsBluetoothDeviceProvider.cs

Lines 75 to 82 in b5884de

	private static bool IsWiiDevice(NativeMethods.BluetoothDeviceInfo deviceInfo)
	{
	if (deviceInfo.name == "Nintendo RVL-CNT-01")
	return true;
	else if (deviceInfo.name == "Nintendo RVL-WBC-01")
	return true;
	return false;
	}

Same goes for Bluez:

wiidevicelibrary/WiiDeviceLibrary/Bluetooth/Bluez/BluezDeviceProvider.cs

Lines 258 to 265 in b5884de

	switch(name)
	{
	case "Nintendo RVL-WBC-01":
	case "Nintendo RVL-CNT-01":
	break;
	default:
	return;
	}

And same goes for Bluesoleil:

wiidevicelibrary/WiiDeviceLibrary/Bluetooth/Bluesoleil/BluesoleilDeviceProvider.cs

Lines 183 to 190 in b5884de

	private bool IsWiiDevice(BluetoothDevice device)
	{
	if (device.Name == "Nintendo RVL-CNT-01")
	return true;
	else if (device.Name == "Nintendo RVL-WBC-01")
	return true;
	return false;
	}

I do not have a Wiimote with integrated motionplus, but @ludo6577 could set a breakpoint there and check the name of the device. Adding that name to the MsBluetooth provider is trivial.

That would be the proper fix for the prioritization.

[birbilis]

that would fix the MsBluetooth stack indeed. Any idea how the MsHid stack could be fixed regarding its balance-board misdetection? Or is it expected that it can only see as "generic" wiimotes such devices?

[birbilis]

btw, don't devices on Windows have a SUBCLASS too? Aka VID (Vendor ID), PID (Product ID) and Subclass that the Properties dialog at Windows Device Manager shows for a detected device? Maybe all Wii-related devices from Nintendo have the same PID and separate Subclass?

[FrozenCow]

I thought Subclass is for USB. I'm not sure whether the MsHid also has a subclass.

That said, MsBluetooth recognizes the Balanceboard correctly because it can distinguish them based on name: https://github.com/FrozenCow/wiidevicelibrary/blob/master/WiiDeviceLibrary/Bluetooth/MsBluetooth/MsBluetoothDeviceProvider.cs#L214-L219

You can see here that MsHid doesn't have any support for recognizing the balanceboard: https://github.com/FrozenCow/wiidevicelibrary/blob/master/WiiDeviceLibrary/Bluetooth/MsHid/MsHidDeviceProvider.cs#L153 (it just creates a Wiimote, there is no notion of balanceboards there).

Like said before, MsHid kind of a black sheep. It doesn't support everything. If you can avoid using MsHid, do that.

I presumed the device could be determined before actually connecting to the device. This is true for the proper bluetooth providers, but I don't think that's possible with MsHid. With MsHid you get a Wiimote with an extension. The extension is now not recognized (because the balanceboard-extension isn't implemented), but you could use this.

This is also how WiimoteLib does things. There, a balanceboard is a wiimote with a balanceboard extension. We have chosen not to do this, since a wiimote can do much more than a balanceboard, you can see the distinction between: https://github.com/FrozenCow/wiidevicelibrary/blob/master/WiiDeviceLibrary/Interface/IBalanceBoard.cs and https://github.com/FrozenCow/wiidevicelibrary/blob/master/WiiDeviceLibrary/Interface/IWiimote.cs.

Anyway, if you go with MsHid, I'm interested about your findings!

[birbilis]

Relevant quote:

"For a large part of the development process, the board was an extension controller to a normal Wii remote.[7] The effects of this are seen in the released balance board, which acts as a Wii remote with the front button mapped to "A" and all load cells on an "extension controller".[8]"

• from:
  https://en.m.wikipedia.org/wiki/Wii_Balance_Board
• ref points to: http://wiibrew.org/wiki/Wii_Balance_Board

[birbilis]

Also maybe the following library that I think I read you were based on, may have newer stuff on balance board access via MsHID (if I understand correctly they only used MsHID). See the history in that article

"6/15/08 – Version 1.5.2 is now up at CodePlex. The Balance Board should really work this time…."

https://channel9.msdn.com/coding4fun/articles/Managed-Library-for-Nintendos-Wiimote

[FrozenCow]

Yes, exactly. With the Bluetooth naming we are able to distinguish between the balanceboard and the wiimote, allowing to expose a nicer API than a Wiimote+BalanceBoardExtension.

Yes, the link you sent is the WiimoteLib I was talking about. It relies solely on MsHid.

[birbilis]

So, is there a chance you were based on an older version of their library/examples?

[birbilis]

...seems after 1.5.2 they later released 1.9 (maybe more unreleased commits are in the source section there)

[birbilis]

In fact others have submitted some patches there that are still under review: http://wiimotelib.codeplex.com/SourceControl/list/patches

[FrozenCow]

No, only the MsHid connectivity is based on WiimoteLib. Everything else is different.
This project is handling the Balanceboard differently, because we can rely on Bluetooth information when NOT using MsHid. WiimoteLib cannot do this, because it is based on MsHid.

Like said before, try to avoid MsHid. Use the normal Bluetooth providers, like MsBluetooth.

[ludo6577]

Did you solve this problem ? I don't have my Wiimotes now (normal Wiimote and Wiimote with motion plus inside) so i can't give you the name of the devices for the moment.

I think the only modification that can cause this issue is the inversion of the two providers in DeviceProviderRegistry.cs (commit: ludo6577@c7e5640)

As said by @FrozenCow the MsHidDeviceProviderFactory is not a good provider and should be avoided. But for the moment i didn't succeed to make the MsBluetoothDeviceProvider works with the Wiimote with Wiimotion plus inside.
I will have further investigation in the next few week but you can revert my modifications if needed.

[birbilis]

I don't have the balance board available myself, a partner has it. However indeed the problem is the order of the providers I believe. If you add the proper device name to the code (would be needed for all 3 bluetooth-stack based providers) from what I understand the other providers should work, so the Hid one could go to the bottom again.