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

Jacob Gilbert mrjacobagilbert at gmail.com
Tue Sep 9 20:17:38 EDT 2014


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?

Thanks,
Jacob

On Tue, Sep 9, 2014 at 8:05 PM, Marcus D. Leech via USRP-users <
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 listUSRP-users at lists.ettus.comhttp://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 Consortiumhttp://www.sbrac.org
>
>
> _______________________________________________
> 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/20140909/bf823f41/attachment-0002.html>


More information about the USRP-users mailing list