[time-nuts] PRS-10 Missing SP values in Appendix A.

Sun Sep 15 00:42:06 UTC 2019

I really think we're on the same page.

Appendix A in the PRS-10 manual lists a set of recommended divider settings
such that you can select values for the divider to add a bit more or less
frequency offset so that you can bring the 10Mhz Oscillator into lock at
10Mhz regardless of what the Rb frequency turns out to be (within reason).
 This was the goal of this exercise since my PRS-10 had apparently aged
enough that it needed this tuning to be able to lock without everything
being at the extreme edge of configurable values.

The divider values in the officially released PRS-10 manual range wildly
from a low of 1466 to a high of 7187.   This is an enormous range,
resulting in output frequencies ranging from 6.82KHz to 1.39KHz.   This is
fine, assuming the rest of the loop is designed to handle this range (which
I'm assuming it was at least at some point).   However, in my unit, the
divisor programmed into the unit turned out to not be in Appendix A.
Instead it was a multiple of 3 from the stated value of row 52, which is
one of the lower values (2038).   It would make sense to me that it would
be more consistent to ensure all of the divisor values are within a
reasonable range, say from 3600 to 7200, resulting in output frequencies of
2.78Khz to 1.38Khz.   This appears to be what happened with my unit - the
value I found programmed into the unit was 6096, which is in this higher
range.

Like I mentioned before, I suspect someone at SRS figured out that they
could improve performance by moving the lower dividers up to a higher,
consistent, range, and as a result,  units are programmed with a higher
divider value than is stated in Appendix A.  Whether they made analog
changes at the same time, I have no way of knowing.

In my case, I only had to move one step in the table, which changed the
divider from the programmed 6096 value to 5971, resulting in an output
frequency change from 1.64KHz to 1.67KHz.   This isn't a big change so I
doubt that I'm going to bump into any issues as a result.

On Sat, Sep 14, 2019 at 3:01 PM Bob kb8tq <kb8tq at n1k.org> wrote:

> Hi
>
> Page 19 in the 145190 data sheet sends you off to a bunch of app notes
> about
> designing the rest of the circuit. If the reference frequency used does
> not match
> what the loop filter is designed for, things will not go well. Spurs and
> damping are
> both dependent on things matching up.
>
> Bob
>
> > On Sep 13, 2019, at 7:01 PM, Forrest Christian (List Account) <
> lists at packetflux.com> wrote:
> >
> > I suspect someone figured out some of the side effects what you're
> > describing and adjusted the divisors to better match across all rows.  I
> > just wish SRS would have updated the manual if it was them.
> >
> > In my device, the R,N,A values were 6114,3456,29.   The R,N,A values in
> the
> > table in the docs on row 52 are 2038,1145,31.   For the discussion below,
> > I'm just going to focus on R since the others are effectively related.
> >
> > The R values 'around' row 52 are 6400,4219,6257,2038,5971,3933 and 5828
> > (rows 49 through 55).    It seems logical to me to use 6114 as the R
> > divisor for row 52 instead of 2038 because the resulting frequency is
> > closer to the rest of the values in the table.   The highest value I can
> > quickly see is 7258 and the lowest is 1180.   That is quite a range in
> > output frequencies to deal with.   If you take the lower values and
> > multiply them by a integer multiple so that everything is within a
> narrower
> > range then I'd expect it would be easier to deal with the side effects
> of a
> > now more consistent divided frequency while still permitting the finer
> > resolution afforded by a larger divider value.  If this is the case, I'd
> > also expect the 1180 'lowest value' to have been multiplied by either 4
> or
> > 5 instead of just 3, and the other lower values in the table to have been
> > multiplied by an appropriate range to end up closer to 6000.
> >
> > Just to add another piece to the big-picture puzzle, the following is
> from
> > the manual:
> >
> > "The gain of U400’s phase detector may be set (coarsely) by the CPU, and
> it
> > is adjusted to maintain roughly the same PLL damping factor as divisors
> are
> > changed. This loop has a very low natural frequency (about 10 r/s) and a
> > damping factor which ranges from 0.84 to 1.19."
> >
> > U400 is the same MC145190 which is doing the division.   So it sounds
> like
> > they're compensating for some of the effects by configuring the phase
> > detector differently depending on the divisor values.
> >
> >
> > On Fri, Sep 13, 2019 at 11:00 AM Bob kb8tq <kb8tq at n1k.org> wrote:
> >
> >> Hi
> >>
> >> Ummm ….. errrr ……
> >>
> >> The divisors run down to an output port. There has to be a filter at
> that
> >> port to
> >> knock down the noise and make the loop close properly. When you multiply
> >> the
> >> divisors by three, you cut the frequency at that port by three. You also
> >> have a
> >> significant impact on the control loop…..
> >>
> >> Probably a good idea to make sure your board has the “normal”
> components on
> >> it that correspond to the numbers in the manual. There may have been a
> >> running
> >> change at some point that is not reflected in the doc’s.
> >>
> >> Bob
> >>
> >>> On Sep 13, 2019, at 12:12 AM, Forrest Christian (List Account) <
> >> lists at packetflux.com> wrote:
> >>>
> >>> Mainly wanting to post this to the list so it will end up in the
> >> archives.
> >>>
> >>> So I decided to give calibration/adjustment of my bench PRS-10 a go.
> >>>
> >>> What I discovered is that on my particular unit, the frequency was
> enough
> >>> off that in order to bring it close to spec, I had to adjust the Mag
> >> Offset
> >>> to the lower end of it's range (2300), and even then the set frequency
> >> was
> >>> lower than I would have liked.
> >>>
> >>> According to the section of the manual under the SP command, if the Mag
> >>> Offset is at the end of it's range, you can change the frequency
> >>> synthesizer's parameters by querying the existing SP? settings, finding
> >> the
> >>> row in Appendix A which corresponds to those values, then changing the
> SP
> >>> value up or down a step (by using the values in the table row just
> above
> >> or
> >>> below the value).
> >>>
> >>> In my unit, the SP value set (6114,3436,29) were not anywhere to be
> found
> >>> in Appendix A.
> >>>
> >>> After some digging, and reading the manual, I discovered that these
> >> values
> >>> are used to configure the  MC145193 inside the PRS-10.   Specifically
> the
> >>> first value (R) is used to divide the 10Mhz output.   The second two
> >> values
> >>> (N, A) are used to divide 359.72Mhz (which is related to the Rb
> >>> frequency).   This second divisor is calculated by (N*64+A).  The
> >> resulting
> >>> two divided down signals will be very close in frequency, and the
> >>> difference is used to stabilize the oscillator.
> >>>
> >>> After some more work, I discovered that the divisor values currently in
> >> my
> >>> oscillator were actually exactly 3 times the value of row 52, that is
> >>> 6114/3=2038 and (3436*64+29)/3=(2038*64+31).   Since it's only the
> ratio
> >>> between the divisors which matter, I'm assuming someone at some point
> >>> decided to use the higher division ratio for some reason.  Not sure if
> >> this
> >>> was at SRS or in the field.
> >>>
> >>> After discovering this, I followed the procedure to move the SP values
> by
> >>> one row in the table, and everything seems to have re-centered itself.
> >>>
> >>> Hope this helps someone...  Even if it's me in the future if I have to
> do
> >>> this again.
> >>>
> >>> --
> >>> - Forrest
> >>> _______________________________________________
> >>> time-nuts mailing list -- time-nuts at lists.febo.com
> >>> To unsubscribe, go to
> >> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> >>> and follow the instructions there.
> >>
> >>
> >> _______________________________________________
> >> time-nuts mailing list -- time-nuts at lists.febo.com
> >> To unsubscribe, go to
> >> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> >> and follow the instructions there.
> >>
> >
> >
> > --
> > - Forrest
> > _______________________________________________
> > time-nuts mailing list -- time-nuts at lists.febo.com
> > To unsubscribe, go to
> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> > and follow the instructions there.
>
>
> _______________________________________________
> time-nuts mailing list -- time-nuts at lists.febo.com
> To unsubscribe, go to
> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.
>

-- 
- Forrest