[USRP-users] Rx/Tx Loopback

Marcus Müller marcus.mueller at ettus.com
Thu Apr 16 11:08:14 EDT 2015

Hi Rob, hi crowd,

just a notification: we discussed a fix that you verified, namely,
making the usrp_sink start to transmit just a bit later than the
usrp_source starts receiving (and not the other way around). Johnathan
has just merged that into maint, so it's kinda "mainline" now :)


On 04/02/2015 07:37 PM, Rob Kossler via USRP-users wrote:
> I'm not much concerned with latency.  My original goal with this
> flowgraph was to demonstrate RF channel modeling using multiple signal
> fading blocks in between the UHD source and sink.  So, essentially
> there is some DSP to be applied to the data prior to retransmission. 
> I figured that as long as the CPU DSP processing was fast enough at
> the given data rate, it would be able to supply samples to the sink as
> fast as needed.  When this didn't work as expected, I simplified
> things to remove the fading blocks and just have the source and sink
> (which is the GRC file I previously attached).
> So, I think I can tolerate latency just fine.  Perhaps I need to add a
> time constant to the metadata as Ian suggested and/or implement some
> type of buffering block in GRC to avoid Underruns.  Let me know if
> anyone has ideas on this.  My initial goal is to get this simple
> flowgraph working before reverting back to adding fading blocks or
> other processing.
> Rob
> On Thu, Apr 2, 2015 at 12:31 PM, Ian Buckley <ianb at ionconcepts.com
> <mailto:ianb at ionconcepts.com>> wrote:
>     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 <mailto: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 <mailto: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 <mailto:USRP-users at lists.ettus.com>
>>     http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> _______________________________________________
> 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/20150416/ce9b1733/attachment-0002.html>

More information about the USRP-users mailing list