Setup Ubuntu GPSd/GPSLib, AIS and Other NMEA Data

[bluearcus]

I'm currently experimenting building a little Linux Mint machine for OpenCPN use and have decided to try gpsd to see if it helps resolve some issues with USB/serial port/bluetooth setup.

Unfortunately I'm not having much success.

I have gpsd and libgps installed fine, and my USB NMEA feed is correctly identified by gpsd and piped (via libgps) to OpenCPN.

However, I have two problems, both because my NMEA data stream has LOTS more info in it than just GPS position,

First of all, I have NMEA heading info available, and this is not appearing via GPSd/LibGPS. That's very annoying...

But even worse... my NMEA feed is a combined AIS data and local NMEA network data feed. This is identified by GPSd (as cgps shows AIS messages...). However, at the moment, OpenCPN only allows GPS data to be sourced from GPSd/GPSLib... it assumes AIS will be on a real serial port... so I can't get to my AIS data.

Argh!

At the moment I'm going to have to revert to raw serial device connections I think, but if gpsd should surely be able to be used...?

Regards,

Mike

PS Not in a position to look at the code at the moment, but expressing my frustration is possible over very slow net access...

[bdbcat]

BlueArcus....

1. How do you mux the AIS, heading, and GPS info before feeding to GPSD?

2. I think that libgps ignores and does not pass thru the NMEA HDT/HDM messages. AFAICT, there are no related items in the data structures managed by libgps.

3. It is true that opencpn does not support AIS messages coming from the libgps channel. AIS support in libgps is quirky, in my experience.

4. Seems to me that what you want is a simple (?) mux of all your NMEA and AIS data together, and brought into one serial port. Some AIS receivers will do this for you. What problems would this create for you?

Dave

[wadda]

Originally Posted by bluearcus

<snip>

But even worse... my NMEA feed is a combined AIS data and local NMEA network data feed. This is identified by GPSd (as cgps shows AIS messages...). However, at the moment, OpenCPN only allows GPS data to be sourced from GPSd/GPSLib... it assumes AIS will be on a real serial port... so I can't get to my AIS data.
<snip>

Since OCPN is expecting a separate channel for the AIS data and is not set up to demux the data from the one source I'm not sure it's presently possible.

It looks like you'd have to sift out the 'cgps' and pipe it somewhere else...but I don't know my AIS from a hole in the ground.

[bluearcus]

I have an all-in fast NMEA feed with GPS data, Compass Heading, Depth and AIS combined already, but my thinking was that GPSd/libGPS would be the best approach to take to help resolve device file locking / changing issues on sleep etc.

The feed is assembled by

1) Fully populated Seatalk -> NMEA using an old style Raymarine Seatalk bridge
2) NMEA -> fast NMEA with additional AIS data through and EasyAIS receiver

Looking at GPSd, it seems the authors take a dim view of the original marine roots of NMEA and are keen to rid themselves of almost all of the still-in-use marine only parts of the spec... I can only assume AIS has been included because someone though it was 'interesting'...

So, if raw heading and depth data is unavailable on the other side of GPSd I guess that suggests reverting to straight serial device file access. Right oh! Will have to attack sleep or other device file quirks another way then ;-)

Cheers,

Mike

[bdbcat]

Bluearcus...

OK, there were some old postings on some old opencpn thread regarding configuring udev to provide "static" ttyxx names after sleep and hotplug.

I have avoided this kind of platform-specific stuff in opencpn, but maybe it is time....

Sorry I cannot be more specific on the reference, but maybe someone else will remember.

In general, I think libgps should be considered for use in "special cases", but the fewer bits in the data link, the better opencpn will like it.

Good Luck
Dave

[wadda]

Originally Posted by bdbcat

<snip>

In general, I think libgps should be considered for use in "special cases", but the fewer bits in the data link, the better opencpn will like it.

It would be nice to have someone who knew how OPCN handle the data. I don't think it is equipped to demux then data stream, but treats gps and ais data as separate critters.

I also don't think gpsd, nor libgps, is the problem child...nor the solution to the original problem.

[bdbcat]

Wadda....

Please clarify.

I think I know how OCPN handles the data.

OCPN demuxes a composite stream, and internally pipes AIS to the AIS decoder, and all other NMEA sentences to general use. Use Toolbox->GPS->AIS Port (Shared)

lidgps does not (seem to) understand NMEA HDT/HDM data sentences which may be present in a composite stream fed to it as input. They are eaten internally by libgps, I think, and so are lost. Does anyone know differently?

libgps will provide "cooked" position, velocity, and time information through its API, and that is what OCPN uses when the library is selected.

Are we on the same page?

Dave

[wadda]

Originally Posted by bdbcat

I think I know how OCPN handles the data.

Oh, you're 'Dave'....cool.

Originally Posted by bdbcat

OCPN demuxes a composite stream, and internally pipes AIS to the AIS decoder, and all other NMEA sentences to general use. Use Toolbox->GPS->AIS Port (Shared)

Yeah, I had no idea since I feed in through a modified VHF, gnuais and a series of tubes. I thought it was processed later. Ashamedly I never looked.

Originally Posted by bdbcat

lidgps does not (seem to) understand NMEA HDT/HDM data sentences which may be present in a composite stream fed to it as input. They are eaten internally by libgps, I think, and so are lost. Does anyone know differently?

HDT and HDM were deemed obsolete NMEA sentences by the powers that be about a year or two ago.

Originally Posted by bdbcat

Are we on the same page?

Yep.

[bluearcus]

Originally Posted by bdbcat

Bluearcus...

OK, there were some old postings on some old opencpn thread regarding configuring udev to provide "static" ttyxx names after sleep and hotplug.

I have avoided this kind of platform-specific stuff in opencpn, but maybe it is time....

Thanks Dave. I think I've seen reference to similar hotplug/udev tweaks on the GPSd website, so will research those and give them a go.

I think what is really needed is an intelligent XPort-style NMEA multiplexor/serial manager component for linux which will do NMEA USB/serial and potentially also bluetooth rfcomm serial management and provide one or more persistant socket or virtual device file based connections for applications to use.

Regards,

Mike