On Tue, Jan 5, 2016 at 3:04 PM, Tim K <[email protected]> wrote: > 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 >
Note that the problem is in the specific block that wasn't handling the book-keeping of consume/produce properly. It was also very subtle. Might have similar issues in the moving average filter. Tom > On Mon, Jan 4, 2016 at 8:55 AM, <[email protected]> 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:* [email protected] >> [mailto:[email protected]] *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 <[email protected]> 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 <[email protected]> wrote: >> >> On Wed, Dec 30, 2015 at 3:32 PM, <[email protected]> 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:* [email protected] [mailto:[email protected]] *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, <[email protected]> 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 >> [email protected] >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> >> >> >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> [email protected] >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
