Although that does not necessarily mean they'll fix it. I've followed up with them as you can see in the bug report.
As for this thread, @Eric are you planning on coding the "handle BLE externally" strategy yourself? You seem to be 2 steps ahead of us in trying to find a solution that works, so trust your opinion on the best way forward. We'd like to know whether you will be investigating it, or whether we've reached a dead-end in terms of Unity support.
@Eric said:
The C# SDK works in Unity 2018, barring that serialization bug on UWP which they need to fix (this can be worked around with some minor changes until then).
I tried to put the SDK, but it seems that Unity doesn't recognize Windows.Devices.Bluetooth/ Here is the code:
Although that does not necessarily mean they'll fix it. I've followed up with them as you can see in the bug report.
As for this thread, @Eric are you planning on coding the "handle BLE externally" strategy yourself? You seem to be 2 steps ahead of us in trying to find a solution that works, so trust your opinion on the best way forward. We'd like to know whether you will be investigating it, or whether we've reached a dead-end in terms of Unity support.
Thanks!
I'm not really ahead of anything; what I suggested is how pygatt (a Python BLE library for Linux) uses BlueZ's gatttool program to control the BLE connections rather than call into the BlueZ librariey itself.
No, i will not be pursuing this suggestion. Given that the Unity QA Team has acknowledged the issue, I do not think it is worth investigating this matter any further until we know if the Unity devs will fix your address your ticket soon, if at all.
@Eric said:
The C# SDK works in Unity 2018, barring that serialization bug on UWP which they need to fix (this can be worked around with some minor changes until then).
I tried to put the SDK, but it seems that Unity doesn't recognize Windows.Devices.Bluetooth/ Here is the code:
Can you please let me know if i miss something and where?
If yes, can you please note which DLLs should we put in Assets in order to use , and put some minimum demo version of this in unity ?
I am talking about the C# SDK, which makes no references to that namespace in question, not the external BLE plugins, which we have concluded do not work in the current release of Unity.
Besides, what you are describing sounds like a general Unity issue, not something specific to the MetaWear SDK.
You will most likely be able to get better support for your Unity issues on the Unity forums.
Very well. I will create a separate C# console app that reads from the sensor and streams the data to unity, over network or disk. Note that this means you clearly do not support Unity desktop development. You should both correct your marketing material (e.g. https://mbientlab.com/research-development-kits/) and make people clearly aware of it when they ask about it on this forum.
When I purchased the kit, I made sure to check both the website and the forum, and there was indication on both that Unity support was available. I also expect a refund if I decide to not pursue the workaround which I am currently planning on building this week.
See above for proof of concept of streaming data to Unity from external .NET server. If anyone wants a copy of the projects, drop a line here (so that any strong demand for Unity support becomes visible to Mbientlab), and I'll send it to you.
I would love to use Unity with Windows 10. I didn't know anything about C# or visual studio starting out, but I'm willing to put in the time to learn, as long as I know there is actually a possible way forward. I managed to get the sample Windows 10 apps from Mbientlab working. Then I made a DLL for Unity that had mbientlab functions in it, but I kept running into issues with the .NET version. This is probably just an issue on my end, but this thread indicates that even if I fix that I'll run into other issues.
Were you able to build something that lets Unity read sensor data without using the Mbientlab functions? Can you please send me what you have so far for Windows? I'm sure it would help me quite a bit.
Hello @mandyg,
As you can see in the prev posts of this thread, i also tried to work with Win10.
I tried to put the SDK, but it seems that Unity doesn't recognize Windows.Devices.Bluetooth. As i understood, Mono doesn't include Windows.Devices.Bluetooth, so need to use UWP only, but even then it is not recognized
@jimjam
You said you can share with us your project that seem to be working now with the help of Bluetooth LE for iOS, tvOS and Android asset. Do you think that if we use the code from https://github.com/tpitman/unity-plugin-mbientlab-metamotionr-example and some BT LE code that mbientlab SDK has together so we avoid buying this asset.
Thanks
It seems that Unity finally answered and they say they won't fix the issue because it's not their faul. They say that there is a problem with your library, that doesn't offer a way to cleanup the threads it creates and thus locks Unity. https://fogbugz.unity3d.com/default.asp?1065590_p5vr9ftohapf1apf
In the mean time we'll use ebadier's solution, but it's less than ideal. We really hope that you can fix this issue and make it work with Unity, otherwise we'll be forced to find another hardware that is actually compatible.
@rgonzalezEvolv said:
It seems that Unity finally answered and they say they won't fix the issue because it's not their faul. They say that there is a problem with your library, that doesn't offer a way to cleanup the threads it creates and thus locks Unity. https://fogbugz.unity3d.com/default.asp?1065590_p5vr9ftohapf1apf
If they don't want to fix it, then no standalone Windows project using the official Windows Bluetooth LE APIs will work.
In the mean time we'll use ebadier's solution, but it's less than ideal. We really hope that you can fix this issue and make it work with Unity, otherwise we'll be forced to find another hardware that is actually compatible.
You can try but there is a reason that no Windows 10 Bluetooth LE assets exist for Unity, as documented in this thread.
@Eric said:
If they don't want to fix it, then no standalone Windows project using the official Windows Bluetooth LE APIs will work.
You can try but there is a reason that no Windows 10 Bluetooth LE assets exist for Unity, as documented in this thread.
The Unity incompatibility is not with the Bluetooth API, but with the Parallel Patterns Library which is not necessary for the Bluetooth API. In fact, is derived of how you use the PPL, as you can see here: https://github.com/mbientlab/Warble/blob/fd044911c8be83b81c4d25d34d005bd1df75a894/src/warble/cpp/win10_api.cpp
In the connect_async method, line 177, you are creating a task, which is in fact a separate thread, but in the disconnect method you are neither stoping that thread, nor signaling it to stop, so that is causing the Unity hang, because it's wait for that thread to end.
You could either find a way to stop that thread or use something different than the PPL, something that uses proper threads that can be stopped or that can signal a thread to stop.
@Eric said:
If they don't want to fix it, then no standalone Windows project using the official Windows Bluetooth LE APIs will work.
You can try but there is a reason that no Windows 10 Bluetooth LE assets exist for Unity, as documented in this thread.
The Unity incompatibility is not with the Bluetooth API, but with the Parallel Patterns Library which is not necessary for the Bluetooth API. In fact, is derived of how you use the PPL, as you can see here: https://github.com/mbientlab/Warble/blob/fd044911c8be83b81c4d25d34d005bd1df75a894/src/warble/cpp/win10_api.cpp
In the connect_async method, line 177, you are creating a task, which is in fact a separate thread, but in the disconnect method you are neither stoping that thread, nor signaling it to stop, so that is causing the Unity hang, because it's wait for that thread to end.
Yes...this is why the the fogz bug thread is about using Windows PPL, not Bluetooth specifically.
You could either find a way to stop that thread or use something different than the PPL, something that uses proper threads that can be stopped or that can signal a thread to stop.
This defeats the purpose of using an async task framework. Even if it didn't, windows does not expose this functionality.
Non-ppl option has already been discussed in this thread.
Again, there is a reason why no windows 10 ble asset currently exists on the Unity store.
Comments
HI Guys. Sorry my break ended up being longer than usual.
First of all, some movement from the Unity folks. We're made it through QA at least: https://fogbugz.unity3d.com/default.asp?1065590_p5vr9ftohapf1apf
Although that does not necessarily mean they'll fix it. I've followed up with them as you can see in the bug report.
As for this thread, @Eric are you planning on coding the "handle BLE externally" strategy yourself? You seem to be 2 steps ahead of us in trying to find a solution that works, so trust your opinion on the best way forward. We'd like to know whether you will be investigating it, or whether we've reached a dead-end in terms of Unity support.
Thanks!
I tried to put the SDK, but it seems that Unity doesn't recognize Windows.Devices.Bluetooth/ Here is the code:
https://drive.google.com/file/d/1zYh8gm0zTnU3Fmd3ce4G9MJ-fyelmXCc/view
Can you please let me know if i miss something and where?
If yes, can you please note which DLLs should we put in Assets in order to use , and put some minimum demo version of this in unity ?
I'm not really ahead of anything; what I suggested is how pygatt (a Python BLE library for Linux) uses BlueZ's gatttool program to control the BLE connections rather than call into the BlueZ librariey itself.
No, i will not be pursuing this suggestion. Given that the Unity QA Team has acknowledged the issue, I do not think it is worth investigating this matter any further until we know if the Unity devs will fix your address your ticket soon, if at all.
I am talking about the C# SDK, which makes no references to that namespace in question, not the external BLE plugins, which we have concluded do not work in the current release of Unity.
Besides, what you are describing sounds like a general Unity issue, not something specific to the MetaWear SDK.
You will most likely be able to get better support for your Unity issues on the Unity forums.
Very well. I will create a separate C# console app that reads from the sensor and streams the data to unity, over network or disk. Note that this means you clearly do not support Unity desktop development. You should both correct your marketing material (e.g. https://mbientlab.com/research-development-kits/) and make people clearly aware of it when they ask about it on this forum.
When I purchased the kit, I made sure to check both the website and the forum, and there was indication on both that Unity support was available. I also expect a refund if I decide to not pursue the workaround which I am currently planning on building this week.
Regards,
H.
http://recordit.co/WzawktuC47
See above for proof of concept of streaming data to Unity from external .NET server. If anyone wants a copy of the projects, drop a line here (so that any strong demand for Unity support becomes visible to Mbientlab), and I'll send it to you.
FYI, the project I've built now also supports mobile devices, using a BLE library I found on the Unity store.
Hi jimjam,
I would love to use Unity with Windows 10. I didn't know anything about C# or visual studio starting out, but I'm willing to put in the time to learn, as long as I know there is actually a possible way forward. I managed to get the sample Windows 10 apps from Mbientlab working. Then I made a DLL for Unity that had mbientlab functions in it, but I kept running into issues with the .NET version. This is probably just an issue on my end, but this thread indicates that even if I fix that I'll run into other issues.
Were you able to build something that lets Unity read sensor data without using the Mbientlab functions? Can you please send me what you have so far for Windows? I'm sure it would help me quite a bit.
Thanks,
Mandy
Hello @mandyg,
As you can see in the prev posts of this thread, i also tried to work with Win10.
I tried to put the SDK, but it seems that Unity doesn't recognize Windows.Devices.Bluetooth. As i understood, Mono doesn't include Windows.Devices.Bluetooth, so need to use UWP only, but even then it is not recognized
Here is the code sample i used:
https://drive.google.com/file/d/1zYh8gm0zTnU3Fmd3ce4G9MJ-fyelmXCc/view
Let me know if you manage to progress
@jimjam
Can you share some code you used to interact with mobile devices and MetaMotionR.
Did you use this example? https://github.com/tpitman/unity-plugin-mbientlab-metamotionr-example
@Eric
You should take a look at this github implementation to see if you can add unity sup@Eric
@jimjam
You said you can share with us your project that seem to be working now with the help of Bluetooth LE for iOS, tvOS and Android asset. Do you think that if we use the code from https://github.com/tpitman/unity-plugin-mbientlab-metamotionr-example and some BT LE code that mbientlab SDK has together so we avoid buying this asset.
Thanks
Hi Guys,
You could be insterested by these projects:
https://github.com/ebadier/MetaWearRPCServer
https://github.com/ebadier/MetaWearUnityRPC
Best,
It seems that Unity finally answered and they say they won't fix the issue because it's not their faul. They say that there is a problem with your library, that doesn't offer a way to cleanup the threads it creates and thus locks Unity.
https://fogbugz.unity3d.com/default.asp?1065590_p5vr9ftohapf1apf
In the mean time we'll use ebadier's solution, but it's less than ideal. We really hope that you can fix this issue and make it work with Unity, otherwise we'll be forced to find another hardware that is actually compatible.
If they don't want to fix it, then no standalone Windows project using the official Windows Bluetooth LE APIs will work.
You can try but there is a reason that no Windows 10 Bluetooth LE assets exist for Unity, as documented in this thread.
The Unity incompatibility is not with the Bluetooth API, but with the Parallel Patterns Library which is not necessary for the Bluetooth API. In fact, is derived of how you use the PPL, as you can see here:
https://github.com/mbientlab/Warble/blob/fd044911c8be83b81c4d25d34d005bd1df75a894/src/warble/cpp/win10_api.cpp
In the connect_async method, line 177, you are creating a task, which is in fact a separate thread, but in the disconnect method you are neither stoping that thread, nor signaling it to stop, so that is causing the Unity hang, because it's wait for that thread to end.
You could either find a way to stop that thread or use something different than the PPL, something that uses proper threads that can be stopped or that can signal a thread to stop.
Yes...this is why the the fogz bug thread is about using Windows PPL, not Bluetooth specifically.
This defeats the purpose of using an async task framework. Even if it didn't, windows does not expose this functionality.
Non-ppl option has already been discussed in this thread.
Again, there is a reason why no windows 10 ble asset currently exists on the Unity store.
Hi jimJam
is possible to share your sample unity project?
thanks
@jimjam