[time-nuts] Best Chance GPS module
MLewis
mlewis000 at rogers.com
Sat Dec 3 10:29:42 EST 2016
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://www.febo.com/pipermail/time-nuts/attachments/20161203/01febe66/attachment-0003.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://www.febo.com/pipermail/time-nuts/attachments/20161203/01febe66/attachment-0004.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://www.febo.com/pipermail/time-nuts/attachments/20161203/01febe66/attachment-0005.png>
More information about the time-nuts
mailing list