[time-nuts] Making the most of SRS Rb source
brooke at pacific.net
Wed Jan 18 17:35:07 EST 2006
That's very interesting. How about using the PRS10 in time stamping
mode where you feed it the 1 PPS from the GPS and use a uC to read back
the time stamp and the GPS saw tooth to get the actual delta time? It
would be easy to record these every hour and after a day or so make a
tweak to the PRS10 frequency. This way the only additional equipment
would the the uC connecting to the PRS10 serial port.
w/o Java http://www.pacificsites.com/~brooke/PRC68COM.shtml
Poul-Henning Kamp wrote:
>In message <email@example.com>, David Forbes writes:
>>At 6:43 AM -0800 1/18/06, James Maynard wrote:
>>I suppose it would make a lot more sense to run the GPS 1PPS into the
>>Rb source so that it will discipline itself, and the phase error be
>>monitored to make sure it stays at zero.
>>Am I barking up the right tree here?
>Sorry if this is a bit longwinded:
>You would want to be quite carefull in your choice of timeconstant
>on the PRS10, if you set it too short you will ruin your short term
>stability and if you set it too long you will get worse performance
>than you have today.
>I've been playing a lot with the PRS10 and one of the things I found
>is that a raw PPS signal from a GPS is badly suited as input for
>the PRS10 because of the short term jitter (+/- N nanoseconds for
>some N > 20 typically, dependent on your GPS receiver.
>The PRS10 can enable a a 256 sample running average on the PPS
>input, but that is not nearly long enough to filter out the sampling
>artifacts in the GPS/PPS (The ones Tom calls "Hanging Bridges").
>In an experiment I slaved an OCXO oscillator to the PPS
>from the GPS, and divided that down to 1Hz as input to the PRS10.
>That allowed me to use about four times longer timeconstant in the
>PRS10 and disable the "256 filter" in the PRS10 and the stability
>was better overall.
>An even better result was obtained by moving the PLL from the PRS10
>onto a computer where the "negative-sawtooth" information from the
>GPS could be taken into account. I fed the GPS/PPS into the PRS10,
>used the TT command to read the measured phase as input to the PLL
>and the SF command to set the frequency.
>The best results where had using my HP5370B for the timestamping.
>My conclusion was that even though the timestamping circuitry in
>the PRS10 is good, it is not good enough to do the Rb part justice
>and leaving the negative sawtooth correction out of the PLL is
>ruinous for the Rb parts good performance.
>So if I were you, I would use the SR620 to measure between the
>GPS and the PRS10 and implement the PLL in a small computer
>which talks to both, or alternatively, use the PRS10 for the
>timestamping, but have the external computer do the PLL.
>Ideally, it should be possible to have a microcontroller read
>the GPS data stream, extract the negative sawtooth and send
>TO commands to the PRS10, but at least in my firmware version
>that is not possible. SRS told me that they have allowed that
>in more recent firmware.
>PS: If you read the PRS10 docs, it's pretty simple to replicate
>their PLL parameters. Just remember that they had to do it
>on a small microcontroller and you'll see how simple it is.
More information about the time-nuts