[time-nuts] Is my Cs C-Field set OK or do I need to take more data?

Poul-Henning Kamp phk at phk.freebsd.dk
Mon Jan 10 09:24:15 UTC 2005


In message <41E23583.3090205 at pacific.net>, Brooke Clarke writes:
>Hi Poul:
>
>I don't understand that.  The manual says the 256 reading filter is 
>automatically set when LM is set to 1, i.e. when locking to an external 
>1 PPS input.

Correct.

The trouble is that even the 256 pos filter is not enough to fully
de-wiggle the Oncore jitter.

The problem is that the jitter is not gaussian, it is the modulus
residual which means that it mostly have a box-distribution, but
is not guaranteed to.

If you plot the "negative sawtooth" field from the serial data-stream
you will get a curve which looks a lot like a "Fresnell Lens" (this
is not accidental).

As long as the internal Oncore clock is sufficiently far from a
frequency which is multiple of 1 Hz there is no trouble, you get a
box distribution and averaging that you get close (enough) to a
zero.

But when the internal clock is close to a multiple of 1Hz and it
can easily stay close for a few minutes if you have good temperature
regulation, the negative sawtooth could be any value for several
minutes, if you are unlucky it will be 49 nsec.

And obviously a 256 second average of 49 nsec is 49nsec.

In theory running without the averager but with a longer timeconstant
would work better, but that ruins the short term stability of the
PRS10.  If you increase the timeconstant to avoid that you loose
the mid term stability to wander.

The correct solution is to grab the "negative sawtooth" value in
the serial data from the Oncore and feed it to the PRS10 (presumably
using the "TO%d" command) so that the intentional PPS is tracked.

I tried to make this work but concluded that my PRS10 had too
old firmware.

I've been meaning to reimplement the PRS10's PLL in software on a
computer and try to "do it right" but for various reasons I have
not got around to it yet.

Poul-Henning


>My Motorola 8 channel GPS receiver does not have a clean 1 PPS.  Are you 
>referring to the phase lock time constant (PT command, now set to 8)?
>
>Thanks,
>
>Brooke
>
>Poul-Henning Kamp wrote:
>
>>In message <41E22178.4020103 at pacific.net>, Brooke Clarke writes:
>>  
>>
>>>Hi Poul:
>>>
>>>Ha    ha    ha   you give me a chuckle.  Probably because that's the 
>>>problem, when to stop and change something.
>>>I'm thinking I might be able to keep this test going and at the same 
>>>time get a GPS direct 1 PPS for comparison.  I think the PRS10 is adding 
>>>a variable that actually makes the test harder than it needs to be.  I 
>>>was hoping that the PRS10 would act as a flywheel to smooth out the GPS, 
>>>but I think it's more like a roller coaster.  After posting the plot and 
>>>watching a movie the data went back down to the 32 ns area and so the 
>>>data has taken on a completely new flavor.
>>>    
>>>
>>
>>Running the PRS10 off a GPS is not as trivial as it could sound.  If your
>>GPS has significant jitter (they all do) you need to run with the 256
>>sample averaging filter ON in the PRS10.  If you do that, the entire PLL
>>changes dynamics significantly and at least I have found that a relatively
>>short timeconstant is necessary (I'm using a UT+ and PT=8)
>>
>>Poul-Henning
>>
>>  
>>
>
>-- 
>w/Java http://www.PRC68.com
>w/o Java http://www.pacificsites.com/~brooke/PRC68COM.shtml
>http://www.precisionclock.com
>
>_______________________________________________
>time-nuts mailing list
>time-nuts at febo.com
>https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.




More information about the Time-nuts_lists.febo.com mailing list