Using ordinary virtual COM-port while wclAPI is loaded (BlueSoleil)

[autocom]

Hi

Background:
We have an application which used ordinary virtual COM-ports for Bluetooth communication earlier. Now, we'se extended it with wcl so we can skip the manual pairing and setup. The plan from the beginning was to leave the old routines to fall back on if needed and for the old customers to use which already have setup a COM-port long ago.

Problem:
Our application have one instance of serialstreamdriver which loads wclAPI in the constructor and unloads it at dispose and one instance of the old handler for virtual COM-ports. Now we have had reports back from customers using BlueSoleil that the ordinary virtual COM-ports are very unstable to connect to. All reporters have used the same COM-port in earlier versions of our program without problem.

Testing:
We downloaded trials of BlueSoleil 5.4.277.0 (and later 6.x and 8.x) and saw for ourselves that about every second connection attempt fails and all operations take long time. When commenting out all wclAPI.Load() in the other class the virtual COM-port worked fine again. All three other stacks supported by wcl work fine in both handlers.

Do you have any ideas how to get around this? Seems like wclAPI.Load() is triggering something in BlueSoleil to start which interfere with COM-port. We need the instance using wcl from time to time, for example when checking for supported stacks installed at startup.

Kind regards,
/Martin J (Autocom Diagnostic Software)

[Mike Petrichenko]

Hi,

Thank you for so detailed report. We have been reported about such problem about a week or so ago from our other customer and are now working on this matter. I'll be in touch to update you with issue fixing result. I do not think it takes too much time.

[Mike Petrichenko]

Hi,

We have tested vCOM with BS 8.0.376.0 and Nokia N72 cell phone. Our tests shown that the problem may appear only if you destroy vCOM before stop using created vCOM. Do you close COM port before destroy it?

[Autocom2]

Hi!

I've attached a screenshot of a small C# sample program that illustrates our problem.
The first time we try to connect to the virtual com port(and every second time after that) we get an IOException saying "The specified port does not exist".

If we comment out the line with "wclApi.Load();" the connection works without a problem.

Hopefully this helps you to recreate our problem.

Kind regards,
/Martin B (Autocom Diagnostic Software)

[attachment deleted by admin]

[Mike Petrichenko]

Hi,

But as you can see you simple use standard Serial port class and opens COM19 (Why 19???). You do not use WCL in your code. wclAPI.Load does nothing with regards to COM ports. If you would like to use WCL with vCOM you have to use wclVirtualCOMPort class (refer to VirtualPort demo). You must create vCOM before use it (and each time you close vCOM it is destroyed and will not be available until you create new one). A number of a vCOM may be different each time you create it.

I am sorry but your code part just shows me that you use SerialPort class (which is not WCL part) and COM19 (what COM 19 is/means on your system I do not know).

[Autocom2]

Hi again!

I'll try to clearify some things about my last post and our problem.

In our code we have two different ways of connecting to bluetooth devices:

1. The old way, using the System.IO.Ports.SerialPort class.

2. The new way, using your WCL component(but not the wclVirtualCOMPort class)

And, as I tried to illustrate in my last post, connecting using the standard Serial port won't work when the WCL component is loaded(It works fine if we call wclAPI.Unload() before System.IO.Ports.SerialPort.Open()). Somehow the WCL component seems to interfer with the standard serial port communication.

As mentioned before, the problem only concerns the BlueSoleil BT Stack.
The "COM19" in my sample program is a BT serial port created by the BlueSoleil software.

Regards,
Martin

[Mike Petrichenko]

Hi,

Ok, finaly I reproduced the problem. Well, unfortunately it appears somewhere outside WCL (after WCL calls BS API Initialize function) and I have no solution. The only way I see:

1. Use wclVirtualCOMPortCreator to create vCOM for old way;
2. Do not use WCL (wclAPI.Load) when connecting in old way.

[autocom]

Thanks for the information and for your efforts.

In case someone else stumble upon this problem. Here is what we think is the problem so far.
We looked at the free SDK from BlueSoleil (only for BlueSoleil stack 8+) and it seems to indicate that there can only be one callback set to receive information of events. Therefore after wclAPI.Load() we think wcl is the only receiver of information when we connect through BlueSoleils virtual COM-port. We clearly see that we get connected (by a led indicator on the device we connect to) but BlueSoleils bluetooth manager (the program managing virtual COM-ports) never get this information obviously.

We will try to get around this by unloading wclAPI whenever we need to communicate the old way.

Kind regards,
/Martin J (Autocom Diagnostic Software)

[Mike Petrichenko]

Hello,

BSBT manager is notified too. But. What I did to reproduce the issue and what I have found:

1. I used Samsung cell phone which has SPP profile.
2. I paired it with PC (PC runs BS 8.0.376.0 on Win 7).
3. I searched its services with BS BT manager.
4. I connected to SPP profile on cell and BS created a COM port for this connection. Let say it is COM11.

Now when I do not use WCL (or use WCL without loading BS API/SDK).

4.1. If I open COM11 from any application/code all works great.
4.2. I close COM11 - device disconnects.
4.3. I open COM11 again - PC (BS) connects to device and all works great again.
4.4. .... I can repeat steps 4.1-4.2 any times. All works.

Now I modified my test code to call wclAPI.Load (to load BS API/SDK). And I got:

5.1. If I use same COM11 created on step 4 and simple open port with CreateFile an app freez for a few seconds (very long time, may be seconds 20-30) on CreateFile function. Even BS and cell shows that connection already exists. After that time (20-30 seconds) my application is notified from BS than outgoing connection has been established and CreateFile returns and all works.
5.2. After that I close the COM11 and again I got freez on CloseHandle function for about 20-30 seconds. After that time the app is notified about outgoing connection is closed and connection is actualy closed.
5.3. If I try to open COM11 again (with scenariuos described in step 5.1) it may work or may not work. Usualy it doesn't work even CreateFile returns valid handle (fast, without any delay) but no connection, not data transferring. Even if I close app and open it again. Only dongle replug helps. Sometimes it may work two times and then stop working again.

And the final test I did:

6.1. I used wclVirtualPortCreator to create vCOM for BS (wclAPI loads BS API/SDK). In this case I got other COM number (let say COM12). So I call wclVirtualPortCreator.Open function, get new created COM number (COM12) and use it in CreateFile function. Now it works fast (without any delay).
6.2. I close COM12 (CloseHandle) and destroy vCOM (wclVirtualPortCreator.Close). Device is disconnected, port destroyed.
6.3. I back to step 6.1. - All works again.

In this case (steps 6.1.-6.3.) all works greate any times you want repeat that.

I don't know why, but it looks that if you try to use COM port created in BS BT manager and then try to use it in any application uses BS SDK then you get a problem. If your application doesn't use BS SDK then the port works great. But if you create a COM port in your application uses BS SDK then the port works greate.

I do not think it is something with hooking BS callbacks because BS BT manager is always notified about actions with BT in any case. But in case when you use COM port created in BT manager and use it in app with BS SDK it dies.

So that's what I got. Just FYI.

[Mike Petrichenko]

One more thing:

In steps 5.1. - 5.3.:

* connection etsablished immediatelly after CreateFile call (it is shown by BS BT manager and by cell) but CreateFile waits for something too long before return (even connection is already established);
* connection terminates immediately on CloseHandle call but CloseHandle waits for something before return;
* if you terminate application from debugger (simple killing it) when it is frozen on CloseHandle (on step 5.2.) then you can reconnect to this COM port (COM11 in my case) any times without any problem - all will work. Problem appears only if CloseHandle returns and application closes as should (without terminating it).

[autocom]

Thanks for the information. Very interesting reading.

/Martin J