Re: [gpsd-users] Set up for time sync and separate serial port use

[Gary E. Miller]

Yo Randall!

On Fri, 10 Mar 2017 20:29:04 +0000
"Pittman, Randall" <address@hidden> wrote:

> Thank you for the response, Gary. I have skimmed over the Time
> Service howto, as well as the Garmin GPS 18 ntpd recipe
> [http://www.rjsystems.nl/en/2100-ntpd-garmin-gps-18-lvc-gpsd.php].

Good.  I sure hope you are not using a Garmin 18!  That tutorial
is pretty old too.  And the way he did the RS-232 will not work
on many systems, he forgot the level translator.  RS-232 is +/- 12V and
the Garmin 18 is 0 to 5V data.  Some serial ports will work, others
not.

He is also wrong about ntpd caring about getting input every second...

His minpoll o4 4 is OK on some hosts, but things like RasPi prefer
minpoll=maxpoll=2.  A tweak you will not need for a long time, if ever.

A good start, but use more current sources for the details.

> 1. My GPS (Hemisphere Vector V103) starts up at 19200 baud, but can
> be changed to a max 38400 baud with $JBAUD

Keep an eye on it, at 20Hz the speed 19200 may be too low.  You'll know
if the messages lag.

> 2. The V103 starts up with a default set of messages, but I want to
> turn those off and only enable the messages that I need.

Very normal.  You could write a simple script to send the
setup you want and then start gpsd.

> 3. It is crucial that I receive the PASHR (heading, pitch, roll,
> heave) and GPGGA messages at the max 20Hz rate as this unit is being
> used to geolocate marine radar imagery at long ranges on a boat.
> These two messages use about 25600 of my 38400 baud budget.

Ouch.  Can't it do 56,400?  And you can't calulate the BW needed that
accurately.  NMEA messeages are variable length.

> 4. I would like to bring GPS timing along for the ride. I'm worried
> that if I let gpsd talk to my unit it will mess up the message
> configuration that I need.

The -b option tells gpsd not to send to the GPS.  But easier is
to code your deisred setup into gpsd.  Prolly not a 1 day project...


> so it must not be strictly necessary for gpsd to
> talk to the unit for it to be able to do timing.

Correct, just a LOT easier to let gpsd do the setup work.  In your case
you are gonna have to do the setup work.

> I guess my python app and the splitter are not strictly necessary. I
> could use the approach in the Garmin GPS 18 ntpd recipe and in the
> step where he runs “$PGRMO,,4” for the Garmin unit, I could run the
> commands to set the baud rate, disable default messages, and then
> enable the messages I want.

Or you can start gpsd and then use gpsctl to send your setup messages
through gpsd.

> And then I could use gpspipe to get the
> data, as you mentioned. So… is it sufficient to enable GPRMC, GPGSA,
> and GPGSV at 1Hz for timing to work? Would more often be any better?

The PPS only comes once a second, so faster is not better.  You can
easily get to 1 micro second with the PPS. gpsd just needs to know the
current second, and know that the PPS is valid by looking at the GPS
status.

GPGSA and GPGSV do not come every second, just when needed, which can
cause unexpected bottlenecks in the data stream.

I think GPRMC also needs GPZDA to get the current year.

> Also, if I change the baud rate to 38400 with $JBAUD, will gpsd
> automatically figure that out and switch the baud rate of the serial
> port?

On startup if gpsd can not grok the data it will autobaud.  It will also 
autobaud when the data stream is lost.  So if you use stty to set
the port speed before starting gpsd then gpsd will not go into 
autobaud.  You can also force gpsd into a fixed speed mode, but no
need if you are careful with stty.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        address@hidden  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can’t measure it, you can’t improve it." - Lord Kelvin

pgpl2TYIEx4n3.pgp
Description: OpenPGP digital signature