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.
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.
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.
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.
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.
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)
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.
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
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.