Hi,
I’m using stream tags to time tag my data. In particular, I’m reading
in one-second files and tagging the first sample read in with the time.
I’m concerned with how the tag will be handled during decimation,
filtering etc. I have read the documentation and understand that the
tag is reassigned based on the relative_rate. For this particular data
set though, it is important that the tags stay with the specific samples
to which they were assigned, even if some of the tags are lost during
decimation, filtering, etc.
From: discuss-gnuradio-bounces+sean.nowlan=removed_email_address@domain.invalid
[mailto:discuss-gnuradio-bounces+sean.nowlan=removed_email_address@domain.invalid] On
Behalf Of Jenny Galasso
Sent: Friday, October 25, 2013 3:06 PM
To: [email protected]
Subject: [Discuss-gnuradio] stream tag samples
Today at 1:02 PM
Hi,
I’m using stream tags to time tag my data. In particular, I’m reading in
one-second files and tagging the first sample read in with the time. I’m
concerned with how the tag will be handled during decimation, filtering
etc. I have read the documentation and understand that the tag is
reassigned based on the relative_rate. For this particular data set
though, it is important that the tags stay with the specific samples to
which they were assigned, even if some of the tags are lost during
decimation, filtering, etc.
Is this even possible? Are there any recommendations or tricks to get it
to behave this way?
Thanks!
Jenny
Hi Jenny,
If you decimate by N, you’re getting rid of N-1 out of every N samples.
So naturally you would want the tag to stick with the sample that
doesn’t get thrown out. Similarly, if you interpolate by M, you
introduce M-1 samples into the stream for every input sample; you’d
naturally want the tag associated with input sample /i/ to be placed on
the first sample of the corresponding batch of M output samples. The
propagate_tags method in gnuradio/gnuradio-runtime/lib/block_executor.cc
handles this by default. You can override this behavior in your own
blocks by calling “set_tag_propagation_policy(TPP_DONT)” in your block’s
constructor and then handling tags yourself in your work method.
Sean
From: discuss-gnuradio-bounces+sean.nowlan=removed_email_address@domain.invalid
[mailto:discuss-gnuradio-bounces+sean.nowlan=removed_email_address@domain.invalid] On
Behalf Of Nowlan, Sean
Sent: Friday, October 25, 2013 3:23 PM
To: Jenny Galasso; [email protected]
Subject: Re: [Discuss-gnuradio] stream tag samples
From:
discuss-gnuradio-bounces+sean.nowlan=removed_email_address@domain.invalidmailto:discuss-gnuradio-bounces+sean.nowlan=removed_email_address@domain.invalid
[mailto:discuss-gnuradio-bounces+sean.nowlan=removed_email_address@domain.invalid] On
Behalf Of Jenny Galasso
Sent: Friday, October 25, 2013 3:06 PM
To: [email protected]mailto:[email protected]
Subject: [Discuss-gnuradio] stream tag samples
Today at 1:02 PM
Hi,
I’m using stream tags to time tag my data. In particular, I’m reading in
one-second files and tagging the first sample read in with the time. I’m
concerned with how the tag will be handled during decimation, filtering
etc. I have read the documentation and understand that the tag is
reassigned based on the relative_rate. For this particular data set
though, it is important that the tags stay with the specific samples to
which they were assigned, even if some of the tags are lost during
decimation, filtering, etc.
Is this even possible? Are there any recommendations or tricks to get it
to behave this way?
Thanks!
Jenny
Hi Jenny,
If you decimate by N, you’re getting rid of N-1 out of every N samples.
So naturally you would want the tag to stick with the sample that
doesn’t get thrown out. Similarly, if you interpolate by M, you
introduce M-1 samples into the stream for every input sample; you’d
naturally want the tag associated with input sample /i/ to be placed on
the first sample of the corresponding batch of M output samples. The
propagate_tags method in gnuradio/gnuradio-runtime/lib/block_executor.cc
handles this by default. You can override this behavior in your own
blocks by calling “set_tag_propagation_policy(TPP_DONT)” in your block’s
constructor and then handling tags yourself in your work method.
Sean
I don’t think there’s a way to tell GNU Radio blocks derived from
sync_decimator and sync_interpolator to quit propagating tags as
described above (unless you write blocks that inherit from these classes
yourself). It’s the only way that really makes sense when changing rate
domains by a rational factor.
Sean