What I would guess is that there is some sort of aging estimation going on. > > It was weird: yesterday LH highlighted the DAC value which was around > 0.38V (I didn't write down the number, alas) and the "osc age alarm", > both of which were red. Which is the sort of thing I have seen.

The RTC is only there to give the GPS module a rough estimate of the time so it can use the stored ephimeris data to speed up the search for satellites. Ie there is no need to phase lock or stabilize the 32kHz in any way. > Suggestions of any other component, for driving both the VCXO, and > possibly for a RTK implementation, are welcome.

No matter how good the antenna, day / night ionosphere compared to the estimated numbers they broadcast will be an issue. Is the level that the local multi path and the constellation "gets you" higher than the level that the ionosphere correction falls apart? Without a lot of data, you will have a hard time sorting that out.

. > > I thought I would come back to this sample data point and see what the impact of using a 1st order estimate for the log function would entail.

There are a number of subtle issues that can creep into the GPS module’s location estimate. Whatever the issues are, they are also (hopefully) built into the survey data the GPS reports. This is also another reason to run very long surveys (many days). That way you include as much of the weirdness into the survey as you can.

The next is the accuracy of the estimate of that offset (again maybe a few ns, maybe …). After that you get into things like survey accuracy. Position hold is a single fixed location that gets applied to all systems. If the “right”survey is here for this system and there for that system, there will be an error one way or the other.

H-masers where not used until the ALGOS algorithm got a drift estimator component in it. Cheers, Magnus On 03/02/2017 09:50 AM, Azelio Boriani wrote: > These data fles?

This paper claims an estimated Allan Deviation of <1e-14 (perhaps 3e-15) at a one day interval when in space: https://www.researchgate.net/publication/260036335_Expected_Performance_of_the_Deep_Space_Atomic_Clock_Mission Here are the latest two papers I can find (from Feb 2016): ** Deep Space Atomic Clock Technology Demonstration Mission Onboard Navigation

The app corrects for half the round-trip delay, assuming that to be a good estimate for the one way delay from the web server. However, if there is a network bottleneck or vary slow packet transfer in one direction, then the correction will not be accurate.

the jump you see it when it selects a different cycle and jumps The software tracks the error and outputs an estimate of the root on the serial channel. You can verify this by plotting the sawtooth correction vs.time and see that it lines up with your observation of the jump back to zero error.