Hi > On Dec 4, 2016, at 6:57 AM, MLewis <[email protected]> wrote: > > > On 03/12/2016 12:33 PM, Bob Camp wrote: >> 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. > Thank you! > > That is exactly what I "thought" I was getting from reading various sources, > but I wasn't confident I was getting it right. > > I think: > - There's GPS Time and with the offset (currently 17 seconds?) in the GPS > location message we get UTC Time. > - The GPS module receives the satellite's GPST, offset, and hence UTC Time, > and its location fix allows for correcting for the message delay. > - A better fix, and that correction is more accurate. > - With a number of satellites reporting, that correction is more accurate.
Not quite correct. Until the module has a proper fix it does not have useful time. The delay from the sats is long enough that for most purposes there is no value in putting out raw time. You *could* re-write the firmware from scratch to do it a different way, but that’s the way it works now on all these modules. > > If the module has a good fix and a good solution from several satellites and > is providing me with a local UTC Time that is close to true UTC, but then > conditions degrade to a single satellite: > - will the module be able to maintain a quality correction to true UTC Time? If it has a properly surveyed location (and thus can calculate the delay in getting the signal from the sat) yes. > - or perhaps I should be asking: what is the precision from a GPS module's > best time solution vs. that from a single satellite. With a proper survey, it’s in the 10’s of ns. It degrades roughly 1.5 ns / meter for typical survey errors. The survey induced error tends to show up as a long term (hours) drift in the output. It is slow enough that NTP will try to track it. The 10’s of ns basic error is related to things like ionosphere corrections and that also can be a long term drift. Both errors may go up a bit with a single sat. How much depends a lot on the geometry involved both with the single sat and the group you replace it with. It’s possible (but unlikely) to have a single sat in a “perfect” location give you a better solution than a group of sats in a really crummy location ….. This is yet another reason for wanting a full sky view. Seeing several sats at a crummy angle may still be a less than ideal thing. > - or is that irrelevant given my rather trivial goal of 1 ms precision? On a LAN, you should be aiming for < 10 us in terms of the time input to the main server. Your “delivered time” budget needs to allow for a lot of different errors that all add up. The idea is to make the time input error insignificant compared to the rest. If your time input error is 1 ms, and you are after 1 ms, the rest of the errors would have to be zero. Depending on your setup, they may well be a significant chunk of 1 ms. > > >> 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 > > And here I was thinking that internal oscillator was going to save me by > continuing to provide PPS from a recently disciplined TCXO. The TCXO in the module is not disciplined. A GPSDO is a device that disciplines an oscillator. These modules are not GPSDO’s. If you have a GPSDO, then “holdover” is what takes care of the PPS output when you loose GPS. > > If I have a good sat solution and am getting PPS for some hours, then it > loses all satellites, > - is the internal TCXO sufficient to trust for a number of minutes? It may slew at a couple microseconds per second. That’s much worse than just ignoring it. > - if so, how would I determine how much error for how many minutes? Measure it under your conditions. It likely will be a bit different each time. > - or do I just have to set an alarm, let NTP fall back to the internet > hosts, and monitor my data clusters for drift? That is why the PPS drops out. NTP then knows to ignore it and go do it’s own thing. That is a much better solution than tracking a slewing source. > > I'd guess this is related to the Best Practices I saw that said that for time > critical applications, as a minimum: use a local GPS time source, but have > NTP polling four or more NTP hosts (non GPS based) through the internet as > backup if the GPS system goes out. For a variety of reasons, you want multiple sources with NTP. Unless it has at least three reasonable time sources, it gets into all sorts of strange behavior. Setting up with four to six sources is a pretty good idea. With 4, if one drops out you are at the limit of three. Six gives you a bit more margin. The biggest issue with NTP is offsets. This is why they created PTP. If you run NTP for a long time with a good local reference *and* have a stable connection to a fixed set of remote servers … NTP can work out what the offsets are. That magic depends on the local reference being there all the time along with a few other things. Bob > Or in my case, simply if I can't track a sat. > > Thanks, > > Michael > > > _______________________________________________ > time-nuts mailing list -- [email protected] > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
