Network LIBGPS Data Source Problems

[josephine]

Hello OpenCPN Forum,

I am attempting to use OpenCPN's libgps functionality and am having problems getting OpenCPN to reliably use the data from gpsd. To summarize my problem: when OpenCPN is the first client to connect to gpsd everything works. When OpenCPN is _not_ the first client to connect to gpsd it does not work.

In the non-working situation a tcp connection is established between OpenCPN and gpsd. Tcpdump shows NMEA packets transmitted to OpenCPN and 'ACK' messages returned, but no gps data appears on the OpenCPN screen and the status indicator remains red.


Is this a known issue with OpenCPN? Other gpsd client programs that use libgps do not exhibit any problematic behavior on my system.

I am very excited to get OpenCPN working but my installation requires OpenCPN to communicate properly with gpsd on a remote host in conjunction with other libgps-based clients.



-Josephine

[bdbcat]

josephine....

Welcome aboard!

I see your Flyspray ticket on this issue. It is next on my worklist, so we should soon have some more information on this bug.

Stay tuned
Dave

[josephine]

Dave,

I am glad to hear that it is coming up on the todo list. Let me know if you need any additional information from me... logs, tcpdumps, serial traces or more testing.

Thanks,

-Josie

[bdbcat]

josie...

Well, here we are.

I have built foxtrotgps, works fine with libgps, AFAICT.

I can start OCPN before or after foxtrotgps, and it also works fine.

Can you give me more ideas on how to break it?
Maybe any unique command line options you have used?

I admit that libgps is something of a mystery....

Thanks
Dave

[josephine]

I take it from your last post that this is not a known problem!

I have tried various gpsd command line options and still experience the same problem. The current is:
# /usr/sbin/gpsd -G -D3 -F /var/run/gpsd.sock -P /var/run/gpsd.pid /dev/ttyS2

As mentioned in a previous post, I am not using gpsd's '-n' option. This allows me to close all clients, wait, and then reconnect OpenCPN after gpsd has dropped DTR and cycled the gps serial port.


My OpenCPN client is running on a different host than gpsd, hence the '-G' option for gpsd. Without -G gpsd only listens on the loopback address.

- - -

When initially researching my problem, I came across the following thread in the forum:
http://www.cruisersforum.com/forums/...1-a-53982.html

In cray's first post it sounded like a similar problem to the one that I am having, but then cray changed his configuration to a direct serial connection and the intermittent connection issue using libgps was never resolved.

Before I realized that allowing gpsd to reset the serial port would result in a successful OpenCPN connection to gpsd, I too (like cray) was repeatedly connecting/disconnecting OpenCPN hoping for a random success.

- - -

From my understanding, gpsd is supposed to smooth over any differences between gps hardware to provide the client a standardized bunch of JSON. I have tried multiple versions of gpsd/libgps/opencpn on multiple host and client operating systems with the same result. I am beginning to wonder if the one piece of the puzzle that has not changed, namely my _gps_ could be at fault. It is an internal gps receiver in a Panasonic Toughbook CF-19 internally connected somehow to ttyS2. I am not sure of the make or model of the gps receiver.

On my boat the Toughbook is used strictly as a front-end at my helm, the internal gps is not used. My actual working gps is a Lowrance NMEA-2000 model. The Lowrance output is pulled from the NMEA-2000 backbone by a Linksys router that combines NMEA-2000, RS422, and RS232 inputs into one gpsd bundle. This weekend I will hook everything up on the boat and see if the problem persists.

In the mean time let me know if there is anything else you would like me to check on my testing system.

Thanks
-Josie

[bdbcat]

Josie...

Ahhh, remote gpsd.

So, I need a libgps client (other than OCPN) to test with.

How do I configure foxtrotgps for remote gpsd? Any other libgps clients I could try?

At the moment, I cannot get OCPN to connect remotely, either. Something broken.....

Dave

[bdbcat]

Josie....

I have had some iptables firewall problems here. Fixed. Now have OCPN working with remote gpsd.

But foxtrotgps and xgps do not work. Yet.

Dave

[josephine]

Dave,

WIth foxtrotgps/tangogps simply enter the remote ip addr of the gpsd host in the final page of the Info/Config sidebar.

For [cx]gps enter the remote hostname as a command line argument.

For gpsdrive enter the remote hostname as an optarg to the '-b' option.

Funny, I thought a whole bunch of folks would be using _remote_ gpsd!



-Josephine

[josephine]

SInce you mentioned iptables...

I thought that I should mention that both my client and gpsd server are on the same private subnet. I am not using any firewall rules.


-j

[bdbcat]

josie....

foxtrotgps now working with remote gpsd and libgps, and OCPN interoperates with no problem.

I used gconf-editor to configure foxtrotgps, after finding the proper keyname by grepping around in the source code. Sigh...

Anyway, after all, start/stop of either application in any order, all works fine.

I will continue to test.

I'm suspicious of the toughbook internal GPS.....

Dave

[bdbcat]

Josie...

Thanks for the info on libgps clients. I did not see the info config pane on foxtrotgps until I full-screened the app. Clear enough now.

I don't know how many people are using remote gpsd. I also thought that it would be highly used, and a way to build a redundant linux based nav system. As it turns out, though, I don't use it underway either. So there it sits, under-exercised.

I find it useful to run gpsd on the host with -D3 -N options, so that the gpsd debug output comes to stdout. You can see the socket connects and data flow as the client(s) comes alive.


Good luck, and let me know what you find.
Dave

[josephine]

Re: Remote GPSD vs. Local GPSD

I have just tested OCN running on the same host upon which my gpsd is running. It connects fine.

However, if I:

1) close OCN;

2) start cgps;

3) start OCN... OCN shows the red ball.


While OCN is running but not displaying any position data, I can see the ESTABLISHED connection in netstat -an. I also occasionally see packets in netstat's Recv-Q for OpenCPN's socket.


The above test was conducted with gpsd, cgps, and opencpn all on one host.

- - -

I guess I am suspicious of the internal gps as well. I thought that gpsd would smooth over any problems with the hardware and provide a consistent data stream to the clients. Something is obviously going wrong and it is very repeatable.

Is it possible for me to get some more debugging info out of OCN? I am wondering why it behaves differently whenever the gps is already talking to gpsd.

After all clients have disconnected from gpsd, it continues to hold DTR high and receive data from the gps for nearly a minute. During this time even though no other client connections to gpsd are ESTABLISHED, OCN can still not receive data. OCN only works when it connects to gpsd prior to DTR going high and the gps hardware waking up.

Is the gps possibly sending a certain message only at wakeup that OCN needs to start processing position data?

-j

[bdbcat]

Josie...

Tested that scenario. Works fine here. OCPN can connect and get green bars whether the gpsd is still active, or is quietly waiting.

You can add a line to opencpn.conf to get some cryptic debug output. It won't tell you much except by reference to the code in nmea.cpp

[Settings]
DebugGPSD=1

As far as our code goes, kicking off the gpsd interface is handled by libgps. We simply open a high level "channel" to the library, and periodically poll the library for positioning info. This heartbeat is what you will see in the debug output.

Dave

p.s. Thomas, are you lurking? Anything like this with your gpsd experiences?

[josephine]

Dave,

I really appreciate you taking time to address this issue with the OCPN connection through libgps. I will continue testing this weekend with my on-board system to see if the problem clears up with different gps hardware. I'll let you know my findings.

I also just noticed your post regarding the debug config. I'll try that out to see if I can isolate where the toughbook gps communication is breaking down.

I am excited to start using OpenCPN for actual navigation, I am a little tired of seeing my current vessel position icon in the brown!

-Josephine

[cagney]

From lurking Thomas....
Dave
I think that josephine is on to something.
It used to be that when xgps was working it was a foregone conclusion that gps would work on OpenCPN. I don't think I have used gpsd much since 2.1 or so. There seems to be a regression here. Now my findings tend to agree with josephine's.I cannot get the gps going if xgps is already running.

gpsd is started by the standard installation on (k)ubuntu with the following command

/usr/sbin/gpsd -F /var/run/gpsd.sock -P /var/run/gpsd.pid

Thomas