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?
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
