How to synchronize feedback between blocks?

GNU Radio
1

Hi all,

I’m struggling with what I hope isn’t a naive problem regarding feedback
between flowgraph blocks. I’ve written a simple frequency estimator for
FSK signals based on the squared FFT method. Its input is an N-point
FFT, created by an N-item stream-to-vector block feeding an N-bin FFT
block. The output of the frequency estimator is a float value in Hz, and
it is a sync_block. Therefore, the output produces samples at the
original (pre-stream-to-vector) sample rate divided by N. So if my
original raw sample rate is 50000, and I use a 4096-bin FFT, the output
frequency estimate arrives at ~12.2 samples per second. That’s fine.

The problem is that I want to use the output of the frequency estimator
to center the input data at baseband. With continuous streaming data,
this is easy – just use a frequency-xlating filter, and call
set_center_freq() when data comes in from the frequency estimator.
However, the packets I’m interested in are short, and I’d like the
frequency correction to be applied at or near the start of the packet so
the preamble can be detected appropriately. In order to do this, I have
to be able to determine the delay it takes for feedback to come back,
and that delay has to be constant. For this reason, I can’t use a
frequency-xlating filter, because the delay in calling set_center_freq()
from the main Python loop could take any amount of time. I could write a
version of the frequency-xlating filter that accepted a second stream of
filter offset data at the input sample rate – my thinking is that would
make the delay a fixed number of samples. Is that assumption valid?

Before I go reinventing the wheel, I’m wondering if there is a “usual”
way of solving this feedback problem within the architecture of GNU
Radio, or if I’m totally out in left field.

Thanks for any feedback (no pun intended),
Nick

Hotmail has tools for the New Busy. Search, chat and e-mail from your
inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_1

2

On Wed, Apr 28, 2010 at 11:29:16PM +0000, Nick F. wrote:

I’m struggling with what I hope isn’t a naive problem regarding feedback between flowgraph blocks. I’ve written a simple frequency estimator for FSK signals based on the squared FFT method. Its input is an N-point FFT, created by an N-item stream-to-vector block feeding an N-bin FFT block. The output of the frequency estimator is a float value in Hz, and it is a sync_block. Therefore, the output produces samples at the original (pre-stream-to-vector) sample rate divided by N. So if my original raw sample rate is 50000, and I use a 4096-bin FFT, the output frequency estimate arrives at ~12.2 samples per second. That’s fine.

The problem is that I want to use the output of the frequency estimator to center the input data at baseband. With continuous streaming data, this is easy – just use a frequency-xlating filter, and call set_center_freq() when data comes in from the frequency estimator. However, the packets I’m interested in are short, and I’d like the frequency correction to be applied at or near the start of the packet so the preamble can be detected appropriately. In order to do this, I have to be able to determine the delay it takes for feedback to come back, and that delay has to be constant. For this reason, I can’t use a frequency-xlating filter, because the delay in calling set_center_freq() from the main Python loop could take any amount of time. I could write a version of the frequency-xlating filter that accepted a second stream of filter offset data at the input sample rate – my thinking is that would make the delay a fixed number of samples. Is that assumption valid?

Before I go reinventing the wheel, I’m wondering if there is a “usual” way of solving this feedback problem within the architecture of GNU Radio, or if I’m totally out in left field.

Hi Nick,

I recommend tracing the flow graph of the OFDM system. That helped me a
lot understanding how to do synchronisation in GNU Radio.

However, I think there’s no direct way to feed back data between blocks.
You need to create a feed-forward structure, i.e. have a synchronisation
block near the beginning that outputs the frequency offset to your
frequency correction.

g
mb

–
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin B.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-3790
Fax: +49 721 608-6071
www.cel.kit.edu

KIT – University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association

3

On 04/29/2010 08:23 AM, Martin B. wrote:

Imagine the following setup:
http://img338.imageshack.us/img338/6418/diffequation.png
(for those who don’t want to follow the link: I connect a noise source
to two connected delays such that they form the difference equation

y(n) = x(n) + x(n-2)

This is easy and already supported in GNU Radio, since it is not
feedback. Perhaps you meant:

y(n) = x(n) + y(n-1)

Which would be feedback, and is not currently supported. You can, of
course, do it within a block, like our IIR filter blocks.

My question is: can GNU Radio be modified to accept this? It’s a
perfectly valid flow graph (similar to ones you find in DSP textbooks),
and thanks to the history of the delays, one that should work. I’d be
very interested to hear some comments on this.

Cheers
MB

Assuming you meant the feedback version I mentioned above, the current
GNU Radio scheduler does not allow this. The changes to support it
would be significant, but not impossible. Eric would be better
positioned to explain it, but here is my take on it.

First, you would need to be able to communicate the amount of delay to
the scheduler, so it could insert leading zeros for time when it does
not have feedback values. This is because the adder would not have its
own previous output in order to produce its first input.

Second, you would need to check for deadlock. If you were to put
variable rate blocks in the loop, you could end up with deadlock.

Third, blocks in GNU Radio usually take large blocks of input and
produce large blocks of output. If you were to do your block like
above, you could only produce 1 output per call, which would result in
very high overhead and poor performance.

Matt

4

Hi Martin -

On Apr 29, 2010, at 9:23 AM, Martin B. wrote:

y(n) = x(n) + x(n-2)

My question is: can GNU Radio be modified to accept this? It’s a
perfectly valid flow graph (similar to ones you find in DSP
textbooks),
and thanks to the history of the delays, one that should work. I’d be
very interested to hear some comments on this.

Shortest Answer: Yes, this could be done – GNU Radio is open
source :). Go for it! I think you’ll find that it’s not trivial to
implement. Further: If you look at the radio of computation time
versus overhead time (one version of “computational intensity”) of any
such loops – when implemented in a data-flow block fashion such as
what GNU Radio does (and, all SDRs that I know of) – it will be very
low compared with writing a specific block that internally handles the
feedback. So, low efficiency but allowing for feedback, or high
efficiency but no feedback … hmm … seems obvious which to choose
at least for the initial implementation. Maybe some future
implementation will deal with feedback loops in some special way.
Hope this helps! - MLD

5

Thanks Matt, and Michael, for your input.

To clarify: I was thinking about a frequency offset detection at a later
stage in the demodulation process, which feeds back the frequency offset
to an initial xlating FIR filter (I do realise feeding back individual
samples is kind of ridiculous from a scheduling POV).

Another question: will the message interface be able to send messages
“backwards” in the flow graph?

Thanks
MB

On Thu, Apr 29, 2010 at 09:07:27AM -0700, Matt E. wrote:

current GNU Radio scheduler does not allow this. The changes to

Third, blocks in GNU Radio usually take large blocks of input and
produce large blocks of output. If you were to do your block like
above, you could only produce 1 output per call, which would result
in very high overhead and poor performance.

–
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin B.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-3790
Fax: +49 721 608-6071
www.cel.kit.edu

KIT – University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association

6

On Thu, Apr 29, 2010 at 12:00:33PM +0200, Martin B. wrote:

However, I think there’s no direct way to feed back data between blocks.
You need to create a feed-forward structure, i.e. have a synchronisation
block near the beginning that outputs the frequency offset to your
frequency correction.

This has been bugging me for a while now, and since I sent that email, I
just can’t get it out of my head (sorry, Nick, for hijacking this
thread).

Imagine the following setup:
http://img338.imageshack.us/img338/6418/diffequation.png
(for those who don’t want to follow the link: I connect a noise source
to two connected delays such that they form the difference equation

y(n) = x(n) + x(n-2)

My question is: can GNU Radio be modified to accept this? It’s a
perfectly valid flow graph (similar to ones you find in DSP textbooks),
and thanks to the history of the delays, one that should work. I’d be
very interested to hear some comments on this.

Cheers
MB

–
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin B.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-3790
Fax: +49 721 608-6071
www.cel.kit.edu

KIT – University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association