discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: Fan In of tagged and un-tagged stream.


From: Jeff Long
Subject: Re: Fan In of tagged and un-tagged stream.
Date: Fri, 20 Nov 2020 10:30:48 -0500

[back on mailing list]

Ha, I don't think any question regarding tagging and filtering counts as "simplistic"! Good luck.

On Fri, Nov 20, 2020 at 10:04 AM Nicholas Long <nicholaslong94@gmail.com> wrote:
Yes, what you described in the first section is what I am planning, 

Looking at it more, my main concern was ensuring that the full data block of taps was on the output block at of whatever is feeding the tapped input to my OOT module, though I am realizing now that that is a problem for the output block, and can be easily solved by putting a check on the tap generator block like is in tagged_stream_block.cc and use set_min_noutput_items.

Thanks for the quick response, and sorry for the simplistic question.
Have a great day.



On Fri, Nov 20, 2020 at 8:22 AM Jeff Long <willcode4@gmail.com> wrote:
If the taps need to be changed exactly at the tag, then I think you'll have to make your own version of the filter block you're using, adding handling for a "set_taps" tag. None of the filter blocks pay any attention to tags and a call to set_taps() would take effect "approximately" when you mean it to.

If the taps need to change at approximately the time of the tag, then you could just either (1) forget about tags and drive the changes from your Python program, or (2) make a block (e.g., Python Embedded) that just looks for tags in the stream and calls set_taps() on your filter.

On Fri, Nov 20, 2020 at 8:38 AM Nicholas Long <nicholaslong94@gmail.com> wrote:
Hi, I am looking for comments/thoughts/advice on how to combine (fan in) untagged and tagged streams.

Basically my goal is to make a sample synchronous filter with adjustable taps, where the data to be filtered is a untagged stream that periodically has a tag flag saying "update taps" when this flag is seen the block will look at the other input (tagged) and use the next pdu block there as the taps for the newly configured filter. I do not want to define the filter length before runtime, and that as the number of filter taps can change between update calls. Also because there is no packet type structure It does not make sense for the data stream to be tagged (though that is my current fallback plan).

Thanks,
Nick

reply via email to

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