Hi,
I have a problem with my DBSRX daughterboard. I tried to send in a
single carrier on 1.57542 GHz and watch it with usrp_fft.py, and I
observe that the received signal is offset by many KHz. This really
does not come as a big surprise, since ack. to the usrp_fft.py GUI the
actual BB frequency is 1.5755 GHz. Is it not possible to tune the
DBSRX to 1.57542 GHz? BTW: How is the C++ version of the dbsrx driver
coming along? Does it contain any improvements over the python
version?
–
Trond D.
Trond:
Tuning the down-converter on the DBS-RX card consists of programming the
values of 2 dividers. The R divider divides down the reference clock
frequency (4 MHz, which derives from the 64 MHz board clock). The N
divider divides down the LO frequency. The R divider has a range from 2
to 256, the N divider from 256 to 32768. The Max2118 phase locks the
divide LO frequency to the divided reference clock frequency, or:
LO = N*(Refclk_Freq/R)
However, the PLL in the Max2118 is unstable if you divide down the
reference clock frequency to below 250 kHz, this effectively limits the
frequency resolution at which you can command the LO frequency.
Additionally, the error in the board clock at 64 MHz will produce a
frequency error in the LO frequency of tens of kHz at L1. I would
suggest passing a sine wave at 1.57542 GHz through the DBS-RX and USRP
(set the digital down-convert frequency to 0), and observing where the
frequency appears in the PSD of your samples. You can then use the
resulting frequency to command the digital down-convert stage of the
USRP to mix L1 precisely to baseband. I will formally submit the C++
driver after I get it commented out, if you want the version I have
working now I can forward it to you.
Greg Heckler
2007/3/27, Gregory W Heckler [email protected]:
driver after I get it commented out, if you want the version I have
working now I can forward it to you.
Greg Heckler
Thank you very much for your explanation! Unfortunately the appnote
that describes how to set the frequency of the dbsrx is only available
on demand from Maxim, and the python driver contains only magic number
for someone who does not have access to this. Would it be possible to
add this information to the wiki?
I would very much like to test you C++ driver.
–
Trond D.
On Tue, Mar 27, 2007 at 10:36:05AM +0200, Trond D. wrote:
–
Trond D.
Trond, I would venture that the offset of a many KHz is not because of
anything having to do with the reported BB frequency, but rather
because of the offset between the Tx and Rx clocks.
They are spec’d at 50 ppm. At 1.5 GHz each clock could be off by
75kHz and they’d still be within spec.
Also, I think you may be worrying about the wrong thing, when you see
the baseband frequency reported. On both the Tx and Rx paths, tuning
is a two step processes. Part of it is handled on the daughterboard,
and part of it is handled with a DDC or DUC. The value reported in
usrp_fft.py is the frequency that the front end is tuned to. The DDC
is programmed such that the frequency you asked for is actually at DC
in the complex baseband signal (post DDC).
Did this help?
Eric
On Tue, Mar 27, 2007 at 09:40:38PM +0200, Trond D. wrote:
coming along? Does it contain any improvements over the python
The input signal is generated by a Spirent GPS simulator, not by the
USRP, so the carrier should be very stable.
Yes, but there’s still the clock on the USRP.
500kHz
500 kHz seems excessive. Can you post a link to a screen shot?
Eric
2007/3/27, Eric B. [email protected]:
version?
–
Trond D.
Trond, I would venture that the offset of a many KHz is not because of
anything having to do with the reported BB frequency, but rather
because of the offset between the Tx and Rx clocks.
They are spec’d at 50 ppm. At 1.5 GHz each clock could be off by
75kHz and they’d still be within spec.
The input signal is generated by a Spirent GPS simulator, not by the
USRP, so the carrier should be very stable.
Also, I think you may be worrying about the wrong thing, when you see
the baseband frequency reported. On both the Tx and Rx paths, tuning
is a two step processes. Part of it is handled on the daughterboard,
and part of it is handled with a DDC or DUC. The value reported in
usrp_fft.py is the frequency that the front end is tuned to. The DDC
is programmed such that the frequency you asked for is actually at DC
in the complex baseband signal (post DDC).
Okay, I think I understand. But still, when inspecting the signal with
ursp_fft.py, the signal is not at baseband, but offset by approx.
500kHz
–
Trond D.
Trond D. wrote:
Okay, I think I understand. But still, when inspecting the signal with
ursp_fft.py, the signal is not at baseband, but offset by approx.
500kHz
KD7LMO’s setup seems to bring L1 down to approx. -4kHz. At least the
signals I acquire are centered about -4kHz.
Chris
Trond D. wrote:
Okay, I think I understand. But still, when inspecting the signal with
ursp_fft.py, the signal is not at baseband, but offset by approx.
500kHz
I use the DBS_RX for radio astronomy, and I use a narrowband calibration
signal (not from a precision source, but
within a few Khz). That signal shows up in my FFT display within a
few Khz of where it should be. I never
see any errors as large as 500Khz, that’s for sure, and I’ve used 3
different DBS_RX boards over the last couple
of years.
Also, 21cm emissions from the galactic plane are usually within 200Khz
of 1420.4058Mhz, and that’s where they
show up, so I’m reluctant to believe that in general observed
frequencies can be off by as much as 500Khz.
Something else is wrong.
2007/3/27, Eric B. [email protected]:
Okay, I think I understand. But still, when inspecting the signal with
ursp_fft.py, the signal is not at baseband, but offset by approx.
500kHz
500 kHz seems excessive. Can you post a link to a screen shot?
I am not at the lab atm, but I’ll post a screenshot tomorrow when I
get back to the university (which is in about 10h).
Trond D.
2007/3/27, Trond D. [email protected]:
2007/3/27, Eric B. [email protected]:
Okay, I think I understand. But still, when inspecting the signal with
ursp_fft.py, the signal is not at baseband, but offset by approx.
500kHz
500 kHz seems excessive. Can you post a link to a screen shot?
I am not at the lab atm, but I’ll post a screenshot tomorrow when I
get back to the university (which is in about 10h).
Thank you all for your replies. I this case I think that the user is
the one to blame for the problem… Something must have been very
wrong yesterday, because today I get within 20kHz of the desired
frequency, which is good enough atm.
(http://trondd.blogspot.com/2007/03/gps-l1.html)
–
Trond D.