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.
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
