Can the io signatur of the gnuradio blocks be dynamically updated?

Hi,

I know it may not be possible in the current gnuradio blocks framework,
but
I am still curious if it can be done.
When I write a signal processing block, the io signature could be
determined by some parameters. It is ok, if these parameters are fixed.
But
sometimes, especially in the adaptive system, I need to dynamically
update
these parameter, which result in the updating of io signature of the
blocks. I can make the io_signature to be independent with the dynamic
parameters, but it could be more convenient if the io signature can be
adapted. Of course, it is not easy, as the io signature change could
impact
the upstream and downstream.

Thanks,

Alex,
Dreams can come true just believe.

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.

On Thu, Oct 11, 2012 at 6:29 PM, Alex Z. [email protected]
wrote:

adapted. Of course, it is not easy, as the io signature change could impact
the upstream and downstream.

Thanks,

Alex,
Dreams can come true just believe.

Alex,
Dreams can come true just believe.

On Thu, Oct 11, 2012 at 7:41 PM, Alex Z. [email protected]
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.

Tom

On 12 Oct 2012 11:12, Tom R. wrote:

On Thu, Oct 11, 2012 at
7:41 PM, Alex Z. [email protected] 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.

On Fri, Oct 12, 2012 at 11:16:44AM -0400, [email protected] wrote:

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.

These blocks never change the io-signature–not in a GNU Radio sense,
nor in a DSP sense. They always take 1 sample and output 1 sample. They
do mess around with the history, I believe. This is something very
different than dynamically changing the input vector length.

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-43790
Fax: +49 721 608-46071
www.cel.kit.edu

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

On Fri, Oct 12, 2012 at 10:16 AM, [email protected] wrote:

buffers into the block that you’re removing.

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.

Alex,
Dreams can come true just believe.

Hi Tom, thanks for the response, but I am still have questions regarding
your comments as below inline:

On Fri, Oct 12, 2012 at 10:12 AM, Tom R. [email protected]id wrote:

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.

It seems that the event stream scheduler can only handle finite options
for
selection?
This is different with what I am expecting. Sometimes, you don’t know
the
actual options and the dynamic parameters is computed based on some
other
optimization algorithm. Thus I can not pre-configure finite graphs for
my
selection, but just adjust the exiting graph with specified parameter.

BTW, maybe my expectation is kind of over-design which brings more risk
than benefits. But from the Software defined radio perspective, the
dynamic/adaptive signal processing chain with expecting flexibility
really
deserves more attention.

When I write a signal processing block, the io signature could be
upstream

https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Alex,
Dreams can come true just believe.

Hi Tom,

There is the other thing I need to confirm:
It looks that the block’s output buffer size can not be changed after
its
construction, right?

On Fri, Oct 12, 2012 at 10:12 AM, Tom R. [email protected] wrote:

buffers into the block that you’re removing.

sometimes, especially in the adaptive system, I need to dynamically
Thanks,

Alex,
Dreams can come true just believe.


Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Alex,
Dreams can come true just believe.

On Fri, Oct 12, 2012 at 5:57 PM, Alex Z. [email protected]
wrote:

Hi Tom,

There is the other thing I need to confirm:
It looks that the block’s output buffer size can not be changed after its
construction, right?

On the latest git master/next, you can change the buffer size once
before you run the flowgraph. The buffers are actually created when
you call top_block.start(), and we’ve put in a call to the gr_blocks
that allows you to set the maximum buffer size. But you cannot change
it afterwards, even when you lock/unlock (you’d have to delete the old
block and create a new one).

The allocation of gr_buffer space is a very costly operation. You
really, really don’t want to be adjusting this during runtime.

Tom

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs