[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-users] Must first run gpsmon...

From: Gary Hodges - NOAA Affiliate
Subject: Re: [gpsd-users] Must first run gpsmon...
Date: Wed, 10 Aug 2016 09:29:40 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.1.0

Good morning, Gary:

On 08/09/2016 03:35 PM, Gary E. Miller wrote:
Yo Gary!

On Tue, 9 Aug 2016 14:57:49 -0600
Gary Hodges - NOAA Affiliate <address@hidden> wrote:

In-Line Comments:

On 08/09/2016 01:46 PM, Gary E. Miller wrote:
Yo Gary!

On Tue, 9 Aug 2016 13:04:37 -0600
Gary Hodges - NOAA Affiliate <address@hidden> wrote:

To configure gpsd I follow the example found at:

Exactly?  Or with any changes?  That looks to be from 2014, so does
not account for the 'quirks' of Jessie.

For the subset of that page I follow, it's pretty much exactly.  I
install gpsd and ntp, and configure gpsd like the example with the
only difference being the device path.

Then that would be slightly sub-optimal.  The ntp pool is flakey.  Find
and pick better chimers close to you.  You should have noselect on the
NMEA time.  And have you measured the offset to know that 0.183 is
correct for you?

It has not been measured, only eyeballed. That number looks like the default value (or at least whatever number was in the example) though, so probably not even eyeballed. "Correct" for me is likely pretty loose for most. The reality is I'm good if accurate to a second or few with my instrument. That said, this has been an on and off again little project of mine. I have a little time this week which is why I decided to post.

Are you using the GPS 18lvc?  That is a 10 year old GPS, not so good

I'm using a Garmin 16X HVC, outdoors, at all my sites.

Even older.  But should be good enough if you hae a good sky view.

Basically this means I install gpsd and ntp with aptitude, then run
"dpkg-reconfigure gpsd" answering the questions as directed:

We have had troubles with the debian gpsd packages.  We recommend
you use a recent gpsd from a tar ball.  But I do not think that is
the problem here.

I'm hopeful the default debian packages are OK, or at least good
enough. I strive to make the set-up/config of these machines as
streamlined as possible to simplify my life.

The Wheezy packages were certinaly not OK.  Jessie seems better, but
many people still do not give them an OK.  With your gpsmon issue they
are not OK for you yet.

The -b could be problematic.  Your article says the default 40 mSec
PPS is a problem, but it is not.

I can try removing the -b.  OK, just tried and I'm immediately
reminded of something.  "dpkg-reconfigure gpsd" does not work with
Jessie.  I've been manually editing /etc/default/gpsd file when I
configure a machine. That file looks like:

address@hidden:~$ more  /etc/default/gpsd
# Default settings for the gpsd init script and the hotplug wrapper.

# Start the gpsd daemon automatically at boot time

# Use USB hotplugging to add new USB devices automatically to the
daemon USBAUTO="false"

# Devices gpsd should collect to at boot time.
# They need to be read/writeable, either by user gpsd or the group
dialout. DEVICES="/dev/ttyUSB0"

# Other options you want to pass to gpsd

Removing -b had no effect, or at least did not not change the
behavior as far as I can tell.

Basically that turns off some auto-config.  If you have manually
configured you GPS then you are prolly good, until that config gets

Also, run "pstree -paul | fgrep gpsd" to verify which CLI options
are on gpsd.

address@hidden:~$ pstree -paul | fgrep gpsd
  |-gpsd,1149,gpsd -N -n /dev/ttyUSB0
  |   `-{gpsd},1154
  |               |-grep,4858 -F gpsd

address@hidden:~$ pstree -paul | fgrep gpsd
  |-gpsd,1199,gpsd -N -b -n /dev/ttyUSB0
  |   `-{gpsd},1204
  |               |-grep,1215 -F gpsd

Two examples there. The first one is the system I removed the -b option from.

Note that six of my machines use /dev/ttyUSB0 and one
uses /dev/ttyS3.

Ser you doing the setserial every tim on boot before running gpsd?

When I have to reboot a machine I run gpsmon so that ntp will use the
local GPS.  Not a huge deal if I'm doing the rebooting.  A bigger
deal when a power glitch causes a remote machine to reboot.

Whcih makes zero sense.  All gpsmon does, when gpsd is running, is
be a gpsd client.  If gpsd is started with the -n I can't see how that
changes how ntpd sees the gpsd server.

Though I haven't found it today or yesterday, I recall reading that gpsmon performs an auto config of the serial port. I've been running with the assumption that all I needed to do was configure the ports correctly and my quest would be over.

I configure ntp.conf, and that's pretty much it, I believe.

And what is you configuration?  Are you using driver 20, 22, 28,
etc? Do you have the right offset for you NMEA time?  Lot's of
questions, but it is easier if you just show us youur config.

Please tell how to determine the driver version and I'll report back.

gpsd -V
ntpd -V

address@hidden:~$ /usr/sbin/gpsd -V
gpsd: 3.11 (revision 3.11-3)

address@hidden:~$ /usr/sbin/ntpd --version
ntpd 4.2.6p5

There is no separate driver version, and I'm no concerned about the
driver version, I'm concerned about the driver NUMBER in the ntp.conf.

I've fiddled with the NMEA offset many times at different locations
and it's never made a difference, at least as far as my current
question is concerned.

Not immediately obvious, it is more an error margin thing.

 It does change the ntp time though, and I do
have other questions related to this and PPS, but that's for another
thread, I think.

Depending on your config, it can have different effects.  Without seeing
your ntp.conf it is hard to say.

Nope.  You provided no info on the ntp.conf.

You are correct, my apologies.  I believe it's all stock Debian
except the server/fudge 127 lines.

address@hidden:~$ more /etc/ntp.conf

server minpoll 4
fudge time1 0.608 refid GPSe
server minpoll 4 prefer
fudge refid PPSe

Looks good, except the GPS should be noselect.  And how do you know
that is the right fudge?  Eyeball?

I will add the noselect option. At best fudge is eyeballed. Could also be the value in the example I worked off of.

server iburst
server iburst
server iburst
server iburst

Sorta good, there are some bas chimers in the pool.  Best to hand
select some local ones.

I've gone back-and-forth on this. I seem to recall in the past I've had time servers go away. Using the pool seems to me a good way to avoid that. Also, the reality is my time accuracy needs are pretty loose.

 I don't know which is run run first, gpsd or ntpd.

Usually not a problem, but it means you don't really know what is

Correct, again.  I'm more of a computer user than a computer USER,
though I have been installing Linux and using it as my primary
desktop since 1997.  I used to tinker more, but much, much less these

Systemd really changed the game, and messes up a bunch of things.

Hard to fix a problem unless you know what is happening.

The verion is important, but I asked for the driver NUMBER.  Jessie
does ship with an older gpsd, but the major problems in Jessie are
in the surround stuff.

OK, I have to confess ignorance.  How do I determine the driver
number? I'm getting no where with the google.

You provided it above.  And repeated here:

server minpoll 4
server minpoll 4 prefer

You are using driver number 28, units 0 and 1.  basically the SHM
driver.  Notice other people answering this thread have been using
driver 22 as well.  Which is a very different configuration, so that
will be confusing the issue.

It just
won't use the local GPS unless gpsmon is first run.

Which is a new one on us.  If you run 'cgps' before running gpsmon,
do you see anything?

Yes.  I've never run this before.  A similar screen as gpsmon.  It
all looks good.  Nine satellites found.

Good.  cgps is the FIRST debug tool to check.

If you wait several minutes on startup, then run just cgps, do you
see a 3D fix right away?

Yes.  In 4.5 seconds by my count.

Not good.  It should have a fix within a second.  That may mean the "-n"
is not being used by gpsd on startup.

If you reboot, letting gpsd and nptd start, and you run 'ppscheck'
and 'ppstest' do you see good data?

address@hidden:~$ ppstest /dev/ttyUSB0
trying PPS source "/dev/ttyUSB0"
cannot create a PPS source from device "/dev/ttyUSB0" (Operation not

No, you run it this way:

    # ppstest /dev/pps0

address@hidden:~$ sudo ppstest /dev/pps0
trying PPS source "/dev/pps0"
found PPS source "/dev/pps0"
ok, found 1 source(s), now start fetching data...
source 0 - assert 1470842538.999674124, sequence: 66675 - clear 1470842538.099658684, sequence: 66674 source 0 - assert 1470842538.999674124, sequence: 66675 - clear 1470842539.099675690, sequence: 66675 source 0 - assert 1470842539.999705534, sequence: 66676 - clear 1470842539.099675690, sequence: 66675 source 0 - assert 1470842539.999705534, sequence: 66676 - clear 1470842540.099706895, sequence: 66676 source 0 - assert 1470842540.999713668, sequence: 66677 - clear 1470842540.099706895, sequence: 66676 source 0 - assert 1470842540.999713668, sequence: 66677 - clear 1470842541.099714081, sequence: 66677 source 0 - assert 1470842541.999736985, sequence: 66678 - clear 1470842541.099714081, sequence: 66677

I have not been able to locate the deb package with ppscheck up to
now. I'll keep looking.

It is in the gpsd tar ball.  My guess is another thing the debian gets

Thank you for your time with this.  In googling I found a document
you wrote with Eric R published in May this year.  I'll become
familiar with it.

That doc has been tested by a lot of people.  Except for that I run Gentoo
it is how my 3 RasPi's are running.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]