|
| From: | Tom Rondeau |
| Subject: | Re: [Discuss-gnuradio] Working with Tags |
| Date: | Tue, 5 Jan 2016 15:10:08 -0500 |
- TimHey 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
On Mon, Jan 4, 2016 at 8:55 AM, <address@hidden> 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=address@hidden [mailto:discuss-gnuradio-bounces+mark.w.christiansen=address@hidden] 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 <address@hidden> 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 <address@hidden> wrote:
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:
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
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
| [Prev in Thread] | Current Thread | [Next in Thread] |