Nabble - GPSd - Users

Gpsd + Zeroshell linux / Mikrotik routers

2009-11-29T04:48:53Z

Hi,

Has anyone had any experience using Gpsd with Zeroshell linux or Mikrotik
hardware?

Thanks,

Mike
_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

Re: gpsd.berlios.de down

2009-11-27T06:14:00Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Richard Horton wrote:
> Working fine from the UK

Yup. It's back up now.

Regards,
Diego Berge.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAksP338ACgkQmlKEtSWrbj0RywCePgS7j+3p9V3xzmsPY7l5y9ba
1tQAnA6lSSzqC40/JiqENd3f6yZq2J3j
=Xhmr
-----END PGP SIGNATURE-----
_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

Re: gpsd.berlios.de down

2009-11-27T06:07:11Z

Working fine from the UK

2009/11/27 Diego Berge <gpsd@...>:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Morning,
>
> I've just tried to access http://gpsd.berlios.de/ and the website
> appears to be down. I have tried accessing from two different locations
> in two different countries with the same result. Ping does get a
> successful response from unicorn.berlios.de (195.37.77.138)
>
> I remember talk about moving away from Berlios but I'm unaware of
> gpsd's new home, if any.
>
> If necessary, I'm willing and able to provide hosting for it on a
> dedicated server, and I can set it up immediately if provided with a
> copy of the website from an up to date SVN (which mine isn't).
>
>
> Regards,
> Diego Berge.
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAksPuOoACgkQmlKEtSWrbj0oaQCfdZd7iOabUq2LUz1Cy5BGYSLM
> 8RQAn3StB7IsieAD4RtSLKMCH/JJKxyE
> =WRgU
> -----END PGP SIGNATURE-----
> _______________________________________________
> Gpsd-users mailing list
> Gpsd-users@...
> https://lists.berlios.de/mailman/listinfo/gpsd-users
>

--
Richard Horton
Users are like a virus: Each causing a thousand tiny crises until the
host finally dies.
http://www.solstans.co.uk - Solstans Japanese Bobtails and Norwegian Forest Cats
http://www.pbase.com/arimus - My online photogallery
_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

gpsd.berlios.de down

2009-11-27T03:32:59Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Morning,

I've just tried to access http://gpsd.berlios.de/ and the website
appears to be down. I have tried accessing from two different locations
in two different countries with the same result. Ping does get a
successful response from unicorn.berlios.de (195.37.77.138)

I remember talk about moving away from Berlios but I'm unaware of
gpsd's new home, if any.

If necessary, I'm willing and able to provide hosting for it on a
dedicated server, and I can set it up immediately if provided with a
copy of the website from an up to date SVN (which mine isn't).

Regards,
Diego Berge.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAksPuOoACgkQmlKEtSWrbj0oaQCfdZd7iOabUq2LUz1Cy5BGYSLM
8RQAn3StB7IsieAD4RtSLKMCH/JJKxyE
=WRgU
-----END PGP SIGNATURE-----
_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

Re: bluetooth blues

2009-11-26T11:00:55Z

On Thu, 26 Nov 2009 17:27:25 +0100
Jos Meijer <josessex@...> wrote:

> Charles Curley wrote:
> > script looks a lot like mine on Ubuntu 9.10. In that case, you want
> > to modify /etc/default/gpsd, not /etc/init.d/gpsd. (.........)
> I was speaking before my turn.
> After a reboot I only get data in xgps/telnet/gpsdrive after
>
> jos@jos-netbook:~$ sudo rfcomm bind rfcomm0
> jos@jos-netbook:~$ killall -HUP gpsd
> jos@jos-netbook:~$ gpsd start
>
> Is there anything in my script, if you would be so kind to compare,
> that differs from yours?

I don't think it's the script per se, but the order in which things
occur at boot.

I don't use bluetooth, so I'm guessing. But it might be enough to run
dpkg-reconfigure gpsd and specify /dev/rfcomm as your device. Then add
the line

rfcomm bind rfcomm0

to /etc/rc.local

The ability to specify the device is designed to work with
hotplugged devices, e.g. USB and bluetooth. gpsd will monitor that
device whether it exists or not. When it comes into existence, gpsd
will detect it and use it. What will happen here is that gpsd will fire
up as it normally does, but won't have a device. When rc.local runs,
later on, that (I am guessing here) will cause the device to come into
existence. gpsd will then pick it up and start using it.

Anyone with more bluetooth experience than I have have a better way to
do this?

Oh, today is a holiday in the US, so most Americans won't be paying
attention to this list.

--

Charles Curley /"\ ASCII Ribbon Campaign
Looking for fine software \ / Respect for open standards
and/or writing? X No HTML/RTF in email
http://www.charlescurley.com / \ No M$ Word docs in email

Key fingerprint = CE5C 6645 A45A 64E4 94C0 809C FFF6 4C48 4ECD DFDB
_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

Fw: bluetooth blues

2009-11-26T10:43:40Z

Forwarded because Jos neglected to copy the list.

Begin forwarded message:

Date: Thu, 26 Nov 2009 17:06:55 +0100
From: Jos Meijer <josessex@...>
To: Charles Curley <charlescurley@...>
Subject: Re: [Gpsd-users] bluetooth blues

Charles Curley wrote:

To make a short story long:

it was indeed init.d I meant, and the device should not be defined
there but in etc/devices/gpsd
(As I am, like you, using Ubuntu 9.10)
I did change etc/default/gpsd with dkgp (sudo) and boldly corrected a
type error I made later with the text editor of MC.
Yet, after some re-initializing, stopping and re-starting of gpsd I
suddently had a response in telnet,
xgps shows sats and positions and (main goal) GPSDrive finally moves me
from near Russia to Dunkerque (fr).

Any of you developer-guys reading along with this:
I would love to shape this happy end into a complete story for ubuntu
users but how and where should I post it?

>> hello,
>>
>> in my struggle to get rid of Bill Gates I tried to get my GPS
>> working. I neatly followed the instructions about installing a
>> bluetooth gps and it went well untill I got to the part about adding
>> gps_device to gpsd in init_d.
>>
>
> Did you mean /etc/init.d?
>
>
>> The howto assumes there is already a #GPS_DEV="/dev/ttyS3" or so to
>> be found which can be uncommented and altered to the correct
>> GPS_DEV="/dev/rfcomm0" .
>>
>
> I take it you mean this document: http://gpsd.berlios.de/bt.html
>
>
>> My gpsd in init_d has no such entry, so I put it where I thought it
>> would be at the right place, but I should confess that that is in my
>> case merely guessing.
>>
>
> You may not need to modify anything, as gpsd will try several likely
> suspects. In case you do:
>
> I guess you are using either Debian or Ubuntu, partly because your
> script looks a lot like mine on Ubuntu 9.10. In that case, you want to
> modify /etc/default/gpsd, not /etc/init.d/gpsd. And the way to do that
> is with the command line tool `dpkg-reconfigure gpsd'. You should do
> that as root, so either log in as root however you usually do it (a
> typical Debian route) or prefix that with `sudo' (the Ubuntu route).
>
> The Debian/Ubuntu script doesn't use GPS_DEV, it uses DEVICES to
> specify the device. I suspect the howto is based on a different Linux
> distribution.
>
>
>
>
>> Anyway, as I go on with the procedure and start telnet, it reports
>> nothing and after a while it says "connection closed by foreign
>> host".
>
> Right, a timeout is normal. Once you get a connection, use the "r"
> command to see gps data. Using a gps receiver which is running but has
> no fix, I see:
>
> --------------------------------------------------
> ccurley@dragon:~$ telnet freeman 2947
> Trying 192.168.1.31...
> Connected to freeman.localdomain.
> Escape character is '^]'.
> r
> GPSD,R=1
> $GPRMC,143646,V,18000.0000,N,00000.0000,W,0.0000,0.000,261109,,*1E
> $GPGSA,A,1,,,,,,,,,,,,,,,,*32
> $GPRMC,143647,V,18000.0000,N,00000.0000,W,0.0000,0.000,261109,,*1F
> $GPGSA,A,1,,,,,,,,,,,,,,,,*32
> $GPRMC,143648,V,18000.0000,N,00000.0000,W,0.0000,0.000,261109,,*10
> $GPGSA,A,1,,,,,,,,,,,,,,,,*32
> r
> GPSD,R=0
> ^]
>
> telnet> quit
> Connection closed.
> ccurley@dragon:~$
> --------------------------------------------------
>
> I provided the two "r" lines. Also, you will probably want to use
> "telnet localhost 2947" rather than what I typed.
>
>
>> Anyone has any clue how I should go on? kind regards Jos Meijer
>>
>> init_d/gpsd looks like:
>>
>>
>> #!/bin/sh
>> #
>> # Authors: Tilman Koschnick <til@...>
>> # Bernd Zeimetz <bzed@...>
>> #
>>
>>
>
> ...
>
>
>> # include gpsd defaults
>> if [ -f /etc/default/gpsd ] ; then
>> . /etc/default/gpsd
>>
>
> This is where /etc/init.d/gpsd reads in its parameters
>
>
>
>> else
>> log_failure_msg "gpsd: error: Cannot find /etc/default/gpsd."
>> exit 1
>> fi
>>
>
>
>

--

Charles Curley /"\ ASCII Ribbon Campaign
Looking for fine software \ / Respect for open standards
and/or writing? X No HTML/RTF in email
http://www.charlescurley.com / \ No M$ Word docs in email

Key fingerprint = CE5C 6645 A45A 64E4 94C0 809C FFF6 4C48 4ECD DFDB
_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

Re: bluetooth blues

2009-11-26T06:54:33Z

On Thu, 26 Nov 2009 09:37:40 +0100
Jos Meijer <josessex@...> wrote:

> hello,
>
> in my struggle to get rid of Bill Gates I tried to get my GPS working.
> I neatly followed the instructions about installing a bluetooth gps
> and it went well untill I got to the part about adding
> gps_device to gpsd in init_d.

Did you mean /etc/init.d?

>
> The howto assumes there is already a #GPS_DEV="/dev/ttyS3" or so to be
> found which can be uncommented and altered to the correct
> GPS_DEV="/dev/rfcomm0" .

I take it you mean this document: http://gpsd.berlios.de/bt.html

>
> My gpsd in init_d has no such entry, so I put it where I thought it
> would be at the right place, but I should confess that that is in my
> case merely guessing.

You may not need to modify anything, as gpsd will try several likely
suspects. In case you do:

I guess you are using either Debian or Ubuntu, partly because your
script looks a lot like mine on Ubuntu 9.10. In that case, you want to
modify /etc/default/gpsd, not /etc/init.d/gpsd. And the way to do that
is with the command line tool `dpkg-reconfigure gpsd'. You should do
that as root, so either log in as root however you usually do it (a
typical Debian route) or prefix that with `sudo' (the Ubuntu route).

The Debian/Ubuntu script doesn't use GPS_DEV, it uses DEVICES to
specify the device. I suspect the howto is based on a different Linux
distribution.

>
> Anyway, as I go on with the procedure and start telnet, it reports
> nothing and after a while it says "connection closed by foreign host".

Right, a timeout is normal. Once you get a connection, use the "r"
command to see gps data. Using a gps receiver which is running but has
no fix, I see:

--------------------------------------------------
ccurley@dragon:~$ telnet freeman 2947
Trying 192.168.1.31...
Connected to freeman.localdomain.
Escape character is '^]'.
r
GPSD,R=1
$GPRMC,143646,V,18000.0000,N,00000.0000,W,0.0000,0.000,261109,,*1E
$GPGSA,A,1,,,,,,,,,,,,,,,,*32
$GPRMC,143647,V,18000.0000,N,00000.0000,W,0.0000,0.000,261109,,*1F
$GPGSA,A,1,,,,,,,,,,,,,,,,*32
$GPRMC,143648,V,18000.0000,N,00000.0000,W,0.0000,0.000,261109,,*10
$GPGSA,A,1,,,,,,,,,,,,,,,,*32
r
GPSD,R=0
^]

telnet> quit
Connection closed.
ccurley@dragon:~$
--------------------------------------------------

I provided the two "r" lines. Also, you will probably want to use
"telnet localhost 2947" rather than what I typed.

>
> Anyone has any clue how I should go on? kind regards Jos Meijer
>
> init_d/gpsd looks like:
>
>
> #!/bin/sh
> #
> # Authors: Tilman Koschnick <til@...>
> # Bernd Zeimetz <bzed@...>
> #
>

...

>
> # include gpsd defaults
> if [ -f /etc/default/gpsd ] ; then
> . /etc/default/gpsd

This is where /etc/init.d/gpsd reads in its parameters

> else
> log_failure_msg "gpsd: error: Cannot find /etc/default/gpsd."
> exit 1
> fi

--

Charles Curley /"\ ASCII Ribbon Campaign
Looking for fine software \ / Respect for open standards
and/or writing? X No HTML/RTF in email
http://www.charlescurley.com / \ No M$ Word docs in email

Key fingerprint = CE5C 6645 A45A 64E4 94C0 809C FFF6 4C48 4ECD DFDB
_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

gpspipe question

2009-11-26T04:08:20Z

Hi,

Quick question:

I've got the following setup:

Box a: running gpsfake using prerecorded nmea log files, xgps shows
expected results on this box.

Box b: This box is a custom distribution and doesn't run python so
can't run gpsfake locally, using gpspipe to take the output from box a
using -r -s .

I'm having problems on box b to get gpsd to pick up the data from gpspipe.

Box b:
gpsd running using /dev/gps
(/dev/gps created using mknod -m 666 /dev/gps c 4 64)
gpspipe -r -s /dev/gps 192.168.0.1:2947 (box a's ip address).

The gpspipe command is showing the expected nmea sentances from box a,
however running a second gpspipe or cgps on box b's gpsd does not show
any output...

gpspipe -r 127.0.0.1:2947 just gives the initial gpsd message and no
futher data.

Any ideas?

(Or do I need to setup /dev/gps_in and /dev/gps_out and link them some
how to get a gpsd to listen to the gpspipe data?)

--
Richard Horton
Users are like a virus: Each causing a thousand tiny crises until the
host finally dies.
http://www.solstans.co.uk - Solstans Japanese Bobtails and Norwegian Forest Cats
http://www.pbase.com/arimus - My online photogallery
_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

bluetooth blues

2009-11-26T00:37:40Z

hello,

in my struggle to get rid of Bill Gates I tried to get my GPS working.
I neatly followed the instructions about installing a bluetooth gps and
it went well untill I got to the part about adding
gps_device to gpsd in init_d.

The howto assumes there is already a #GPS_DEV="/dev/ttyS3" or so to be
found which can be uncommented and altered to the correct
GPS_DEV="/dev/rfcomm0" .

My gpsd in init_d has no such entry, so I put it where I thought it
would be at the right place, but I should confess that that is in my
case merely guessing.

Anyway, as I go on with the procedure and start telnet, it reports
nothing and after a while it says "connection closed by foreign host".

Anyone has any clue how I should go on? kind regards Jos Meijer

init_d/gpsd looks like:

#!/bin/sh
#
# Authors: Tilman Koschnick <til@...>
# Bernd Zeimetz <bzed@...>
#

### BEGIN INIT INFO
# Provides: gpsd
# Required-Start: $syslog $network dbus
# Should-Start: bluetooth
# Required-Stop: $syslog $network
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Start the GPS (Global Positioning System) daemon
### END INIT INFO

set -e

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
DAEMON=/usr/sbin/gpsd
DESC="GPS (Global Positioning System) daemon"
PIDFILE="/var/run/gpsd.pid"
SELF=$(cd $(dirname $0); pwd -P)/$(basename $0)
GPS_DEV="/dev/rfcomm0"

test -x $DAEMON || exit 0

. /lib/lsb/init-functions

# include gpsd defaults
if [ -f /etc/default/gpsd ] ; then
. /etc/default/gpsd
else
log_failure_msg "gpsd: error: Cannot find /etc/default/gpsd."
exit 1
fi

case "$1" in
start)
if [ "x$START_DAEMON" = "xtrue" ] ; then
log_daemon_msg "Starting $DESC" "gpsd"
start-stop-daemon --start --quiet \
--exec $DAEMON -- $DAEMON_OPTS -P $PIDFILE $DEVICES \
&& log_end_msg 0 \
|| log_end_msg 1
else
log_daemon_msg "Not starting $DESC" "gpsd" && log_end_msg 0
fi
;;
stop)
if [ "x$START_DAEMON" = "xtrue" ] ; then
log_daemon_msg "Stopping $DESC" "gpsd"
WARN=$(start-stop-daemon --stop --quiet --oknodo --pidfile $PIDFILE)
log_end_msg 0
[ -n "$WARN" ] && log_warning_msg "$WARN"
else
log_daemon_msg "Not stopping $DESC" "gpsd" && log_end_msg 0
fi
;;
reload|force-reload)
log_action_msg "gpsd: Resetting connection to GPS device"
WARN=$(start-stop-daemon --stop --signal 1 --quiet --oknodo
--pidfile $PIDFILE)
[ -n "$WARN" ] && log_warning_msg "$WARN"
;;
restart)
set +e; $SELF stop; set -e
$SELF start
;;
status)
status_of_proc $DAEMON gpsd
;;
*)
N=/etc/init.d/gpsd
echo "Usage: $N {start|stop|restart|reload|force-reload|status}" >&2
exit 1
;;
esac

exit 0

_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

Re: PPS data from gpsd on OpenBSD??

2009-11-25T16:04:17Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Yo Rich!

On Wed, 25 Nov 2009, Rich Wales wrote:

> > PPS works just fine on stock Linux kernels/distros.
> > Just add ntpd and gpsd.
>
> Do I not need to use the "LinuxPPS" kernel patches to make it work
> in Linux?

Correct. You do not need to patch the kernel. There may be advantages
to doing so, but not seen the need myself.

> I had been under the impression that PPS handling either wouldn't
> work at all, or would be very unreliable, in Linux without LinuxPPS.

Works for me, and a lot of others, YMMV.

> I'm not looking for nanosecond (or even microsecond) accuracy here,
> mind you. Accuracy in the 10 - 100 microsecond range would be fine.

You are not going to get close to nanosecond with a GPS. Most are
speced to 1uS. Accuracy is pretty hard to prove and usually not
any where near what people think they have. Just look at all the
stratum 1 servers that differ by 10mS or more.

Stability is a lot easier to show. I have two different Linux hosts,
one getting PPS from a SiRF III and one from a Garmin GPS-18/LVC. ntpd
says they agree better than 10uS most of the time. You will easily be
stable to less than 100uS.

RGDS
GARY
- ---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701
gem@... Tel:+1(541)382-8588

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFLDcYEBmnRqz71OvMRAqtjAJ9m3CfBZjEPoQfdHo0/xGA0/w2ziwCgtUyt
wrZCfu5ydK7NLTeLzTeRvkg=
=bom5
-----END PGP SIGNATURE-----

_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

Re: PPS data from gpsd on OpenBSD??

2009-11-25T15:50:16Z

Gary E. Miller wrote:

> PPS works just fine on stock Linux kernels/distros.
> Just add ntpd and gpsd.

Do I not need to use the "LinuxPPS" kernel patches to make it work
in Linux?

I had been under the impression that PPS handling either wouldn't
work at all, or would be very unreliable, in Linux without LinuxPPS.

I'm not looking for nanosecond (or even microsecond) accuracy here,
mind you. Accuracy in the 10 - 100 microsecond range would be fine.

Rich Wales
richw@...
_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

Re: PPS data from gpsd on OpenBSD??

2009-11-25T15:37:20Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Yo Rich!

On Wed, 25 Nov 2009, Rich Wales wrote:

> I'm using the current gpsd sources from SVN (revision 6600).

Good. Been a lot of improvment lately.

> PPS_ENABLE is defined in gpsd_config.h, but TIOCMIWAIT appears to be a
> Linux-specific thing that doesn't exist in OpenBSD.

Yep, no TIOCMIWAIT then you get no PPS from gpsd. Since I have no OpenBSD
I have no idea what the workaround might be.

On Linux the gps_ppsmonitor() uses ioctl(TIOCMIWAIT) to wait for a
change on the PPS pin. That way it gets woken up promptly on a PPS
change and yet wastes no time in a wait loop.

I see two options, connect the PPS pin somehow directly to ntpd or
figure out a way to wait on the pin so gps_ppsmonitor() can work on
OpenBSD.

> I want to get this working in OpenBSD, if possible, because I'm
> looking for a software platform that will support PPS out of the box,
> without requiring a custom-built kernel -- and this appears to be a
> realistic possibility in OpenBSD, but not Linux or FreeBSD.

PPS works just fine on stock Linux kernels/distros. Just add
ntpd and gpsd.

RGDS
GARY
- ---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701
gem@... Tel:+1(541)382-8588

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFLDb+yBmnRqz71OvMRAvtNAJ9FmJ9z+zgX2pqh58NDGCQECRvQlwCdFJlV
sVqO1DrC8wynkfyB83dGb50=
=OO3L
-----END PGP SIGNATURE-----

_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

PPS data from gpsd on OpenBSD??

2009-11-25T15:19:59Z

I'm trying to get gpsd to report PPS-corrected time stamps (via shared
memory) to ntpd, on an OpenBSD 4.6 system, using "ldattach" to invoke
the "nmea" line discipline (see OpenBSD's "ldattach" manual page if you
aren't sure what this means) on a serial device to which I've attached a
Garmin 18x LVC GPS unit.

I'm using the current gpsd sources from SVN (revision 6600).

I can get gpsd to read the GPS and report its regular timestamps (not
corrected for PPS) via shared memory -- but the second set of timestamps
(which *are* corrected for PPS) are not being communicated to ntpd.

I've tried running gpsd with logging (-D 5), and none of the PPS-related
log messages in ntpshm.c or libgpsd_core.c are being output.

As I examine the source code, it appears that the PPS-corrected timestamp
data is written to shared memory via ntpshm_pps() in ntpshm.c -- which is
called at only one place, in gpsd_ppsmonitor() in libgpsd_core.c. But
gpsd_ppsmonitor() is conditionally defined to be included only if *both*
PPS_ENABLE *and* TIOCMIWAIT are defined.

PPS_ENABLE is defined in gpsd_config.h, but TIOCMIWAIT appears to be a
Linux-specific thing that doesn't exist in OpenBSD.

I had been under the impression that PPS data from a reference clock
could be processed in OpenBSD, via a combination of "ldattach", "gpsd",
and "ntpd". Did I misunderstand? Am I missing some crucial piece?

I've verified that my Garmin GPS unit is configured to emit PPS pulses,
and I've also verified (on FreeBSD and Linux) that I've correctly wired
up the GPS to send the PPS signals via the carrier line of the serial
port. I want to get this working in OpenBSD, if possible, because I'm
looking for a software platform that will support PPS out of the box,
without requiring a custom-built kernel -- and this appears to be a
realistic possibility in OpenBSD, but not Linux or FreeBSD.

Rich Wales
richw@...
_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

Re: Problem compiling gpsd from SVN

2009-11-25T14:11:15Z

I managed to fix the problem by removing and reinstalling autoconf and
automake.

I successfully built gpsd using autoconf-2.59 and automake-1.9. These
are earlier versions than what I was using before, and they're earlier
than the versions recommended in the INSTALL file, but all I can say is
that autogen.sh worked (for me) with these versions and did not work
(for me) with the later versions I had tried earlier.

Rich Wales
richw@...
_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

Re: Chrony

2009-11-25T08:39:31Z

Gary E. Miller wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Yo Chrony users!
>
> I see that last Chrony update was 2007, and I can not get to the chrony
> web site: http://chrony.sunsite.dk/
>
> This from the Ver 1.23 README:
>
> Compared to the `reference' RFC1305 implementation xntpd, chronyd does
> not support hardware reference clocks, leap seconds or broadcast
> modes.
>
> Can anyone tell me how chrony works with PPS?
>
> Am I missing something obvious here?
>
>

Sunsite died unexpectedly and the site has now moved to tuxfamily.org.
There is a new git tree there and in particular the redhat developer
M.Lichvar is posting a load of useful patches. The latest trunk at
least has good support for PPS (and excellent support for occasionally
connected internet connections)

I don't think the disruption is intentional, but the project is still
alive and I personally think it beats ntpd in many areas

Good luck

Ed W
_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

Problem compiling gpsd from SVN

2009-11-24T20:42:07Z

I'm trying to compile the current development version of gpsd which I checked
out via SVN.

I'm compiling on an OpenBSD 4.6 system, with automake-1.11 and autoconf-2.62
installed by hand (because the OpenBSD packages aren't new enough).

./autogen.sh is failing with an error in automake:

automake: ####################
automake: ## Internal Error ##
automake: ####################
automake: unrequested trace `include'
automake: Please contact <bug-automake@...>.
at /usr/local/share/automake-1.11/Automake/Channels.pm line 656
Automake::Channels::msg('automake', '', 'unrequested trace
`include\'') called at /usr/local/share/automake-1.11/Automake/ChannelDefs.pm
line 201
Automake::ChannelDefs::prog_error('unrequested trace `include\'')
called at /usr/local/bin/automake line 5267
Automake::scan_autoconf_traces('configure.ac') called at
/usr/local/bin/automake line 5523
Automake::scan_autoconf_files() called at /usr/local/bin/automake line
8682

Before I report it to the "automake" people, I thought I should ask here, just
in case the "automake" developers decide to fingerpoint back at "gpsd".

Any thoughts?

Rich Wales
richw@...
_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

Re: Garmin StreetPilot C320

2009-11-23T06:57:44Z

On Fri, Nov 20, 2009 at 06:43, Eric S. Raymond <esr@...> wrote:
> Try pulling Subversion trunk. Our Garmin expert is back after along
> absence and has made some much-needed repairs to the handler code.

Rev 6585 properly reports my position. Verified against my other unit,
the TN-200. This is on Linux 2.6.31 (x86) after having modprobed
garmin_gps.
_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

Release of GPSD 2.90 draws near

2009-11-20T13:42:06Z

It's been a long epic, but we expect to release the 2.90 version of
GPSD very soon. I'm planning to call freeze on Monday, after which
only urgent bug fixes will be accepted and we may ship at any time.

The release number has been bumped to 2.90 to reflect the fact that
there have been major changes since 2.39 in March, and the next
few minor releases will be preparatory for 3.00 in which we drop the
old pre-JSON GPSD protocol.

Please get your last-minute features and your bug reports in this
weekend.

Highlights of the upcoming release will include:

* New JSON-based protocol fully deployed and documented, with all test
clients converted. libgps will support both protocols, with
application writers not needing to care which the daemon is actually
emitting.

* No more jitter! The daemon now does reliable detection of cycle
start and end on NMEA devices.

* gpsd now accepts error estimates from the NMEA $GPGBS sentence.

* Major improvements and stabilization work on PPS.

* Unpacked AIS reports will be available through the client library
for those with AIS receivers.

For client application developers: a major point of this release is to
get the new client library (libgps) deployed. Once you convert your code to use
it, you should be able to ignore the rest of the wire protocol
transition. See <http://gpsd.berlios.de/protocol-transition.html> for
transition help.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

"Historical examination of the right to bear arms, from English
antecedents to the drafting of the Second Amendment, bears proof that
the right to bear arms has consistently been, and should still be,
construed as an individual right."
-- U.S. District Judge Sam Cummings, in re U.S. vs Emerson (1999).
_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

Re: Garmin StreetPilot C320

2009-11-20T03:43:17Z

Max Afonov <max@...>:

> I've been trying unsuccessfully to get my C320 to work with gpsd.
> First off, here are some system stats:
>
> Linux wart 2.6.31-rc1-00114-g4075ea8 #1 PREEMPT Sat Jun 27 22:12:50
> EDT 2009 armv5tel GNU/Linux
>
> Module Size Used by
> garmin_gps 17536 0
> usbserial 35396 1 garmin_gps
> ipv6 268280 10
> dm_crypt 14372 0
> dm_mod 70204 1 dm_crypt
>
> gpsd 2.38
>
> I'm running on this machine whatever I pulled out of Linus' git
> repository yesterday. This is mostly because garmin_gps is broken in
> kernels 2.6.26 through even the released 2.6.30. The rest of the
> system is Ubuntu Jaunty. Very vanilla.

Try pulling Subversion trunk. Our Garmin expert is back after along
absence and has made some much-needed repairs to the handler code.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

Chrony

2009-11-18T13:04:22Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Yo Chrony users!

I see that last Chrony update was 2007, and I can not get to the chrony
web site: http://chrony.sunsite.dk/

This from the Ver 1.23 README:

Compared to the `reference' RFC1305 implementation xntpd, chronyd does
not support hardware reference clocks, leap seconds or broadcast
modes.

Can anyone tell me how chrony works with PPS?

Am I missing something obvious here?

RGDS
GARY
- ---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701
gem@... Tel:+1(541)382-8588
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFLBGFYBmnRqz71OvMRAj41AKCYecGfZGUzKsVuFAAtJ9loNBxaygCfWN9Z
yX5iB6SMlqFbVUyqqNaRVV8=
=PP8F
-----END PGP SIGNATURE-----

_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

Re: Fw: GPSD Documentation

2009-11-18T01:53:31Z

Rogier Wolff <R.E.Wolff@...>:
> As far as I can tell, the device only "speaks" Serial. It has a 9pin
> serial connector.

What does it present as a USB product/vendor ID when you
use the Garmin adaptor cable?
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

Re: Fw: GPSD Documentation

2009-11-18T01:25:01Z

On Wed, Nov 18, 2009 at 04:04:42AM -0500, Eric S. Raymond wrote:

> > 1) The device interface should be shown as "RS232" not
> > "USB" (even if the connection is made via a usb-serial
> > converter lead.) Garmin supplies a lead for transferring
> > data to/from a computer. This lead connects between the GPS
> > 76 device and a 9-pin RS232 connector. I could not find any
> > reference in the user manual to a lead that can be connected
> > directly between the GPS device and a computer USB port.
> > 2) Because it's RS232 the exclamation icon in the "tested
> > with" column is not appropriate. Connecting the Garmin will
> > probably not start the gpsd daemon. Plugging the usb-serial
> > device lead into a computer socket WOULD load the usbserial
> > driver module and might start the daemon if the system was
> > set up to do that (mine isn't). Anyway NOT correct as it
> > stands.
>
> Something seems wrong in your account. If it talks over a USB
> connector and requires the usbserial module, in what way is it
> not USB? You are describing the normal way that vendors
> support both interfaces.

As far as I can tell, the device only "speaks" Serial. It has a 9pin
serial connector. How you connect that to your PC is your problem. If
you have a serial port on your PC you can connect it there, If you
have a PCMCIA serial port on your laptop you can connect it there. If
you have an USB serial port on your computer, you can connect it
there.

You might even buy the serial adapter with Garmin. That makes it
"supported by Garmin", but if it goes through a 9pin serial connector,
saying it is serial is as far as you should go.

A FAQ entry might say:

Q: How do I connect a serial device?

A: Some computers still have serial ports. These are 25 or 9 pin
D-type connectors on the back of the PC (or on an adapter board).
More and more modern computers are shipped without a serial port.
Thus you may need an USB serial adapter or an adapter board. USB
serial ports can be bought for as little as $3 over the internet or
for about $10 - $20 in your local computer store.

Roger.

--
** R.E.Wolff@... ** http://www.BitWizard.nl/ ** +31-15-2600998 **
** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement.
Does it sit on the couch all day? Is it unemployed? Please be specific!
Define 'it' and what it isn't doing. --------- Adapted from lxrbot FAQ
_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

Re: Fw: GPSD Documentation

2009-11-18T01:04:42Z

dofinch-aria@... <dofinch-aria@...>:
> CAVEAT: I hope that the gpsd development collaborators
> won't take offense about any of this but rather that this
> mail will be of some assistance as the observations of a
> happy and grateful, but not especially linux savvy, user
> of gpsd.

Your feedback was extremely useful and I am in the process of
incorporating several of your suggestions.

> 1) Immediately after the section "SYNOPSIS" add a new
> section "EXAMPLES OF BASIC OPERATION".

I'm doing this now.

> 3) To be truly helpful the Compatible Hardware table should
> be extended to show also HOW the hardware is to be used. A
> few simple additions should suffice. In this context I would
> like to see the following added to the Garmin GPS 76 entry:
>
> In the Notes column:
>
> "This device can be connected directly to a Serial RS232
> port on the computer using the special PC connector lead
> supplied by Garmin (a 9-pin RS232 connector is used at the
> PC end). Issue the command 'gpsd /dev/ttyS0', or similar, in
> a terminal window to start gpsd.
>
> The device can also be connected to a USB socket on the PC
> by using a USB-Serial converter lead. In this latter case,
> in Linux, the usbserial Kernel Module must be loaded and
> started with a command such as 'sudo modprobe usbserial
> vendor=0×1a86 product=0×7523' (check the manual for your
> usb-serial converter device for more information on this -
> vendor and product number will most likely be different for
> your device). Start gpsd by issuing the command 'gpsd
> /dev/ttyUSB0' or similar in a terminal window. In this case
> the Garmin GPS 76 comms MUST be set to 'NMEA'. The kernel
> module garmin_gps is not needed and should not be specially
> loaded."

This is *far* too long for the notes column. The stuff about the
usbserial module actually belongs in our FAQ and I'm going to put it
there.

> Unfortunately, at present I believe that the table also has
> some errors in its content for the Garmin GPS 76 device:
>
> 1) The device interface should be shown as "RS232" not
> "USB" (even if the connection is made via a usb-serial
> converter lead.) Garmin supplies a lead for transferring
> data to/from a computer. This lead connects between the GPS
> 76 device and a 9-pin RS232 connector. I could not find any
> reference in the user manual to a lead that can be connected
> directly between the GPS device and a computer USB port.
> 2) Because it's RS232 the exclamation icon in the "tested
> with" column is not appropriate. Connecting the Garmin will
> probably not start the gpsd daemon. Plugging the usb-serial
> device lead into a computer socket WOULD load the usbserial
> driver module and might start the daemon if the system was
> set up to do that (mine isn't). Anyway NOT correct as it
> stands.

Something seems wrong in your account. If it talks over a USB
connector and requires the usbserial module, in what way is it
not USB? You are describing the normal way that vendors
support both interfaces.

> 3) There's a coding bug in the html which makes the three
> star designation in "tested with" column look wrong (see
> attached image).

Attachment is missing.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

We're now in a pre-release condition for 2.40

2009-11-16T09:37:25Z

The patch I was waiting for from Gary Miller came in; Garmin
functionalitry is restored. Under our release procedure, this puts us
in condition Yellow. That is, there are no known blocker bugs. 'make
testregress' passes. Problem children have been live-tested.

The only known issue is one report on IRC that gpsdrive and gostango
don't talk to the trunk daemon. This may be pilot error or a local
configuration problem; it would be useful if someone on the lists
were to test those.

7 days from now any developer with release authorirty (Chris, Gary,
or myself) can call a freeze for release.

From this point until release I'm going to be very conservative about
allowing changes into core code. PPS and driver bugfixes can continue.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

"Extremism in the defense of liberty is no vice; moderation in the
pursuit of justice is no virtue."
-- Barry Goldwater (actually written by Karl Hess)
_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

Re: TSIP patch

2009-11-15T15:38:45Z

Chris Adams <cmadams@...>:
> Once upon a time, Chris Adams <cmadams@...> said:
> > Here's an updated version of my patch to the TSIP support to get my
> > SVeeSix working. It does several things:
>
> Is there anything else I need to do with this? It'd be nice to see this
> upstream.

I understand, but I'm not our TSIP driver expert.

ckuethe, would you please review this patch and merge as appropriate?
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

Re: TSIP patch

2009-11-15T15:29:38Z

Once upon a time, Chris Adams <cmadams@...> said:
> Here's an updated version of my patch to the TSIP support to get my
> SVeeSix working. It does several things:

Is there anything else I need to do with this? It'd be nice to see this
upstream.
--
Chris Adams <cmadams@...>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

Re: Ntp Problems

2009-11-14T18:57:10Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Yo Håkan!

On Sat, 14 Nov 2009, Håkan Johansson wrote:

> The attached patch adds a call to shmctl to get the size of the just attached
> shm segment.

Nothing attached.

RGDS
GARY
- ---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701
gem@... Tel:+1(541)382-8588

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFK/24IBmnRqz71OvMRAjjpAKCSu5ZTu4rqsioXsy2QmWZNLi7JawCeI9jw
qoo1evwdgYrGnSW0frsWK2Y=
=2Uu4
-----END PGP SIGNATURE-----

_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

Re GPSD Documentation

2009-11-14T10:06:57Z

Hello Eric,

That's good to hear. Thank you. Roll on V2.40.

Thanks once again for a great piece of software.

Sincerely

Geoff Childs
_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

Re: Ntp Problems

2009-11-14T02:23:05Z

The attached patch adds a call to shmctl to get the size of the just
attached shm segment. Could be useful for debugging. On my i686 linux
system, I get lines like:

gpsd: NTPD shmat(65538,0,0) succeeded, size = 80 (expect 80)
gpsd: NTPD shmat(98307,0,0) succeeded, size = 80 (expect 80)

When playing with the shmget size argument, the following happens:

attemting to shmget with a larger size than the already existing segment
(created by ntpd):

gpsd: NTPD shmget fail: Invalid argument

attempting to shmget with a smaller size succeeds. (shmctl returns the
original size)

--

I've checked ntp back to xntp3-5.93e (or rather: back at. year 1998) and
it uses the same shm structure layout as today, so from that point it
could be safe to make gpsd refuse to use the shm segment if the size
mismatches. However, I do not know if there are any systems that e.g.
round the size up to the nearest page size, which would make the test
fail. Perhaps best left as just debug output, or make it a warning
message on mismatch.

Cheers,
Håkan

On Sat, 14 Nov 2009, Don Weeks wrote:

> NTP/GPSD is finally working. If anyone else has this problem, please be
> aware that ntpd and gpsd must be compiled with the same bit size. My 32bit
> ntpd gave me a smaller shm than gpsd would use and gpsd gave a larger shm
> than ntp would use. After compiling both with the same flags and getting the
> clocks reasonably close, it is working. I had this problem on a 64 bit
> Cavium processor which has both 32 and 64 bit memory models. Most of the OS
> is MIPS O32 and our modules are compiled 64 bit.
> Don
>
>>
>>
> _______________________________________________
> Gpsd-users mailing list
> Gpsd-users@...
> https://lists.berlios.de/mailman/listinfo/gpsd-users
>

_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

Re: Fw: GPSD Documentation

2009-11-13T22:19:18Z

dofinch-aria@... <dofinch-aria@...>:
> How could this be changed?
> ================================

Thank you! This is extremely valuable feedback. I am responsible for the
manual page, and I will make sure these issues are addressed before we
ship 2.40.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

gps callback function oddity

2009-11-13T18:52:31Z

I am having some issues with the callback routine. While in general, it
works great but one thing that is causing me a problem is that when I lose
GPS signal, the mode never gets updated by the callback to nofix. Has anyone
else seen this? I need to update LEDs based on GPS status and while the 2d
to 3d works, the change to nofix is never reported back to me.
Don
_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

Re: Ntp Problems

2009-11-13T18:43:02Z

NTP/GPSD is finally working. If anyone else has this problem, please be
aware that ntpd and gpsd must be compiled with the same bit size. My 32bit
ntpd gave me a smaller shm than gpsd would use and gpsd gave a larger shm
than ntp would use. After compiling both with the same flags and getting the
clocks reasonably close, it is working. I had this problem on a 64 bit
Cavium processor which has both 32 and 64 bit memory models. Most of the OS
is MIPS O32 and our modules are compiled 64 bit.
Don

>
>
_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

Fw: GPSD Documentation

2009-11-13T18:26:04Z

Hello,

I am using Viking GPS Manager running
under Ubuntu Linux on my laptop and connect it to a Garmin
handheld GPS 76 device to implement an excellent SatNav
system.

Viking uses gpsd to provide real time 3D position
information. It's extremely easy, in principle, to set this
up and the results are first class. Tested by using xgps the
values shown on the xgps window are EXACTLY those displayed
on the GPS device. Testing using Viking, the cursor jumps
immediately to my present location on the displayed maps.

I would like to thank ALL the collaborators for their work
in providing the truly excellent gpsd software!

Despite there being a trivial solution I COULD NOT by
myself get gpsd to communicate with the Garmin. There are so
many options and possibilities that it's necessary to know
exactly what you are doing or you get nowhere. In the end I
had to seek advice and I am grateful to Gary E Miller who
responded to my cry for help rapidly and with spot-on
information about what I should do.

My Solution
=================

My laptop is a Lenovo 3000 C200. The operating system is
Ubuntu Linux v 9.10 (Karmic Kaola!) My chosen GPS Manager is
Viking v0.98 and I am using gpsd v 2.39 (the most up-to-date
version that I could find on the berliOS website) so that
Viking can obtain current position updates.

My GPS device is a Garmin GPS 76
handheld which communicates to a PC through an RS232
interface. The Lenovo doesn't have an RS232 socket so I
connect via a USB-Serial Interface and install the usbserial
Linux driver module to enable it as /dev/ttyUSB0.

I set the Garmin hardware's comms to "NMEA".

I issue the command "gpsd /dev/ttyUSB0" to start the
daemon.

And that's it! Perfect operation - fast updates and very
accurate position reports.

What was my problem?
=============================

CAVEAT: I hope that the gpsd development collaborators
won't take offense about any of this but rather that this
mail will be of some assistance as the observations of a
happy and grateful, but not especially linux savvy, user
of gpsd.

The first resource that I read was the on-line manual
viewed by issuing "man gpsd" at a terminal. With the benefit
of hindsight I've re-read the complete manual to see whether
I could have deduced the solution suggested by Gary. Sadly I
believe that I would not have succeeeded.

The manual has the following outline:

a) The SYNOPSIS (lines 9/10) - interesting but all I needed
was the much simpler syntax: "gpsd source_name". IMPORTANT:
"source_name" is a KEY parameter. What this is, however, is
not explained anywhere in the document and only a few,
vague, clues appear MUCH further down.

b) The DESCRIPTION - a useful introduction to the purpose
of gpsd. Interesting but not relevant to getting gpsd
talking to my Garmin. The suggested probe "gpsd -l" produces
a list of possible protocols - 22 in my case, many obviously
inappropriate - without any guidance as to which should be
used - not very helpful.

c) The OPTIONS (starting with the -F option) - Interesting
but not relevant. My solution needs NO options.

d) The remaining document - interesting but not helpful.
Line 146 warns that from then on a large chunk is deprecated
anyway!

The "clues":

- in line 114! - it says that "Normally, a data source is
the name of a local serial device from which the daemon may
expect GPS data." What is meant by "name" here is never
explained.

-in line 702 and 763! - some passing references to
"/dev/ttyS0" in line 702 and 763! Flash of light! - the
source_name is just the Linux device file (thus "gpsd
/dev/ttyUSB0" for my solution.)

How could this be changed?
================================
I suggest that, to help people in my situation who "just"
need to get the daemon talking to a gps device as quickly
and easily as possible:

1) Immediately after the section "SYNOPSIS" add a new
section "EXAMPLES OF BASIC OPERATION".

The examples would probably be something like "gpsd
/dev/ttyS0". Perhaps half a dozen or so would suffice to
cover a majority of basic implementations.

2) At the end of the "EXAMPLES..." section add the
paragraph:

"For your first connection tests, set your GPS hardware
device comms to "NMEA" (check the User Manual of your GPS
hardware device to find out how to do this). Most devices
will talk this protocol. After you have successfully
communicated with your device using this protocol you can
try others to see whether they offer any speed or
functionality advantages."

Next point the reader to the "Compatible Hardware" table to
be found on the web at http:///gpsd.berlios.de/hardware.html.

The following would also be helpful:

"You can test correct operation by first starting gpsd and
then xgps (the X-Windows test client for gpsd). You should
ensure that your GPS device has a good fix and that it is
displaying your current location. Then, if all is well, the
xgps x-window will display EXACTLY the same location data."

Finally, in case the user doesn't get the connection
working, make sure that the he/she knows about the
"Troubleshooting" document to be found (at least in the
Ubuntu distribution) at /usr/share/doc/gpds. To be honest
this document didn't help me either and I suggest that it
should be revised radically. But that's another subject.

3) To be truly helpful the Compatible Hardware table should
be extended to show also HOW the hardware is to be used. A
few simple additions should suffice. In this context I would
like to see the following added to the Garmin GPS 76 entry:

In the Notes column:

"This device can be connected directly to a Serial RS232
port on the computer using the special PC connector lead
supplied by Garmin (a 9-pin RS232 connector is used at the
PC end). Issue the command 'gpsd /dev/ttyS0', or similar, in
a terminal window to start gpsd.

The device can also be connected to a USB socket on the PC
by using a USB-Serial converter lead. In this latter case,
in Linux, the usbserial Kernel Module must be loaded and
started with a command such as 'sudo modprobe usbserial
vendor=0×1a86 product=0×7523' (check the manual for your
usb-serial converter device for more information on this -
vendor and product number will most likely be different for
your device). Start gpsd by issuing the command 'gpsd
/dev/ttyUSB0' or similar in a terminal window. In this case
the Garmin GPS 76 comms MUST be set to 'NMEA'. The kernel
module garmin_gps is not needed and should not be specially
loaded."

---End of addition---

Unfortunately, at present I believe that the table also has
some errors in its content for the Garmin GPS 76 device:

1) The device interface should be shown as "RS232" not
"USB" (even if the connection is made via a usb-serial
converter lead.) Garmin supplies a lead for transferring
data to/from a computer. This lead connects between the GPS
76 device and a 9-pin RS232 connector. I could not find any
reference in the user manual to a lead that can be connected
directly between the GPS device and a computer USB port.
2) Because it's RS232 the exclamation icon in the "tested
with" column is not appropriate. Connecting the Garmin will
probably not start the gpsd daemon. Plugging the usb-serial
device lead into a computer socket WOULD load the usbserial
driver module and might start the daemon if the system was
set up to do that (mine isn't). Anyway NOT correct as it
stands.
3) There's a coding bug in the html which makes the three
star designation in "tested with" column look wrong (see
attached image). For a long time I thought that the rating
was just ONE star or at best TWO and I nearly gave up!!!!
The image is copied from the Firefox browser but the page
displayed by IE7 is similarly corrupt.

Sincerely,

Geoff Childs

_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

Re: Ntp Problems

2009-11-13T13:57:50Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Yo Don!

On Fri, 13 Nov 2009, Don Weeks wrote:

> I think I see the problem. In the /proc/sysvipc/shm that was created on
> my system, gpsd, which is compiled with a 64bit OCTEON MIPs compiler is
> running against an NTP compiled with 32 bit O32 compiler.

Hmm... If you see how we can fix the packing to make both 64/32 work
then pass on the idea.

I'm thinking this structure, in ntpshm.c is the problem:

struct shmTime {
int mode; /* 0 - if valid set
* use values,
* clear valid
* 1 - if valid set
* if count before and after read of values is equal,
* use values
* clear valid
*/
int count;
time_t clockTimeStampSec;
int clockTimeStampUSec;
time_t receiveTimeStampSec;
int receiveTimeStampUSec;
int leap;
int precision;
int nsamples;
int valid;
int pad[10];
};

That is right out of the ntpd driver file refclock_shm.c, so likely
nothing we can do about it.

RGDS
GARY
- ---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701
gem@... Tel:+1(541)382-8588

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFK/dZgBmnRqz71OvMRAiE5AJ985iDLlCLEuQwBmghBuNN1nEnI8QCfdqdN
E/FaIvQNeJvQqUatS3DEzuw=
=4iRw
-----END PGP SIGNATURE-----

_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

Re: Ntp Problems

2009-11-13T13:51:34Z