Unity crashing when calling Connect() method

[Joelx]

In fact, I was probably a little too hasty when I said that "everything" worked. The scan works beautifully. However, when I try to connect a device with "ble.Connect()", the Unity Editor hangs completely and has to be terminated via the Task Manager.
I rebuilt the code of "Program.cs" in a Unity monobehavior and replaced any "Thread.Sleep" with coroutines. But it completely boils down to the "Connect()" method. More specifically to the "PollService()" routine inside the .dll.

ScanStatus PollService(Service* service, bool block) { ScanStatus res; unique_lock<mutex> lock(serviceQueueLock); if (block && serviceQueue.empty() && !serviceScanFinished) if (QuittableWait(serviceQueueSignal, lock)) return ScanStatus::FINISHED; if (!serviceQueue.empty()) { *service = serviceQueue.front(); serviceQueue.pop(); res = ScanStatus::AVAILABLE; } else if (serviceScanFinished) res = ScanStatus::FINISHED; else res = ScanStatus::PROCESSING; return res; }

I'm not sure why this would be a problem from inside Unity, but not from your VS project? May it have something to do with my Unity project settings?
I know this is not too accurate information, but off the top of your head, do you have any idea what this could be?
Please let me know, if you need further information.
Or maybe you have a small example snippet of an implementation in Unity?
I would be very grateful!

[adabru]

Hi @Joelx, thanks for sharing your problem! Yeah, a sample Unity-scene is on my todo-list.

The sample BLE.cs works with blocking calls. The current example is laid out to be used with an extra thread in Unity. That complicates the Unity code a bit because you need to start at least one extra communication thread. From my observations so far I'd say that working with an extra thread can reduce latency by a minimum of 4ms.

If such optimization is not needed and code-simplicity is more important, the functions also have the possiblity to be called non-blocking by setting the bool block parameter to false. This way you can check for new scanresults/data packets e.g. once per frame.

If you want to use coroutines, I think you still have to start another thread and use the appropriate C# synchronization primitives to connect it with the async function. I don't remember at the moment how the API for this looks like, but it shouldn't be complicated. If starting Threads in Unity just make sure the threads are always terminated when the scene stops or else the Editor will freeze on the second play like it's freezing for you now :)

Also try to make sure to call ble.Close() when your scene stops. Or else there could be some errors or longer timeouts when calling the ble functions again. I guess there are some resources that the Windows-BLE stack won't free otherwise. That could, maybe also be a reason why PollService is blocking indefinitely in your case.

--

Nevertheless, PollService should never block indefinitely. That would be a bug. Are you sure the block doesn't release after e.g. 120 seconds?

[adabru]

For debugging you can also try to disable+reenable your bluetooth functionality or reinserting the bluetooth-dongle.

[Joelx]

First of all, thank you so much for this elaborate and insightful answer.
What you say makes perfect sense to me now :)
Also, you were right about your assumption regarding the timeout (and the dongle for that matter). When I either unplugged the dongle or waited long enough, Unity would unfreeze.

I delved a bit deeper into your work yesterday afternoon and created a little demo Unity project implementing your wrapper and making it accessable via a simple demo GUI.
You can find it here: https://github.com/Joelx/BleWinrtDll-Unity-Demo
It surely doesn't meet your high standards, as I'm not that experienced with C# (and .NET in general) yet. But if you like, you can take it for your project repo.
It atleast works for my test application receiving packages from a ESP32.

Of course I would be more than open for any proposals for improvement.

[Joelx]

There are also some redundancies, e.g. the dictionary for the discovered devices. But I didn't find a way to access this data from the MonoBehavior without messing around too much with your BLE.cs. I really wanted to leave this file as it is, but I had to add another method (ReadBytes) to access the buffer data.
Would there be a way to kinda extend the BLE class from a separate Unity Script, with the intention of leaving your repo files untouched?
Or may this intention be nonsense in the first place? ;D

[adabru]

Wow, thanks for uploading the Unity scene! I don't have the opportunity to check it out at the the moment, but I'll link it in the readme and try it out later.

It atleast works for my test application receiving packages from a ESP32.

I'm glad it worked out for you in the end.

Would there be a way to kinda extend the BLE class from a separate Unity Script, with the intention of leaving your repo files untouched?
Or may this intention be nonsense in the first place? ;D

At the moment its only purpose is to make the demo work :) There are some functions left over from the other project I am working on where I'm using the dll. So I wouldn't be sure that you can use it as is. But it's maybe really a good idea to make a generally usable BLE.cs. I'll create an issue for that.