[USRP-users] Retune stream tag arriving before retune Is complete

Marcus D. Leech mleech at ripnet.com
Tue Sep 9 20:23:27 EDT 2014


On 09/09/2014 08:17 PM, Jacob Gilbert wrote:
> Thank you Marcus. I had erroneously assumed the tag was an indication 
> that the samples following it were post-retune as opposed to it being 
> more of an acknowledgement that the tune request had been performed by 
> the driver. It makes sense though given how quick DSP tuning is.
>
> If I were to move to timed commands to perform more deterministic 
> retuning, do you know if a tag be generated at the time of retuning? 
> And if so, would that have some level of assurance that subsequent 
> data is corresponding to the newly tuned frequency?
B2xx don't support timed commands anyway, as far as I know.

What magnitude of latency are you observing, and at what sample rates?


>
> Thanks,
> Jacob
>
> On Tue, Sep 9, 2014 at 8:05 PM, Marcus D. Leech via USRP-users 
> <usrp-users at lists.ettus.com <mailto:usrp-users at lists.ettus.com>> wrote:
>
>     On 09/09/2014 08:01 PM, Jacob Gilbert via USRP-users wrote:
>>
>>     Hello,
>>
>>     I am having some trouble with a USRP B210 and quickly retuning it
>>     for a wideband survey application. I have an OOT GR block which
>>     retunes (DSP only, since the LO retune takes quite a while) the
>>     USRP via a call to the usrp_source block's retune method, waits
>>     for the stream tag, passes some data forward, then repeats.
>>
>>     The issue I am currently having is on occasion the stream tag
>>     indicating the retune will arrive well before the data is
>>     actually valid for the frequency the tag is indicating it just
>>     tuned to. I had originally thought the uhd source block would
>>     insert a stream tag when the USRP indicated the retune had been
>>     completed, however in looking into usrp_source_impl.cc:145, it
>>     looks like the tag is appended (or indicated it should be
>>     appended) immediately after the tune call is made regardless of
>>     whether or not the tune in the FPGA has actually completed.
>>
>>     Is this correct? And if so, is there a better way to know when a
>>     DSP-only tune has completed and the data stream is valid for the
>>     new frequency?
>>
>>
>>     Thanks,
>>
>>     Jacob
>>
>>
>>     _______________________________________________
>>     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
>     The FPGA-only tune happens so quickly that the way it is currently
>     written is "correct", modulo latencies in Gnu Radios internal
>     buffering mechanisms,
>       which are definitely outside the scope of what the hardware can
>     control.
>
>     There will be ambiguous data after a retune, since you don't
>     really know how many samples are "in flight" after doing that.
>
>
>
>     -- 
>     Marcus Leech
>     Principal Investigator
>     Shirleys Bay Radio Astronomy Consortium
>     http://www.sbrac.org
>
>
>     _______________________________________________
>     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
>
>


-- 
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

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


More information about the USRP-users mailing list