Garmin GPS almost never sends new position data

[Eivind Tagseth]

Hi.

I've got a Garmin GPSmap 60Cx that's connected to my laptop using a USB
cable.

The problem is that when running gpsd (2.32), the communication _seems_
to  be working, but the gpsd server (almost) never gets positioning data.

This is how it normally looks (gspd started with -D 8 -N /dev/ttyUSB0):

gpsd: select waits
gpsd: polling 7
gpsd: GetPacket()
gpsd: got 12 bytes
gpsd: GotPacket() sz=12
gpsd: GPS sent 1 new characters
gpsd: garmin_parse_input()
gpsd: PrintPacket()
gpsd: Transport, Packet: Type 0 0 0, ID: 2, Sz: 0
gpsd: LOS matrix is singular, can't calculate DOPs.
gpsd: select waits
gpsd: polling 7
gpsd: GetPacket()
gpsd: got 64 bytes
gpsd: got 64 bytes
gpsd: got 44 bytes
gpsd: GotPacket() sz=172
gpsd: GPS sent 1 new characters
gpsd: garmin_parse_input()
gpsd: PrintPacket()
gpsd: Appl, SAT Data Sz: 84
gpsd:   Sat 24, snr: 1650, elev: 19, Azmth: 28, Stat: 5
gpsd:   Sat 5, snr: 1550, elev: 66, Azmth: 124, Stat: 5
gpsd:   Sat 2, snr: 1860, elev: 30, Azmth: 103, Stat: 5
gpsd:   Sat 1, snr: 2010, elev: 34, Azmth: 302, Stat: 4
gpsd:   Sat 14, snr: 1679, elev: 32, Azmth: 247, Stat: 5
gpsd:   Sat 30, snr: 2150, elev: 66, Azmth: 239, Stat: 5
gpsd:   Sat 4, snr: 1920, elev: 30, Azmth: 59, Stat: 5
gpsd:   Sat 9, snr: 1450, elev: 15, Azmth: 149, Stat: 5
gpsd:   Sat 20, snr: 1670, elev: 14, Azmth: 350, Stat: 5
gpsd:   Sat 6, snr: 1879, elev: 20, Azmth: 206, Stat: 4
gpsd:   Sat 255, snr: 0, elev: 0, Azmth: 0, Stat: 0
gpsd:   Sat 255, snr: 0, elev: 0, Azmth: 0, Stat: 0
gpsd: <= GPS:
$GPGSV,3,1,10,24,19,028,97,05,66,124,97,02,30,103,97,01,34,302,96*79\x0d\x0a$GPGSV,3,2,10,14,32,247,97,30,66,239,96,04,30,059,97,09,15,149,97*7C\x0d\x0a$GPGSV,3,3,10,20,14,350,97,06,20,206,97*79
gpsd: client(8): channel 7 already active.
gpsd: => client(8): GPSD,Y=20 ? 10:24 19 28 97 1:5 66 124 97 1:2 30 103
97 1:1 34 302 96 1:14 32 247 97 1:30 66 239 96 1:4 30 59 97 1:9 15 149
97 1:20 14 350 97 1:6 20 206 97 1:

The connected client is xgps.  The message above is repeated over and
over again, with little variation (the values varies, and the number of
satellites).

Sometimes, however, I _do_ get new positioning data, but then these stay
unchanged on the client for a very long time.  In fact, I'm not sure if
I've ever seen positioning data received by the gpsd unless I was either
debugging, or freezing the output console looking at the messages.

If I freeze the output console for about 30 seconds (using Ctrl-S), and
then unfreeze, I _always_ get new positioning data.  Could there be some
kind of timing issue here?

When unfreezing, I get the following output:

gpsd: select waits
gpsd: polling 7
gpsd: GetPacket()
gpsd: got 64 bytes
gpsd: got 64 bytes
gpsd: got 64 bytes
gpsd: got 64 bytes
gpsd: GetPacket() packet too long!
gpsd: GotPacket() sz=0
gpsd: GPS sent 1 new characters
gpsd: New data, not yet a packet

[I get lots of these, at least 10, all the same]

gpsd: select waits
gpsd: polling 7
gpsd: GetPacket()
gpsd: got 28 bytes
gpsd: GotPacket() sz=28
gpsd: GPS sent 1 new characters
gpsd: garmin_parse_input()
gpsd: PrintPacket()
gpsd: bogus packet, size too large=100991223
gpsd: LOS matrix is singular, can't calculate DOPs.
gpsd: select waits
gpsd: polling 7
gpsd: GetPacket()
gpsd: got 32 bytes
gpsd: GotPacket() sz=32
gpsd: GPS sent 1 new characters
gpsd: garmin_parse_input()
gpsd: PrintPacket()
gpsd: bogus packet, size too large=-16449186

[and then, finally]

gpsd: select waits
gpsd: polling 7
gpsd: GetPacket()
gpsd: got 64 bytes
gpsd: got 12 bytes
gpsd: GotPacket() sz=76
gpsd: GPS sent 1 new characters
gpsd: garmin_parse_input()
gpsd: PrintPacket()
gpsd: Appl, PVT Data Sz: 64
gpsd: time_l: 1149716312
gpsd: Appl, mode 3, status 1
gpsd: UTC Time: 1149716312.000000
gpsd: Geoid Separation (MSL - WGS84): from garmin 40.950176, calculated
40.950223
gpsd: Alt: 34.980, Epe: 22.868, Eph: 25.088, Epv: 19.120, Fix: 3,
Gps_tow: 337125.968750, Lat: 63.432, Lon: 10.410, LonVel: -0.039,
LatVel: -0.458, AltVel: -0.500, MslHgt: -40.950, Leap: 14, GarminDays: 5999
gpsd: <= GPS:
$GPGGA,213832,6325.9081,N,01024.6187,E,3,09,,-6.0,M,40.950,M,,*40\x0d\x0a$GPRMC,213832,A,6325.9081,N,01024.6187,E,1.7380,184.910,070606,,*26
gpsd: client(8): channel 7 already active.
gpsd: GPS has a fix (status=1, mode=3).
gpsd: => client(8): GPSD,O=20 1149716312.00 0.005 63.431802 10.410312
-5.97 30.73 23.42 184.9100    0.894 -0.500  97.9067  0.87        ?

I may get several of these.  And then, when the console catches up with
all the pending output, I get back to the original problem again, with
the same satellite data output, but no new coords.

I'm running linux kernel version 2.6.17_rc2, and the garmin_gps driver,
and I've had no problems using it with other software, like gpsbabel.

Any hints or suggestions to what I may do to make gpsd work, or to help
debugging the problem would be appreciated.




Eivind


This is the output during startup:

gpsd: launching (Version 2.32)
gpsd: listening on port 2947
gpsd: running with effective group ID 0
gpsd: running with effective user ID 0
gpsd: opening GPS data source at '/dev/ttyUSB0'

[garmin_probe]

gpsd: Set garmin_gps driver mode = 0
gpsd: SendPacket(), writing 16 bytes
gpsd: PrintPacket()
gpsd: Private, Set Mode: 0
gpsd: SendPacket(), wrote 16 bytes
gpsd: Get garmin_gps driver version
gpsd: SendPacket(), writing 12 bytes
gpsd: PrintPacket()
gpsd: Private, ID: Info Req
gpsd: SendPacket(), wrote 12 bytes
gpsd: GetPacket()
gpsd: got 24 bytes
gpsd: GotPacket() sz=24
gpsd: PrintPacket()
gpsd: Private, ID: Info Resp
gpsd: Garmin USB Driver found, Version 0.23, Mode: 0, GPS Serial# 3300811160
gpsd: Send Garmin Start Session
gpsd: SendPacket(), writing 12 bytes
gpsd: PrintPacket()
gpsd: Transport, Start Session req
gpsd: SendPacket(), wrote 12 bytes
gpsd: GetPacket()
gpsd: got 16 bytes
gpsd: GotPacket() sz=16
gpsd: Got packet waiting for START_SESSION
gpsd: PrintPacket()
gpsd: Transport, Start Session resp, unit: 0xc4be6198
gpsd: Get Garmin Product Data
gpsd: SendPacket(), writing 12 bytes
gpsd: PrintPacket()
gpsd: Appl, Product Data req
gpsd: SendPacket(), wrote 12 bytes
gpsd: GetPacket()
gpsd: got 12 bytes
gpsd: GotPacket() sz=12
gpsd: PrintPacket()
gpsd: Transport, Packet: Type 0 0 0, ID: 2, Sz: 0
gpsd: GetPacket()
gpsd: got 64 bytes
gpsd: got 64 bytes
gpsd: got 64 bytes
gpsd: got 64 bytes
gpsd: GetPacket() packet too long!
gpsd: GotPacket() sz=0
gpsd: PrintPacket()
gpsd: Appl, Product Data, sz: 147
gpsd: Garmin Product ID: 292, SoftVer: 2.70
gpsd: Garmin Product Desc: GPSMap60CX Software Version 2.70
gpsd: probe found Garmin binary driver...


gpsd: to garmin_probe()
[garmin_probe again, removed here, the output is exactly like the output
from garmin_probe() above]
gpsd: from garmin_probe() = 1

gpsd: Set Garmin to send reports every 1 second
gpsd: SendPacket(), writing 14 bytes
gpsd: PrintPacket()
gpsd: Appl, Command Data: Start Xmit PVT data
gpsd: SendPacket(), wrote 14 bytes
gpsd: gpsd_activate: opened GPS (7)
gpsd: flagging descriptor 7 in open_device
gpsd: select waits
gpsd: polling 7
gpsd: GetPacket()
gpsd: got 64 bytes
gpsd: got 64 bytes
gpsd: got 12 bytes
gpsd: GotPacket() sz=140
gpsd: GPS sent 1 new characters
gpsd: garmin_parse_input()
gpsd: PrintPacket()
gpsd: bogus packet, size too large=1409288769
gpsd: select waits
gpsd: polling 7
gpsd: GetPacket()
gpsd: got 12 bytes
gpsd: GotPacket() sz=12
gpsd: GPS sent 1 new characters
gpsd: garmin_parse_input()
gpsd: PrintPacket()
gpsd: Transport, Packet: Type 0 0 0, ID: 2, Sz: 0

[after this it starts printing satelite data]

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

[Gary E. Miller]

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

Yo Eivind!

On Thu, 8 Jun 2006, Eivind Tagseth wrote:

> I've got a Garmin GPSmap 60Cx that's connected to my laptop using a USB
> cable.
> The problem is that when running gpsd (2.32), the communication _seems_
> to  be working, but the gpsd server (almost) never gets positioning data.

Very odd.  Seems like the input buffer is getting corrupted. GetPacket()
is about as close to the bottom of the stack as gpsd can get.  Since
packets are getting corrupted there something very basic is bad.  What
distro are you running?  This is not a 64bit CPU is it?  Or a really
loaded up CPU?

gpsd is just about the only app that uses Garmin binary, so I am not
surprised that other apps work differently since they likely use NMEA.

I have a Garmin GPS18/USB running the SVN trunk right now just fine.

RGDS
GARY
- ---------------------------------------------------------------------------
Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701
        gem@...  Tel:[phone]

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

iD8DBQFEh8j58KZibdeR3qURAmRXAKDq9+vheybql7zJjKFYx0M4OgpvSACcDcm1
9mIMyjHfNWR04i5rIhB/VWo=
=O7xt
-----END PGP SIGNATURE-----

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

[Eivind Tagseth]

Gary E. Miller wrote:

> Yo Eivind!
>
> On Thu, 8 Jun 2006, Eivind Tagseth wrote:
>
>>> I've got a Garmin GPSmap 60Cx that's connected to my laptop using a USB
>>> cable.
>>> The problem is that when running gpsd (2.32), the communication _seems_
>>> to  be working, but the gpsd server (almost) never gets positioning data.
>
> Very odd.  Seems like the input buffer is getting corrupted. GetPacket()
> is about as close to the bottom of the stack as gpsd can get.  Since
> packets are getting corrupted there something very basic is bad.  What
> distro are you running?  This is not a 64bit CPU is it?  Or a really
> loaded up CPU?

I'm running Gentoo linux.  It's not a 64bit CPU, but it _is_ a dual core
 Intel Centrino Doa (Yonah), maybe that's what's causing problems?  The
system was not under any load at all.




Eivind

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

[Gary E. Miller]

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

Yo Eivind!

On Thu, 8 Jun 2006, Eivind Tagseth wrote:

> I'm running Gentoo linux.  It's not a 64bit CPU, but it _is_ a dual core
>  Intel Centrino Doa (Yonah), maybe that's what's causing problems?  The
> system was not under any load at all.

I run on a P4/HT.  Linux thinks that is dual core, and I run in SMP mode,
so I doubt that is the problem.

Have you tried the current SVN?  Which gcc are you on?

RGDS
GARY
- ---------------------------------------------------------------------------
Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701
        gem@...  Tel:[phone]

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

iD8DBQFEh9QM8KZibdeR3qURAkchAKDl9rN+Ji0E4kC4lO6Zn8/Xnl0REgCffRnP
+UHR93up2+DiyiPafGLa8DA=
=cfaP
-----END PGP SIGNATURE-----

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

[Eivind Tagseth]

Gary E. Miller wrote:
> Yo Eivind!

> Have you tried the current SVN?  Which gcc are you on?

I haven't tried the current SVN.  Will do tonight.
My gcc identifies itself as

        gcc (GCC) 3.4.6 (Gentoo 3.4.6-r1, ssp-3.4.5-1.0, pie-8.7.9)


Eivind

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

[Gary E. Miller]

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

Yo Eivind!

On Thu, 8 Jun 2006, Eivind Tagseth wrote:

> > Have you tried the current SVN?  Which gcc are you on?
>
> I haven't tried the current SVN.  Will do tonight.
> My gcc identifies itself as
>
> gcc (GCC) 3.4.6 (Gentoo 3.4.6-r1, ssp-3.4.5-1.0, pie-8.7.9)

Odd, I just tested this on gcc 3.4.5 and it works fine.

Just to rule things out, can you switch to a non-SMP kernel and test
things out?

RGDS
GARY
- ---------------------------------------------------------------------------
Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701
        gem@...  Tel:[phone]

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

iD8DBQFEiHg38KZibdeR3qURAnC0AKCM4AD9t+86CKxfZs9AX65Zh32wBQCeM8M0
pB3cqz5f9iLZ29GoolchveA=
=FFYX
-----END PGP SIGNATURE-----

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

[Eivind Tagseth]

Gary E. Miller wrote:

> Have you tried the current SVN?  Which gcc are you on?

I've just tried with the latest SVN version.  No change there.

I don't have any non-SMP kernels lying around, so I cannot test
that right now.  I'll try to do that as soon as possible though.



Eivind

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

[Eivind Tagseth]

Gary E. Miller wrote:

> Just to rule things out, can you switch to a non-SMP kernel and test
> things out?

Haven't tried this just yet, but I tried adding some code to log all
data received from the gps tty, and the necessary data _is_ present, but
gpsd throws it away!

This seems to be because the POV data packet is simply appended to the
SAT data packet.  GetPacket expects that when reading, after read()
returns less than 64 bytes, only _one_ packet has bean read.

I'm not sure if gpsd is at fault here, or if the kernel garmin_gps
driver is.



Eivind

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

[Gary E. Miller]

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

Yo Eivind!

On Wed, 28 Jun 2006, Eivind Tagseth wrote:

> This seems to be because the POV data packet is simply appended to the
> SAT data packet.  GetPacket expects that when reading, after read()
> returns less than 64 bytes, only _one_ packet has bean read.

Uh, oh.  The linux driver passes framing data to the client (gpsd)
by putting them in separate packets.  If that is not the case then
the entire packet reading engine has to get thrown out.  In the mode
gpsd used there is no other way to sync to packets.  Ugh.

There is another mode that used DLEs to separate the packet.  If the
packet separation is broken I will have to do that instead.  Not a
pleasant thought.

> I'm not sure if gpsd is at fault here, or if the kernel garmin_gps
> driver is.

I am running 2.6.16.14 just fine.  So looks to me like a kernel driver
problem on the 64 bit CPU.  Sned me your traces and I'll check it out.


RGDS
GARY
- ---------------------------------------------------------------------------
Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701
        gem@...  Tel:[phone]

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

iD8DBQFEouKy8KZibdeR3qURAtErAKCDI86xe8+hWkgWs6Ie+WwklyBW+QCdE3Sj
IgpHS2/Cx3Rf03L6o9A722w=
=RFMJ
-----END PGP SIGNATURE-----

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

[MikeyCarter]

Did you ever get your GPS working with gpsd?

I've got the same problem.

I'm running Fedora Core 5 : 2.6.17-1.2187_FC5
GPS: Garmin GPSMap 60Cx

[root@blue-faerie log]# gpsd -D 99 -n -N /dev/ttyUSB0
gpsd: launching (Version 2.33)
gpsd: listening on port gpsd
gpsd: successfully connected to the DBUS system bus
gpsd: running with effective group ID 0
gpsd: running with effective user ID 0
gpsd: opening GPS data source at '/dev/ttyUSB0'
gpsd: Set garmin_gps driver mode = 0
gpsd: SendPacket(), writing 16 bytes
gpsd: PrintPacket()
gpsd: Private, Set Mode: 0
gpsd: SendPacket(), wrote 16 bytes
gpsd: Get garmin_gps driver version
gpsd: SendPacket(), writing 12 bytes
gpsd: PrintPacket()
gpsd: Private, ID: Info Req
gpsd: SendPacket(), wrote 12 bytes
gpsd: GetPacket()
gpsd: got 24 bytes
gpsd: GotPacket() sz=24
gpsd: PrintPacket()
gpsd: Private, ID: Info Resp
gpsd: Garmin USB Driver found, Version 0.23, Mode: 0, GPS Serial# 3300021732
gpsd: Send Garmin Start Session
gpsd: SendPacket(), writing 12 bytes
gpsd: PrintPacket()
gpsd: Transport, Start Session req
gpsd: SendPacket(), wrote 12 bytes
gpsd: GetPacket()
gpsd: got 16 bytes
gpsd: GotPacket() sz=16
gpsd: Got packet waiting for START_SESSION
gpsd: PrintPacket()
gpsd: Transport, Start Session resp, unit: 0xc4b255e4
gpsd: Get Garmin Product Data
gpsd: SendPacket(), writing 12 bytes
gpsd: PrintPacket()
gpsd: Appl, Product Data req
gpsd: SendPacket(), wrote 12 bytes
gpsd: GetPacket()
gpsd: got 12 bytes
gpsd: GotPacket() sz=12
gpsd: PrintPacket()
gpsd: Transport, Packet: Type 0 0 0, ID: 2, Sz: 0
gpsd: GetPacket()
gpsd: got 64 bytes
gpsd: got 64 bytes
gpsd: got 64 bytes
gpsd: got 64 bytes
gpsd: GetPacket() packet too long!
gpsd: GotPacket() sz=0
gpsd: PrintPacket()
gpsd: Appl, Product Data, sz: 135
gpsd: Garmin Product ID: 292, SoftVer: 3.00
gpsd: Garmin Product Desc: GPSMap60CX Software Version 3.00
gpsd: probe found Garmin binary driver...
gpsd: to garmin_probe()
gpsd: Set garmin_gps driver mode = 0
gpsd: SendPacket(), writing 16 bytes
gpsd: PrintPacket()
gpsd: Private, Set Mode: 0
gpsd: SendPacket(), wrote 16 bytes
gpsd: Get garmin_gps driver version
gpsd: SendPacket(), writing 12 bytes
gpsd: PrintPacket()
gpsd: Private, ID: Info Req
gpsd: SendPacket(), wrote 12 bytes
gpsd: GetPacket()
gpsd: got 24 bytes
gpsd: GotPacket() sz=24
gpsd: PrintPacket()
gpsd: Private, ID: Info Resp
gpsd: Garmin USB Driver found, Version 0.23, Mode: 0, GPS Serial# 3300021732
gpsd: Send Garmin Start Session
gpsd: SendPacket(), writing 12 bytes
gpsd: PrintPacket()
gpsd: Transport, Start Session req
gpsd: SendPacket(), wrote 12 bytes
gpsd: GetPacket()
gpsd: got 16 bytes
gpsd: GotPacket() sz=16
gpsd: Got packet waiting for START_SESSION
gpsd: PrintPacket()
gpsd: Transport, Start Session resp, unit: 0xc4b255e4
gpsd: Get Garmin Product Data
gpsd: SendPacket(), writing 12 bytes
gpsd: PrintPacket()
gpsd: Appl, Product Data req
gpsd: SendPacket(), wrote 12 bytes
gpsd: GetPacket()
gpsd: got 12 bytes
gpsd: GotPacket() sz=12
gpsd: PrintPacket()
gpsd: Transport, Packet: Type 0 0 0, ID: 2, Sz: 0
gpsd: GetPacket()
gpsd: got 64 bytes
gpsd: got 64 bytes
gpsd: got 64 bytes
gpsd: got 64 bytes
gpsd: GetPacket() packet too long!
gpsd: GotPacket() sz=0
gpsd: PrintPacket()
gpsd: Appl, Product Data, sz: 135
gpsd: Garmin Product ID: 292, SoftVer: 3.00
gpsd: Garmin Product Desc: GPSMap60CX Software Version 3.00
gpsd: from garmin_probe() = 1
gpsd: Set Garmin to send reports every 1 second
gpsd: SendPacket(), writing 14 bytes
gpsd: PrintPacket()
gpsd: Appl, Command Data: Start Xmit PVT data
gpsd: SendPacket(), wrote 14 bytes
gpsd: gpsd_activate: opened GPS (5)
gpsd: flagging descriptor 5 in open_device
gpsd: select waits
gpsd: polling 5
gpsd: GetPacket()
gpsd: got 64 bytes
gpsd: got 59 bytes
gpsd: GotPacket() sz=123
gpsd: GPS sent 1 new characters
gpsd: garmin_parse_input()
gpsd: PrintPacket()
gpsd: bogus packet, size too large=7226368
gpsd: select waits
gpsd: polling 5
gpsd: GetPacket()
gpsd: got 64 bytes
gpsd: got 64 bytes
gpsd: got 64 bytes
gpsd: got 64 bytes
gpsd: GetPacket() packet too long!
gpsd: GotPacket() sz=0
gpsd: GPS sent 1 new characters
gpsd: New data, not yet a packet
gpsd: select waits
gpsd: polling 5
gpsd: GetPacket()
gpsd: got 64 bytes
gpsd: got 8 bytes
gpsd: GotPacket() sz=72
gpsd: GPS sent 1 new characters
gpsd: garmin_parse_input()
gpsd: PrintPacket()
gpsd: bogus packet, size too large=1137544069
gpsd: select waits
gpsd: polling 5
gpsd: GetPacket()
gpsd: got 64 bytes
gpsd: got 64 bytes
gpsd: got 64 bytes
gpsd: got 64 bytes
gpsd: GetPacket() packet too long!
gpsd: GotPacket() sz=0
gpsd: GPS sent 1 new characters
gpsd: New data, not yet a packet
gpsd: select waits
gpsd: polling 5
gpsd: GetPacket()
gpsd: got 64 bytes
gpsd: got 8 bytes
gpsd: GotPacket() sz=72
gpsd: GPS sent 1 new characters
gpsd: garmin_parse_input()
gpsd: PrintPacket()
gpsd: bogus packet, size too large=1137544069
gpsd: select waits
gpsd: polling 5
gpsd: GetPacket()
gpsd: got 64 bytes
gpsd: got 64 bytes
gpsd: got 64 bytes
gpsd: got 64 bytes
gpsd: GetPacket() packet too long!
gpsd: GotPacket() sz=0
gpsd: GPS sent 1 new characters
gpsd: New data, not yet a packet
gpsd: select waits
gpsd: polling 5
gpsd: GetPacket()
gpsd: got 64 bytes
gpsd: got 8 bytes
gpsd: GotPacket() sz=72
gpsd: GPS sent 1 new characters
gpsd: garmin_parse_input()
gpsd: PrintPacket()
gpsd: bogus packet, size too large=1137544069
gpsd: select waits
gpsd: polling 5
gpsd: GetPacket()
gpsd: got 64 bytes
gpsd: got 64 bytes
gpsd: got 64 bytes
gpsd: got 64 bytes
gpsd: GetPacket() packet too long!
gpsd: GotPacket() sz=0
gpsd: GPS sent 1 new characters
gpsd: New data, not yet a packet
gpsd: select waits
gpsd: polling 5
gpsd: GetPacket()
gpsd: got 64 bytes
gpsd: got 8 bytes
gpsd: GotPacket() sz=72
gpsd: GPS sent 1 new characters
gpsd: garmin_parse_input()
gpsd: PrintPacket()
gpsd: bogus packet, size too large=1137544069
gpsd: select waits
gpsd: polling 5
gpsd: GetPacket()
gpsd: got 64 bytes
gpsd: got 64 bytes
gpsd: got 64 bytes
gpsd: got 64 bytes
gpsd: GetPacket() packet too long!
gpsd: GotPacket() sz=0
gpsd: GPS sent 1 new characters
gpsd: New data, not yet a packet
gpsd: select waits
gpsd: polling 5
gpsd: GetPacket()
gpsd: got 64 bytes
gpsd: got 8 bytes
gpsd: GotPacket() sz=72
gpsd: GPS sent 1 new characters
gpsd: garmin_parse_input()
gpsd: PrintPacket()
gpsd: bogus packet, size too large=1137544069
gpsd: select waits
gpsd: polling 5
gpsd: GetPacket()
gpsd: got 64 bytes
gpsd: got 64 bytes
gpsd: got 64 bytes
gpsd: got 64 bytes
gpsd: GetPacket() packet too long!
gpsd: GotPacket() sz=0
gpsd: GPS sent 1 new characters
gpsd: New data, not yet a packet
gpsd: select waits
gpsd: polling 5
gpsd: GetPacket()
gpsd: got 64 bytes
gpsd: got 8 bytes
gpsd: GotPacket() sz=72
gpsd: GPS sent 1 new characters
gpsd: garmin_parse_input()
gpsd: PrintPacket()
gpsd: bogus packet, size too large=1137544069
gpsd: select waits
gpsd: polling 5
gpsd: GetPacket()
gpsd: got 64 bytes
gpsd: got 64 bytes
gpsd: got 64 bytes
gpsd: got 64 bytes
gpsd: GetPacket() packet too long!
gpsd: GotPacket() sz=0
gpsd: GPS sent 1 new characters
gpsd: New data, not yet a packet
gpsd: select waits
gpsd: polling 5
gpsd: GetPacket()
gpsd: got 64 bytes
gpsd: got 8 bytes
gpsd: GotPacket() sz=72
gpsd: GPS sent 1 new characters
gpsd: garmin_parse_input()
gpsd: PrintPacket()
gpsd: bogus packet, size too large=1137544069
gpsd: select waits
gpsd: polling 5
gpsd: GetPacket()
gpsd: got 64 bytes
gpsd: got 64 bytes
gpsd: got 64 bytes
gpsd: got 64 bytes
gpsd: GetPacket() packet too long!
gpsd: GotPacket() sz=0
gpsd: GPS sent 1 new characters
gpsd: New data, not yet a packet
gpsd: select waits
gpsd: polling 5
gpsd: GetPacket()
gpsd: got 60 bytes
gpsd: GotPacket() sz=60
gpsd: GPS sent 1 new characters
gpsd: garmin_parse_input()
gpsd: PrintPacket()
gpsd: bogus packet, size too large=1110704128
.....

[Chris Kuethe]

On 9/22/06, MikeyCarter <mikey@...> wrote:

>
> Did you ever get your GPS working with gpsd?
>
> I've got the same problem.
>
> I'm running Fedora Core 5 : 2.6.17-1.2187_FC5
> GPS: Garmin GPSMap 60Cx
>
> [root@blue-faerie log]# gpsd -D 99 -n -N /dev/ttyUSB0
> gpsd: GetPacket() packet too long!
> gpsd: GetPacket() packet too long!
> gpsd: bogus packet, size too large=7226368
> gpsd: GetPacket() packet too long!
> gpsd: bogus packet, size too large=1137544069
> gpsd: GetPacket() packet too long!
> gpsd: bogus packet, size too large=1137544069
> gpsd: GetPacket() packet too long!
> gpsd: bogus packet, size too large=1137544069
> gpsd: GetPacket() packet too long!

etc.

0x6e4400 and 0x43cd8b85, eh? that implies that gpsd is reading the
wrong bytes. That is code where I fear to tread though - not having
test hardware.

CK

--
GDB has a 'break' feature; why doesn't it have 'fix' too?
_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

[Gary E. Miller]

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

Yo Mikey!

On Fri, 22 Sep 2006, MikeyCarter wrote:

I am the maintainer of the Garmin binary driver.

> I'm running Fedora Core 5 : 2.6.17-1.2187_FC5
> GPS: Garmin GPSMap 60Cx

I have the GPS-18/USB but am having trouble finding info on the your
product.

> gpsd: Garmin Product ID: 292, SoftVer: 3.00
> gpsd: Garmin Product Desc: GPSMap60CX Software Version 3.00

I just made sure I had the latest Garmin SDK, but I can not find produt
ID 292 in that doc.  Since the text part of that packet decoded fine I
have to assume that 292 is a valid product ID.

You can get the Garmin DOC here:
        http://www.garmin.com/support/commProtocol.html

> gpsd: bogus packet, size too large=7226368

The usually means the compiler is setting up the data structures incorrectly.
We saw this before we debugged the 64-bit gcc support, but that is fixed
now.

Have you tried the latest SVN code?  What gcc are you using?  What is
ypur CPU?

RGDS
GARY
- ---------------------------------------------------------------------------
Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701
        gem@...  Tel:[phone]

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

iD8DBQFFFFWo8KZibdeR3qURAnntAKDQZaZWlc7JKQr6aa9xeN69vh0QxQCeLyTp
LJgG4ZAiVGnxtM5ZXnlYsqw=
=GHWs
-----END PGP SIGNATURE-----

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

[Eivind Tagseth]

MikeyCarter wrote:
> Did you ever get your GPS working with gpsd?
>
> I've got the same problem.
>
> I'm running Fedora Core 5 : 2.6.17-1.2187_FC5
> GPS: Garmin GPSMap 60Cx
>

Nope, it's still the same for me.  I haven't tried any more though.

I tried just now, and it's still the same.  I've upgraded both kernel,
GPS SW and gpsd since, but it doesn't seem to be having any effect.

I still haven't tried Gavin's suggestion to boot in single cpu mode
though (sorry).



Eivind

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

[Eivind Tagseth]

I've now tried some more.  I now really thinks this must be an error
caused by the way gpsd uses the tty layer, garmin_gps uses the tty
layer, or how the tty layer works on a dual cpu computer.

I've added some debugging statements in my kernel's n_tty.c (the line
discipline being used by the tty layer when using the garmin_gps serial
usb driver).

As far as I can see (and please correct me if I'm wrong), the garmin_gps
driver calls tty_flip_buffer_push (from send_to_tty) for each message it
receives from the gps.

This causes the tty layer to call the tty discipline's receive_buf
(either directly from tty_flip_buffer_push, or from a wait queue the
next scheduling loop).

n_tty_receive_buf will copy the head tty buffer "packet" contents into
tty->read_buf and wake up anyone waiting to read from that tty (this can
be anyone trying to read() from the tty device or anyone doing poll() on
the device).

The process/thread read()ing from the tty device file will cause
read_chan in n_tty.c to be called, which uses copy_from_read_buf to copy
the contents of tty->read_buf to user space.

I've added a simple printk in n_tty_receive_buf and one in
copy_from_read_buf.

With these log messages I can see the usb driver writing e.g. 22 bytes
to the tty layer, followed by a call to copy_from_read_buf returning
these bytes to the gpsd process.  These are ok, as far as I can see.

But for messages larger than the 64 byte buffer, things behave like this:

        n_tty_receive_buf(64 bytes)
        copy_from_read_buf(64 bytes)
        n_tty_receive_buf(32 bytes)
        n_tty_receive_buf(64 bytes)
        n_tty_receive_buf(22 bytes)
        copy_from_read_buf (repeated several times)

[unfortunately I lost the log files, so the byte counts above may be
incorrect]

I'm in deep water here, but I cannot see anything stopping the
garmin_gps driver from calling tty_flip_buffer_push for multiple
packets, and thus calling n_tty_receive_buf, _before_ copy_from_read_buf
has returned all of the previous packet (or any of it) back to user space.

Could this possibly be broken since I'm on a dual core cpu?

Unfortunately, I was unable to boot my kernel with nosmp set, and
booting with maxcpus=1 only made matters worse, where gpsd couldn't even
probe the GPS properly, since also the small packets got garbled.

Anyone have any insight in this?  I'm obviously in very deep water here...



Eivind

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

[Gary E. Miller]

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

Yo Eivind!

On Sat, 23 Sep 2006, Eivind Tagseth wrote:

> > I'm running Fedora Core 5 : 2.6.17-1.2187_FC5
> > GPS: Garmin GPSMap 60Cx

> Nope, it's still the same for me.  I haven't tried any more though.

Have you tried a stock kernel?  Those non-linux Fedora kernels often
do very strange things.

> I still haven't tried Gavin's suggestion to boot in single cpu mode
> though (sorry).

We have tried that in the past and it never fixed anything.

Maybe I missed it, but what is your gcc version and CPU type?

RGDS
GARY
- ---------------------------------------------------------------------------
Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701
        gem@...  Tel:[phone]

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

iD8DBQFFFfip8KZibdeR3qURAvGkAJ0b3l+VrVu76udQCcbiATDszFvB2QCdHil/
THH5loUtMgg279G7RmuaA14=
=doie
-----END PGP SIGNATURE-----

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

[Gary E. Miller]

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

Yo Eivind!

On Sat, 23 Sep 2006, Eivind Tagseth wrote:

> But for messages larger than the 64 byte buffer, things behave like this:

First pass this looks to me like the documented garmin driver behavior.

> n_tty_receive_buf(64 bytes)
> copy_from_read_buf(64 bytes)
> n_tty_receive_buf(32 bytes)
> n_tty_receive_buf(64 bytes)
> n_tty_receive_buf(22 bytes)
> copy_from_read_buf (repeated several times)

USB packets are max 64 bytes.  So each one of those is a USB packet as
recieved from the Garmin.  The Garmin packets are composed of several
USB packets.  For each Garmin packet the gps send 64 byte packets
until the whole packet is sent with the last packet containing the
last bits.  If the Garmin packet is an even 64 bytes then it will
send a zero byte packet to denote the end of the Garmin packet.

> I'm in deep water here, but I cannot see anything stopping the
> garmin_gps driver from calling tty_flip_buffer_push for multiple
> packets, and thus calling n_tty_receive_buf, _before_ copy_from_read_buf
> has returned all of the previous packet (or any of it) back to user space.

The gpsd garmin driver reads the garmin kernel driver the way that the
garmin driver tells us to.  I would not put it past Redhat to have
messed up the driver in their non-Linux copy.  I have been bit by RedHat
way too many times to trust them.

> Could this possibly be broken since I'm on a dual core cpu?

You can always boot to single user and try.  It is just a lilo option.
Other folks have run fine on dual CPU and Garmin but I know of no recent
success reports.

> Unfortunately, I was unable to boot my kernel with nosmp set, and
> booting with maxcpus=1 only made matters worse, where gpsd couldn't even
> probe the GPS properly, since also the small packets got garbled.

This sounds more and more like a Fedora bug in their custom kernel.  I
would really like to have you try a vanilla kernel.


RGDS
GARY
- ---------------------------------------------------------------------------
Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701
        gem@...  Tel:[phone]

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

iD8DBQFFFfuE8KZibdeR3qURAkCCAJ9KdGHaRSM7hr61HKeY4y3mpFbVewCggYuf
H5zl9ulCpdh5/lTZD/xvX1I=
=30r8
-----END PGP SIGNATURE-----

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

[Eivind Tagseth]

Gary E. Miller wrote:

> This sounds more and more like a Fedora bug in their custom kernel.  I
> would really like to have you try a vanilla kernel.

I think you're confusing me with Chris here.  I'm running Gentoo on a
vanilla kernel.




Eivind

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

[Eivind Tagseth]

Gary E. Miller wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Yo Eivind!
>
> On Sat, 23 Sep 2006, Eivind Tagseth wrote:
>
>> But for messages larger than the 64 byte buffer, things behave like this:
>
> First pass this looks to me like the documented garmin driver behavior.
>
>> n_tty_receive_buf(64 bytes)
>> copy_from_read_buf(64 bytes)
>> n_tty_receive_buf(32 bytes)
>> n_tty_receive_buf(64 bytes)
>> n_tty_receive_buf(22 bytes)
>> copy_from_read_buf (repeated several times)
>
> USB packets are max 64 bytes.  So each one of those is a USB packet as
> recieved from the Garmin.  The Garmin packets are composed of several
> USB packets.  For each Garmin packet the gps send 64 byte packets
> until the whole packet is sent with the last packet containing the
> last bits.  If the Garmin packet is an even 64 bytes then it will
> send a zero byte packet to denote the end of the Garmin packet.

Yes, and as you can see above, the gps has sendt 2 packets, one of 96
bytes (64 + 32) and one of 86 bytes (64 + 22).  The problem is (as far
as I can see) that n_tty_receive_buf will just stuff all these packets
into the same tty->read_buf, and since there is no copy_from_read_buf
between n_tty_receive_buf(32 bytes) and n_tty_receive_buf(64 bytes),
this will result in one read of 64 bytes and on read of 32 bytes from
the client (gpsd)!

This is wrong, since the last 32 bytes of the first read will simply be
discarded, and the next 32 bytes will be corrupt, as they are the second
half of that packet.

In order for this to work correctly, copy_from_read_buf should have been
called directly after n_tty_receive_buf being called.  Why this doesn't
happen is beyond me at the moment...



Eivind

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

[Eivind Tagseth]

Ok, I've finally made this work.  I'm not sure if you'll like my
solution, but here it is anyway!

As I couldn't find anything in the tty layer that could guarantee that
any two packets passed from the usb layer to the tty layer wouldn't just
be concatenated into one (unless the client is fast enough reading), I
went for a different approach.

I decided that the nanosleep in GetPacket() was cause of my problems.
But while removing it improved my problems, it didn't remove them, and
it was obviously there for a reason, so I got some problems that weren't
already there before.

So, here's a patch that will change GetPacket() as follows:

        o replace the nanosleep function with a call to select,
          waiting up to 1 second   [ This change was enough to make
          gpsd usable with my gps, but I still got a few errors about
          packets too long ]
        o before returning, look at the received data, and if we've read
          more than we need, copy these to a separate buffer
        o at the start of GetPacket, initialize the buffer with the left
          over bytes from the last run, and only read more bytes if
          necessary

I've done some testing, and so far not gotten a single error message
about too long packets.  Maybe Chris could try this patch and see if it
helps on his system?




Eivind

Index: garmin.c
===================================================================
--- garmin.c (revisjon 3511)
+++ garmin.c (arbeidskopi)
@@ -180,6 +180,8 @@
     } mData;
 } Packet_t;
 
+#define BASE_PACKET_SIZE 12
+
 // useful funcs to read/write ints, only tested on Intel byte order
 //  floats and doubles are Intel order only...
 static inline void set_int32(uint8_t *buf, uint32_t value)
@@ -213,6 +215,33 @@
 static void SendPacket (struct gps_device_t *session, Packet_t *aPacket );
 static int GetPacket (struct gps_device_t *session );
 
+static bool NeedMoreData(const char* buf, int buf_len)
+{
+ Packet_t *pkt = (Packet_t*) buf;
+ if (buf_len < BASE_PACKET_SIZE)
+ return true;
+
+ if (buf_len < (pkt->mDataSize + BASE_PACKET_SIZE))
+ return true;
+
+ return false;
+}
+
+static uint8_t LeftOvers[256];
+static ssize_t LeftOverSize = 0;
+
+static void SaveLeftOvers(uint8_t* buf, ssize_t len)
+{
+ Packet_t *pkt = (Packet_t*) buf;
+ if (len < BASE_PACKET_SIZE) return;
+
+ if (len > (pkt->mDataSize + BASE_PACKET_SIZE)) {
+ memcpy(LeftOvers, buf + BASE_PACKET_SIZE + pkt->mDataSize,
+ len - (BASE_PACKET_SIZE + pkt->mDataSize));
+ LeftOverSize = len - (BASE_PACKET_SIZE + pkt->mDataSize);
+ }
+}
+
 /*@ -branchstate @*/
 // For debugging, decodes and prints some known packets.
 static gps_mask_t PrintPacket(struct gps_device_t *session, Packet_t *pkt)
@@ -553,7 +582,9 @@
 static int GetPacket (struct gps_device_t *session )
 {
     struct timespec delay, rem;
+    struct timeval timeout;
     int cnt = 0;
+    fd_set rdset;
     // int x = 0; // for debug dump
 
     memset( session->driver.garmin.Buffer, 0, sizeof(Packet_t));
@@ -561,8 +592,15 @@
     session->driver.garmin.BufferLen = 0;
     session->outbuflen = 0;
 
+    if (LeftOverSize > 0) {
+    memcpy(session->driver.garmin.Buffer, LeftOvers, LeftOverSize);
+    session->driver.garmin.BufferLen = LeftOverSize;
+    LeftOverSize = 0;
+    }
+
     gpsd_report(4, "GetPacket()\n");
 
+    if (NeedMoreData(session->driver.garmin.Buffer, session->driver.garmin.BufferLen)) {
     for( cnt = 0 ; cnt < 10 ; cnt++ ) {
  // Read async data until the driver returns less than the
  // max async data size, which signifies the end of a packet
@@ -587,11 +625,11 @@
  gpsd_report(5, "got %d bytes\n", theBytesReturned);
 
  session->driver.garmin.BufferLen += theBytesReturned;
- if ( 64 > theBytesReturned ) {
+ if ( ASYNC_DATA_SIZE > theBytesReturned ) {
     // zero length, or short, read is a flag for got the whole packet
             break;
  }
-
+
  if ( 256 <=  session->driver.garmin.BufferLen ) {
     // really bad read error...
     session->driver.garmin.BufferLen = 0;
@@ -600,12 +638,15 @@
  }
 
  /*@ ignore @*/
- delay.tv_sec = 0;
- delay.tv_nsec = 3330000L;
- while (nanosleep(&delay, &rem) < 0)
-    continue;
- /*@ end @*/
+ timeout.tv_sec = 1;
+ timeout.tv_usec = 0L;
+ FD_SET(session->gpsdata.gps_fd, &rdset);
+ if (select(session->gpsdata.gps_fd+1, &rdset, NULL, NULL, &timeout) < 0) {
+ gpsd_report(3, "select() failed, error=%d (%s)\n", errno, strerror(errno));
+ break;
+ }
     }
+    }
     // dump the individual bytes, debug only
     // for ( x = 0; x < session->driver.garmin.BufferLen; x++ ) {
         // gpsd_report(6, "p[%d] = %x\n", x, session->driver.garmin.Buffer[x]);
@@ -615,6 +656,10 @@
     return -1;
     }
 
+    if (session->driver.garmin.BufferLen > 0) {
+    SaveLeftOvers(session->driver.garmin.Buffer, session->driver.garmin.BufferLen);
+    }
+
     gpsd_report(5, "GotPacket() sz=%d \n", session->driver.garmin.BufferLen);
     session->outbuflen = session->driver.garmin.BufferLen;
     return 0;

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

[Dave Hylands]

Hi Elvind,

Replying to all this time.

> As I couldn't find anything in the tty layer that could guarantee that
> any two packets passed from the usb layer to the tty layer wouldn't just
> be concatenated into one (unless the client is fast enough reading), I
> went for a different approach.


So, I figured I'd ask for some clarification. When the packets are
being being passed from the usb layer to the tty layer, is it the
driver that's messing up and dropping data?

Or is it the case that gpsd is getting more data than its expecting?
If its the latter, then this is clearly a bug in gpsd, and could even
happen on normal serial lines without USB if the gpsd process was
being held back in an otherwise busy system.

If 2 packets of 96 bytes are being sent and gpsd is doing 64 byte
reads and getting those 2 packets as 3 reads of 64, 64, 64, then the
problem is in gpsd.

--
Dave Hylands
Vancouver, BC, Canada
http://www.DaveHylands.com/
_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users