Hi Marcus and Jeff:
So now that I've got something working for correct tag propagation with
a static relative rate through one block, I'm ready to tackle some
other problems.
1. The runtime performing (or at least assisting) correct tag
propagation for blocks with a changing relative rate.
2. Precision tag propagation through multiple rate changing blocks
using fractional tag offsets. See the discussion at
https://lists.gnu.org/archive/html/discuss-gnuradio/2017-11/msg00089.html
for the gist of this one.
(If some thinks either of the above shouldn't be implemented, let me know.
I don't want to waste time on dead-ends.)
The conceptual solutions for these require API changes that are not
backward compatable. They can't be fixed on the master branch, and
they have to be fixed on the next branch.
#2 above is a big, wide ranging change, and Marcus has already provided
a sketch of some of it, so I'll do that one last. :)
Regarding #1:
Off list, Jeff requested that the runtime be fixed to correct tag
propagation for block that change their relative rate. My initial
response was not to bother trying, since the runtime doesn't have
enough information - only the block itself can perform correct tag
propagation.
However, if we allow blocks that change their relative rate to give the
runtime more information about the rate change, then the runtime can
actually do most of the work for tag propagation.
For some background, my latest pull request for a tag propagation fix
made these relevant changes:
1. Modified or added these API methods:
gr::block::set_relative_rate(double relative_rate);
gr::block::set_relative_rate(uint64_t interpolation, uint64_t decimation);
gr::block::set_inverse_relative_rate(double inverse_relative_rate);
2. Changed the tag offset propagation arithmetic to use multiple
precision integer rationals:
...
static const mpq_class one_half(1, 2);
...
else {
mpz_class offset;
for(t = rtags.begin(); t != rtags.end(); t++) {
tag_t new_tag = *t;
offset = new_tag.offset * mp_rrate + one_half;
new_tag.offset = offset.get_ui();
out_buf->add_item_tag(new_tag);
}
}
...
The expression
offset = new_tag.offset * mp_rrate + one_half;
can be viewed as a degenerate case of a more general expression
offset = (new_tag.offset - rr_in_offset) * mp_rrate + rr_out_offset +
one_half;
Where rr_in_offset is the input sample offset where the particular
mp_rrate value is first valid, and rr_out_offset is the output sample
offset where the particular mp_rrate value is first valid.
The runtime currently assumes these rr_(in|out)_offset values are
always 0.
So the solution, at a high level, is for the blocks performing relative
rate changes to provide values for rr_in_offset and rr_out_offset along
with every change to the relative rate. Then the runtime can take care
of the rest of the tag propagation headaches.
So the API for setting relative rate then becomes:
gr::block::set_relative_rate(double relative_rate, uint64_t in_offset =
0, uint64_t out_offset = 0);
gr::block::set_relative_rate(uint64_t interpolation, uint64_t
decimation, uint64_t in_offset = 0, uint64_t out_offset = 0);
gr::block::set_inverse_relative_rate(double inverse_relative_rate,
uint64_t in_offset = 0, uint64_t out_offset = 0);
But since the runtime would now maintian a dynamic structure of
(relative rate, in offset, out offset) tuples, the external API for
getting relative rate gets a little messy/ambiguous. I'm not sure what
to do about that yet.
This concept can support blocks that change their relative rate with
every output sample, such as the PFB clock sync blocks and the symbol
synchronizer blocks.
I suppose I'll test it with the symbol synchronizer blocks, since I now
see that they don't do correct tag propagation if their output rate is
set to anything higher than 1 sample/symbol. :P
Regards,
Andy