GPS Dropping Out

[djmarchand]

Hello all:

I am running OpnCPN 2.1.0 on a Toshiba netbook under Win 7 with a BU-353 hockey puck gps plugged into a usb port as com5.

The GPS starts up fine with OpnCPN but after 5-50 minutes it drops out. The gps has a full view of the sky. Once it drops out it is very difficult to reengage. Closing and reopening OpnCN sometimes works, shifting to another usb com port sometimes works, but often I have to reboot.

Once the GPS drops out if I close OpnCPN and run the GPSinfo utility, the GPS is always active.

Any ideas?

David

PS: An excerpt of the last log session where the GPS dropped out after 30+/- minutes follows:

12:07:09: 2010-11-01
12:07:09: -------Starting opencpn-------
12:07:09: Version 2.1.0 Build 624a
12:07:09: SData_Locn is C:\Program Files\OpenCPN\
12:07:09: Using existing Config_File: C:\Users\David\AppData\Roaming\opencpn\opencpn.ini
12:07:09: Setting Viewpoint Lat/Lon 33.6169, -117.886
12:07:09: Setting Ownship Lat/Lon 33.6163, -117.886
12:07:09: System default Language: en_US
12:07:09 PM: Opencpn language set to: en_US
12:07:09 PM: Using s57data in C:\Program Files\OpenCPN\s57data
12:07:09 PM: Using Tide/Current data from: C:\Program Files\OpenCPN\tcdata\
12:07:09 PM: Setting Viewpoint Lat/Lon 33.6169, -117.886
12:07:09 PM: Setting Ownship Lat/Lon 33.6163, -117.886
12:07:09 PM: NMEA Data Source is....Serial:COM5
12:07:10 PM: AIS Data Source is....None
12:07:10 PM: Using WVSChart datafile: C:\Program Files\OpenCPN\wvsdata\wvs43.dat
12:07:10 PM: NMEA AutoPilot Port is....None
12:07:10 PM: OpenPD: 296, new_count = 1 for COM5
12:07:10 PM: Loading chart db version: V016
12:07:10 PM: Chart directory C:\Users\David\Documents\MD_RNCs[1]
12:07:10 PM: Chart directory C:\Users\David\Documents\CA_RNCs[1]
12:07:10 PM: Chart directory C:\Users\David\Documents\VA_RNCs[1]
12:07:11 PM: GPS Watchdog Timeout is: 6 sec.
12:07:11 PM: Initializing Chart C:\Users\David\Documents\CA_RNCs[1]\BSB_ROOT\18754\18754_1.KAP
12:07:11 PM: Initializing Chart C:\Users\David\Documents\CA_RNCs[1]\BSB_ROOT\18746\18746_1.KAP
12:07:12 PM: Initializing Chart C:\Users\David\Documents\CA_RNCs[1]\BSB_ROOT\18740\18740_1.KAP
12:07:13 PM: Initializing Chart C:\Users\David\Documents\CA_RNCs[1]\BSB_ROOT\18022\18022_1.KAP
12:07:15 PM: Initializing Chart C:\Users\David\Documents\CA_RNCs[1]\BSB_ROOT\18020\18020_1.KAP
12:07:16 PM: Initializing Chart C:\Users\David\Documents\CA_RNCs[1]\BSB_ROOT\501\501_1.KAP
12:07:16 PM: Initializing Chart C:\Users\David\Documents\CA_RNCs[1]\BSB_ROOT\530\530_1.KAP
12:07:18 PM: Initializing Chart C:\Users\David\Documents\CA_RNCs[1]\BSB_ROOT\50\50_1.KAP
12:08:10 PM: LOGBOOK: 2010-11-01 19:08:10 UTC GPS Lat 33.61626 Lon -117.88564 COG 152.38000 SOG 0.12
12:30:00 PM: LOGBOOK: 2010-11-01 19:30:00 UTC GPS Lat 33.61628 Lon -117.88566 COG 171.82000 SOG 0.11
1:00:00 PM: LOGBOOK: 2010-11-01 20:00:00 UTC DR Lat 33.61628 Lon -117.88566
1:11:56 PM: opencpn::MyFrame exiting cleanly.
1:11:57 PM: ClosePD: 296, count_after_close = 0 for COM5
1:11:57 PM: and so CloseComPortPhysical
1:11:58 PM: LOGBOOK: 2010-11-01 20:11:58 UTC OFF: Lat 33.61628 Lon -117.88566
1:11:58 PM: opencpn::MyApp exiting cleanly...

[djmarchand]

I may have discovered the problem and the fix. The GPS has been running for more than an hour without dropping out. Here is what I think was causing it and what I did about it:

Windows 7 (don't know about other versions) turns off power to USB devices. I don't know when or why. But you can defeat that by going into device manager and with the proper USB Root Hub device click on it and then power management. Then unclick the box that says allow the computer to turn off power to this device. Then click ok to apply it and exit.

This change seems to allow the usb to continuously power the gps and not drop out periodically. Why the gps was still active when I closed OpnCPN and then used the GPSinfo utility I don't know. Presumably power was returned to the usb port and the GPS started working again. But when I restarted OpnCPN the gps didn't work.

So, one the question remains, how to quickly restore GPS functionality to OPNCpn if power is cut off to the GPS, you unplug it or whatever without rebooting the whole computer.

David

[bgmaxlow]

I use Curious Tech's Xport program -and it works brilliantly !XPort

Blurb from their website (you'll be interested in the text in bold :-)
<LI class=style4>New interface for easy access to GPS data. Develop GPS applications quickly. Unlimited direct connections. No buffers. No delays. Even allows XPort to be closed while apps are running. Finding GPS, baud rate, COM port reading, NMEA/SiRF parsing, and hibernation/standby handling is a thing of the past!

[claire]

I have the same problem with the GPS dropping out on Opencpn R2.1.0 under W7. I did disable the power saving on all the USB hubs as suggested above, however my gps keeps dropping out after about 90mn. Note that the laptop is set to never go to sleep.

[djmarchand]

I am the OP on this thread. After reading claire's post I was curious if I had really solved the problem, so I set my system up to run for an extended period. After 1 hour it was still going strong. But sometime between one and two hours the gps froze. Almost as irritating is that it is very difficult to get it back, usually requiring a system reboot.

I then went back and checked my power setting for that port. It was back to turning off power. I can only assume that a system reboot resets all of the settings to their default.

After reading claire's post and the extensive chatter on a similar thread, this seems to be a real bug and until fixed makes OpnCPN unusable for me in the real world of boating.

David

[CarCode]

David,

try out PolarCOM (it is free from Polar Navy - Marine Navigation Software ) and see if you have the same problems.
If yes, it is a problem with your Windows or hardware.
Otherwise it might be a bug in OpenCPN.

Gerhard

[bdbcat]

Hi folks....
Sorry for the problems with BU-353 and Win7.
I do not have the right hardware to duplicate this error, so the debugging and iterative releasing is a bit like pushing on a rope. It is a slow process.

But lets be sure of some basic assumptions first.

1. I assume the BU-353 is really a serial device with an embedded Prolific USB-Serial converter chip. When it is working, that's what it looks like. Maybe (not sure here) it needs 9600 baud?)
2. If that is the case, the BU-353 driver is really nothing more than a Prolific USB-Serial converter driver. The BU353 needs nothing from opencpn to start transmitting generic NMEA positioning data.
3. OK so far?
4. If OK, what is the version or other identification of the BU353 supplied driver that is being used when the problem occurs?
5. On the other hand, has anyone tried the most, most recent Prolific USB-Serial driver setup for this configuration? Does it work at all? Does it display the same behavior?
6. I can run a generic Prolific USB adapter with the latest Prolific driver and a generic serial NMEA GPS on Win7 (VirtualBox, linux host) indefinitely. No problems. Does anyone on Win7 use this configuration or anything like it??
7. Or, another permutation: can anyone run a generic Prolific USB-Serial adapter cable and a generic NMEA Serial GPS with the BU353 standard driver?

Any amplifications and/or corrections to the above may help us debug this problem from first principles.

Otherwise, we shall have to wait until I can get access to the affected hardware, slap some debugging tools together, and figure it out.

Thanks for the help
Dave

[djmarchand]

Dave:

Thanks for your interest in resolving this problem. This is the driver I am using:

Prolific USB to serial port comm driver (com5)
Date 11/19/2009
Version 3.310.140

I clicked on update driver and it told me that I have the most current driver.

What is puzzling is that after the GPS freezes in OpnCPN if I close it and then run GPSInfo, the GPS data is always there and active. So something causes the GPS to drop out in OpnCPN and then it stays out.

David

[fgd3]

Originally Posted by djmarchand

Dave:

What is puzzling is that after the GPS freezes in OpnCPN if I close it and then run GPSInfo, the GPS data is always there and active. So something causes the GPS to drop out in OpnCPN and then it stays out.

David

When I run GPSInfo I always have to select the com port and click "Start GPS". So when you say that when you run GPSInfo "the GPS data is always there and active" I wonder if you're forgetting to mention those two steps or if your system works differently from mine.

Fabbian

[djmarchand]

Fabbian:

Yes you are correct, my GPSInfo works the same. Does that mean that when you click "start gps" then some signal is sent to the gps to make it start sending data to the port. I doubt it. I would expect that gps data is always being sent to the usb port as long as it is plugged in and getting power. Maybe "start gps" enables that port which was somehow disabled by OpnCPN and caused the drop out.

David

[fgd3]

David:

Like you, I doubt that GPSInfo somehow "turns on" the BU-353. I suspect there is something that connects the "com port" with the USB port.

Fabbian

[champ8242]

Hi,

I have a spare Haicom HI-204 III USB GPS receiver. I've installed it yesterday on my Windows 7 machine.

W7 automatically downloaded the PL2303_Prolific_DriverInstaller_v1210 drivers and installed the GPS on COM3

OpenCPN (Version 2.2.1124 Build 2010-11-24 running VS2010 in debug mode) immediately saw incoming NMEA data when configured for COM3 and kept on running for some more than one hour when I saw the incoming data stopped. The satellite Icon (top right) was changed and the ship went from red to black.

I’ve cleared the logfile, restarted OpenCPN, same conditions. And as you can see in the logfile, after about 7 hours the NMEA data stream stopped.

I have OpenCPN running in debug mode so please let me know if I can be of help tackling this one.

Bart

[CarCode]

Dave,

the OCPN sources includes a watchdog for GPS, Heading and Sat data. It should write a line "*** xx Watchdog timeout... ***" in the log. So when GPS data stops such a line should be seen in the log. Right?

Gerhard

[bdbcat]

Champ8242...

Are you running VS2008 and compiling from source?

We can try this:
Edit the opencpn.ini file. Add this:

[Settings]
DebugNMEA=100000

Run as normal. The logfile will be very large, with lots of detail regarding the NMEA thread. Most of it will be of no use, until we stop working. The last messages before stopping may be useful. You will want to edit the log before posting, since it will be so large. Hopefully it will fail quickly, so that the log does not consume your disk.

If you are running VS2008, you can break the program whenever you see that the NMEA data has stopped, and take a look at the status of the running threads. One of the opencpn threads is doing overlapped serial IO, and seems to probably be stalled for some reason. This also may be useful. This is what I would do if I had the environment.

Carcode's comment is useful. If DebugNMEA is set in the .ini file, we should see the notification in the log. This happens in chart1.cpp around line 4618.

I begin to think that the problem is generic to Prolific USB/Serial converters, and not specific to BU353. I have one set up on a Win7 virtual running under linux, and cannot make it fail. Grrrrr......

I can walk you thru any of this as necessary. Online all day today.

Thanks, and good luck.
Dave

[champ8242]

Running now with 120GIG of diskspace
indeed compiled from source VS2010.

Keep you posted.
Bart

PS
Wrote today a simple serial app reading and displaying the serial (USB) port, till now without problems