On 07/15/2017 10:33 PM, Jacob Gilbert wrote:
> 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).
_tag_now is set *after* the command is already "in flight". Note I
just said "issued", NOT "completed".
> 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.
For the most part, it is true. With the exception of commands that
directly alter streaming, control commands (tuning, gain setting, etc)
are conceptually asynchronous to each other in the FPGA. In fact, the
FPGA has no *concept* of "gain", or "frequency", or any of a number of
other radio-hardware
operating parameters. The "model" is that the FPGA exposes I2C and SPI
buses so that the host can manipulate registers on the radio hardware in
use,
but the actual *meaning* of those commands is completely opaque to the
FPGA (and hence things like frequency tags). Timed commands make it seem
more "synchronous", but the architecture of the FPGA in general makes no
linkage between the data stream, and the radio hardware control stream.
Jacob
On Fri, Jul 14, 2017 at 2:46 PM, Marcus D. Leech via USRP-users
<[email protected] <mailto:[email protected]>> 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 <tel:%28310%29%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:*[email protected] <mailto:[email protected]>
[mailto:[email protected]]
*Sent:* Friday, July 14, 2017 12:34 PM
*To:* Eugene Grayver <[email protected]>
<mailto:[email protected]>
*Cc:* [email protected] <mailto:[email protected]>
*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 <tel:%28310%29%20336-1274>
________________________
_______________________________________________
USRP-users mailing list
[email protected] <mailto:[email protected]>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
<http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
_______________________________________________
USRP-users mailing list
[email protected] <mailto:[email protected]>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
<http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
