gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] n followed by n in gpsmon


From: Eric S. Raymond
Subject: Re: [gpsd-dev] n followed by n in gpsmon
Date: Mon, 25 Aug 2014 06:12:51 -0400
User-agent: Mutt/1.5.21 (2010-09-15)

Hal Murray <address@hidden>:
> > When I run it on a SiRF emitting binary, I already see a Firmware Version 
> > box filled in. Accordingly, I don't understand your request.
> 
> If it's in SiRF binary mode when I start it, the Firmware slot never gets 
> filled in.  It does get filled in when I start in NMEA mode and poke "i" to 
> switch to SiRF.

Hm. On looking into this, you're right.  Fixing this would be
tricky. It collides with a design goal of gpsmon and a weakness in the
driver architecture.

The design goal: Unlike gpsd, gpsmon doesn't perturb the state of the
GPS unless you explicitly tell it to. In particular, gpsmon disables
writing to the device most of the time in order to prevent the init
method(s) from messing with the device settings

The architectural problem: there's no slot in the driver method
tables for "probe for firmare version" that's separate from
"initialize the device for gpd's use".

Because that's so, there's no way for gpsmon to probe firmware unless
to do an 'i', explicitly invoking the initialization sequence.

Yuck.  There's a bit of a swamp here...

> > I'm never quite sure what people mean when they say "the time offset". Given
> > the time of receipt of the PPS pulse as a Unix timestamp to microsecond
> > resolution, what function of it do you want displayed? 
> 
> I'm looking for whatever it takes to debug timekeeping issues.  Just knowing 
> that a PPS happened is only half the battle.  The PPS offset as displayed on 
> screen above would be fine.

Added to TODO.

> >> If you want to get fancy, you could add an option to put a time
> >> stamp on the front of the logging info.  I'm mostly interested in
> >> relative times, so seconds+microsec per day is probably more
> > useful than HH:MM:SS format.
> 
> > What's the use case for this?
> 
> Standard glitch chasing sort of thing.  If I'm the only one interested in 
> timing from log fiiles, you should probably ignore me.

Not convinced yet, but you might manage it.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>



reply via email to

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