Re: [Discuss-gnuradio] Reading carrier frequency

[Gnu Radio Explorer]

Thanks for the reply Eric. I am completely new to this field. I understand the receiver should be able to accomodate these differences. 

But is it possible for a GNU radio program running on the receiver computer to be able to read the changing values of the sender's carrier frequency, or is it just that the programs will only be able to read the values after the carrier frequency is converted to the intermediate frequency and not directly at carrier frequency?

Another question by the way. I am having a RFX 900 board. Suppose a transmitter program desires that the USRP should produce a signal with center frequency f1 = 925.123456 MHz, for example. But in reality will the USRP be able to transmit the signal at this exact frequency f1 (at the granularity of Hertz) by some way? 

Thanks in advance.

G

On Thu, Sep 11, 2008 at 8:02 AM, Eric Blossom <address@hidden> wrote:

On Wed, Sep 10, 2008 at 11:46:26PM -0600, Gnu Radio Explorer wrote:
> Hi,
> I am new to GNU radio and want to experiment. From the mailing lists, I
> understood that the carrier frequency offsets change over time but that
> those offsets are within +/- 20ppm of the center frequency. Suppose I use
> two USRP boards; one for transmission and another for reception of signals.
> I want to know how I can read the carrier frequency of  the transmitted
> signal on the receiver side through a python or C++ program. Is there any
> program to do this? Or, which library routine can I use for this purpose?
>
> Appreciate any kind of help you may provide on this.
>
> Thanks.
>
> G.

This is a FAQ that needs an answer.  Can someone please write
something up on carrier tracking and symbol timing recovery and post
it to the wiki?

Bottom line: there will always be a frequency offset between any two
radios and part of the receiver's job is to handle it.  There's a ton
of literature on this as well as complete text books.  In the simplest
case it's a PLL to track the carrier, but oftentimes it's more
complicated than that.

Eric