odd delay problem, with sirf receiver

[Paul Fox-3]

hi --

i'm having a very strange delay issue with my sirf receiver.

i use a sirf-based USB mouse attached to a (linux) laptop running
a mapping program.  some days (like today) everything works
perfectly.  other days (like yesterday) GPS reports are delayed
by a full 14 or 15 seconds from when they really happen.

to describe the behavior in more detail:  if i'm traveling, the
trail followed by the mapping program's cursor follows my actual
trail exactly (meaning that the position reports are all correct)
but each is delayed by 15 seconds -- i can come to a stop at
an intersection, and watch the cursor "catch up".  or, if i'm on
a bus, and we come to a stop, the speed reported from the device
comes to a stop 15 seconds later -- it inicates 0m/s for the duration
of the stop, then starts climbing 14 seconds after the bus has
started moving.  this is observed using my mapping client, or
using gpsmon.  if using gpsmon, i can observe this behavior
whether using gpsd as the data source, or when connecting
directly to /dev/ttyUSB0.  gps data seems to arrive at the usual
rate -- an update or two per second.

while i can't fully interpret what i'm seeing, it sure feels like
either my sirf chip, or the USB stack (!?) is in some sort of
wayback mode.  has anyone else ever seen anything like this?

when the problem is occuring (and i've had it happen enough that
i've watched it quite a bit, both with my map program, and
gpsmon), it's so reliably "wrong" that it feels deliberate --
i.e., it feels like a debug flag in the sirf firmware has been
set (the "delay all reports by 14 seconds" debug flag?).  are
there any sirf dumping utilities that i could use to get a more
complete picture of the receiver's state?)  i haven't figured out
any way of forcing the receiver in or out of this odd mode --
unplugging/replugging/reopening the device usually has no affect.

versions:  i've been using svn r5863 of gpsd.  if someone can tell me
how to get the sirf firmware version number, i'll provide it.

thanks!

paul
=---------------------
 paul fox, pgf@... (arlington, ma, where it's 68.4 degrees)
_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

[Jens Oberender-3]

Hi Paul

We have the same problem with u-Blox devices, though the delay is only 5
seconds.
See https://lists.berlios.de/pipermail/gpsd-users/2009-January/003566.html
We are using version 2.32 now (as far as I remember) which works correct.
Could you give that version and the next a try, so we can be sure the
bug came in with that changes. My workmates thought it's a problem with
u-Blox only.
What OS are you using?

Bye,
    Jens
--
20 years - Keynote SIGOS GmbH -
1989 - 2009

Visit us at:
3rd Annual Telecoms
Fraud Risk and Revenue Management
16th - 18th September 2009
at the Radisson Blu Hotel Berlin, Germany

Keynote SIGOS GmbH
 - TESTING IS OUR COMPETENCE -
Klingenhofstrasse 50d
D-90411 Nuernberg
Fon [phone]
www.keynote-sigos.com

HRB 9323 Nuernberg
Gerichtsstand: Nuernberg
Geschaeftsfuehrer: Adil Kaya, Martin Loehlein, Umang Gupta, Andrew Hamer


Paul Fox wrote:

> hi --
>
> i'm having a very strange delay issue with my sirf receiver.
>
> i use a sirf-based USB mouse attached to a (linux) laptop running
> a mapping program.  some days (like today) everything works
> perfectly.  other days (like yesterday) GPS reports are delayed
> by a full 14 or 15 seconds from when they really happen.
>
> to describe the behavior in more detail:  if i'm traveling, the
> trail followed by the mapping program's cursor follows my actual
> trail exactly (meaning that the position reports are all correct)
> but each is delayed by 15 seconds -- i can come to a stop at
> an intersection, and watch the cursor "catch up".  or, if i'm on
> a bus, and we come to a stop, the speed reported from the device
> comes to a stop 15 seconds later -- it inicates 0m/s for the duration
> of the stop, then starts climbing 14 seconds after the bus has
> started moving.  this is observed using my mapping client, or
> using gpsmon.  if using gpsmon, i can observe this behavior
> whether using gpsd as the data source, or when connecting
> directly to /dev/ttyUSB0.  gps data seems to arrive at the usual
> rate -- an update or two per second.
>
> while i can't fully interpret what i'm seeing, it sure feels like
> either my sirf chip, or the USB stack (!?) is in some sort of
> wayback mode.  has anyone else ever seen anything like this?
>
> when the problem is occuring (and i've had it happen enough that
> i've watched it quite a bit, both with my map program, and
> gpsmon), it's so reliably "wrong" that it feels deliberate --
> i.e., it feels like a debug flag in the sirf firmware has been
> set (the "delay all reports by 14 seconds" debug flag?).  are
> there any sirf dumping utilities that i could use to get a more
> complete picture of the receiver's state?)  i haven't figured out
> any way of forcing the receiver in or out of this odd mode --
> unplugging/replugging/reopening the device usually has no affect.
>
> versions:  i've been using svn r5863 of gpsd.  if someone can tell me
> how to get the sirf firmware version number, i'll provide it.
>
> thanks!
>
> paul
> =---------------------
>  paul fox, pgf@... (arlington, ma, where it's 68.4 degrees)
> _______________________________________________
> 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

[Paul Fox-3]

hello jens --

jens wrote:
 > Hi Paul
 >
 > We have the same problem with u-Blox devices, though the delay is only 5
 > seconds.
 > See https://lists.berlios.de/pipermail/gpsd-users/2009-January/003566.html
 > We are using version 2.32 now (as far as I remember) which works correct.

if i could reproduce the problem reliably, i would certainly do that.
unfortunately, the condition has gone away, so everything's fine right
now.  i'm sure it's waiting for my next road trip to reappear.

 > Could you give that version and the next a try, so we can be sure the
 > bug came in with that changes. My workmates thought it's a problem with
 > u-Blox only.
 > What OS are you using?

fedora F-9, on an OPLC XO laptop.

i see in your earlier thread you write that the problem only occurs
with a USB connection, not with serial.  how do you test the same
device in both ways?

just to add more confusion to the current discussion (more is
good, right ;-), i'll add that in may of last year i wrote here
concerning the 5-second latency i was experiencing with my
bluetooth MTK-based receiver.  at the time my serial receiver
(the one i currently get 15 second delays from sometimes) was
working perfectly:
    http://lists.berlios.de/pipermail/gpsd-users/2008-May/003239.html

i haven't been using the bluetooth receiver much recently, for
other reasons, but i'll try it again today, just to see.

paul
p.s. anyone know if the owners of lists.berlios.de are pursuing
a new security certificate?


 >
 > Bye,
 >     Jens
 >
 >
 > Paul Fox wrote:
 > > hi --
 > >
 > > i'm having a very strange delay issue with my sirf receiver.
 > >
 > > i use a sirf-based USB mouse attached to a (linux) laptop running
 > > a mapping program.  some days (like today) everything works
 > > perfectly.  other days (like yesterday) GPS reports are delayed
 > > by a full 14 or 15 seconds from when they really happen.
 > >
 > > to describe the behavior in more detail:  if i'm traveling, the
 > > trail followed by the mapping program's cursor follows my actual
 > > trail exactly (meaning that the position reports are all correct)
 > > but each is delayed by 15 seconds -- i can come to a stop at
 > > an intersection, and watch the cursor "catch up".  or, if i'm on
 > > a bus, and we come to a stop, the speed reported from the device
 > > comes to a stop 15 seconds later -- it inicates 0m/s for the duration
 > > of the stop, then starts climbing 14 seconds after the bus has
 > > started moving.  this is observed using my mapping client, or
 > > using gpsmon.  if using gpsmon, i can observe this behavior
 > > whether using gpsd as the data source, or when connecting
 > > directly to /dev/ttyUSB0.  gps data seems to arrive at the usual
 > > rate -- an update or two per second.
 > >
 > > while i can't fully interpret what i'm seeing, it sure feels like
 > > either my sirf chip, or the USB stack (!?) is in some sort of
 > > wayback mode.  has anyone else ever seen anything like this?
 > >
 > > when the problem is occuring (and i've had it happen enough that
 > > i've watched it quite a bit, both with my map program, and
 > > gpsmon), it's so reliably "wrong" that it feels deliberate --
 > > i.e., it feels like a debug flag in the sirf firmware has been
 > > set (the "delay all reports by 14 seconds" debug flag?).  are
 > > there any sirf dumping utilities that i could use to get a more
 > > complete picture of the receiver's state?)  i haven't figured out
 > > any way of forcing the receiver in or out of this odd mode --
 > > unplugging/replugging/reopening the device usually has no affect.
 > >
 > > versions:  i've been using svn r5863 of gpsd.  if someone can tell me
 > > how to get the sirf firmware version number, i'll provide it.
 > >
 > > thanks!
 > >
 > > paul
 > > =---------------------

=---------------------
 paul fox, pgf@... (arlington, ma, where it's 67.5 degrees)
_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users