Bluetooth Device gets disconnected when wclVirtualComPort object is disposed

[saysmaster]

We use the demo (trial) version of the wcl library (.net 4.0) in a proof of concept scenario.

A 3rd party library we use communicates with a Bluetooth device through a serial port. This means the device has to be connected, paired and SPP enabled. We want to use wcl for automatic discovery, pairing and serial port creation.

Our application runs for only a few seconds, communicates with the device, and exits. What we want is, at the first time the application executes, to discover the device, pair it and create a virtual COM port for this device. Then the flow continues with the 3rd part library communicating with the device through the vCOM port. At subsequent executions of the application, we don't want to go through the discovery-pairing-vCOM creation part again, since the device should already be in windows' "Bluetooth Devices" list, paired and with SPP enabled.

We don't know if this is a limitation in the demo assemblies, or actually a bug in the wcl library, but whenever we open a virtual port on the device (we have successfully discovered it and paired it in the previous step) then when the wclVirtualComPort object is disposed (or the api.Unload() method is called), the COM port in Windows is destroyed too (it's not listed in windows device manager) even if we haven't called .Close() method. Moreover, when the virtual com port is destroyed, the Bluetooth device get's removed from windows' "Bluetooth devices" list, which forces the application to go through the discovery-pairing-port creation step each time it executes.

What we want is

• 1st application execution
  
  • Discover the Bluetooth device
  • Pair the Bluetooth device
  • Enable SPP on the Bluetooth device (create vCOM port)
  • Communicate with the Bluetooth device through the vCOM port
• Subsequent application executions
  
  • Scan COM ports to communicate with device.
  • If none of the COM ports communicates with the device go through the steps of first application execution
  • Otherwise communicate with the Bluetooth device through the COM port we discovered in step 1

In the above scenario, we successfully do device discovery, pairing and port creation, but when the application exits, everything is wiped out of the system. The virtual COM port is destroyed and the device is removed from Bluetooth devices list.

[Mike Petrichenko]

Hello,

Unfortunately WCl does not support such feature as it is Wireless Communication Library and vCOM has been added in WCL for legacy app support only. We recomend to use native Bluetooth connection using wclClient instead of vCOM. In some case it can be possible to change a little bit WCL to leave create vCOM in the system but will work only with MS drivers and will not with any other. So the best way is to use wclClient with direct Bluetooth connection.

[saysmaster]

Unfortunately the 3rd party library we use (actually it is the vendor's API for the Bluetooth device) needs a COM Port as the initial input for any subsequent communication attempts.
It does not communicate through direct Bluetooth link.

Through Windows interaction we can discover and pair the device, then right-click on it, go to properties->Services, check the 'Serial port (SPP)' service and Apply changes. This way, a COM port is created in the system, that can be used from within our application without the need for us to create a vCOM port through wcl (because the port already exists)

So if I understand correctly, there is no way, through WCL, to perform those actions that the user would have to perform manually to enable SPP on the device.
Also I understand that the vCOM port is used only inside a single execution of the application, which means that, in order to use WCL, we probably have to change the way the application functions, probably keeping it alive.

In anyway, still, is it an expected behavior for the device to get removed from the system's Bluetooth devices when the virtual COM port component is destroyed from within the application, or is it a bug? I am talking about the device itself, not the COM port that is created for it when the vCOM port is Opened. I would expect that the device would be still connected and paired, and only the COM port would have been removed from the system.

[Mike Petrichenko]

When WCL stops using created vCOM it releases resources the BT driver remove vCOM and (of course) remove the device. For other than MS stack it may work different. Any way Device can not be connected when you release the vCOM. Probably it may still be paired (at least BlueSoleil keeps it paired). But no one driver keeps it connected. More: with BlueSoleil only when device connected the vCOM is available (in some cases it may re-connect to device when you opens the vCOM but it depends on BlueSoleil version).