[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: Tue, 9 Aug 2016 14:57:49 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.1.0

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.

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.

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.

Start gpsd automatically on boot? Yes
Device the GPS receiver is attached to: /dev/ttyS0
Should gpsd handle attached USB GPS receivers automatically? No
Options to gpsd: -b -n

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

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

# 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.

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.

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. 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. 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.

process worked with the previous debian stable with the same
hardware. It is only with Jessie that I have to first run gpsmon.

Jessie changes to systemd, many people rip it out and then report better

I think I covered your configuration question above.

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
# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help

driftfile /var/lib/ntp/ntp.drift

# Enable this if you want statistics to be logged.
#statsdir /var/log/ntpstats/

statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable

# You do need to talk to an NTP server or two (or three).
#server ntp.your-provider.example

# maps to about 1000 low-stratum NTP servers.  Your server will
# pick a different set every time it starts up.  Please consider joining the
# pool: <>

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

server iburst
server iburst
server iburst
server iburst

# Access control configuration; see /usr/share/doc/ntp-doc/html/accopt.html for # details. The web page <
# might also be helpful.
# Note that "restrict" applies to both servers and clients, so a configuration # that might be intended to block requests from certain clients could also end
# up blocking replies from your own upstream servers.

# By default, exchange time with everybody, but don't allow configuration.
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery

# Local users may interrogate the ntp server more closely.
restrict ::1

# Clients from this (example!) subnet have unlimited access, but only if
# cryptographically authenticated.
#restrict mask notrust

# If you want to provide time to your local subnet, change the next line.
# (Again, the address is an example only.)

# If you want to listen to time broadcasts on your local subnet, de-comment the
# next lines.  Please do this only if you trust everybody on the network!
#disable auth

 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 happening.

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 days.

 As for the driver version... ntp works just fine if pointing at Internet
time servers.

Two things.

Ntpd ALWAYS needs internet time servers. ntpd was never designed for
standalone usage.

Ah, this is very interesting and relates directly to another question I have that I alluded to above. Another thread, but boy am I curious now!

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.

Most people just rip out the debian scripts and write their own.

I believe it, but with these field machines I maintain I strive to make the set-up and config as easy and as quick as I can. If necessary, I will head down that path.

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.

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.

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 supported)

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

I have not been able to locate the deb package with ppscheck up to now. I'll keep looking. On the above ppstest attempts, I'm not sure I'm pointing at the correct device, though I don't have other options, at least none I'm aware of.

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.


reply via email to

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