GPS Dropping Out

[djmarchand]

HotRod:

From a careful reading of this thread, the problem does seem to be the Prolific chip or driver, which I guess does make the BU-353 junk.

But the GPSs you mentioned are all NMEA 2000 devices and would require a NMEA/USB converter much less the $249 MSRP of the Garmin GPS 17X.

My piece of junk BU-353 cost something like $35 and I had hoped with OpnCPN and my netbook would give me a nice chartplotter system. I think I'll wait and hope that someone solves the problem.

If any of you developers needs a BU-353 to test and try to come up with a solution, I will gladly mail mine to you. It isn't doing me any good.

David

[CarCode]

David,

you are right. The Prolific stuff works with some computer hardware and with others not. It might have to do with the fifo buffer used, see the messages above, which loses bytes when not exactly configured and shows therefore perhaps different behavior with different operating systems and/or computer hardware.
Because of that it will be very hard to find a general solution for any constellation. So do not expect a workaround for this. For myself I use a Bluetooth GPS mouse which works nice with any computer hardware equipped with Bluetooth.

Gerhard

[fgd3]

David, I don't think you can blame the BU-353 when OpenCPN fails to see data from it but other applications do see the data. I have also experienced a loss of GPS data with a Garmin GPS72 connected through a USB/RS-232 converter. In fact, the reason I switched to the BU-353 was to eliminate the converter and avoid having to run a separate power line to the GPS.

HotRod wrote "As far as I know, OpenCPN is not litening for a GPS signal, but for the GPS sentences from the GPS." Right. I wrote about OpenCPN getting or not getting a GPS signal but what I meant by that was it was not seeing data from the GPS. I hope that didn't cause any confusion.

It's my opinion that the problem is not the loss of GPS data so much as the failure to re-establish communication. If OpenCPN automatically restored communication with the GPS when it detected a loss of GPS data the user wouldn't even be aware of the problem. If OpenCPN posted a message when it detected a loss of GPS data and offered the user the option of restoring communication users wouldn't be nearly as frustrated.

Of course, it's hard to come up with a reliable way to restore communication if you don't know why the communication is breaking down.

Fabbian

[bdbcat]

Gang....

Good work so far on trying to characterize this problem. All very helpful.

Here is a test that I would like to see in simple bare terms:

1. Start OpenCPN with BU353, or any other serial NMEA GPS using a Prolific Serial/USB adapter.

2. Wait for GPS drop out.

3. Stop Opencpn normally.

4. Open Device manager. Is the Prolific virtual serial port still shown in the list?

5. If NOT shown, the OS and driver have, for some reason, simply dropped the interface stack. To OpenCPN this looks like a hot-unplug event, and we don't (yet) handle this well. I don't really consider this to be an OpenCPN issue of first order, although we do need to get hotplugging/unplugging working. That is a separate issue, I think.

6. If Virtual port is still shown as available, open Hyperterminal, or other similar comm program. Look for an NMEA data stream.

7. If data stream is running at this point, then OpenCPN has a clear fault. Its receive thread is stalling, and this needs to be fixed.
An OpenCPN restart should work fine at this point, btw.

8. If no data is seen in Hyperterminal at this point, then the problem is in either the Prolific driver or the NMEA data source upstream of it.

9. If not data seen in Hyperterminal, then unplugging/replugging USB cable may reset the driver stack. Try this, then OpenCPN start as normal. Does it now work OK? If so, go to step 1 and repeat if desired.....

If we can look at the results of this isolated test, we can then make more judgments on how to proceed.

Awaiting results.....
Dave

[hellosailor]

cagney-
"How come there is no problems on Linux with the prolific driver?"
Different OS, totally different driver. You might as well ask why your TV set works with Linux and not Win7.

dj-
I would suggest that the Prolific driver is simply not written well enough for Win7 users. yes, Prolific has a good reputation but the bottom line is that companies with bigger budgets and bigger resources generally can invest more in writing and perfecting drivers. As a consumer you can look for the Windows Logo Certified equipment, with a logo and compliance certification for your specific OS. (XP, Vista, 7). This certification also means someone spent about fifty grand getting their hardware submitted and tested with the MS protocols and IT WAS CONFIRMED TO WORK with that specific OS under a wide range of test conditions.

No certification? Then it is less certain that a wide range of testing was done, less certain that the device will work properly. A crapshoot.

You can also find the HCL (Hardware Certification List) for each OS listed somewhere among MS's web sites.

An uncertified device may work perfectly well. But you, as a buyer, have one less assurance that it actually DOES work well. And they're often no more expensive, although the cheapest junk on the market, obviously, won't be wasting money on the test process at all.

[djmarchand]

Dave:

I have done the test that you propose. Here is what I have found:

When the GPS drops out under OpnCPN, the com port is gone in device manager.

When the GPS drops out under Hyperterminal, the com port is still there!!!

Unplugging and replugging the GPS doesn't restore function with either application. Only a reboot works. Maybe and I suspect that this is so, waiting a significant length of time, an hour will make it work again without rebooting.

David

[CarCode]

Hellosailor

The WHQL certification says absolutely nothing. There are enough drivers available with a hacked and stolen WHQL certification. Even a driver with a correct certification might fail with some not tested strange hardware configuration.

Gerhard

[Gypsy23]

Hello Everybody
I have been following this thread as I have just started experimenting with OpenCPN under W7 and Ubuntu. I was drawn to the thread as I purchased a BU-353 GPS 'puck' since it was highly recommended for sensitivity.

Over the past 5 days I have been running OpenCPN on 2 laptops described below. To my knowledge I have not had a GPS dropout for either system!! My tests are done indoors in my home in Sydney overlooking the bay where I moor my yacht. As the GPS units are stationary and I am not doing active navigating the test situation may not compare with the OP. However, I have left the systems running for more than 12hrs for each of 2 tests with the NMEA window scrolling so that I can see activity whenever I glance at the screens. If the GPS has stopped for a short period, it has restarted because during these tests I have always returned to OCPN and found a RED myship icon.

Here is my setup:

Fujitsu S7111
Centrino Duo 1.83GHz
2GB RAM
Windows 7 Pro (32bit)
USB-to-Serial driver – Prolific 2303 v3.3.10.140 19/11/2009

Open CPN 2.2.1111 Build 2010-11-11
CM93 ed2 May 2010


Sony VAIO PCG-R505DT
Pentium III 750MHz
320MB
Ubuntu 10.10
USB-to-Serial driver – Standard loaded with Ubuntu 10.10
OpenCPN 2.2.1111 Build 2010-11-11
CM93 ed2 May 2010


GPS
1) eTrex (Original Yellow circa 2001) NMEA output to PC via Serial>USB adaptor U232-P9 (Taiwan manufacturer unknown, circa 2002)


2) Globalsat BU-353 USB “puck”.

I ran 2 versions. 1) BU-353 connected to the VAIO running Ubuntu and eTrex connected to the Fujitsu running W7. 2) The reverse of the above, swapped over GPS units.
I ran both configs for a period of more than 12 hrs each which included 8hrs overnight. During the testing time I did occassional non OCPN work on the Ubuntu system while OCPN was running but there was no internet connectivity. I worked a lot on the Fujitsu as it is my main PC and is connected to the internet by WiFi using ASDL2+ speeds.

I did not try to import/export routes.

Just now I tried another couple of tests:
1) Start OCPN without the USB-GPS connected then plug in the USB-GPS.
Results: VAIO/Ubuntu does not 'see' the GPS when it is plugged in. I can 'see' the GPS data using a terminal program (CuteCom) with OCPN still running. Stop CuteCom, restart OCPN and it 'sees' the GPS.
Fujitsu/W7 doesn't 'see' the GPS when plugged in. I can see GPS data using a terminal program (Docklight) with OCPN still running. Stop Docklight, restart OCPN and it 'see's' the GPS.
Both systems react the same - BUT - test 2) they are different:
2) Start OCPN with GPS attached, confirm it sees the GPS then remove the GPS (unplugging USB). After a short period, 1-2 minutes with OCPN still running and showing a grey ship, hotplug the USB-GPS back into operation.
Results: VAIO/Ubuntu - recognises the GPS has returned and gives a red ship within seconds.
Fujitsu/W7 - Does NOT recognise the GPS return. Run Docklight and it 'sees' GPS data. Stop Docklight and OCPN, restart OCPN and it now 'sees' the GPS and I have a red ship.

I hope these observations are useful even if they conflict with the GPS stalling reports you have been trying to track down. I would be happy to carry out other tests if it can assist.

Readers may be interested to know how OCPN performs on the 2 different systems:
- The map movement is much faster on the Fujitsu due to higher CPU speed and greater memory. All things considered it would be a very usable system but I want to dedicate a PC for the job and I am still nervous about Windows and I don't like the long bootup time.
- I have installed a dual boot system on the VAIO, (Ubuntu and XP SP3). System speed for map movement is slower and jerky but still very usable. The response for both Ubuntu and XP is about the same. Ubuntu boots much quicker and generally appeals to me more as a dedicated ChartPlotter PC. I don't use a virus checker and will generally not be connected to the internet so I can use all CPU power and memory for OCPN. Ubuntu is my choice.

Ray

[hellosailor]

Gerhard-
The certification I'm talking about cannot be stolen or hacked. You are talking about a driver certification that the OS looks for when you are installing a new driver.

I am talking about a certificate, issued by MS to a hardware maker, which is not part of any software or firmware at all. This is like a driver's license. You can't "hack" it, and there's no way to "counterfeit" it, unless you hack into Microsoft's servers and add your own device to the master list. Or do something foolish like use their certification logo on your product box, when it hasn't been certified. That might work once--but I'd expect MS to prosecute a case for fraud for each box printed that way.

i.e.: "The Microsoft Hardware Compatibility List (HCL) has been replaced by the Microsoft Windows Catalog as the premier location for locating Cluster Server hardware qualification data for Microsoft Windows 2000 and for Microsoft Windows Server 2003. All the Windows Server 2003 listings and the latest Windows 2000 listings are in the Windows Catalog. The remaining Windows 2000 listings are still on the Microsoft Hardware Compatibility List (HCL)." How to locate qualified cluster solutions for Windows

I mis-called the full name of the HCL. Mice, GPS, adapters, keyboards...even the littlest stuff is on it, not just whole computers or boxed applications.

[claire]

Ray,

I have the GPS disappearing problem and my W7 is 64 bits. I am not sure if anybody with W7/32bits has the problem.

[bdbcat]

HiHo folks....

We are still trying to determine if the problem is unique to OpenCPN, or endemic to the Prolific driver. That is the question.....

Here are some other possibly revealing tests to try.

1. On Win7 with Prolific USB/Serial converter cable or BU353 and OpenCPN dropout problems: Does NavMonPC standing alone with one port configured run indefinitely, or does it drop out eventually?

2. Same system setup, does Hyperterminal drop out eventually?

3. Does any other GPS application drop out at all?

Before we go hacking on the OpenCPN serial interface code, we must answer this question.


Food for thought: If OpenCPN detects (by watchdog) that the NMEA data is stalled, what then? OpenCPN does not know about the Prolific device. All it knows is COM ports. We could, by some very fragile Microsoft specific code, figure out that there is a Prolific driver in the stack, and possibly try to reset the driver dynamically, and then re-open the COM port.

I resist this, unless there is no other possible solution. Why? Because a small driver change or SP update to Windows could very easily break this solution.


More food:
There is a little known Microsoft utility called devcon.exe which allows direct control of some hardware devices.

The DevCon command-line utility functions as an alternative to Device Manager

The following command line may be of some help in restarting the Prolific driver manually after a stall.

devcon.exe restart @usb\vid_067b*

or, you may build a desktop shortcut to do the same thing.

Focusing on this issue......

Thanks
Dave

[CarCode]

Originally Posted by bdbcat

Food for thought: If OpenCPN detects (by watchdog) that the NMEA data is stalled, what then?

In any case the user should be notified of the missing NMEA data. The watchdog should fire up a popup message then!

Originally Posted by bdbcat

devcon.exe restart @usb\vid_067b*

Are you shure about the correct VID number of this device?

Gerhard

[bdbcat]

CarCode...

I avoid the popup message on NMEA data loss only because it is a band-aid to a system/driver problem. In "normal" operations, the Grey ownship icon should be enough, and data flow will restart correctly when the NMEA data resumes.

067b is the VID for my Prolific-based converter cable. Do you have something different?

Dave

[CarCode]

Dave,

there are many reasons for a stopping NMEA signal, even an unplugged cable by accident...

We mostly used in our company the FTDI converter chips for our devices and these might have different VID numbers. When I understand correct the BU353 uses the chipset inside its device and this might have also another VID than the stand-alone RS232/USB Prolific converter cables.

Gerhard

[claire]

Dave,

I don't have a BU353, but I have an old Garmin GPS and a prolific adapter. I have had the disappearing GPS problem with Prolific connected to Ocpn. The longest that has run, so far, between problems, has been 4:30 h.

The following tests were done today with W7 64 bits and Ocpn R2.1.0.

First, I tested, as you requested, Prolific connected to NavMonPC: 5:30 h with no problem. At the same time, I had Ocpn running without a hitch with my ATT Option usb modem/GPS, doing some track imports/deletions at times, to stress the program.

Then, I downloaded VSPE, as my other virtual serial port emulator didn't work on W7(64), and neither did the NavMonPC virtual ports.
I tested the following setup:
Garmin -> Prolific -> Seaclear -> virtual port10 -> virtual port 20 -> Ocpn.
After about 6 hours, I noticed that Seaclear GPS input was stopping for a couple of seconds every minute or so. I then disconnected the adapter and restarted just Seaclear: the problem continues at irregular intervals. However, every time Seaclear loses GPS, it comes back almost instantly. Ocpn follows Seaclear happily and has not crashed; some times, it displays lost GPS, but recovers as soon as Seaclear does.

I now think I should have left NavMonPC on longer than I did.

Cheers