[USRP-users] TwinRX tuning timing

Jacob Gilbert mrjacobagilbert at gmail.com
Sat Jul 15 22:33:02 EDT 2017


>  The only guarantee is that samples that arrive after the tag will be
after the comman has been issued.

This has not been my experience, particularly at lower sample rates. As far
as I can tell, the code path responsible for tagging never actually goes to
the USRP device at all, when a retune is issued, a flag is set in the work
function that causes a tag to be emitted on the next call (
https://github.com/gnuradio/gnuradio/blob/master/gr-uhd/lib/usrp_source_impl.cc#L645
).

> The control-plane an data-plane run asynchronously to one another.

This does not appear to be strictly true, as timed commands exist. It more
seems like this is just a feature that is not implemented yet. It should
certainly be possible within the current UHD paradigm since timing metadata
certainly runs synchronous to the data-plane as it propagates downstream.

Jacob


On Fri, Jul 14, 2017 at 2:46 PM, Marcus D. Leech via USRP-users <
usrp-users at lists.ettus.com> wrote:

> On 07/14/2017 04:22 PM, Eugene Grayver wrote:
>
> Yes, I definitely agree that there’s no way to tell when the tuning is
> DONE.  However, my question was about the ‘shortly after’ part.  Should it
> not be inserted ‘shortly before’, or ‘exactly at’?  Since there’s typically
> no way to look into the future, (yes, of course it is doable), there’s no
> way for somebody to know that the samples that are before the tag are
> actually ‘invalid.’
>
>
>
> _______________________
> Eugene Grayver, Ph.D.
> Aerospace Corp., Sr. Eng. Spec.
> Tel: 310.336.1274 <(310)%20336-1274>
> ________________________
>
>
>
> The control-plane an data-plane run asynchronously to one another.   The
> only guarantee is that samples that arrive after the tag will be after the
> comman has been issued.
>
>
> *From:* mleech at ripnet.com [mailto:mleech at ripnet.com <mleech at ripnet.com>]
> *Sent:* Friday, July 14, 2017 12:34 PM
> *To:* Eugene Grayver <eugene.grayver at aero.org> <eugene.grayver at aero.org>
> *Cc:* usrp-users at lists.ettus.com
> *Subject:* Re: [USRP-users] TwinRX tuning timing
>
>
>
> The frequency tag is inserted at some point shortly after the command-set
> is issued to the hardware.  There's no way for the various bits and pieces
> to tell when the underlying (mostly analog) hardware has converged to an
> "acceptable" steady-state operating mode.  PLL synthesizers don't instantly
> switch from one frequency to another, digital (and analog) filters have
> group delays, etc.
>
> The time to achieve steady-state can vary from hardware-type to
> hardware-type, ambient temperature, size of the frequency step, etc.
>
>
>
>
>
>
>
> On 2017-07-14 15:10, Eugene Grayver via USRP-users wrote:
>
> I am running some experiments to understand the timing of TwinRX tuning.
> A very simple experiment shows that the tag indicating a frequency change
> is not placed at the right sample.  Here’s a capture: The dashed line
> indicates the tag sample number.  However, there’s clearly something
> happening before the tag.  Note that I am not using timed commands for this
> – just a regular tune request.
>
>
>
>
>
> _______________________
> Eugene Grayver, Ph.D.
> Aerospace Corp., Sr. Eng. Spec.
> Tel: 310.336.1274 <(310)%20336-1274>
> ________________________
>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> 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/20170715/5350b3ec/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 58862 bytes
Desc: not available
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170715/5350b3ec/attachment.png>


More information about the USRP-users mailing list