Current approach: In the source block, I set the tx_time tag to a point that is in the future relative to the host computer's clock, which was synchronized with the USRP at program startup. The samples flow through the graph and get to the usrp_sink block for transmission. The latency in the flowgraph seems to vary enough such that some packets are late (UHD prints 'L') while other packets are not late. I have set max_noutput_items when calling top_block.run() to try to bound the latency, but with limited improvements.
1. In GNU Radio using stock usrp_sink, is there a method of getting the late flag without having to monitor stdout and parse Ls? I recently read on USRP-users that the proper way to detect late packets is to look at the metadata returned from uhd's send function. Does the usrp_sink block publish this in some way?
2. Any tips for doing *tightly timed* TDD in GNU Radio in general? For example, we are experimenting with a) setting tx_time at the source block (requires predicting the flowgraph's processing delays in order to not be late at the USRP) and b) setting tx_time at a custom block just before the usrp_sink so that most of the flowgraph processing delays are not a factor when computing a tx_time. What approaches have been taken by others?
3. When or why would supplying a max_noutput_items to top_block.run() not be passed on to or respected by blocks in a flow graph? My colleague observed that noutput_items given to work() was greater than what was given to top_block.run(). Do tagged stream blocks change the scheduler behavior w.r.t max_noutput_items?
-Stephen
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
No comments:
Post a Comment