[GPS_Standard] GPS Jitter.

[Stig Kristiansen - OZ3XO.]

Hello Glen.

My mistake, you are right, the sampling time is only 16 sec, with a 16 sec DAC rest time, starting a new count every 32 sec, ( that's what I remembered ).
The PIC has the two averaging modes available as the summing mode and voting mode, so has to be possible to adapt to averaging out the jitter of the system.

You are right about using a higher frequency, and using the controlled oscillator might be a good idea, but multiplying a frequency, still give the same PPM error to the system.

I am working with commercial V-Sat transmitting on 14,5 GHz, with as low speed as 32 Kbps, and HF Maritime DSC Modems, and I found out, that for commercial use, the stability don't has to be that high, but for very narrow band communication in very high frequency's, it will still call for high stability.

So it will never be perfect, but near perfect for only a fraction of the investment might just be what is needed.

Best 73
Stig - OZ3XO

  ----- Original Message ----- 
  From: Glenn Elmore 
  To: Stig Kristiansen - OZ3XO. ; gps_standard at mailman.qth.net 
  Sent: Tuesday, May 12, 2009 12:44 AM
  Subject: Re: [GPS_Standard] GPS Jitter.



  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:


      a.. 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. 
      a.. Decrease the number of captures by increasing the capture interval above the current 16 seconds (160 million counts) 

      a.. 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.

      a.. 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.