Nabble - GPSd

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

From forum: 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

From forum: 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

From forum: 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

From forum: 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

From forum: GPSd - Users

Re: [Gpsd-commit-watch] r6606 - trunk

2009-11-26T08:11:41Z

esr at BerliOS <esr@...> writes:

> Author: esr
> Date: 2009-11-26 12:47:09 +0100 (Thu, 26 Nov 2009)
> New Revision: 6606
>
> Modified:
> trunk/Makefile.am
> Log:
> Deal with jsongen.py not having execute permission.
>
>
> Modified: trunk/Makefile.am
> ===================================================================
> --- trunk/Makefile.am 2009-11-26 11:12:37 UTC (rev 6605)
> +++ trunk/Makefile.am 2009-11-26 11:47:09 UTC (rev 6606)
> @@ -206,7 +206,7 @@
>
> ais_json.i: jsongen.py
> rm -f $(srcdir)/ais_json.i && \
> - $(srcdir)/jsongen.py --ais --target=parser >ais_json.i && \
> + python $(srcdir)/jsongen.py --ais --target=parser >ais_json.i && \
> chmod a-w $(srcdir)/ais_json.i
>
> revision.h: Makefile

This is wrong, because

configure.ac does set the execute bit

we don't know that 'python' runs python - the point of substituting
@PYTHON@ is precisely to avoid this unportable assumption.

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

attachment0 (200 bytes) Download Attachment

From forum: GPSd - Dev

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

From forum: GPSd - Users

libtool 2.2.6 breakage affects gpsd build

2009-11-26T04:26:11Z

After upgrading to Ubuntu 9.10 (Karmic Koala) I have discovered that
libtool got completely broken sometime before 2.2.6. The symptom is
that a clean build with autogen.sh fails; a workaround is to specify
the --disable-shared option.

This is on top of an earlier problem where libtool was spuriously
generating a libgps-0.0.0 rather than inserting the major and minor
version correctly.

I have reached my disgust limit with autotools. I will be moving
us to scons as soon as is practicable.
--
>>esr>>
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

From forum: GPSd - Dev

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

From forum: 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

From forum: 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

From forum: 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

From forum: 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

From forum: 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

From forum: 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

From forum: 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

From forum: 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

From forum: GPSd - Users

Re: Open bug

2009-11-24T10:27:03Z

Gary E. Miller <gem@...>:
> Just checked out the latest SVN and not I get a blank 'GPS Type' in cgps.

There's client-side debugging now. Resync, run with -d, and cvapture stderr.
That will tell you if the driver type is being shipped in the JSON and
whether cgps sees it. Look for ""Device ID or list set." in the debug output
and in the cgps.c code.

> For SiRF this works:
> gpsctl -n
>
> But this is broken again:
> gpsctl -b

There have been no changes to the SiRF driver or gpsct.c recently. so
I have no idea what the problem could be. Can you bisect again a revision
that didn't have this problem?
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

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

signature.asc (196 bytes) Download Attachment

From forum: GPSd - Dev

Re: watch and DEVICES object at startup in 2.90dev

2009-11-24T08:57:50Z

Michael R. Davis <mrdvt92@...>:
> If you restart the deamon and then quickly execute a
> ?WATCH={"enable":true}; You get the DEVICES object before the DEVICE
> has had a chance to get the flags or subtype properties.

Yes, this is an unavoidable hardware-level race condition. The time
at which the device probe will elicit a device subtype ID - or even
whether it will do so at all - is not predictable. The time at which
gpsd will achieve packet sync after the device is opened as an effect
of the ?WATCH is also not predictable.

You're now bumping into one of the major reasons I designed the new
protocol around streaming and the client library is designed to handle
any response at any time rather than being built around a lockstep
assumption and query operations.

Older protocol versions tried to paper over this problem, pretending
the device can be assumed to be in a good state (with driver type
known) any time after channel attach. It cannot be; the problem is
fundamental.

In fact, it is not even guaranteed that any device in the DEVICES list
will *ever* achieve packet sync - you could be looking at non-GPSes or
GPSes of unknown type, put in GPSD's device pool by udev simply
because of a USB hotplug event.

Hm. This may belong in the FAQ.

>I also think the WATCH object should come before the the DEVICES
>object in the return.

If this proposal is an attempt to head off the race condition, it won't work.

The initial DEVICES response is intended to tell the client the driver
type in the event that gpsd has already achieved packet sync when the
device is opened. Perhaps gpsd was started with -n, or another GPSD
client application has previously triggered the GPS open.

If this isn't the case, gpsd will ship a DEVICE notification when the
device subtype field is set. Clients need to watch for both cases
if they're interested in that information.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

From forum: GPSd - Dev

Re: changing the TSIP probe logic

2009-11-23T12:11:22Z

Michael R. Davis <mrdvt92@...>:
> > > So, it appears to me that configuring a
> > > BU-303 as a "Trimble TSIP" locks it up.
> >
> > Chris said he thought he might have fixed this
> > one by changing the TSIP probe logic. Please
> > resync and test.
>
> I'm not sure what version you think you fix this but it happened again

Something is not right with the diagnosis. Where is the code that is
'configuring a BU-303 as a "Trimble TSIP"'?

There aren't any probes we send to elicit a "this is a TSIP" response,
that binary type is only set when we see its packets coming up the wire.
So under what circumstances can a SiRF get sent TSIP configuration strings?
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

From forum: GPSd - Dev

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

2009-11-23T11:29:51Z

Greg Troxel <gdt@...>:
> > I've heard rumor that the early, alpha versions of scons were flaky.
> > Perhaps you were using one of those?
>
> Maybe so - this was 2+ years ago on lprof.

Yeah, that'd make a *big* difference. I took a first look at scons
around the same time you were using (maybe a few nmonths earlier) it
and rejected it as promising but immature.

We did the Wesnoth conversion about nine months ago, at which point
scons had improved really dramatically, to the point where it was a
clear win over autotools.

I've occasionally checked on scons development since and it appears
they haven't slowed down. Notably, a module to support generating
autotools-like config files for backwards compatibility, experimental
when I used it for Wesnoth, now seems to be part of base scons.

> IMHO the build system also needs to support cross builds and builds in
> objdirs with r/o source trees. I would think scons does that by now,
> but in any case that's probably a discussion for later.

I think it does, but you're quite right. Moving to scons, if we do
it at all, is not a near-term project.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

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

signature.asc (196 bytes) Download Attachment

From forum: GPSd - Dev

Re: Patch fixing time conversion on Mac OS X

2009-11-23T10:41:37Z

On Nov 23, 2009, at 12:58 PM, Eric S. Raymond wrote:

> This patch seems wrong to me. time_t is definitionally the correct
> type
> for time in seconds from the Unix epoch. If the Mac's time_t can't
> hold
> any result of a calculation that has time in seconds from the Unix
> epoch
> as a result, then it is the the Mac's definition that is broken, not
> our code.

I don't think that's a fair statement. You can't expect time_t, who's
size is undefined by the standard, to hold *any* result of a
calculation that has time in seconds from the UNIX epoch. I think you
can only expect it to hold a reasonable calculation. Even with an
unsigned long there will come a time when a particular date will not
be supported.

> That suggests a driver bug somewhere. Which tests were these again?

However, I do like the juxtaposition of those two statements next to
each other. ;-)

The errors were produced from:

./test/stable/mkt-3301.log
./test/stable/rgm3800.log

Sorry I didn't look closer at the "good" date actually being spit out
in the test diff.

Sincerely,
Michael

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

smime.p7s (3K) Download Attachment

From forum: GPSd - Dev

Re: Patch fixing time conversion on Mac OS X

2009-11-23T10:01:04Z

Michael Ledford <michael@...>:
> Hmm, I didn't look at the actual values of the dates until you just
> mentioned it. 2080!?! :)

That suggests a driver bug somewhere. Which tests were these again?
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

From forum: GPSd - Dev

Re: Patch fixing time conversion on Mac OS X

2009-11-23T09:58:32Z

Michael Ledford <michael@...>:
> What was happening is the mkgmtime() function had an internal variable
> that used the system defined time_t type and also used that as the
> return type. On Mac OS X 10.5 and 10.6 time_t is defined as a long. Too
> short for the values being calculated. Presented here is a patch to
> change the internal variable and return type of mkgmtime() to be an
> unsigned long. I considered moving from time_t to clock_t, but I felt it
> was best to be more explicit about the length of the value. However, feel
> free to use clock_t if deemed more appropriate, it is defined as unsigned
> long on Mac OS X.

[patch omitted]

This patch seems wrong to me. time_t is definitionally the correct type
for time in seconds from the Unix epoch. If the Mac's time_t can't hold
any result of a calculation that has time in seconds from the Unix epoch
as a result, then it is the the Mac's definition that is broken, not
our code.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

From forum: GPSd - Dev

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

2009-11-23T09:47:16Z

"Eric S. Raymond" <esr@...> writes:

> Greg Troxel <gdt@...>:
>> You can count me on the list of people opposed to scons. I dealt with
>> it on another project and considered it a disaster - it needed
>> os-specific files.
>
> I set against this our experience on Battle For Wesnoth - ports
> to Mac OS X and Windows - which was a huge win qand required no
> OS-specific files at all; I know because I did the conversion
> myself in conjection with a Windowsa developer.
>
> I've heard rumor that the early, alpha versions of scons were flaky.
> Perhaps you were using one of those?

Maybe so - this was 2+ years ago on lprof.

IMHO the build system also needs to support cross builds and builds in
objdirs with r/o source trees. I would think scons does that by now,
but in any case that's probably a discussion for later.

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

attachment0 (200 bytes) Download Attachment

From forum: GPSd - Dev

Re: Doc update to VERSION object

2009-11-23T09:45:48Z

Michael R. Davis <mrdvt92@...>:
> GPSD Folks,
> api_major and api_minor are now proto_major and proto_minor.
>
> Documentation Diff attached.

Merged, thanks.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

From forum: GPSd - Dev

Re: regress test fails due to missing (undocumented??) dependency

2009-11-23T09:32:45Z

Greg Troxel <gdt@...>:

>
> ./regress-driver -t ./test/stable/*.log
> Testing the daemon...
> Traceback (most recent call last):
> File "./gpsfake", line 10, in <module>
> import gpsfake
> File "/home/gdt/SOFTWARE/GPSD/gpsd-trunk-https/gpsfake.py", line 69, in <module>
> import gps, gpspacket
> File "/home/gdt/SOFTWARE/GPSD/gpsd-trunk-https/gps.py", line 6, in <module>
> import time, calendar, math, socket, sys, select, json
> ImportError: No module named json
>
>
> This seems to be new in 2.6, but configure.ac did not complain about
> 2.5. (2.5 is still a reasonable version of python to be running, given
> the API instability python has. gpsd requiring 2.6 is ok, but it should
> fail to configure with 2.5 if so)

Good catch. Fixed in trunk.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

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

signature.asc (196 bytes) Download Attachment

From forum: GPSd - Dev

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

2009-11-23T09:29:58Z

Greg Troxel <gdt@...>:
> You can count me on the list of people opposed to scons. I dealt with
> it on another project and considered it a disaster - it needed
> os-specific files.

I set against this our experience on Battle For Wesnoth - ports
to Mac OS X and Windows - which was a huge win qand required no
OS-specific files at all; I know because I did the conversion
myself in conjection with a Windowsa developer.

I've heard rumor that the early, alpha versions of scons were flaky.
Perhaps you were using one of those?
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

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

signature.asc (196 bytes) Download Attachment

From forum: GPSd - Dev

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

From forum: GPSd - Users

Re: 2.90 `make dist-rpm` - SVN 6577

2009-11-23T04:51:58Z

Mike,
If what your asking is during install, do you need libgpsmm.h. The answer to that would be yes as it is the primary header used for C++ client side development. So after an install of gpsd, if you need to create a C++ application using gpsd, this header and libgpsmm need to be there. Typically, Red Hat creates a package and then a "devel" package and both headers would be appropriate for the devel package.
Don

On Sat, Nov 21, 2009 at 7:16 AM, Greg Troxel <gdt@...> wrote:

From: "Michael R. Davis" <mrdvt92@...>

GPSD Folks,
I had to make the following change to get the rpm to build but should we be installing libgpsmm.h.
Mike (mrdvt92)

$ svn diff
Index: packaging/gpsd.spec.in
===================================================================
--- packaging/gpsd.spec.in (revision 6577)
+++ packaging/gpsd.spec.in (working copy)
@@ -135,7 +135,6 @@
/usr/lib/python*/site-packages/gpspacket.so*
/usr/lib/python*/site-packages/gpslib.so*
%{_includedir}/gps.h
-%{_includedir}/libgpsmm.h
%{_includedir}/gpsd.h
%{_mandir}/man1/gpscat.1*
%{_mandir}/man1/gpsfake.1*

On my box (netbsd-5, amd64), I see libgpsmm.h in $prefix/include after
an install:

gdt 284 ~/SOFTWARE/GPSD/gpsd-trunk-https > l /usr/y0/include/
total 190
-rw-r--r-- 1 root wheel 38803 Nov 21 08:06 gps.h
-rw-r--r-- 1 root wheel 32633 Nov 21 08:06 gpsd.h
-rw-r--r-- 1 root wheel 1526 Nov 21 08:06 libgpsmm.h
-rw-r--r-- 1 root wheel 17806 Aug 11 07:40 unicase.h
-rw-r--r-- 1 root wheel 6621 Aug 11 07:40 uniconv.h
-rw-r--r-- 1 root wheel 31706 Aug 11 07:40 unictype.h
-rw-r--r-- 1 root wheel 3701 Aug 11 07:40 unilbrk.h
-rw-r--r-- 1 root wheel 1514 Aug 11 07:40 uniname.h
-rw-r--r-- 1 root wheel 10410 Aug 11 07:40 uninorm.h
-rw-r--r-- 1 root wheel 8489 Aug 11 07:40 unistdio.h
-rw-r--r-- 1 root wheel 20876 Aug 11 07:40 unistr.h
drwxr-xr-x 2 root wheel 512 Aug 11 07:40 unistring
-rw-r--r-- 1 root wheel 993 Aug 11 07:40 unitypes.h
-rw-r--r-- 1 root wheel 2475 Aug 11 07:40 uniwbrk.h
-rw-r--r-- 1 root wheel 1956 Aug 11 07:40 uniwidth.h

libgpsmm.h is in Makefile.am as

include_HEADERS = gps.h libgpsmm.h

but conditional on LIBGPSMM_ENABLE, which is on by default unless turned
off or c++ support fails.

I don't grok spec files - are you saying that libgpsmm.h is installed so
it has to be in the spec file, or that it is in the spec file but the
file isn't installed, or ??

To guess, it looks to me like your build happened wrong.

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

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

From forum: GPSd - Dev

Re: Need to monitor GPS fix status when callback stops

2009-11-23T04:45:26Z

This bug occurs in NMEA when the fix code goes to 0 or Invalid. Is the new call in the 2.39 or 2.40 code? This is not happening in 2.40.
Don

On Fri, Nov 20, 2009 at 3:56 PM, Eric S. Raymond <esr@...> wrote:

Eric S. Raymond <esr@...>:

> I'm planning to put these both under runtime control so you can flip a
> switch and get client progress messages to standard error. Then I
> think I'm going to write a little monitor program that does nothing
> but grab data through the C client lib and dump it line-oriented
> interleaved with with those progress messages.

This has been done. In the default build, client-side debugging
is now available through the gps_enable_debug() call. You can specify
a debug level and an fp to write to. Read the libgps.c and json.c
source for more details.

--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

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

From forum: GPSd - Dev

Doc update to VERSION object

2009-11-22T21:27:45Z

GPSD Folks,
api_major and api_minor are now proto_major and proto_minor.

Documentation Diff attached.

Thanks,
Mike

Index: gpsd.xml
===================================================================
--- gpsd.xml (revision 6585)
+++ gpsd.xml (working copy)
@@ -253,7 +253,7 @@
may be only one in the future. It is a bad idea for applications to
speak either protocol directly: rather, they should use the
<application>libgps</application> client library and take appropriate
-care to conditionalize their code on the major and minor API version
+care to conditionalize their code on the major and minor protocol version
symbols.</para>

</refsect1>
@@ -494,10 +494,10 @@

<varlistentry>
<term>l</term>
-<listitem><para>Returns four fields: the major protocol/API revision number,
-the minor revision number, the gpsd version, and a list of accepted
+<listitem><para>Returns four fields: the major protocol revision number,
+the minor protocol revision number, the gpsd version, and a list of accepted
request letters. Note: earlier versions of this command returned only
-three fields, omitting the minor revision number.</para></listitem>
+three fields, omitting the minor protocol revision number.</para></listitem>
</varlistentry>

<varlistentry>
@@ -1191,16 +1191,16 @@
<entry>Internal revision-control level.</entry>
</row>
<row>
- <entry>api_major</entry>
+ <entry>proto_major</entry>
<entry>Yes</entry>
<entry>numeric</entry>
- <entry>API major revision level..</entry>
+ <entry>Protocol major revision level..</entry>
</row>
<row>
- <entry>api_minor</entry>
+ <entry>proto_minor</entry>
<entry>Yes</entry>
<entry>numeric</entry>
- <entry>API minor revision level..</entry>
+ <entry>Protocol minor revision level..</entry>
</row>
</tbody>
</tgroup>
@@ -1215,7 +1215,7 @@
<para>Here's an example:</para>

<programlisting>
-{"class":"VERSION","version":"2.40dev","rev":$Id$,"api_major":3,"api_minor":1}
+{"class":"VERSION","version":"2.40dev","rev":$Id$,"proto_major":3,"proto_minor":1}
</programlisting>

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

From forum: GPSd - Dev

Re: Navcom testregress errors on OS X.

2009-11-22T18:14:54Z

Michael Ledford <michael@...>:
> As you know I've been working to get testregress errors resolved on
> Mac OS X. I've come across one in the Navcom driver which I'm not sure
> how to resolve. Any direction would be appreciated.

I think this is not a regression error, but rather due to a recent
change in that driver. I will investigate and resolve.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

From forum: GPSd - Dev

Navcom testregress errors on OS X.

2009-11-22T17:37:50Z

Hello,

As you know I've been working to get testregress errors resolved on
Mac OS X. I've come across one in the Navcom driver which I'm not sure
how to resolve. Any direction would be appreciated.

Sincerely,
Michael

--- ./test/stable/log-copy.chk 2009-11-22 16:47:46.000000000 -0500
+++ ./test/stable/test-whole.chk 2009-11-22 16:47:46.000000000 -0500
@@ -97,7 +97,7 @@
$GPGGA,102021,3020.5010,N,01213.7242,E,2,09,1.00,627.54,M,
31.480,M,,*42
$GPRMC,102021,A,3020.5010,N,01213.7242,E,31847.9445,0.000,150107,,*2D
$GPGSA,A,3,03,06,07,16,18,21,25,30,31,,,,2.0,1.0,1.8*31
-{"class":"TPV","tag":"0xb1","time":1168856421.000,"ept":3.920,"lat":
30.341683180,"lon":12.228735886,"alt":627.543,"epx":0.222,"epy":
0.222,"epv":10.350,"track":0.0000,"speed":16383.998,"climb":
0.002,"epd":83.0472,"eps":0.44,"mode":3}
+{"class":"TPV","tag":"0xb1","time":1168856421.000,"ept":3.920,"lat":
30.341683180,"lon":12.228735886,"alt":627.543,"epx":0.222,"epy":
0.222,"epv":10.350,"track":0.0000,"speed":16383.998,"climb":
0.002,"eps":0.44,"mode":3}
$GPGSV,3,1,10,21,78,040,46,31,39,230,44,06,36,062,43,25,36,245,43*7F
$GPGSV,3,2,10,30,26,132,38,16,40,321,42,18,31,140,39,03,10,284,34*7F
$GPGSV,3,3,10,07,43,056,43,22,13,173,35*7D
@@ -137,7 +137,7 @@
$GPGGA,102026,3020.5010,N,01213.7242,E,2,08,1.10,627.54,M,
31.479,M,,*43
$GPRMC,102026,A,3020.5010,N,01213.7242,E,0.0042,26.565,150107,,*1B
$GPGSA,A,3,06,07,16,18,21,25,30,31,31,,,,2.3,1.1,2.1*38
-{"class":"TPV","tag":"0xb1","time":1168856426.000,"ept":5.880,"lat":
30.341683256,"lon":12.228735936,"alt":627.539,"epx":0.222,"epy":
0.222,"epv":12.075,"track":26.5651,"speed":0.002,"climb":0.003,"eps":
0.44,"mode":3}
+{"class":"TPV","tag":"0xb1","time":1168856426.000,"ept":5.880,"lat":
30.341683256,"lon":12.228735936,"alt":627.539,"epx":0.222,"epy":
0.222,"epv":12.075,"track":26.5651,"speed":0.002,"climb":0.003,"mode":3}
$GPGSV,3,1,10,21,78,040,46,31,39,230,44,06,36,062,43,25,36,245,43*7F
$GPGSV,3,2,10,30,26,132,38,16,40,321,42,18,31,140,38,03,10,284,32*78
$GPGSV,3,3,10,07,43,056,43,22,13,173,34*7C

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

From forum: GPSd - Dev

watch and DEVICES object at startup in 2.90dev

2009-11-22T17:06:54Z

GPSD Folks,
If you restart the deamon and then quickly execute a ?WATCH={"enable":true}; You get the DEVICES object before the DEVICE has had a chance to get the flags or subtype properties. I also think the WATCH object should come before the the DEVICES object in the return.
Mike (mrdvt92)

$ telnet localhost 2947
Trying 127.0.0.1...
Connected to localhost.localdomain (127.0.0.1).
Escape character is '^]'.

{"class":"VERSION","release":"2.90dev","rev":"svnexported","proto_major":3,"proto_minor":1}

?WATCH={"enable":true};

{"class":"DEVICES","devices":[{"class":"DEVICE","path":"/dev/ttyUSB0","activated":1258937356.20,"driver":"SiRF binary","native":1,"bps":19200,"parity":"N","stopbits":1,"cycle":1.00}]}

{"class":"WATCH","enable":true,"nmea":false,"raw":0,"scaled":false,"timing":false}

{"class":"DEVICE","path":"/dev/ttyUSB0","activated":1258937356.32,"flags":1,"driver":"SiRF binary","subtype":"2.3.2-GSW2-2.05.024-C1Prod1.1","native":1,"bps":19200,"parity":"N","stopbits":1,"cycle":1.00}

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

From forum: GPSd - Dev