[USRP-users] Rx/Tx Loopback

Rob Kossler rkossler at nd.edu
Thu Apr 2 13:37:48 EDT 2015


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> 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> 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/ee001fe9/attachment-0002.html>


More information about the USRP-users mailing list