Re: [gpsd-users] count of satellites_used is incorrect

[David J Taylor]

Yo David!

On Sun, 29 Apr 2018 08:09:06 +0100
"David J Taylor" <address@hidden> wrote:

> "www/client-howto.txt" - I installed libgps-dev.  Where would I find
> that file?  Obviously I've not read it.  Can the file be found on the
> Web?

Oh, gpsd has nothing called libgps-dev.  I have no idea where that comes
from and it not ours.

If you want support on packages from your distro you need to contact
your distro packagers.

If you want to use the package that gpsd maintains then you need to
delete your distro package and install our source from here:

http://www.catb.org/gpsd/#downloads

> My program is called once every five minutes, so from what you said
> it might be holding old data.

It IS holding old data.  The data is always old.  The question is how
old?  One second old or one hour old?

> NTP (which uses the PPS data much more
> frequently) doesn't seem to be showing any issues,

PPS is a different path.  The PPS is a hardware pulse, the NMEA is
serial data.

ntpd cares nothing about satellites, but you do.  So red herring.


> so I'm guessing
> that the program is probably adequate for my purposes.  If anyone
> wants to improve it I'd welcome that.

Adequate, except you issue with sats.

> BTW: the only major GPS issue I've seen is when (I believe) a vehicle
> with a GPS jammer was in the area.

Those would be illegal pretty much everywhere.  Much more common is
loss of signal in built up areas, or multipath (multiple reflectons
from the same sat).

>  I can't currently see any
> significant correlation between either the number of satellites used
> or average SNR and the NTP reported offset,

Yup, that's the way it is.  Accuracy is way more affected by many other
things than sats used.  Look at the DOPs (Dilution of Precision).  They
tell you the estimated 'goodness' of the satellite geometry.

Then the DOPs are multiplied by atmospheric effects to give you a
'position error'.  This 'position error' is a number with a modest
confidence of the actual performane and takes into account things like
diurnal atmospheric delays.  The actual error performance includes
additional error sources like multipath and clock errors that are
essentially unkownable in real time.

As for NTP, remember that NTP can measure down to about a micro second.
Maybe better than that when done carefully.  A nano second error is
about 9 inches.  The typical micro second error is the same as a
location error of 9,000 inches (750 feet!).

Until you can measure nano second errors in the GPS signal yuo can not
use it to guess position accuracy.

> so to that extent the
> program has probably already proved its worth.  This using multiple
> Raspberry Pi cards - faster devices may be more sensitive to PPS
> timing variations.

Actually, the RasPi is pretty fast, and the lack of GUI overhead makes
it a fine platform.  Much better than anything running 64 bit Intel
code.  Going to a 64 bit OS on the RasPi can get you down to 300 nano
second range.  To get better you have to go to Arduino, less overhead
from no OS.  Or go to dedicated measurement hardware.

RGDS
GARY
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Gary,

Thanks for the information.  I simply looked for sample code for using gpsd, 
and libgps-dev came up in Google, and it seems to work, so I'll stick with 
it.  I thought there was just one gpsd.  I appreciate the difference between 
PPS line and serial NMEA data.

If the data was consistently an hour old it would show in the graphs, so 
I'll keep a look a look out for that.  Would it be better if gpsd reported 
the current status when requested via its API, i.e. that the API should 
produce current, not historic status?

I'm not interested in positional accuracy, simply whether there might be any 
correlations between NTP reported offsets and poor satellite coverage.  Most 
of my GPS antennas are indoors (but near walls or windows).  I found that 
the greatest enemy of "good" timekeeping was temperature variations, so 
having the Raspberry Pi in an upstairs, unheated cupboard produced the best 
results, even thought it's on a north-facing wall.

There does seem to be a slight confusion here (likely due to my mailer not 
supporting ">" marks, sigh!) and I don't actually have a problem.  It was 
the OP I was trying to help!

Cheers,
David
--
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: address@hidden
Twitter: @gm8arv