Re: [time-nuts] PRS-10 Missing SP values in Appendix A.
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 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) < > li...@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 wrote: > > > >> Hi > >> > >> Ummm ….. e …… > >> > >> 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
Re: [time-nuts] PRS-10 Missing SP values in Appendix A.
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) > 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 wrote: > >> Hi >> >> Ummm ….. e …… >> >> 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) < >> li...@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 i
Re: [time-nuts] PRS-10 Missing SP values in Appendix A.
Hi In a normal PLL the discrete components on the PCB play a big factor in how the loop behaves. There are some chips that allow the current out of the detector to be varied a bit, even on those the discrete R’s and C’s are still the “big deal” in how the loop behaves. There will be a significant impact if the loop output is 1/3 of what the design was intended to use. In general, that impact will not be a good one. Bob > On Sep 13, 2019, at 7:01 PM, Forrest Christian (List Account) > 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 wrote: > >> Hi >> >> Ummm ….. e …… >> >> 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) < >> li...@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 as
Re: [time-nuts] PRS-10 Missing SP values in Appendix A.
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 wrote: > Hi > > Ummm ….. e …… > > 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) < > li...@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@lists.febo.com > > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
Re: [time-nuts] PRS-10 Missing SP values in Appendix A.
Hi Christian, Good catch! If the values is scaled up by a factor of three, the phase comparator frequency is divided by three. This may or may not be much of an issue, depending on where on the range one is. Too low comparator frequency is known to cause an issue thought, but once it is sufficiently high, other factors tend to dominate on what is the wise choice. Thanks for reminding me that I need to tinker around with my PRS-10s. :) Cheers, Magnus On 2019-09-13 08:12, Forrest Christian (List Account) 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. > ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] PRS-10 Missing SP values in Appendix A.
Hi Ummm ….. e …… 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) > 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@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@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] PRS-10 Missing SP values in Appendix A.
Thanks Forrest, I've added this to my documentation packed for my own PRS-10; I suspect that I'm only a year or two from (possibly) needing it myself. Dana On Fri, Sep 13, 2019 at 3:00 AM Forrest Christian (List Account) < li...@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@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@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] PRS-10 Missing SP values in Appendix A.
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@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
