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

Jacob Gilbert mrjacobagilbert at gmail.com
Tue Sep 9 20:39:54 EDT 2014


Unfortunate about timed commands - they are listed as a feature in the
manual so maybe they are on the horizon. I had tried (and failed) to get
them to work properly but was hoping that was just me.

Latency ranging from very low (us) jumping to 10's of ms which is where it
becomes problematic. I am sampling relatively slow (~2.5 MS/s), but it's a
disadvantaged processor (ARM) so there might be some issues related to
samples backing up. I will investigate that.


On Tue, Sep 9, 2014 at 8:23 PM, Marcus D. Leech <mleech at ripnet.com> wrote:

>  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> 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
>>
>>
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140909/64add16e/attachment-0002.html>


More information about the USRP-users mailing list