[time-nuts] Best Chance GPS module

Bob Camp kb8tq at n1k.org
Sat Dec 3 12:33:09 EST 2016


Hi


> On 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.
> 

For an “antenna challenged” location, the T is the better choice. It is simply an update (as the M8Q) of the earlier uBlox parts. The function is very similar to the earlier parts. You nail down the antenna location (like with duct tape) and put the module in survey mode. Eventually it completes the survey and you save that location. That location is then used as part of the fixed location setup. This eliminates any need to ever do a survey again. The reason you want the fixed location operating mode is that it will work with a single satellite. You don’t need the accuracy, but you do want to eliminate dropouts. The module should be set to only put out a PPS when it has a valid timing solution. You very much do *not* want it to simply put one out that is based on the internal oscillator on the module. 

Bob 



> 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...)
> 
> <at idle, well behaved.png><wtf, but not the worst.png><test run N24 16.10, loads heavy, to med to light - short.png>_______________________________________________
> 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.



More information about the time-nuts mailing list