Re: [Discuss-gnuradio] Stream to PDU - Guaranteed to not lump tags?

[Michael Dickens]

Hi Dave - The tagged stream -> PDU block will generate exactly 1 PDU per call to work. In your example, it is possible that all 3 of the PDUs will end up being in the stream, but, because of the way "tagged_stream_block" works, work() will be called with "ninput_items[0]" being just the value entered for the tag representing any given PDU length, no more or less.

This stated, it is possible to end up with multiple same-named tag offset values in the stream on the same item; I've seen this recently. There are also sometimes other tags within range on the stream. All of the tags that aren't removed as the provided length key will be added to the PDU as meta-data. This might be the source of your "multiple offset values" comment.

Hope this helps! - MLD

On Wed, Jan 10, 2018, at 8:32 PM, Dave NotTelling wrote:

     Thanks for the response!  Apologies for the unclear question.  Here's another shot:

Can one call to the work function yield multiple offsets from the `get_tags_in_range(0, nitems_read(0), nitems_read(0) + noutput_items)` call?  With multiple offsets then that means there are multiple sets of PDUs (assuming that the stream was created from pdu_to_tagged_stream).  Let's say for fun that there are 3 PDUs like the following (CAR, CDR):

• ( {'pdu_len': 10, 'offset': 0, 'frame' : 1}, (0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00) )
  
• ( {'pdu_len': 10, 'offset': 10, 'frame' : 2}, (0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00) )
  
• ( {'pdu_len': 10, 'offset': 11, 'frame' : 3}, (0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00) )
  

What I'm curious about is whether or not a single call to work() will end up with tags for more than one of the PDUs above.  For instance, if the buffer for the block is large enough, would 20 samples get lumped in to a single call to work() resulting in say offset 0 and offset 10 both showing up in 'get_tags_in_range(0, nitems_read(0), nitems_read(0) + noutput_items)'?  This of course assumes that pdu_to_tagged_stream and tagged_stream_to_pdu both are set to use 'pdu_len' as the length tag.

     I seem to remember having that very issue once.  I got multiple offset values in a work() function in the past.  Pretty sure I did at least O.o  Really, just curious if there is a guarantee somewhere deeper in the block code that ensures that can't happen. 

     As I write this I realize that this is a pretty easy thing to test out.  If it's still unclear, then I'll just do that and post results :)