OpenCPN not recognising Virtual COM port

[wingssail]

Yes, I am having the same problem. I just created a Flyspray for it (FS1264). My Device (GT1819N Android Phone with BTGPS App) passes NMEA data to HyperTerminal, not OpenCPN.

[wingssail]

The fact that the virtual com port (Com13-standard serial over bluetooth link on my system) shows in device manager, HyperTerminal handles it, and also, using windows explorer, files can be transferred back and forth to the device, indicates to me that windows8 and some PC software (such as HyperTerminal) can access this virtual com port . Makes me think the problem is in the way which OpenCPN looks for the com ports.

I'd love to be using a BU353 for a spare GPS source, unfortunately they don't seem to be available in Colombia, (my current port) and shipping to here is both expensive and problematic due to customs issues.

[bdbcat]

Wingsail....

What version of OpenCPN are you using?

Dave

[wingssail]

Version 3.2.0 Build 2013-02-26

[RhythmDoctor]

Originally Posted by bdbcat

Kobe....

The problems with RFCOMM BT interface on Windows are many. The main issue is that Windows provides no useful error messages to help users or developers to figure out what is going on when it doesn't work. We get INVALID_HANDLE_VALUE, and that is it.

Actually, the problem is usually with the device's virtual device driver, not with MS code. And the drivers are unsupported and often quite buggy.

We can usually tweak something to make a specific device work, if we have access to the hardware. Not possible in the this case. So any changes we try for your hardware will be true shots in the dark.

Sorry....
Dave

I am joining this thread very late, but I should point out that I had many difficulties with the Microsoft Bluetooth stack on my WinXP netbook. I could never get it to function reliably when I was testing it a few years ago. However, I found out that my netbook's Bluetooth chip was made by Toshiba, and installed the Toshiba stack (v8), which is SO MUCH NICER than Microsoft's. So one possible solution might be to find a USB Bluetooth dongle that uses the Toshiba chip, so you can use their driver software.

Even with Toshiba stack, things aren't completely perfect for me. If you search around you'll see some exchanges between Dave and me from this past spring about BSOD errors that only went away when I used XPort to reroute one of my two Bluetooth COM ports to a different location.

Now that my netbook is showing some signs of age, I have to update my research on all the Bluetooth problems since I'll end up replacing it with a Windows 8 tablet (probably Asus Transformer T100). That one doesn't have Toshiba Bluetooth, so I hope Microsoft has improved their native Bluetooth support.

And I really don't want to eliminate Bluetooth, since I've got the boat transmitting GPS and AIS through two industrial-strength Bluetooth transmitters, and I like being able to monitor both from any computer, tablet, or cell phone anywhere in the both without having to hard-wire. With the new SailTimer wireless windvane transmitting via Bluetooth 4, support of Bluetooth protocol will be more important than ever. OpenCPN's Bluetooth issues are worth fixing IMO.

[bdbcat]

Folks....

OpenCPN Beta Version (currently 3.3.1117) has improved support for BT device detection and setup. We think we have ironed out the difficulties, but have limited hardware examples to test with.

So, we definitely request all interested BT users to try this version, and report results.

Thanks
Dave

[RhythmDoctor]

Originally Posted by bdbcat

Folks....

OpenCPN Beta Version (currently 3.3.1117) has improved support for BT device detection and setup. We think we have ironed out the difficulties, but have limited hardware examples to test with.

So, we definitely request all interested BT users to try this version, and report results.

As I mentioned, I have Toshiba bluetooth on my netbook, so it's a totally different (and better) set of Bluetooth drivers. But for purposes of testing in advance of buying a new Win8 tablet, I've ordered a Broadcom Bluetooth 4.0 adapter that I will insert into my Bluetooth-less Win7 laptop. That will give me a chance to test both the Microsoft drivers, and the Broadcom-supplied drivers. I'll let you know how it goes.

[RhythmDoctor]

Originally Posted by bdbcat

Folks....

OpenCPN Beta Version (currently 3.3.1117) has improved support for BT device detection and setup. We think we have ironed out the difficulties, but have limited hardware examples to test with.

So, we definitely request all interested BT users to try this version, and report results.

OK, I finished an initial test today, and learned a lot.

Objective: I've had OpenCPN working on my aging MSI Wind netbook under Windows XP. I connect two Bluetooth transmitters, emulating COM41 @ 4800 (GPS) and COM40 @38400 (AIS). This system has worked well, but is showing its age, and I'm considering the Asus T100 Win8 tablet as a replacement. While awaiting that, I wanted to test on another computer to see if Microsoft has improved their generic Bluetooth support at all, or if I need to find some other software when the Asus arrives.

Environment: For this test I used my cheapo work laptop, a Dell E5430 with Windows 7 Enterprise 64 bit. There is no internal Bluetooth, but I have a bunch of generic $2 Bluetooth 2.0 USB half-moon adapters from DealExtreme sitting around that I've never been able to get to work previously. I was hoping that maybe the updated MS Bluetooth stack would make them work. Before doing anything, I updated O from 3.2.2 to 3.3.1117.

I installed the generic Bluetooth adapter into the USB port, and the system recognized it an installed the Microsoft generic drivers. When I looked at the version it referenced a revision date of 2006, which surprised me a bit. I tried doing a driver update, but Windows told me it was up to date. It looks like it might not be any better than before.

What followed was total hell. I tried connecting to the first Bluetooth adapter, which looked like it succeeded but created two COM ports (COM4 and COM5). Not sure why it created two. I connected the second adapter, and it created two more (COM6 and COM7). I adjusted the first two to 4800 and the second two to 38400 bps through Bluetooth settings. I went into O and tried connecting to them, but nothing came up. I tried different baud rates. I pulled out the USB dongle and reinserted it, and tried to reconnect to the transmitters and could not. I rebooted (which took 20 minutes on this stupid laptop that is so totally choked with corporate bloatware that 70% of memory is used before I even open an app). I tried re-establishing the connections with the BT transmitters and succeeded, but it would not map any COM ports this time. So not only is it a bad result, but it's different each time I try it.

My MSI netbook came with Toshiba Bluetooth stack 5.0, which worked better than Microsoft but still not perfectly. So I upgraded to 8.0, which worked great. But all along I thought that Toshiba stack was limited to Toshiba hardware. But today I saw some comments online that Toshiba stack can work with Broadcom chips and other generic hardware. So I downloaded a 64 bit version of the Toshiba stack 8.00.12 and installed it. It worked flawlessly just like on my Netbook, mapping to COM40 and COM41.

I launched O, did the COM port mapping through the communications settings with NMEA debug window enabled, and both GPS and AIS came through perfectly. Easy!

I can't begin to tell you how disappointed I (still) am in Microsoft's Bluetooth software, and how much better the Toshiba software is. Through reading online, I learned that Broadcom has their own stack as well. I downloaded it, but don't want to try it right now because I'm so happy with the Toshiba stack.

So when I get my new Asus T100 (with Windows 8), one of the first things I am going to do is look for some 3rd party Bluetooth software. I am not sure that Toshiba's software is Bluetooth 4.0 compatible (yet), so I need to check that out before using it. I will definitely need support for low-power BLE mode, because the new SailTimer wind vane that's coming out next spring transmits in low-power mode. I'll have to look around.

In the meantime, I would strongly suggest anyone having problems with Bluetooth on OpenCPN try the Toshiba stack and see if it works. I suspect it may solve 80-90% of the problems people are having.

As far as improvements to version 3.3.1117, I could not run an overnight test because I don't have shore power available on my boat this winter. Under 3.2.2, I was having BSOD errors after a few hours unless I used XPort to remap COM41 to COM12. We were never able to figure that one out.

I did notice that version 3.3.1110 connected with COM40 and COM41 with no tweaking of the .INI file. Under previous versions, I needed to add WindowsComPortMax=42 in the INI file to get this to work. (Oops, it may be premature to conclude this. I need to make sure I can get COM41 working in full duplex to send out autopilot commands, which I did not have time to do. I'll test this out next time I'm at the boat.)

[mkconway]

Hi all,

I am trying to get OpenCPN (v. 3.0.2) on my laptop running Windows 8 to recognize a GPS through a ShipModul miniplexer-BT over a bluetooth connection (using a BT USB adaptor). I can tell that the laptop is pairing with the multiplexer, and I've installed the ShipModul driver. I don't really know what to do with this application- MiniPlex Configuration Tool, but it seems as though it is receiving information from the multiplexer when it is on and paired with the computer.

However, when I go into the ToolBox in OpenCPN, on the GPS tab, I don't see any good choices under NMEA options. Am I missing a step? I've followed directions for the port settings in Device Manager as well.

I've just downloaded O 3.2.2, and will try it out. Should I also try 3.3.? I'm also thinking about trying the Toshiba driver as suggested.

Any suggestions would be appreciated!

Thanks a lot,
Margaret

[bdbcat]

Margaret....

OpenCPN V3.0 and 3.2 has some trouble with the shipmodul....

Please try the current Beta 3.3.1117. It should work, and if it does (or doesn't), we would appreciate the feedback.

Please try with MS stack first. Also, more reports on Toshiba stack would be appreciated.

Thanks
Dave

[RhythmDoctor]

I need to add a few more comments based on what I've learned the last few days.

First, and most importantly, it does appear that you need to have Toshiba hardware to use their drivers. Today when I moused over my work laptop (the one with the DealExtreme generic bluetooth dongle), I saw a pop-up that said "Evaluation Version. The evaluation has 27 days remaining." I would have never noticed this if I hadn't accidentally moused over the Bluetooth icon. There was no warning about this during installation. Apparently if your hardware is not made by Toshiba, the stack will install but only for a temporary trial. I saw some speculation online that they do this to demo the software for developers, apparently in hopes that manufacturers will license their software and/or hardware.

So my original statement was correct - my MSI netbook does, in fact, have Toshiba hardware (or at least, they have a license to use their drivers). I looked on the MSI download area and confirmed that their Bluetooth software is the Toshiba software. They provide version 6, but I found that version 8 works better.

You might want to think twice before putting too much effort into installing the Toshiba stack.

I am gradually learning more than I want to know about Bluetooth. I should point out that I do not have an off-the-shelf Bluetooth GPS (like the Globalsat or Shipmodul multiplexer). I have a wired puck (Garmin 18xLVC) hard-wired directly to my VHF radio, and a wire tapped into that to feed the NMEA into a serial-Bluetooth converter made by USConverters. That's what transmits my GPS coordinates to my netbook. Apparently the transmitting device needs to present itself to the host as a serial device (as opposed to earpiece, stereo headphones, etc.). SPP is the acronym for Serial Port Profile, and there are other acronyms for the other profiles. Since the vast majority of people want headsets or headphones, most drivers support those things, but may not support more arcane things like serial emulation. Since my transmitter is a serial device, it's pretty clear that it would want to convert back to serial emulation at the computer end, so things have worked pretty well. I'm not sure if the other devices do the same thing, or perhaps want to emulate a WiFi network or other type of communications device.

[RhythmDoctor]

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 did not.

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.

[bdbcat]

RythmDoctor...

1. When it connects and then drops after about two seconds, what does the OCPN log say about the COM port that is Bluetooth?

I believe and appreciate your test results. For information, we have been chasing this problem literally for years. Technically, there is no difference between the API to open a COM port, and the same API to open a virtual COM port. That is the whole point of the convoluted SPP and USB stack. From the application's viewpoint, a COM port is a COM port. The physical layer (BT, USB dongle, port capture redirection, or plain-old serial port) is not evident at the application layer, but is administered by the OS

But, as demonstrated, something is obviously different.

Some have suggested that one needs to wait a few seconds for the BT link to be established while opening a BT virtualized COM port. But the MS API to open a COM port has no such facility to specify the wait time. All we can do is try to open the port, wait for the underlying OS to do its thing (i.e. establish the BT SPP link), and report success or failure.

In the BT failure case, what is not clear is if the port is ever actually established, and aborts later, or if the port never gets established at all.

I'll check again, but the only BT hardware I have ( a cheap GPS module) works fine on WIN7, after stabilizing with several reboots as you remark above.

Any WIN gurus invited to contribute....

Mystified....

Dave

[LifePart2]

Just a thought: since PolarCom, and some other utilities, have obviously figured this out, would it be worth while tracking down the guys behind that and see if they can help sort this out? After all, if you keep doing what you have always done and expect different results, it is time to check you in somewhere nice and cosy.

No, seriously, maybe one or other of the O developers could email or phone some of the PolarCom guys. Probably in not a lot of time this could then get resolved.

Just a suggestion.

[RhythmDoctor]

Originally Posted by bdbcat

RythmDoctor...

1. When it connects and then drops after about two seconds, what does the OCPN log say about the COM port that is Bluetooth?

I believe and appreciate your test results. For information, we have been chasing this problem literally for years. Technically, there is no difference between the API to open a COM port, and the same API to open a virtual COM port. That is the whole point of the convoluted SPP and USB stack. From the application's viewpoint, a COM port is a COM port. The physical layer (BT, USB dongle, port capture redirection, or plain-old serial port) is not evident at the application layer, but is administered by the OS...

Dave,

I realize that this has been elusive, but for the first time I am starting to get repeatable, well-defined failures instead of a series of random events. I have workarounds for these issues using PolarCOM and XPort (which, fortunately, works fine under my 32-bit version of Win8.1). But because things seem to be becoming more well-defined, I want to provide the information. It's up to you whether to pursue it further.

And, like you, I have not had this problem with my other Bluetooth GPS, which in my case is my Android phone with "GPS over BT" app.

For me, this issue requires three specific conditions: My Bluetooth-serial transmitter, Windows Bluetooth stack, and OpenCPN. If I change any one of those three, the problem does not occur. Previously I circumvented the problem by using the Toshiba stack. But I cannot do that now because other stacks aren't seeing the tablet's Bluetooth radio on the serial HCI bus. (I did get Toshiba stack working on this tablet with a USB BT dongle, but that takes up the only microUSB port, thus preventing charging.)

I want to re-emphasize one key difference between the Windows and Toshiba stacks. With the Toshiba software, the Bluetooth connection is opened by the stack, and kept open until manually disconnected, even if there is no data actively flowing through the connection. The virtual COM port is not opened by this acction - it seems to be made available to programs on a "first come first served" basis. But throughout, the Bluetooth connection is maintained. If a program closes, the BT connection is maintained, but the COM port is made available to other programs. OTOH, the Windows stack does not establish a BT connection until a program opens the COM port. And it looks like the Windows stack monitors whether any data is passing through the connection, and closes the BT port if there's no data - EVEN IF THE PROGRAM STILL HAS THE COM PORT OPEN. So building in a delay after opening the port might be the exact wrong thing to do.

Another observation, and this is critical: after my Bluetooth-serial adapter is "corrupted" by OpenCPN (i.e., disabling its transmission of data), I need to reset the adapter to re-enable Bluetooth access from the other apps. Rebooting the computer has no effect in this case - the issue is entirely caused by a disabling of my BT adapter's data transmission, and fixed by a reset of the adapter. I have handshaking and flow control turned off at both ends, but wonder if there is some other data trasmitted by OpenCPN to the BT transmitter that is stopping its data transmission.

Here are two logs that I made just for you, under carefully controlled conditions. The first is immediately after a fresh reset of my Bluetooth transmitter, and a fresh reboot of my computer (just in case).

21:01:56: 2014-01-19
21:01:56:  ------- Starting OpenCPN -------
21:01:56: Version 3.3.1303 Build 2014-01-03
21:01:56: wxWidgets version: wxWidgets 2.8.12
21:01:56: MemoryStatus:  mem_total: 1931 mb,  mem_initial: 8 mb
21:01:56: SData_Locn is E:\Sailboat\OpenCPN-Master\
21:01:56: Using existing Config_File: E:\Sailboat\OpenCPN-Master\opencpn.ini
21:01:56: Styles loading from E:\Sailboat\OpenCPN-Master\uidata\styles.xml
21:01:56: No styles found at: E:\Sailboat\OpenCPN-Master\
21:01:56: No styles found at: E:\Sailboat\OpenCPN-Master\.opencpn\
21:01:56: Setting Viewpoint Lat/Lon 39.8587, -75.2305
21:01:56: Setting Ownship Lat/Lon 39.8585, -75.2941
21:01:56: System default Language:  en_US
9:01:56 PM: Opencpn language set to:  en_US
9:01:58 PM: ChartSymbols loaded from .\s57data\chartsymbols.xml
9:01:58 PM: Using s57data in .\s57data
9:01:58 PM: Setting Viewpoint Lat/Lon 39.8587, -75.2305
9:01:58 PM: Setting Ownship Lat/Lon 39.8585, -75.2941
9:01:58 PM: Opening NMEA Datastream Serial:COM3
9:01:59 PM: Creating glChartCanvas
9:02:00 PM: PlugInManager searching for PlugIns in location E:\Sailboat\OpenCPN-Master\plugins
9:02:00 PM: PlugInManager: Loading PlugIn: E:\Sailboat\OpenCPN-Master\plugins\dashboard_pi.dll
9:02:00 PM:   E:\Sailboat\OpenCPN-Master\plugins\dashboard_pi.dll Version detected: 106
9:02:00 PM: PlugInManager: Loading PlugIn: E:\Sailboat\OpenCPN-Master\plugins\grib_pi.dll
9:02:00 PM:   E:\Sailboat\OpenCPN-Master\plugins\grib_pi.dll Version detected: 107
9:02:00 PM: PlugInManager: Loading PlugIn: E:\Sailboat\OpenCPN-Master\plugins\ocpndebugger_win32_pi18_v01_pi.dll
9:02:00 PM:   E:\Sailboat\OpenCPN-Master\plugins\ocpndebugger_win32_pi18_v01_pi.dll Version detected: 108
9:02:00 PM: PlugInManager: Loading PlugIn: E:\Sailboat\OpenCPN-Master\plugins\vdr_win32_pi16_v03_pi.dll
9:02:00 PM:   E:\Sailboat\OpenCPN-Master\plugins\vdr_win32_pi16_v03_pi.dll Version detected: 106
9:02:00 PM: ChartDB Cache policy:  Application target is 965 MBytes
9:02:00 PM: Loading chart db version: V017
9:02:00 PM: Chartdb: Chart directory list follows
9:02:00 PM:   Chart directory #0: E:\Sailboat\NOAA Nautical Charts\03-04Local_RNCs
9:02:00 PM:   Chart directory #1: E:\Sailboat\NOAA Nautical Charts\03-04Distant_RNCs
9:02:00 PM:   Chart directory #2: E:\Sailboat\NOAA Nautical Charts\03-04Local_ENCs
9:02:00 PM:   Chart directory #3: E:\Sailboat\NOAA Nautical Charts\03-04Distant_ENCs
9:02:01 PM: GPS Watchdog Timeout is: 6 sec.
9:02:01 PM: NMEA input device open failed: COM3...GetLastError():  1168
9:02:01 PM: Initializing Chart E:\Sailboat\NOAA Nautical Charts\03-04Local_RNCs\12312\12312_1.KAP
9:02:01 PM: Initializing Chart E:\Sailboat\NOAA Nautical Charts\03-04Local_RNCs\12313\12313_1.KAP
9:02:02 PM: Initializing Chart E:\Sailboat\NOAA Nautical Charts\03-04Local_RNCs\12313\12313_2.KAP
9:02:02 PM: Initializing Chart E:\Sailboat\NOAA Nautical Charts\03-04Local_RNCs\13003\13003_1.KAP
9:02:20 PM: PlugInManager: Deactivating PlugIn: E:\Sailboat\OpenCPN-Master\plugins\dashboard_pi.dll
9:02:20 PM: PlugInManager: Deactivating PlugIn: E:\Sailboat\OpenCPN-Master\plugins\vdr_win32_pi16_v03_pi.dll
9:02:20 PM: opencpn::MyFrame exiting cleanly.
9:02:20 PM: Closing NMEA Datastream Serial:COM3
9:02:21 PM: Chart cache purge
9:02:21 PM: PlugInManager: UnLoading PlugIn: E:\Sailboat\OpenCPN-Master\plugins\dashboard_pi.dll
9:02:21 PM: PlugInManager: UnLoading PlugIn: E:\Sailboat\OpenCPN-Master\plugins\grib_pi.dll
9:02:21 PM: PlugInManager: UnLoading PlugIn: E:\Sailboat\OpenCPN-Master\plugins\ocpndebugger_win32_pi18_v01_pi.dll
9:02:21 PM: PlugInManager: UnLoading PlugIn: E:\Sailboat\OpenCPN-Master\plugins\vdr_win32_pi16_v03_pi.dll
9:02:21 PM: Chart cache purge
9:02:21 PM: LOGBOOK:  2014-01-20 02:02:21 UTC OFF: Lat   39.85850 Lon  -75.29410
9:02:21 PM: opencpn::MyApp exiting cleanly...

This second log is after a re-launch of OpenCPN without and reset of the BT transmitter. You'll see that the error message is different:

21:02:30: 2014-01-19
21:02:30:  ------- Starting OpenCPN -------
21:02:30: Version 3.3.1303 Build 2014-01-03
21:02:30: wxWidgets version: wxWidgets 2.8.12
21:02:30: MemoryStatus:  mem_total: 1931 mb,  mem_initial: 8 mb
21:02:30: SData_Locn is E:\Sailboat\OpenCPN-Master\
21:02:30: Using existing Config_File: E:\Sailboat\OpenCPN-Master\opencpn.ini
21:02:30: Styles loading from E:\Sailboat\OpenCPN-Master\uidata\styles.xml
21:02:30: No styles found at: E:\Sailboat\OpenCPN-Master\
21:02:30: No styles found at: E:\Sailboat\OpenCPN-Master\.opencpn\
21:02:31: Setting Viewpoint Lat/Lon 39.8587, -75.2305
21:02:31: Setting Ownship Lat/Lon 39.8585, -75.2941
21:02:31: System default Language:  en_US
9:02:31 PM: Opencpn language set to:  en_US
9:02:32 PM: ChartSymbols loaded from .\s57data\chartsymbols.xml
9:02:32 PM: Using s57data in .\s57data
9:02:32 PM: Setting Viewpoint Lat/Lon 39.8587, -75.2305
9:02:32 PM: Setting Ownship Lat/Lon 39.8585, -75.2941
9:02:32 PM: Opening NMEA Datastream Serial:COM3
9:02:33 PM:    Error, comm port open failure, INVALID_HANDLE_VALUE, Datastream skipped.
9:02:33 PM: Creating glChartCanvas
9:02:33 PM: PlugInManager searching for PlugIns in location E:\Sailboat\OpenCPN-Master\plugins
9:02:33 PM: PlugInManager: Loading PlugIn: E:\Sailboat\OpenCPN-Master\plugins\dashboard_pi.dll
9:02:33 PM:   E:\Sailboat\OpenCPN-Master\plugins\dashboard_pi.dll Version detected: 106
9:02:33 PM: PlugInManager: Loading PlugIn: E:\Sailboat\OpenCPN-Master\plugins\grib_pi.dll
9:02:33 PM:   E:\Sailboat\OpenCPN-Master\plugins\grib_pi.dll Version detected: 107
9:02:33 PM: PlugInManager: Loading PlugIn: E:\Sailboat\OpenCPN-Master\plugins\ocpndebugger_win32_pi18_v01_pi.dll
9:02:33 PM:   E:\Sailboat\OpenCPN-Master\plugins\ocpndebugger_win32_pi18_v01_pi.dll Version detected: 108
9:02:33 PM: PlugInManager: Loading PlugIn: E:\Sailboat\OpenCPN-Master\plugins\vdr_win32_pi16_v03_pi.dll
9:02:33 PM:   E:\Sailboat\OpenCPN-Master\plugins\vdr_win32_pi16_v03_pi.dll Version detected: 106
9:02:33 PM: ChartDB Cache policy:  Application target is 965 MBytes
9:02:33 PM: Loading chart db version: V017
9:02:33 PM: Chartdb: Chart directory list follows
9:02:33 PM:   Chart directory #0: E:\Sailboat\NOAA Nautical Charts\03-04Local_RNCs
9:02:33 PM:   Chart directory #1: E:\Sailboat\NOAA Nautical Charts\03-04Distant_RNCs
9:02:33 PM:   Chart directory #2: E:\Sailboat\NOAA Nautical Charts\03-04Local_ENCs
9:02:33 PM:   Chart directory #3: E:\Sailboat\NOAA Nautical Charts\03-04Distant_ENCs
9:02:34 PM: GPS Watchdog Timeout is: 6 sec.
9:02:34 PM: Initializing Chart E:\Sailboat\NOAA Nautical Charts\03-04Local_RNCs\12312\12312_1.KAP
9:02:34 PM: Initializing Chart E:\Sailboat\NOAA Nautical Charts\03-04Local_RNCs\12313\12313_1.KAP
9:02:35 PM: Initializing Chart E:\Sailboat\NOAA Nautical Charts\03-04Local_RNCs\12313\12313_2.KAP
9:02:35 PM: Initializing Chart E:\Sailboat\NOAA Nautical Charts\03-04Local_RNCs\13003\13003_1.KAP
9:02:47 PM: PlugInManager: Deactivating PlugIn: E:\Sailboat\OpenCPN-Master\plugins\dashboard_pi.dll
9:02:47 PM: PlugInManager: Deactivating PlugIn: E:\Sailboat\OpenCPN-Master\plugins\vdr_win32_pi16_v03_pi.dll
9:02:47 PM: opencpn::MyFrame exiting cleanly.
9:02:47 PM: Closing NMEA Datastream Serial:COM3
9:02:47 PM: Chart cache purge
9:02:48 PM: PlugInManager: UnLoading PlugIn: E:\Sailboat\OpenCPN-Master\plugins\dashboard_pi.dll
9:02:48 PM: PlugInManager: UnLoading PlugIn: E:\Sailboat\OpenCPN-Master\plugins\grib_pi.dll
9:02:48 PM: PlugInManager: UnLoading PlugIn: E:\Sailboat\OpenCPN-Master\plugins\ocpndebugger_win32_pi18_v01_pi.dll
9:02:48 PM: PlugInManager: UnLoading PlugIn: E:\Sailboat\OpenCPN-Master\plugins\vdr_win32_pi16_v03_pi.dll
9:02:48 PM: Chart cache purge
9:02:48 PM: LOGBOOK:  2014-01-20 02:02:48 UTC OFF: Lat   39.85850 Lon  -75.29410
9:02:48 PM: opencpn::MyApp exiting cleanly...