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]<mailto:[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]<mailto:[email protected]>> wrote: On Wed, Dec 30, 2015 at 3:32 PM, <[email protected]<mailto:[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]> [mailto:[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]<mailto:[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]<mailto:[email protected]> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
