[Top][All Lists]

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

Re: [Discuss-gnuradio] Can the io signatur of the gnuradio blocks be dyn

From: Alex Zhang
Subject: Re: [Discuss-gnuradio] Can the io signatur of the gnuradio blocks be dynamically updated?
Date: Fri, 12 Oct 2012 10:31:23 -0500

On Fri, Oct 12, 2012 at 10:16 AM, <address@hidden> wrote:

On 12 Oct 2012 11:12, Tom Rondeau wrote:

On Thu, Oct 11, 2012 at 7:41 PM, Alex Zhang <address@hidden> wrote:
Let me take an example for my question. For some OFDM blocks, the io signature is determined by the fft length, during the constructing the block. However, sometimes, we need to adjust the the fft length dynamically based on some physical environment or computing environment.
Hi Alex,

I haven't thought about this too much, so my recollection of how
things work could be a bit off. But I'm pretty sure that the answer is
no, you cannot dynamically adjust this. You'd be messing too much with
the scheduler.

The way that you can do it is to lock the flowgraph, swap out the
block in question with a new block that has the new parameters, and
unlock to restart the graph. But you are going to lose samples in the
buffers into the block that you're removing.

This would actually be a great case for the event stream scheduler.
You could have different processing graphs that are selected based on
the state that you need. So you could populate graphs of different FFT
lengths and then dynamically select the right graph based on an event
when you detect a different length is required. This is still a
work-in-progress: https://github.com/osh/gr-eventstream.

So, my question is why this is any different than the existing cases of FFT and FIR filter blocks -- they have an I/O signature of a complex-stream, and internally they "do the right thing" when the filter length changes.  I don't immediately see why blocks that conceptually "change size" can't just do it internally just like the FFT and FIR filter cases.

Yes, in functionality, I can do it internally, with I/O signature independent of the adaptive parameters. I just want to discuss if the dynamic I/O signature  can be done and to provide the user with another user mode which looks cleaner. Because, we do have blocks that have I/O signature related with the physical parameters, I think it could be valuable to consider the corresponding benefit and challenges, if the physical parameters is dynamic while we still want to keep the good thing from the parameter based I/O signature.




Discuss-gnuradio mailing list


Dreams can come true – just believe.

reply via email to

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