discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] Failure of sending square wave over USRPs (back-t


From: Marcus D. Leech
Subject: Re: [Discuss-gnuradio] Failure of sending square wave over USRPs (back-to-back)
Date: Fri, 14 Mar 2014 23:14:09 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

On 03/14/2014 10:51 PM, Activecat wrote:
Dear Martin,

On Fri, Mar 14, 2014 at 5:13 PM, Martin Braun <address@hidden> wrote:
Here's a very brief explanation: The PLL for the synthesizer makes sure the
locally generated frequency is stable (per-device). It's physically
impossible to make perfectly aligned oscillators. By throwing money at the
problem, you can reduce the potential offset. But since you can never get
rid of it entirely, you also need a mechanism (e.g. a PLL) to lock on the
incoming signal.
At the receiver side, the received signal is first processed by SBX
daughtercard before being sent it to the host (which is the PC).
The IQ demodulation is performed at the receiving SBX, not at the host.
In this case the clocking of SBX must be synchronized to the received
IQ-modulated signal.
Hence the PLL must be done precisely in the SBX, not in the host, correct?

If the PLL is done at the gnuradio flow graph, then this flow graph
must be able to adjust the local oscillator of the SBX daughtercard,
via softare. Does gnuradio flow graph have this capability?

Regards,
Activecat

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
The SBX does analog downconversion, nothing more. It knows nothing about the incoming signal, and doesn't demodulate it in any way.

That is what SDR is all about--the signals are represented as complex-baseband (i/Q) format for processing by computer algorithms.

The SBX (or any other daughtercard) is simply doing downconversion (or, upconversion for TX).

Frequency offset in a digital demodulator implemented in software generally drives a local correction--not the hardware. You achieve this by bringing in a bit more bandwidth than you actually need, and then applying frequency corrections in software.





reply via email to

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