[time-nuts] Ublox neo-7M GPS

[Bob Camp]

Hi

I would bet that they drop / add a cycle whenever the output gets ahead or behind GPS by the appropriate (TCXO period) amount. The output stays “in phase” with GPS (sort of). The output spectrum looks messy ….

Why would I guess this - it’s the cheap / low computation way to do it. Playing around with pulse positions to “improve” the spectrum adds code. It also only really helps if you know there is a filter downstream. 

Bob

On Aug 21, 2014, at 4:54 PM, SAIDJACK at aol.com wrote:

> Hal,
> 
>>> Except for a few magic target frequencies, the output  will have 
> occasional (or frequent) missing or extra
>>> cycles.  The output will be clean if you are  dividing by a power of 2.  
> (By switching from 10 MHz to 8 
>>> MHz, you have changed from frequent to  occasional.)
> 
> Not true that dividing by two cleans it up. If you change the cycle time  
> from time to time as you would have to do even at 8MHz since the TCXO is  
> free-running to GPS and then divide this by two you still get the non-standard  
> cycle times, but these will now simply be twice as long on average.
> 
> The divider will not magically remove the huge cycle to cycle jitter  
> whenever the unit does a phase adjustment. Only a PLL with a very long time  
> constant compared to the cycle time (e.g. 100ms versus 100ns) can clean up the  
> phase jitter.
> 
> Also, the number of adjustment cycles at 8MHz now depends on the frequency  
> error of the TCXO versus UTC. Taking a heat gun and cold spray to the unit 
> would  show that easily.
> 
> However at 8MHz with a 48MHz crystal you only need to add/shorten the cycle 
> time to compensate for the error of the crystal versus UTC. This is  
> similar to the sawtooth error we are all familiar with.
> 
> At 10MHz you have to add cycle adjustments to both compensate for the  
> frequency error of the TCXO as well as the N/M divider to generate 10MHz out of  
> 48MHz.
> 
> Wether you have 10,000's of phase adjustments per second or just a few  
> doesn't change the fact that you are changing the cycle to cycle time by 
> massive  degrees/percentages/nanoseconds.
> 
> The question is: does the hardware/software that calculates when to  
> increase/shorten the cycle work with error-diffusion that keeps track of  the 
> overall phase error accrued, or does it simply try to "get close  enough" by 
> statistical averaging.
> 
> In the former case, the 10MHz phase over long periods of measurement would  
> stay in phase with the UTC 1PPS phase. In the later case the 10MHz phase 
> would  drift over time versus UTC which is really bad of course.
> 
> Which way does the uBlox hardware compute the error? I don't know, and the  
> documentation I have seen does not add any insight.
> 
> bye,
> Said
> 
> _______________________________________________
> 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.