discuss-gnuradio
[Top][All Lists]
Advanced

[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: Tom Rondeau
Subject: Re: [Discuss-gnuradio] Can the io signatur of the gnuradio blocks be dynamically updated?
Date: Mon, 15 Oct 2012 10:34:52 -0400

On Fri, Oct 12, 2012 at 5:57 PM, Alex Zhang <address@hidden> 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


> On Fri, Oct 12, 2012 at 10:12 AM, Tom Rondeau <address@hidden> 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.
>>
>> Tom
>>
>>
>> > On Thu, Oct 11, 2012 at 6:29 PM, Alex Zhang <address@hidden>
>> > wrote:
>> >>
>> >> 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.
>> >>
>> >
>> >
>> >
>> > --
>> >
>> > Alex,
>> > Dreams can come true – just believe.
>> >
>> >
>> > _______________________________________________
>> > Discuss-gnuradio mailing list
>> > address@hidden
>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> >
>
>
>
>
> --
>
> Alex,
> Dreams can come true – just believe.
>



reply via email to

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