[GPS_Standard] GPS Jitter.

[Glenn Elmore]

Stig,
Thanks for your comments, the Trimble does pretty well then. I'm using 
an older Motorola OnCore which doesn't seem to be so good. I am getting 
a pair of them to beat together to see how they compare but I'm not 
expecting better than 50 nsec.

I agree that if one averages long enough, the jitter superimposed by the 
PIC can be made arbitrarily small compared to the "signal". However, one 
increases that averaging time at the expense of decreasing the clean-up 
bandwidth of the DFLL.  Effectively this means throwing away improved 
potential shorter term performance  of the disciplined oscillator only 
because the PIC phase/frequency detector is inadequate. I agree 
completely that the quality of the oscillator to be locked is a key 
element in determining what, if anything, to do to improve things.

Perhaps I am not running the same version of code you are but the board 
I tried only averaged for 16 seconds so things are twice as bad as you 
suggest. But I see a several possibilities of ways to improve things to 
take the best advantage of the GPS signal:

        * Increase the number of reference counts/unit time. This could
          be done by diode frequency multipliers taking the (10 MHz)
          reference signal to 40-50 MHz. The C/N of the resultant signal
          would be lower by the multiplier conversion loss but I think
          this is a essentially a non-issue for the region we are
          operating. With the prescaler enabled (probably use
          divide-by-2) the PIC can count 50 MHz, this stands the chance
          of improving things by (50/2 MHz)/10 MHz or 2.5 times. for the
          same performance.

        * Decrease the number of captures by increasing the capture
          interval above the current 16 seconds (160 million counts)

        * Run the PIC clock faster. This reduces the size of the jitter.
          The 18F2220 has a built-in 4x PLL that would allow a clock of
          4*10 MHz = 40 MHz (if the reference were also used as the CPU
          clock, say). Doing this requires considerable change to the
          timers in software because the 2 second timer  have enough
          bits to get to 2 seconds with that high a CPU clock. Also
          changes to the baud rate generator in the serial comms. Still,
          vs. the present 8 MHz clock, 40 MHz is a 5:1 improvement.
          Added to improvement of the first bullet above that's a full
          order of magnitude.

        * Remove the 4/Fosc jitter from the DFLL/Capture phase detector
          by outboarding the phase detector function. This would require
          an external part but could potentially drop the jitter to a
          very small value -completely eliminating the +-1 count issue.

You make a good point though, "How good does anyone really need?". 
Personally, though I've done long-distance and weak signal work on 
10.368 GHz and run SSB there, I probably don't need a lot better than 
100 Hz accuracy - and that's only a part in 10^8, a part in 10^9 if one 
is a purist about SSB tuning or trying to run weak signal psk31, mfsk or 
w1jst sorts of software. (:>)

best 73
Glenn   n6gn


 Stig Kristiansen - OZ3XO. wrote:
> The Trimble Resolution T receiver outputs a 1 Pulse-per-second (PPS) timing.signal accurate to within 15 nanoseconds of GPS or UTC (1.sigma) when using an over determined solution in a stationary mode.
>
> <5 ns with quantization error removed.
>
> The Trimble Resolution T goes Automatically into fixed position timing mode after is has performed a default self-survey by averaging 2000 position fixes (2000 sec.) but is user selectable from 1 to 2e32-1.
>
> So the jitter of the PIC has en effect, but since the timing is evaluated over 32 Sec. so the problem is then reduced to 16,625 ns, as 1 / (( 8.000.000 Hz * 32 sec ) / 4 instructions ), and this will just be equal to the GPS, so if the PIC evaluation time was just 10 times higher, then the jitter will just be 2 almost times better, but this it already been done, by accumulation of the PIC counter over longer time.
>
> So I guess this will be about the best it can get, and we also has to make sure that we are not aiming higher that really needed for our applications, as SSB or even narrowband data on 10 GHz or higher can be done with out any problem, so what do we really need it for, or will it just be to tell others that we are more accurate the your friends, and if so, then the GPS signal might even not be the way to do this, and I think me just have to thing about what will generate our needs.
>
> Stig - OZ3XO.
>
>