Antenna/com trouble

[blubadub]

Hello all,
I am using a netbook w/ win7starter and a US globalsat AT350 antenna. When I use the gpsinfo program supplied with the antenna it is rock solid. When I use it with opencpn it will work anywhere from 10 mins to 3-4 hours. When it stops getting a signal I can still see the com port and it says it is working properly, but neither opencpn or gpsinfo can see it, both say comport error. Unplugging the antenna and replugging it into any usb port causes the com port to disappear and it will not come up again. Closing and opening the programs does nothing. At this point I get an abnormal shut down, pita, but all will work again on start-up. I can open and close gpsinfo no prob but opencpn is not stable. Any help, suggestions, will be appreciated.
Thanks, David

[yachtvalhalla]

Originally Posted by blubadub

Hello all,
I am using a netbook w/ win7starter and a US globalsat AT350 antenna. When I use the gpsinfo program supplied with the antenna it is rock solid. When I use it with opencpn it will work anywhere from 10 mins to 3-4 hours. When it stops getting a signal I can still see the com port and it says it is working properly, but neither opencpn or gpsinfo can see it, both say comport error. Unplugging the antenna and replugging it into any usb port causes the com port to disappear and it will not come up again. Closing and opening the programs does nothing. At this point I get an abnormal shut down, pita, but all will work again on start-up. I can open and close gpsinfo no prob but opencpn is not stable. Any help, suggestions, will be appreciated.
Thanks, David

I believe this type of problem has been discussed on the forum before.

BUT, in my case I solved the problem by using another useful program, NavMonPC, as an intermediary buffer between the GPS input and the OpenCPN program.

I have used this configuration for passages of three or more days without any problem.

HTH, Terry

[JesperWe]

Yes OpenCPN 3.0 is not very good at handling unstable virtual COM ports. Other apps does this much better, so for example NavMonPC will handle the USB error so OpenCPN never sees it.

We are hoping to address this problem in the next OpenCPN release.

[Paul Elliott]

NavMonPc uses the Franson "SerialTools" library, which is extremely solid (I am the author of NavMonPc). Unfortunately, SerialTools is no longer supported. You can still buy it, but expect zero support. It hasn't been upgraded to Win7/64, although there are workarounds.

If you don't want to run NavMonPc, which has a bunch of stuff you may not need, you might consider the very reasonably priced GpsGate Client. This is from Franson, and uses the same drivers that I use for NavMonPc (GpsGate does work with Win7/64).

As far as OpenCPN development, there are other good serial-port libraries which behave well with flaky virtual ports -- I am using "Sax CommStudio" for a .NET application. It doesn't provide virtual ports, but it does handle port faults much better than the built-in Windows library. Unfortunately CommStudio is quite expensive, and is a Windows-only solution.

[ken.roller]

First, let me say I LOVE Open CPN!!! I'm geographically challenged and it has brought me home every time! :-) The wife and I go chasing around Chesapeake Bay and out into the Atlantic and I get confused REALLY easily. All the water looks SOOO similar... ;-)

Did 2.5 work better in this respect? I moved to a bulletproof Dell ATG running XP (an AMAZING daylight visible screen!) as my boat nav computer and 3.0.2 at the same time. I kept my Delorme LT-40 antenna. About every half hour the GPS shuts down in OpenCPN, but the Delorme usb/serial program and antenna are happier than clams. I want to use this an an anchor alarm for an overniter and it would be nice if it stayed up for at least 8 hours... :-/

I can't remember 2.5 having the shut down issues, but it may have. Perhaps trying another emulator like NavMonPC is the best answer, as my maps and setup on 3.0.2 are just where I want them.

[yachtvalhalla]

Originally Posted by Paul Elliott

NavMonPc uses the Franson "SerialTools" library, which is extremely solid ..... It hasn't been upgraded to Win7/64, although there are workarounds.

Paul I've been using NavMonPC for quite awhile now and appreciate the expansion to 6 virtual outputs you did at my request. Many thanks.

Are the 'workarounds' for W7/64 available for disclosure?

Terry

[JesperWe]

The problem with W7/64 (I believe) is that non-signed drivers are not accepted by the kernel. And driver signing costs money.

You can get around it by putting your system in test mode.

[blubadub]

Thank you all for the answers. My win7 starter is 32 bit, will navmon work with that? Can anyone suggest an antenna (permanent mount, I have an aluminum Sailboat) that will work directly and solidly with opencpn?
Again thanks.

[JesperWe]

Originally Posted by blubadub

Thank you all for the answers. My win7 starter is 32 bit, will navmon work with that? Can anyone suggest an antenna (permanent mount, I have an aluminum Sailboat) that will work directly and solidly with opencpn?

This is a good and not so expensive option: Digital Yacht GPS105

Look for a self contained 12V unit that outputs NMEA0183 directly. Not USB connected. Serial port connection is more reliable (you said "solid"...)

[Paul Elliott]

Originally Posted by yachtvalhalla

Paul I've been using NavMonPC for quite awhile now and appreciate the expansion to 6 virtual outputs you did at my request. Many thanks.

Are the 'workarounds' for W7/64 available for disclosure?

Terry

Hi Terry,

I described the procedure on the NavMonPc mailing list. I need to add this to the user's guide, but here it is:

As you may know, the regular NavMonPc installation does not provide Virtual Ports that work with Win7/64. Someone had mentioned that Franson GpsGate installs drivers that work with NavMonPc and Win7/64 (which makes sense since NavMonPc uses Virtual Serial Port drivers from Franson). I can now report: It works! Here's how:

I started with a clean install -- no traces of NavMonPc or the Franson drivers.

I then downloaded and installed Franson's "GpsGate Client" (GpsGate Client - Products - GpsGate.com). This is free (and is a useful program in it's own right).

I then installed NavMonPc, and when asked if I wanted to install Franson SerialTools I declined.

And that's it -- just that easy! NavMonPc now has working Virtual Ports on my new Win7/64 machine.

It is probably possible to just install GpsGate and it's drivers without cleaning out the existing NavMonPc install, but I haven't tried this.

(Apologies for using the OpenCPN thread to discuss NavMonPc)

[Paul Elliott]

Originally Posted by blubadub

Thank you all for the answers. My win7 starter is 32 bit, will navmon work with that?

Yes, it NavMonPc should work fine. See my previous post above if you want to use Win7/64. By the way, NavMonPc also provides a TCP/IP server for MNEA-0183 data that many programs will be able to connect to.

[Paul Elliott]

Originally Posted by JesperWe

This is a good and not so expensive option: Digital Yacht GPS105

Look for a self contained 12V unit that outputs NMEA0183 directly. Not USB connected. Serial port connection is more reliable (you said "solid"...)

The thing about native serial output is that you still have to get it into the computer. Few computers have built-in serial ports these days, so you inevitably need a serial-to-USB adaptor in there somewhere. Some USB/Serial adaptors are apparently better than others. There's no inherent reason why the USB output from a well-designed GPS should be any less reliable.

[JesperWe]

Originally Posted by Paul Elliott

There's no inherent reason why the USB output from a well-designed GPS should be any less reliable.

Of course if you don't have a serial port you need USB. But OpenCPN as it stands with 3.0 can't tolerate the port getting disconnected or any similar error without restarting the app. So serial is better if you have such a port. You can connect and reconnect and so on as much as you want, without needing to restart O.

[bdbcat]

Paul....

Thanks for your comments.
We really would like to get after this problem with Prolific USB chips and Win7/64. It's really become a thorn...

We have two issues:
1. Can't find a "smoking gun", since none of our capable developers has the environment to hand.
2. As you understand, we cannot use, hack, or even look very closely at any paid-for, closed source library solutions.

I'm becoming convinced that the problem is in the 7/64 Prolific driver, and that the apps that work are touching this driver in a special, timing dependent way. Using the standard MSFT API methods, the port looks open, but nothing is happening. We don't get any information that the driver has died....we just stop getting data.

Further, we think the Serial-USB adapters using the FTDI chipset are superior, at least with OpenCPN. They run indefinitely on all platforms.

Also, Prolific USP dongles run fine on W32.

So the issue is the Prolific chipset on 7/64.

Do you have any idea what may be going on here, and what we may do to isolate and resolve the issue? All off-the-wall ideas appreciated.

Dave

[Paul Elliott]

Hi Dave,

I'm sorry, but I don't have any real insight into the driver workings. I have heard from other sources that the Prolific driver can be problematic, but this was for the 32-bit systems. The whole migration from 32 to 64 bits obsoleted a lot of serial adaptors, but I've only had the chance to play with a few of the 64-bit ones and don't have the experience or knowledge to provide any advice. When I looked into this it was to solve the "crash on USB unplug" problem. Franson and CommStudio were well-behaved, while the MSFT API threw an un-catchable exception. Your dead port problem may be a completely different thing.

Now that you mention it, I do recall seeing what appeared to be a dead USB/serial situation with the USB AIS receiver dongle. I should try to re-create that fault and see what USB hardware it is using.

If I stumble across anything useful I will share it.

By the way, can OpenCPN connect to a TCP/IP NMEA server? I would sure like to see our nav-software using something other than virtual serial ports. This wouldn't solve the external device connection problems, but could be a much more robust and flexible solution for inter-program communication. UDP would also be a reasonable option, although NavMonPc currently only supports TCP. With the NMEA and third parties starting to put out ethernet interfaces for NMEA2000, it seems that we might be finally moving towards a rationalization of our interfaces. Of course what it probably means is just more dialects we will need to deal with in the babel that is marine data interface "standards'!