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
