Re: [Discuss-gnuradio] Examples of Python code using 'current_tags' function for Tag Debug block

[Marcus D. Leech]

On 09/03/2019 09:08 PM, Vasil Velichkov wrote:
> Hi Marcus,
>
> On 03/09/2019 08.21, Marcus D. Leech wrote:
> > The subject pretty-much says it all.
> >
> > I'm looking for a Python example of code that uses the 'current_tags' function 
> > for the Tag Debug block, and picks apart the resulting tag(s).
> See:
> https://github.com/gnuradio/gnuradio/blob/822aedb5b8934549a10b70dc602a178f9765eef0/gr-blocks/python/blocks/qa_file_metadata.py#L103-L119
> https://github.com/gnuradio/gnuradio/blob/822aedb5b8934549a10b70dc602a178f9765eef0/gr-blocks/python/blocks/qa_burst_tagger.py#L42-L57
> https://github.com/gnuradio/gnuradio/blob/822aedb5b8934549a10b70dc602a178f9765eef0/gr-digital/python/digital/qa_correlate_access_code_tag.py#L54-L60
>
> > In Python land are the tags just a tuple/list or a dictionary?  I've snarfled 
> > through the generated SWIG code, and can't seem to decipher it.
> >
> > I'd expect perhaps a tuple:
> >
> > (offset, tag, value, srcid)
> >
> > With "tag", "value" and "srcid" all being PMTs.
> It's not a tuple or list but some swig object
>
> (<gnuradio.gr.runtime_swig.tag_t; proxy of <Swig Object of type 'gr::tag_t *' at 
> 0x7fb5ed6883c0> >, <gnuradio.gr.runtime_swig.tag_t; proxy of <Swig Object of type 
> 'gr::tag_t *' at 0x7fb5ed6884e0> >)
>
> Hope this helps.
>
> Cheers,
> Vasil
So, did some experimenting.  Turns out that the "current_tags()" 
function on a tag_debug block is next-to-useless, since d_tags is reset to
  empty on every call to the work function. So the probability that 
some random call to current_tags() will actually intercept d_tags with
  anything in it is nearly zero.