OK, I've spent about 18 hours of testing OpenCPN 3.3.1330 the past couple days, and I have a lot to report. I think there is definitely an issue with the way O
handles virtual COM ports
. In my case it's a virtual COM port from Bluetooth. I am not sure if this would be relevant to virtual COM ports
from USB converters.
I've bought a new Lenovo Miix 2 8" tablet which I highly recommend for chartplotter
output. It's very nicely designed, and a bright enough screen
for full daylight. It runs Windows 8.1. It even has an internal GPS
chip that works with OpenCPN - but you need petrsimon's GeolocationTCP utility
to use it.
In my case, I also want to pull AIS
data into O
via Bluetooth. I have done this very successfully and reliably with several other computers
running WinXP and Win7. This is my first attempt with Win8.1. With the other computers
, Microsoft Bluetooth drivers were horrible and never worked. Toshiba Bluetooth stack is far superior for Serial
Port Profile (SPP). Unfortunately, Toshiba stack will not work with the Miix's internal Bluetooth chip, (I believe) because it is located on the Serial
HCI Bus, which is different enough from Toshiba hardware
to prevent Toshiba stack from working. As more Windows tablets appear, this may become a prevalent problem, as I believe that the power management features are needed for tablet functionality ("Airplane mode" etc). Bluesoleil did not work either. So I was forced to use Microsoft Bluetooth Stack and Lenovo/Broadcom drivers.
Microsoft has greatly improved their Bluetooth support, but it is still very fragile. Bluetooth settings are scattered among multiple settings windows, COM ports disappear and reappear, multiple installs are required to get a device recognized as a needing a virtual COM port (SPP device), etc.
But once I got everything stabilized, I came to realize that O has a real problem with virtual COM ports accessed through Bluetooth. Microsoft's driver will not allow you to manually connect to a COM port. It appears that it waits for a program to open the COM port, and then the driver makes a connection through Bluetooth. If you open the "Devices and Printers" control panel
, then double-click on the Bluetooth transmitting device, you will see a map showing your computer connected to the device with a Bluetooth icon in between. A green check mark will appear if you are running a program that has opened an active connection:
This check mark is key to diagnosing any connection problems. Through a couple days of testing, I discovered that:
- TeraTerm successfully opens and maintains a steady Bluetooth connection
- XPort successfully opens and maintains a steady Bluetooth connection
- PolarCOM successfully opens and maintains a steady Bluetooth connection
But when I launch O
with the serial port configured, the check mark appears for about 2 seconds during initial launch, but then disappears. Basically, everything I tried worked successfully, but O
After I quit out of O
, launching the other programs causes them behave similarly to O
, with a check mark appearing for a couple seconds then disappearing. The only way to restore a successful connection with the other programs is to reset my Bluetooth transmitter (named AIS
in the above picture). After that, the other programs resume successful communications
with the device, until I launch OpenCPN again.
So it appears that there is an issue with O
that prevents it from opening the Bluetooth connection, and also corrupts the communications
ability of my device until I reset it.
I do not know whether other Bluetooth devices (other brands of serial-Bluetooth adapters, Globalsat BT-368 or 821, etc) have similar problems. But after seeing every other program work and O
fail, I believe that there is an issue with the way O
makes its connections to virtual serial ports.