Re: [Discuss-gnuradio] burst timestamps not being respected

[mleech]

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: address@hidden address@hidden on behalf of address@hidden address@hidden
Sent: Wednesday, April 25, 2012 11:34 AM
To: address@hidden
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 :-P **

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?