Frequency offset of USRP

Hi all:
My task is to use the USRP to down convert the GPS L1 channel to
baseband signal.
I have some problems with the carrier offset of the DBS_RX
daughterboard.
When I set f_l0 of the DBS_RX daughterboard to be 1575.42e6 which is the
center frequency of GPS L1 signal, I found the real frequency in the
tune(double _freq) function was 1575.5e6. So there is 80000 hz offset. I
want to know what the output of DBSRX daughterboard is. What is the
effect of this offset to my input signal?

Next, I need to down convert the output signal of the daughterboard. Fox
example, I want to down convert it to 1.5M hz. Then, what should I do?
I think I should use this function:
usrp_standard_rx: set_rx_freq (int channel, double freq).

What is the input value of freq?

Any suggestions? Thanks a lot!

2008/3/30, Sl Peng [email protected]:

Next, I need to down convert the output signal of the daughterboard. Fox
example, I want to down convert it to 1.5M hz. Then, what should I do?
I think I should use this function:
usrp_standard_rx: set_rx_freq (int channel, double freq).

What is the input value of freq?

Any suggestions? Thanks a lot!

Hi,

I think you might find this thread from the mailing list archive
useful:
http://lists.gnu.org/archive/html/discuss-gnuradio/2007-04/msg00105.html

Trond D.

Thanks Trond!
I think this thread just tell me there should be a frequency offset, but
I did not find any answer about how do deal with this problem in this
thread.

2008/3/30, Sl Peng [email protected]:

Next, I need to down convert the output signal of the daughterboard. Fox
example, I want to down convert it to 1.5M hz. Then, what should I do?
I think I should use this function:
usrp_standard_rx: set_rx_freq (int channel, double freq).

What is the input value of freq?

Any suggestions? Thanks a lot!

Hi,

I think you might find this thread from the mailing list archive
useful:
http://lists.gnu.org/archive/html/discuss-gnuradio/2007-04/msg00105.html

Trond D.

2008/3/30, Sl Peng [email protected]:

Thanks Trond!
I think this thread just tell me there should be a frequency offset, but
I did not find any answer about how do deal with this problem in this
thread.

There are several ways to deal with this issue, but a simple solution
that I have used my self is to just increase the Doppler frequency
search range of your acquisition procedure.


Trond D.

But after you acquire, it is a simple matter to detect lock and then
gear shift to a narrower tracking loop.

Bob

Sl Peng wrote:

2008/3/30, Sl Peng [email protected]:

Trond D.


AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL,
TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair
“Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it.” - Brian W. Kernighan

Yes!
This method works for the acquisition, but does not work for the
tracking loop.
Because the chip rate is relevant to the Doppler shift frequency. So
how about your program? Can you suggest me some other ways to deal with
this issue?

Trond D. wrote:

2008/3/30, Sl Peng [email protected]:

Thanks Trond!
I think this thread just tell me there should be a frequency offset, but
I did not find any answer about how do deal with this problem in this
thread.

There are several ways to deal with this issue, but a simple solution
that I have used my self is to just increase the Doppler frequency
search range of your acquisition procedure.


Trond D.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs