|
From: | Nowlan, Sean |
Subject: | [Discuss-gnuradio] burst timestamps not being respected |
Date: | Wed, 25 Apr 2012 15:28:09 +0000 |
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 |
[Prev in Thread] | Current Thread | [Next in Thread] |