Re: [gpsd-dev] gpsd for time sync on Ubuntu remix too hard for normals - how to improve?

[Greg Troxel]

"Gary E. Miller" <address@hidden> writes:

>> I was mostly kidding about BeiDou/Galileo, but redundancy for bad
>> skyview is good.  It's also good in terms of a failure of the GPS
>> system, assuming that one of the other constellations is still ok.
>
> I guess you want that if you are in a war zone and the Russians are
> jamming GPS.

Time to watch Red Dawn again :-) 

> I'm only suggesting recompiling one: gpsd.  Better yet, get the
> package maintainer off his butt.

I know you are suggesting only one.  The other package maintainers will
want their package updated too; everybody thinks their child is special.
It seems that 3.17 was current on 2018-04 when the 18.04 LTS started, so
it doesn't seem broken of them to still be on it.

>> So I really have to ask: why is gpsd's default behavior of waiting
>> until open useful, for who, compared to the harm it causes?
>
> To save power.  Period.  You might have notice that battery life is
> a big deal these days.

I really meant "for which setups does it actually save power, and are
those normal enough to control the default, vs the people with the
setups where it matters being the one to set the option".

>> I pluggd the
>> device into USB power, no computer (Anker lighter socket adaptor),
>> and it started pulling 7-10 mA, and also started blinking.  So
>> declining to open it does absolutely nothing useful.
>
> 10 mA is important to some.  It also matters, a lot, which power saving
> mode you GPS is in.  Many report much larger power savings.

My point is that this is the power with no gpsd, and thus I would expect
with gpsd without -n.  I am not seeing the behavior of the device being
in sleep mode until DTR is asserted.

> Did you measure the total system power?  remember that on an
> ARM chip having gpsd processing is taking about 1% of a core.  That is
> huge to some people.

No, and a fair point.

>> I am seeing fuzz of a few milliseconds.  I call that success; you may
>> call it failure, depending on which accuracy requirements we have in
>> mind.
>
> As Hal pointed out, long term you can't expect accuracy (not jitter) to
> be better than 100 mS.

I really have to wonder if that's true with modern ublox.

> For USB, you want any GPS with an M8030 chip.  But that does not
> do PPS.  For PPS you just have to search for u-blox 8 and PPS.
>
> For PPS over USB, find a Navisys GR-601W or GR-801W.

Thanks.  I have a GR-601W.  Looking for those did not seem to turn up
anything readily purchasable.  i did find a GR-701W on etsy.

>> I'm going with stratum 5 for now.
>
> I think you misunderstand stratum.  Stratum has zero to do with
> "precision".  Stratum is just the number of hops (think traceroute) to
> a "primary" time server.

I do understand.   I'm abusing it to bias the selection so that if there
are normal network peers they are likely to control time.  Given lack of
PPS, I would prefer to use the net if present, and the non-PPS GNSS
receiver if there is no net.