Hi Devin,

I've made a very rough run-down of things in

http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2016-May/020156.html

It's really just an upper-boundary estimate. In fact, the time an LO
takes to retune depends on when you define it's finished doing that, ie.
after which time you consider the PLL to be stable enough for operation.
If you can live with frequency oscillations, you can work with the
signal earlier!

Yep! Also, shameless plug: The TwinRX daughterboard has two independent
frontends, so you get four 80 MHz RX bandwidths per X3x0 + 2x TwinRX,
instead of two 160 MHz RX bandwidths with X3x0 + 2x UBX160.

Best regards,

Marcus

On 02/24/2017 05:41 PM, devin kelly via USRP-users wrote:

I don't think this parameter has been characterized.  There are a number
of factors involved in tuning latency, including "bus" latency, OS
app-to-network-hardware stack latency, latency of the SPI bus that is
used to program the MAX2871 synthesizers, and once THAT piper has been
paid, there's the time it takes for the PLL to converge on a new
frequency setting, which is often variable, depending on how far away
from its current frequency you're asking it to move.

My guess would be on the order of a few milliseconds and perhaps as much
as 20 milliseconds.

On 2017-02-24 11:41, devin kelly via USRP-users wrote:

Thanks for the quick replies.

Suppose I had a some pre-synthesized messages, all the same sample rate and
gain.  Then my delays would be just the analog tuning and DC removal?  I
think for my application we digitally shift the message away from the DC
component and then filter out the DC component with analog filters.  So
that just leaves the analog tuning, which is on the order of 4ms (or maybe
inbetween 1ms and 10ms)?  If that's right I'll try to characterize this in
the next few weeks.

Also, there is anything like a TwinTX coming?

Devin

On Fri, Feb 24, 2017 at 12:00 PM, mleech@ripnet.com wrote:

Hi Devin,

I have measured the UBX tune time.  The SPI writes to tune the LO take
~30-60us and the LO lock time is 400us.  I recommend discarding at least
500us of samples after the LO tune.  I also recommend continuous streaming
of samples so the frontend components are not switched on and off, which
can cause long transients.  For the UBX-160, set the dboard_clock_rate to
20e6 and tune the LO in steps of 160 MHz.  If using a sample rate <200
Msps, use DSP tuning (which takes < 1us) for the frequencies between the
160MHz steps.  With that, you should be able to tune across the full 6GHz
in ~18ms in theory.  There is one caveat.  There are 2 LNAs on the UBX, one
for <1.5 GHz and one for above.  Only one can be powered on at a time and
the warm up time is significant (in the 100s of milliseconds for the low
band LNA and 10s of milliseconds for the high band LNA),, so you would be
best suited using one daughterboard for the low band and one for the high
band for the fastest sweep time.

Unfortunately, I do not have the same experience with the TwinRX, so i
cannot advise on it.

Regards,
Michael

On Fri, Feb 24, 2017 at 9:11 AM, devin kelly via USRP-users <
usrp-users@lists.ettus.com> wrote:

On 02/24/2017 01:24 PM, Michael West via USRP-users wrote:

Not to hijack this thread, but do you have any recommendations on the
most effective way to properly time the "discard 500us of samples after
the LO tune?" One of the drawbacks of using the USRP family for
applications that require fast retuning is that there isn't (from what I
can tell) any in-band indication of what center frequency the radio is
tuned to. The control interface (e.g. through
multi_usrp::set_rx_center_freq()) is completely separate from the data
streaming interface, so if I call set_rx_center_freq() at time T, I have
no way of accurately estimating when the tune will actually be complete
in the data stream.

This seems to be a disadvantage of the CHDR protocol that contemporary
USRPs use; they seem to carry data samples and timetags, but nothing
else. VITA 49 is nice in that it can provide full context in timetagged
packets, so you can get updates as to the radio state (e.g. frequency,
gain) that are aligned as closely as possible with the associated
samples from the SDR.

Jason

Hi Jason,

If you use the set_command_time function to cause the tune to occur at a
specific time then you can use the in-band timestamps from the recv call to
identify the sample when the tune action started. The 500us of samples
following that timestamp are the ones you would want to discard.

An example of setting the execution time for a command:
https://github.com/EttusResearch/uhd/blob/master/host/examples/test_timed_commands.cpp#L96

An example of starting streaming at a set time:
https://github.com/EttusResearch/uhd/blob/master/host/examples/test_timed_commands.cpp#L129

Regards,
Derek

On Fri, Feb 24, 2017 at 11:27 AM, Jason Roehm via USRP-users <
usrp-users@lists.ettus.com> wrote:

Hi Jason,

On 24.02.2017 20:27, Jason Roehm via USRP-users wrote:

That's what threads are for :)

That is correct. The device, in fact, doesn't even have that notion itself.

Luckily, it's not /that/ independent:

You don't have to be told when tuning took place if you're the one to
define when it should happen.
That's what timed commands are for:
You can say "ok, at time 120.122200, execute the following tune
command", and your USRP will truthfully do that. From the timestamp of
the first received sample, the known sampling rate and your desired tune
time, you can directly derive which sample the tuning will take place at.

I'd slightly disagree here: In fact, the USRP doesn't "tune". It
executes commands coming from the host at the time the host says it
should. These commands are of the type "first, write the following six
bytes to the SPI bus, then pull up GPIO 12", for example. So, the USRP
never "sees" frequency. It really only sees commands that configure the
analog and hybrid hardware to do what you want.

Fun fact: CHDR is kind of like Vita, but we threw out all that wasn't
necessary for operation to make it more compact.
The N2xx series and other USRPs used VITA, but they had the same
host-based knowledge, so they couldn't have tagged their streams with
frequency either, simply for lack of having a notion of tuned frequency.

Best regards,
Marcus

Do these tuning/settling times also hold true for the UBX-40 in an N210?

On Fri, Feb 24, 2017 at 2:47 PM, Derek Kozel via USRP-users <
usrp-users@lists.ettus.com> wrote:

On 02/24/2017 02:53 PM, Marcus Müller via USRP-users wrote:

Yes, I've considered using timed commands for this before, and you're
right, it does appear that they would be suitable for some fast-retuning
applications. I can think of a couple drawbacks to this approach:

• Say I'm streaming data at frequency f1 and want to tune to frequency
  f2. If I want to know the precise time that the tune occurred, I first
  need to query the device's time. I then need to add some delay to the
  returned device time to account for the latency of the control interface
  (to ensure that the time I ask the device to tune is still in the
  future). I then need to issue the timed command to perform the tune. The
  extra transactions and timing margin needed to do this safely can add a
  significant amount of latency to the tune, as mentioned earlier in this
  thread. Even if the LO can tune in ~400 usec, the required API-level
  operations to sequence everything can be many times that in duration.

• Consider an application where I have a particular sequence of
  frequencies that I want to tune through rapidly (e.g. for a
  frequency-hopping application or a wideband sweep). I might know a
  priori a list of frequencies and dwell times that I'd like to step
  through, which could conceivably be loaded into the device ahead of time
  using timed commands (e.g. read the time once, calculate all of the tune
  times relative to that time, load up a bunch of tuned commands). I'm not
  sure that I've seen a canonical source for the maximum number of timed
  commands in flight, but my Googling has suggested it's on the order of
  10, which isn't really large enough to be useful for this sort of
  application; at some point you're going to be limited again by host API
  latency.

That makes sense; I understand the justification for why things are the
way they are. I was just expressing the fact that the generic, modular
nature of the USRP/UHD architecture does have some drawbacks at the
application level, whereas a more integrated approach (where the USRP
maintains more knowledge of what is happening at the "SDR level" instead
of the "hardware I/O level") could benefit for some applications, such
as those that need RF-related metadata parameters that are time-aligned
with the data stream. I understand the architecture is what it is, but I
think it has even greater potential.

Jason