[GPS_Standard] GPS Jitter.

Bert, VE2ZAZ ve2zaz at sympatico.ca
Wed May 13 07:43:53 EDT 2009


Greetings,

Some very good ongoing discussion on improving the "stability" on the
GPS-Derived Frequency Standard. Keep on experimenting!

The one comment I am not sure I agree with though is the following from
Glenn-N6GN:

<< The capture circuit in the PIC being used is a state machine which runs
from the PIC CPU clock. The actual captured value must occur at the same
state/phase of the CPU clock phase (four internal 8 MHz Clock cycles per
instruction clock). This behavior is at the root of the +- 4 count ambiguity
one sees on the freq error count - even when counting a perfect 1 PPS
derived with 7 decade dividers from a 10 MHz crystal.>>

I would like to read this much detail in a Microchip document, if possible.
I have been trying to locate similar documentation for improved
understanding, but without success. I wonder if this is applies to both the
Synchronous and Asynchronous Timer mode selection. When I originally
experimented with the CCP, I quickly realized that the Timer1 mode had to be
set to Asynchronous in order for the Capture feature to work and the FLL to
converge. This is contrary to what is stated in the PIC18F2220 datasheet.
Setting Timer1 mode to Synchronous will yield wild results and no
convergence. Maybe I should challenge someone at Microchip on this topic. On
the PIC18F2220 (our chip), it is said that it MAY not work in Asynchronous.
On the PIC18F2620 (same family), it is written that it WILL not work... That
being said, I also tried using the 10MHz OCXO output also as the CPU clock.
That did not work either. Both clocks have to be asynchronous from each
other. I am sure there is a link between this fact and the above discussion,
but I would like to read this from Microchip.

Cheers,

Bert, VE2ZAZ



More information about the GPS_Standard mailing list