To all concerned parties:
I think I've discovered the problem. My "tune" routine chose the R and N
dividers to minimize the difference between the command and desired LO
frequencies. For L1 this ended up being 64 and 25197. The refclk was set
at 4 MHz, producing an R divider frequency of 62500 Hz. For a sanity
check I enabled the debug output of the Max2118 chip, in order to probe
the comparison frequency on the CNTOUT pin. Probing the pin produced a
nice square wave at 31250 Hz. The inconsistency bothered me, and I
double checked my driver was writing the correct values to the Max2118
registers, it checked out as ok. On a lark I decided to sacrifice the LO
error for a greater comparator frequency. After changing the R value to
8 and N to 3150 I recorded some new data and crunched it with my
software receiver. To my amazement the phase jitter went away. So, two
questions:
1) Why the inconsistency with the R divider debug output on the CNTOUT
pin? An R divider value of 8 produced a square wave at 250 kHz, again 2X
lower than the values of R and reclk should produce. I am positive the
value being written to the register complies with the spec sheet (R =
2*2^(R_register))
2) The Max2118 spec sheet quotes an XTAL input from 4 to 27 MHz.
Obviously the low comparison frequency was effecting the stability of
the PLL in the Max2118, why did the Python DB-SRX driver default the
refclk divide to 16, placing the refclk at 4 MHz, rather than placing
the refclk frequency towards the middle (16 MHz) of the spec? Was this
done for some other technical reason?
I will try to quantify the C/N0 loss tomorrow. Additionally, I'd like to
thank everyone very much for the help that has been given to date.
-Greg Heckler
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
