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

[Bob kb8tq]

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.