[time-nuts] Best Chance GPS module

[MLewis]

So much to absorb and learn from what people have responded with.

Thanks all!

On 01/12/2016 12:01 PM, Chris Albertson wrote:
> OK, now I know what you need.   Millisecond level time on the data
> processing machine. ... Let's assume you were able to set up a local NTP server that runs off it's
> own GPS reference clock. ... about 100x better then you
> need. ...  Ethernet is not perfect but good enough for what you want.
That's the take I have on it.

> I really doubt varying processing load is an issue with NTP. ... What happens is
> the PPS causes an interrupt and inside the handler the nanosecond clock is
> sampled and copied to memory.   The handler has something like 8 lines of
> code and runs very fast.
That's good to know about PPS, 'cause the computer's load while polling 
hosts over the internet is getting me horrible variance in offsets.

> The other thing you might look at is NOT using NTP but using PTP.
Looks like fun, but way better than I need. More than I can afford too.

> I don't think your measurements are measuring correctly. ... Any offset is perfectly fine, that is simple the communications delay and is accounted for by NTP. ... If you were looking at
> offset, just don't do that.
O.K.. I'm pretty sure I don't understand that, but the issue I found was 
not that different hosts offsets varied from one another, but that the 
offset reported by "a" host would jump around. And when the load on the 
computer was changing, low-to-high or high-to-low, several hosts', 
sometimes all hosts, offsets jump around, with that multi-host variance 
continuing for some minutes after the computer was running at the new 
load. This settled down a little when I turned core parking off, but 
only a little. I've attached a sample of the offsets I'm getting to show 
this variance. Oddly, a sustained higher load would often settle the 
variance and give the most consistent results: one such period is 
between poll 6 & 10 on the "test run N24" attachment, and the graph 
shows the offset slope and hosts' offset variances as the load moves 
from heavy to medium and then light.

After giving up on SMAs to tame individual host's offsets, to get a 
usable offset from the reported offsets I implemented a cascade of 
filters: applying factors on standard deviation to implement truncation 
means to remove outliers, then winsorizing means, with independent bias 
factors applied to selection and winsorization. This all worked rather 
well once I tuned the filters' parameters. Then the variance got worse, 
so I added some increasing attenuation on increasing corrected offset 
values and that made my corrected offset usable within the tolerance I 
needed, until from a certain date the reported offsets went all over the 
map.

But we shouldn't go down this road, other than curiosity (and I wish I 
had the time to explore the why), as going to a separate machine as an 
NTP host removes all of those types of issues. And I don't have to grow 
my own code...

> I think your only problem is finding a GPS with PPS output that works at
> your location.   Don't worry much more.  If it works and has PPS it is good
> enough
Exactly.
Any module that can get a usable GPS signal can discipline time and be 
delivered over my local Ethernet to better than I need.

> You might have a "Plan B", ...
Thanks for those. Good to know.



I believe the location issues narrows it down to the MAX-M8Q or the 
NEO-M8T.

Both have great sensitivity, but their firmware varies to address 
intent. The M8Q can be explicitly set to Dynamic-Mode-Stationary (as it 
should go to automatically with an unmoving antenna) and the M8T will 
set there as it moves to focusing on a better time solution after 
establishing a location fix. In comparing their product descriptions, 
the M8T seems the better choice while sitting still for obtaining usable 
results in questionable locations, but - speculating - that wording may 
be marketing wording in response to prior issues with earlier T series 
modules. And so far, I've not found any accounts of first hand 
experience with a M8T.

The other issue is what breakout board the modules are available on.
- With the M8Q, there's hats or boards that can connect direct to a Pi 
or such, but lack protection with supply voltage or outputs if I want to 
feed them to another computer.
- And the M8T is available on a board that provides power regulation and 
some protection, so that should be able to feed NEMA & PPS to any 
suitable computer without risk.
- And I found a board that accepts GPS modules-on-breakout, protects 
them, and can feed any computer, but the breakout boards with M8Q or M8T 
have pins don't match the header. A small custom cable would fix that.

But without trying them, I can't Know which will be best by my location. 
Or if my location means one will work and the other won't...

(waiting to do that GPS sat test at my location...)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: at idle, well behaved.png
Type: image/png
Size: 198711 bytes
Desc: not available
URL: <http://febo.com/pipermail/time-nuts_lists.febo.com/attachments/20161203/01febe66/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wtf, but not the worst.png
Type: image/png
Size: 77503 bytes
Desc: not available
URL: <http://febo.com/pipermail/time-nuts_lists.febo.com/attachments/20161203/01febe66/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test run N24 16.10, loads heavy, to med to light - short.png
Type: image/png
Size: 113295 bytes
Desc: not available
URL: <http://febo.com/pipermail/time-nuts_lists.febo.com/attachments/20161203/01febe66/attachment-0002.png>