Burst timestamps not being respected

GNU Radio
1

Hi all,

** Warning: this is rather a Josh question, but anyone’s comments are
welcome :stuck_out_tongue: **

I’m running some flowgraphs in Python that transmit timed bursts. I
implemented a burst_tagger block whose work(…) function is very
similar to that of the stream tags demo in gr-uhd/examples. I also need
to be able to dynamically reconfigure the transmit power, which I’m
controlling with a gr_multiply_const_ff block. Calling lock() -->
mult.set_k(k) --> unlock() does this.

My biggest problem is that I’m observing that calls to lock (and/or
unlock) are emptying the USRP buffer prematurely, causing a burst to be
transmitted out-of-sync. I confirmed that the “tx_time” tag has the
right absolute time on it, but it’s not being respected by the USRP.

At first I thought it could be a USRP problem, but then I looked at the
implementation of gr_top_block and found that unlock() makes a call to
restart(), which in turn calls stop(). The implementation of
gr_uhd_usrp_sink overrides the stop() method to send an end-of-burst
packet to the USRP. I’m wondering if this is what’s clearing my buffer
and forcing it to be transmitted without respecting the time_spec in the
metadata. I haven’t dug through UHD code but I imagine end-of-burst
packets get higher priority than start-of-burst packets or time_specs.

On a sort-of related topic, I don’t like that the “tx_eob” tag affixed
by the burst tagger uses one sample; it causes an ugly spike to be
transmitted. I have two thoughts - I could write 0 to this sample, or I
could find a way to send a tag without a sample. I’m not sure if the
latter method is even possible. I’m guessing it’s not and that I’d have
to implement message passing.

Respectfully,
Sean Nowlan

2

On Wed, 25 Apr 2012 15:28:09 +0000, Nowlan, Sean wrote:

Hi
all,

** Warning: this is rather a Josh question, but anyone’s
comments are welcome :stuck_out_tongue: **

I’m running some flowgraphs in Python
that transmit timed bursts. I implemented a burst_tagger block whose
work(…) function is very similar to that of the stream tags demo in
gr-uhd/examples. I also need to be able to dynamically reconfigure the
transmit power, which I’m controlling with a gr_multiply_const_ff block.
Calling lock() --> mult.set_k(k) --> unlock() does this.

My biggest
problem is that I’m observing that calls to lock (and/or unlock) are
emptying the USRP buffer prematurely, causing a burst to be transmitted
out-of-sync. I confirmed that the “tx_time” tag has the right absolute
time on it, but it’s not being respected by the USRP.

At first I
thought it could be a USRP problem, but then I looked at the
implementation of gr_top_block and found that unlock() makes a call to
restart(), which in turn calls stop(). The implementation of
gr_uhd_usrp_sink overrides the stop() method to send an end-of-burst
packet to the USRP. I’m wondering if this is what’s clearing my buffer
and forcing it to be transmitted without respecting the time_spec in the
metadata. I haven’t dug through UHD code but I imagine end-of-burst
packets get higher priority than start-of-burst packets or time_specs.

On a sort-of related topic, I don’t like that the “tx_eob” tag
affixed by the burst tagger uses one sample; it causes an ugly spike to
be transmitted. I have two thoughts - I could write 0 to this sample, or
I could find a way to send a tag without a sample. I’m not sure if the
latter method is even possible. I’m guessing it’s not and that I’d have
to implement message passing.

Respectfully,
Sean Nowlan

So, why
are you calling lock() around setting a simple constant for a multiplier
block?

3

It was my understanding that this was necessary before reconfiguring a
flowgraph. Is that not the case?

From: discuss-gnuradio-bounces+sean.nowlan=removed_email_address@domain.invalid
[discuss-gnuradio-bounces+sean.nowlan=removed_email_address@domain.invalid] on behalf
of [email protected] [[email protected]]
Sent: Wednesday, April 25, 2012 11:34 AM
To: [email protected]
Subject: Re: [Discuss-gnuradio] burst timestamps not being respected

On Wed, 25 Apr 2012 15:28:09 +0000, Nowlan, Sean wrote:

Hi all,

** Warning: this is rather a Josh question, but anyone’s comments are
welcome :stuck_out_tongue: **

I’m running some flowgraphs in Python that transmit timed bursts. I
implemented a burst_tagger block whose work(…) function is very
similar to that of the stream tags demo in gr-uhd/examples. I also need
to be able to dynamically reconfigure the transmit power, which I’m
controlling with a gr_multiply_const_ff block. Calling lock() -->
mult.set_k(k) --> unlock() does this.

My biggest problem is that I’m observing that calls to lock (and/or
unlock) are emptying the USRP buffer prematurely, causing a burst to be
transmitted out-of-sync. I confirmed that the “tx_time” tag has the
right absolute time on it, but it’s not being respected by the USRP.

At first I thought it could be a USRP problem, but then I looked at the
implementation of gr_top_block and found that unlock() makes a call to
restart(), which in turn calls stop(). The implementation of
gr_uhd_usrp_sink overrides the stop() method to send an end-of-burst
packet to the USRP. I’m wondering if this is what’s clearing my buffer
and forcing it to be transmitted without respecting the time_spec in the
metadata. I haven’t dug through UHD code but I imagine end-of-burst
packets get higher priority than start-of-burst packets or time_specs.

On a sort-of related topic, I don’t like that the “tx_eob” tag affixed
by the burst tagger uses one sample; it causes an ugly spike to be
transmitted. I have two thoughts - I could write 0 to this sample, or I
could find a way to send a tag without a sample. I’m not sure if the
latter method is even possible. I’m guessing it’s not and that I’d have
to implement message passing.

Respectfully,
Sean Nowlan

So, why are you calling lock() around setting a simple constant for a
multiplier block?

4

No.

The only time you need to do that is when you reconfigure the
topology of a flow-graph. Parameters on individual blocks can be
changed on the fly without calling lock().

Although not all parameters
on all blocks can be changed on the fly, those that can be don’t require
lock(). The constant on a multiply_const definitely is changeable on the

fly, and most definitely doesn’t require lock()/unlock() around it.

On Wed, 25 Apr 2012 15:39:19 +0000, Nowlan, Sean wrote:

It was my
understanding that this was necessary before reconfiguring a flowgraph.
Is that not the case?

FROM:
discuss-gnuradio-bounces+sean.nowlan=removed_email_address@domain.invalid
[discuss-gnuradio-bounces+sean.nowlan=removed_email_address@domain.invalid] on behalf
of [email protected] [[email protected]]
SENT: Wednesday, April 25,
2012 11:34 AM
TO: [email protected]
SUBJECT: Re:
[Discuss-gnuradio] burst timestamps not being respected

On Wed, 25
Apr 2012 15:28:09 +0000, Nowlan, Sean wrote:

Hi all,

**
Warning: this is rather a Josh question, but anyone’s comments are
welcome :stuck_out_tongue: **

I’m running some flowgraphs in Python that
transmit timed bursts. I implemented a burst_tagger block whose
work(…) function is very similar to that of the stream tags demo in
gr-uhd/examples. I also need to be able to dynamically reconfigure the
transmit power, which I’m controlling with a gr_multiply_const_ff block.
Calling lock() --> mult.set_k(k) --> unlock() does this.

My
biggest problem is that I’m observing that calls to lock (and/or unlock)
are emptying the USRP buffer prematurely, causing a burst to be
transmitted out-of-sync. I confirmed that the “tx_time” tag has the
right absolute time on it, but it’s not being respected by the USRP.

At first I thought it could be a USRP problem, but then I looked at
the implementation of gr_top_block and found that unlock() makes a call
to restart(), which in turn calls stop(). The implementation of
gr_uhd_usrp_sink overrides the stop() method to send an end-of-burst
packet to the USRP. I’m wondering if this is what’s clearing my buffer
and forcing it to be transmitted without respecting the time_spec in the
metadata. I haven’t dug through UHD code but I imagine end-of-burst
packets get higher priority than start-of-burst packets or
time_specs.

On a sort-of related topic, I don’t like that the
“tx_eob” tag affixed by the burst tagger uses one sample; it causes an
ugly spike to be transmitted. I have two thoughts - I could write 0 to
this sample, or I could find a way to send a tag without a sample. I’m
not sure if the latter method is even possible. I’m guessing it’s not
and that I’d have to implement message passing.

Respectfully,

Sean Nowlan

So, why are you calling lock() around setting a simple
constant for a multiplier block?

5

On Wed, Apr 25, 2012 at 08:39, Nowlan, Sean
[email protected] wrote:

It was my understanding that this was necessary before reconfiguring a
flowgraph. Is that not the case?

‘reconfiguring’ means changing the topology of the flowgraph through
calls to connect() and/or disconnect(). Simply calling a setter
function on a block, like set_k(), does not need lock() and unlock().

Johnathan

6

Thanks for clarifying that. I ran a few tests and things look good. I’m
glad this turned out to be an easy fix!

Sean

From: [email protected] [[email protected]]
Sent: Wednesday, April 25, 2012 11:43 AM
To: Nowlan, Sean
Cc: [email protected]
Subject: RE: [Discuss-gnuradio] burst timestamps not being respected

No.

The only time you need to do that is when you reconfigure the topology
of a flow-graph. Parameters on individual blocks can be changed on the
fly without calling lock().

Although not all parameters on all blocks can be changed on the fly,
those that can be don’t require lock(). The constant on a
multiply_const definitely is changeable on the

fly, and most definitely doesn’t require lock()/unlock() around it.

On Wed, 25 Apr 2012 15:39:19 +0000, Nowlan, Sean wrote:

It was my understanding that this was necessary before reconfiguring a
flowgraph. Is that not the case?

From: discuss-gnuradio-bounces+sean.nowlan=removed_email_address@domain.invalid
[discuss-gnuradio-bounces+sean.nowlan=removed_email_address@domain.invalid] on behalf
of [email protected] [[email protected]]
Sent: Wednesday, April 25, 2012 11:34 AM
To: [email protected]
Subject: Re: [Discuss-gnuradio] burst timestamps not being respected

On Wed, 25 Apr 2012 15:28:09 +0000, Nowlan, Sean wrote:

Hi all,

** Warning: this is rather a Josh question, but anyone’s comments are
welcome :stuck_out_tongue: **

I’m running some flowgraphs in Python that transmit timed bursts. I
implemented a burst_tagger block whose work(…) function is very
similar to that of the stream tags demo in gr-uhd/examples. I also need
to be able to dynamically reconfigure the transmit power, which I’m
controlling with a gr_multiply_const_ff block. Calling lock() -->
mult.set_k(k) --> unlock() does this.

My biggest problem is that I’m observing that calls to lock (and/or
unlock) are emptying the USRP buffer prematurely, causing a burst to be
transmitted out-of-sync. I confirmed that the “tx_time” tag has the
right absolute time on it, but it’s not being respected by the USRP.

At first I thought it could be a USRP problem, but then I looked at the
implementation of gr_top_block and found that unlock() makes a call to
restart(), which in turn calls stop(). The implementation of
gr_uhd_usrp_sink overrides the stop() method to send an end-of-burst
packet to the USRP. I’m wondering if this is what’s clearing my buffer
and forcing it to be transmitted without respecting the time_spec in the
metadata. I haven’t dug through UHD code but I imagine end-of-burst
packets get higher priority than start-of-burst packets or time_specs.

On a sort-of related topic, I don’t like that the “tx_eob” tag affixed
by the burst tagger uses one sample; it causes an ugly spike to be
transmitted. I have two thoughts - I could write 0 to this sample, or I
could find a way to send a tag without a sample. I’m not sure if the
latter method is even possible. I’m guessing it’s not and that I’d have
to implement message passing.

Respectfully,
Sean Nowlan

So, why are you calling lock() around setting a simple constant for a
multiplier block?