[Top][All Lists]

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

Re: [Discuss-gnuradio] How to synchronize feedback between blocks?

From: Matt Ettus
Subject: Re: [Discuss-gnuradio] How to synchronize feedback between blocks?
Date: Thu, 29 Apr 2010 09:07:27 -0700
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4

On 04/29/2010 08:23 AM, Martin Braun wrote:
On Thu, Apr 29, 2010 at 12:00:33PM +0200, Martin Braun 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

Imagine the following setup:
(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.


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.


reply via email to

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