[USRP-users] Rx/Tx Loopback

Ian Buckley ianb at ionconcepts.com
Thu Apr 2 12:31:48 EDT 2015


So this is an interesting one, and a little unexpected for me, but I think I know whats happening.
First off I reproduced this exactly as Rob described using B210, so it's symptomatic of UHD in general rather than X310 specific.
When data is RX'ed on a USRP every UHD packet contains vita time metadata in the header that identifies the timestamp with which the first sample in the packet was received.
Now note that the TX returns "L" as the error, not "U"…so it's not underflowing whilst TX streaming, its rejecting TX UHD packets as having a timestamp thats in the past w.r.t the current vita time.
(Note TX and RX within a USRP channel are sharing the same H/W vita time counter.)

I believe that this flow graph causes the RX time stamps to be placed into the TX data stream as timestamps that are targets for transmission, and of course by definition they will always be in the past when they arrive at the TX DSP.

Someone who is better at GR than me will probably know what block to pass this through to strip the metadata. So saying that I think that this style of simplistic flow graph is still doomed to not run reliably because being fed from a sample source thats forced to run in lockstep with the sample sink means that an adequate buffer of samples will never accumulate in the TX buffering of the USRP to absorb the inevitable jitter in data delivery from the host. Perhaps the way to do this is to add a constant time offset to all the RX timestamps that will force some buffering in H/W(If Robs goal is minimal latency this might be less than useful for him?)

-Ian

On Apr 2, 2015, at 7:51 AM, Marcus D. Leech via USRP-users <usrp-users at lists.ettus.com> wrote:

> Well, I wonder if our gr-uhd maintainer has a comment.
> 
> This seems very odd to me, and perhaps there's a subtlety in the way gr-uhd tries to be helpful and setup a bunch of stuff involving sample timing automatically.
> 
>  
>  
>  
> On 2015-04-02 10:28, Rob Kossler wrote:
> 
>> On Wed, Apr 1, 2015 at 11:45 PM, Marcus D. Leech <mleech at ripnet.com> wrote:
>> On 04/01/2015 11:41 PM, Rob Kossler wrote:
>>> 
>>> 
>>> 
>>> Yes, those are the sync options.  Since there is only one device, I only selected "unknown PPS" for one of the two streamers.  Is that correct?
>>> Rob
>> That would be correct for a device that had 1PPS.  I don't recall whether X3xx has a "fake" internal 1PPS signal or not.  Since this is a single device
>>   at this point, just choose "don't sync" for both of them.  
>> 
>> 
>> I tried "don't sync" for both as well as putting constant multiply blocks in between the source / sink.  Neither seems to fix my "Late" issue.  However, if I exit GRC and simply run benchmark_rate in full duplex, it has no issues even at higher sample rates.
>> 
>> Attached are 3 files: the modified GRC flowgraph as well as two text files showing the results obtained when running this flowgraph from GRC as compared to running benchmark_rate.  The flowgraph sample rate is 1 MS/s while the benchmark_rate is running at 10 MS/s (BTW, it also runs fine at 1MS/s).
>> 
>> Rob
>> 
>> 
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150402/c3d1471a/attachment-0002.html>


More information about the USRP-users mailing list