[Top][All Lists]

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

Re: [Discuss-gnuradio] feedback loop for bpsk carrier recovery ?

From: Tom Rondeau
Subject: Re: [Discuss-gnuradio] feedback loop for bpsk carrier recovery ?
Date: Thu, 23 Oct 2014 09:50:40 -0400

On Thu, Oct 23, 2014 at 6:54 AM, <address@hidden> wrote:
For educational purposes, I am investigating a carrier recovery scheme for BPSK demodulation.
I have synthesized a BPSK modulated signal, assembled a hardware carrier recovery scheme which
works well (squaring the modulated signal, bandpass filtering and dividing, aka Costas loop) which
I now want to implement as SDR in GNURadio. To do so, I acquire the BPSK modulated signal, extract
the carrier by squaring the I/Q data flow and bandpass filtering, all this work fine. Before squaring
the signal, I insert a Xlating FIR filter whose NCO frequency will act as the tunable VCO in the
hardware version of the carrier tracking circuit.

Question: how can I feedback the output of the lowpass filter (ie error signal of the PLL) to the
NCO of the Xlating FIR Filter ?

(I have found, following http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorial_PSK_Demodulation
the Costas loop block which works very well with my real signal, but I'd like to implement it
manually -- or can't gnuradio-companion close a feedback loop ?)

Additional question: since gnuradio-companion 3.7.5 I see a grey "freq" tab in the Xlating FIR
filter block, but cannot find any associated documentation or what the use of this input is. Is
this the functionality I am looking for ?

Thank you, JM

JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe, 25000 Besancon, France

GNU Radio cannot do loops in the flowgraph. Because it passes hundreds to thousands of samples at a time between blocks -- necessary to reduce scheduler overhead and context switching -- it doesn't make any signal processing sense. There's a paper that I'd have to dig up that shows you what happens to a control loop when you're decisions are more than 1 sample away. Spoiler: it's not good. So while it's possible to structure the process graph such that loops are allowed, it complicates things for something that's unworkable mathematically. For loops like this, we do so inside of a block, which can do feedback and all of that.

Instead, the freq xlating block takes in a message that can reset the frequency. That's what that grey tab is in GRC, a message port. You can make a decision elsewhere in the graph and then post a message to that block to change the frequency. Note that this is done asynchronously. So again, you won't use this to control the frequency on a sample-by-sample basis. You'd have to rethink your algorithm for frequency adaptation than the traditional Costas loop concept.

Here's the documentation for the frequency xlating filter. The details explain the format of the 'freq' message input port:


reply via email to

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