Hey all, I just saw Tom has a patch for a similar bug I had relating to tags and resampling. Just bringing this to the discussion in case it helps anyone else!
http://gnuradio.org/redmine/issues/831#change-2511 - Tim On Mon, Jan 4, 2016 at 8:55 AM, <mark.w.christian...@l-3com.com> wrote: > My tag generator takes data packets that are time stamped for the first > sample of each packet and needs to tag the stream produced in the work > function. I tag starting m_tag_offset = 0 and then increment by the number > of samples from my packets after each time I add_item_tag(). > > > > I wouldn’t care so much about the tags stopping except that I sometimes > have a dropped packet and the timing is off from then on. > > > > *From:* discuss-gnuradio-bounces+mark.w.christiansen=l-3com....@gnu.org > [mailto:discuss-gnuradio-bounces+mark.w.christiansen=l-3com....@gnu.org] *On > Behalf Of *Paul David > *Sent:* Thursday, December 31, 2015 6:47 PM > *To:* Tom Rondeau > > *Cc:* GNURadio Discussion List > *Subject:* Re: [Discuss-gnuradio] Working with Tags > > > > Weird. I don't see a problem between strobe_tags -> moving average -> > vector sink with my test. How is m_tag_offset getting set? > > > > On Thu, Dec 31, 2015 at 7:43 PM, Paul David <pudda...@gmail.com> wrote: > > I'm gonna check this out. I may have fixed this according to the tests we > were looking at, but introduced a bug elsewhere. > > A QA test involving the moving average blocks and stream tags might help > clear things up. > > > > On Thu, Dec 31, 2015 at 10:38 AM, Tom Rondeau <t...@trondeau.com> wrote: > > On Wed, Dec 30, 2015 at 3:32 PM, <mark.w.christian...@l-3com.com> wrote: > > It’s a tag generator that goes through several other blocks before getting > to the tag receiver. > > > > tag generator - mag^2 - moving average ------------------- divide - add > constant - tag receiver > > \- moving average -/ > > > > Basically I’m computing the ration of a fast average to a slow average and > sending that to a threshold detector sink (tag receiver) to watch for the > signal to go above threshold. It then sends a message with the time stamp > of that event to another block for other processing. I wrote the tag > generator and tag receiver. > > > > Mark. > > > > > > I'd recommend plugging the tag generator directly into the tag receiver > just to make sure both of those are handling the tags properly. If they > are, then we can dive into the rest of the chain to see where things might > be having problems. My guess is that it'll be related to the different > delays of the moving average filters. > > > > This also might be related to a bug that we recently patched: > > > https://github.com/gnuradio/gnuradio/commit/ae2e24f86b562a5bdcb9f5170e0abb1cd15838cf > > > > Tom > > > > > > > > > > *From:* trond...@trondeau.com [mailto:trond...@trondeau.com] *On Behalf > Of *Tom Rondeau > *Sent:* Wednesday, December 30, 2015 9:36 AM > *To:* Christiansen, Mark W. @ CSG - CSW > *Cc:* GNURadio Discussion List > *Subject:* Re: [Discuss-gnuradio] Working with Tags > > > > On Wed, Dec 30, 2015 at 11:15 AM, <mark.w.christian...@l-3com.com> wrote: > > I wrote a block that writes the rx_time tag and another block that reads > it. After reading them for a 20 to thirty calls to the work function, it > stops getting any. The amount it reads varies from run to run. Any ideas? > > This code snippet is from the work function my block that writes the tag. > The cerr statement continues to print to the console until I stop execution. > > > > <code> > > VITA49_packet_info packet_info = p_packet->get_VITA49_packet_info(); > > if (m_do_send_tags) > > { > > double timestamp_in_seconds = > > static_cast<double>(p_packet->get_integer_seconds()) + > > static_cast<double>(p_packet->get_fraction_seconds()) * 1e-12; > > const pmt::pmt_t timestamp = pmt::make_tuple( > > pmt::from_uint64(static_cast<long > long>(floor(timestamp_in_seconds))), > > pmt::from_double(timestamp_in_seconds - > floor(timestamp_in_seconds))); > > std::cerr << "SEND (" << d_id << ") " > > << " tag_offset=" << m_tag_offset > > << std::setprecision(std::numeric_limits<double>::digits10 > + 1) > > << " timesamp_in_seconds=" << timestamp_in_seconds << > std::endl; > > add_item_tag(0, m_tag_offset, TIME_KEY, timestamp, d_id); > > </code> > > > > > > How are you setting m_tag_offset? > > > > > > This code snippet is from my work function in the block that reads the > tag. The cerr statement stops printing after twenty to thirty times > suggesting that it no longer sees the time tags. The rest of the work > function continues to operate properly. > > > <code> > > static const pmt::pmt_t TIME_KEY = pmt::string_to_symbol("rx_time"); > > std::vector<tag_t> tags; > > get_tags_in_range( > > tags, 0, nitems_read(0), nitems_read(0) + noutput_items); > > std::vector<tag_t>::iterator itr; > > size_t j = 0; > > for (itr = tags.begin(); itr != tags.end(); itr++, j++) > > { > > if (pmt::eq((*itr).key, TIME_KEY)) > > { > > d_real_time_seconds = > > static_cast<double>(pmt::to_uint64(pmt::tuple_ref((*itr).value, > 0))) + > > static_cast<double>(pmt::to_double(pmt::tuple_ref((*itr).value, > 1))); > > std::cerr << "RECEIVE (" << d_id << ") " << j > > << " tag_offset=" << (*itr).offset > > << " noutput_items=" << noutput_items > > << std::setprecision(std::numeric_limits<double>::digits10 > + 1) > > << " time_seconds=" << d_real_time_seconds << std::endl; > > } > > } > > } > > <code> > > > > /\/\ark. > > > > > > What does your flowgraph look like? Or is it just the tag producing block > going straight in to the tag getter block? > > > > Tom > > > > > > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
