discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Working with Tags


From: Tom Rondeau
Subject: Re: [Discuss-gnuradio] Working with Tags
Date: Thu, 31 Dec 2015 10:38:58 -0500

On Wed, Dec 30, 2015 at 3:32 PM, <address@hidden> 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: address@hidden [mailto:address@hidden] 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, <address@hidden> 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

 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]