Toshiba Bluetooth Stack problems

[markc@cognito]

We are using WCL to perform bluetooth communications for our software on Windows 7/8 machines.  Both the problems described below happen with 6.13.4.0 and with a slightly older 6.13.1.0

The majority of devices we have are Microsoft stack based - and we have had no problems with these devices.

We have one device (the Panasonic Toughpad FZ-G1) that uses the Toshiba Bluetooth stack.  This is the device that is causing us problems.

========================
Problem 1: Loading application on boot.
========================
You can replicate this yourself :

1) Get the Bluetooth chat client demo and build it (we built using the 2012 solution / dll). Use the "paid" version of the c++ DLL, so that no pop-ups appear on load / unload of the application.  Make sure it starts normally, and that devices can be discovered when 'discover' is clicked.

2) Create a link to the chat client in shell:startup  (you can type 'shell:startup' in Windows explorer to access the start up folder).

3) Reboot your device

4) When you log in to Windows, the chat application will automatically load.  However, on Toshiba based devices, clicking 'discover' will cause an error to show: No Bluetooth API was found.

5) Only restarting the application will allow the chat application to function correctly.  This kind of defeats the point of being able to load on start up!

I think this is to do with application loading order on device start up.

Additionally, the issue does not happen every time.  Sometimes the application will start up on boot, and the bluetooth will function correctly without needed to restart the application.

CwclAPI.Load() is returning success. Calling CwclAPI.GetBluetoothAPIs() returns 'baToshiba' as the only entry.


========================
Problem 2: Delay loading the API not working
========================

So to get around problem (1), I thought I would only load the WCL api when bluetooth functionality was first used, rather that loading the API on application start.

This change keeps the 'CwclAPI' as a static, but only calls load() on it when bluetooth is first used.

This presents a completely different problem.

Again, this only happens on Toshiba based devices. The Microsoft based ones function as expected (i.e: everything works) with this 'delayed calling load' change .

Again, CwclAPI.Load() returnes success,  CwclAPI.GetBluetoothAPIs() returns 'baToshiba'

However, attempting to use device discovery causes no errors, but the OnDiscoveryComplete() event callback is given a NULL device list.

It does not matter if the app is launched on device start up or not, this problem is consistent when not calling CwclAPI.Load() on app load, but instead calling it on first use of bluetooth.

Also with this change,  the radio does not report itself as connectible (GetConnectable returns success, with a false state 'rfValue'  value).  Without this change the radio does report itself as connectible

When we start device discovery, we perform it in a separate thread. This thread is a message loop thread,  so I do not think the issue is related to this - as the exact same code (without the 'delayed calling load' change) works if we load the API on application start, and do not run the application on device start.

However, I could not replicate this issue in the chat client demo app.  I delayed the API load to when GetSelectedRadio() is called, and the demo app still functioned without error.

So I think this is a multi threading issue.  We do not launch our device discovery in the main thread, so the delayed api load would not occur on the main thread.

However, in our non-delayed api load version, the api was being loaded in the main thread.

So it seems loading the WCL api in a thread other than the main one causes the toshiba bluetooth libraries that WCL uses to not function correctly.

I respect this may be more of a Toshiba issue, rather than a WCL issue - but it is something to bare in mind if you have a multi-threaded application.

[Mike Petrichenko]

Hello,

Toshiba stack can be accasavle/usable only after it completly loaded. Toshiba API is Windows Messages based API and lays in user-level application (which icon appears in system tray). Also after start Toshiba trys to discover some HID devices. That prevents other applications from discovering devices. The same with BlueSoleil. Fortunately, BlueSoleil loads its app when you first time call its API so is solves your first problem. Toshiba does not do so.

Unfortunately there is no workaround for that as Toshiba does not notify when it is ready for use.

Microsoft stack is kernel based so it is ready immediately after boot.

[markc@cognito]

Thanks for that.

The second problem, I realised, was my fault.  I have now put the load/unload into a seperate thread, with a message pump in between the two. 

Now when I want to load the WCL library when bluetooth is first used, I call my own load method that will:

1) Start the thread
2) Wait for the thread to signal its 'loaded' event

Upon starting, the thread will
A) Call the CwclAPI.Load() function
B) Check the return result and set error if necassary
C) Signal the 'loaded' event
D) Start message pump

Similarly the unload is also done in a thread:

1) Set a flag to signal that we want the thread to shut down
2)  Post WM_NULL to thread to make it iterate and re-check the shutdown flag
3) Wait for thread to quit/exit


Where the thread will:

A) Message pump iteration checks 'shutdown' flag
B) If 'shutdown' flag is set, exit message pump loop
C) call CwclAPI.Unoad()
D) signal thread exitg

[Mike Petrichenko]

Good idea. Also not bad way is:

1. call wclAPI.Load()
2. In wclAPI.OnLoaded event handler start timer (for may be 500-1000 ms);
3. When time fires check that required API (or stack) is available and start do what you need (discovering for devices);
4. Monitoring wclAPI.OnChanged even as sometime Toshiba and WidComm may report that stack is not available immediately after load but then they may notify WCL that stack is ready and WCL fires OnChanged event