[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Carrier offset on DBSRX.

From: Trond Danielsen
Subject: Re: [Discuss-gnuradio] Carrier offset on DBSRX.
Date: Tue, 27 Mar 2007 21:40:38 +0200

2007/3/27, Eric Blossom <address@hidden>:
On Tue, Mar 27, 2007 at 10:36:05AM +0200, Trond Danielsen wrote:
> 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 Danielsen

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.

Trond Danielsen

reply via email to

[Prev in Thread] Current Thread [Next in Thread]