[USRP-users] Rx/Tx Loopback
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.
> 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?)
> 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>>
>> 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?
>>> 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).
>> USRP-users mailing list
>> USRP-users at lists.ettus.com <mailto:USRP-users at lists.ettus.com>
> USRP-users mailing list
> USRP-users at lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the USRP-users