Gregory W Heckler wrote:
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))
It is a long time ago that I developed this code, but I seem to recall
seeing the same discrepancy at the time. The center frequency comes out
right, though.
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?
The maximum compare frequency of the DBSRX PLL is 2 MHz, and the minimum
divide ratio is 2. So no matter what we put in for the reference, it
will have to be divided down to 2 MHz or lower. However, if we do as
much of the divide as possible in the FPGA, we can give a phase-matched
signal to 2 DBSRX boards on the same USRP. This is useful in phased arrays.
For example, if we give 2 DBSRXs the same 16 MHz reference, and they
each have to divide by 8, then there is an 8-way phase ambiguity between
them. However, if we give them a matched 4 MHz reference and they both
divide by 2, then there is only a 2-way phase ambiguity, which is much
easier to resolve.
If you aren't doing phased arrays, this doesn't matter.
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.
Thanks for posting your data.
Matt
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
