[time-nuts] Best Chance GPS module

Scott Stobbe scott.j.stobbe at gmail.com
Sat Dec 3 14:24:59 EST 2016

Hi Lewis,

Here is a sample data-point related to processor load, on the RPI 2.
Stepping from Idle to full load on 4 cores resulted in a temp rise near the
XO of approximately 14 degC, and correspondingly the XO shifted 3.6 PPM.

On Sat, Dec 3, 2016 at 10:29 AM, MLewis <mlewis000 at rogers.com> wrote:

> 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...)
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/
> mailman/listinfo/time-nuts
> and follow the instructions there.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: RPI_LoadRamp3_Time.png
Type: image/png
Size: 9858 bytes
Desc: not available
URL: <http://www.febo.com/pipermail/time-nuts/attachments/20161203/fd03aa2f/attachment.png>

More information about the time-nuts mailing list