The data samples that come after the tag very possibly represent data that was received (and has been buffered up) _before_ the tune command was issued. This is important conceptually if you are doing an FPGA-only operation (e.g.: CORDIC tuning, changing decimation) as there is no 'completion' time, and the intuitive assumption would be that data following the tag is described by the tag parameters, which it may or may not be.
Depending on the overall setup the amount of buffered data can be nontrivial (and is not deterministic). Probably not an issue for most applications but if you have tight timing requirements it can be important. The point here for Euegene is that the way tags are done is entirely within the GR source block, and where the tag is placed is done without information from the hardware or UHD - it's put in on the next work function call after a qualifying action. Jacob On Sat, Jul 15, 2017 at 8:42 PM, Marcus D. Leech <mle...@ripnet.com> wrote: > 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 < > usrp-users@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 <%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:* mle...@ripnet.com [mailto:mle...@ripnet.com <mle...@ripnet.com>] >> *Sent:* Friday, July 14, 2017 12:34 PM >> *To:* Eugene Grayver <eugene.gray...@aero.org> <eugene.gray...@aero.org> >> *Cc:* usrp-users@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 <%28310%29%20336-1274> >> ________________________ >> >> >> >> >> >> _______________________________________________ >> USRP-users mailing list >> USRP-users@lists.ettus.com >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >> >> >> >> _______________________________________________ >> USRP-users mailing list >> USRP-users@lists.ettus.com >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >> >> > >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
