usrp-users@lists.ettus.com
Discussion and technical support related to USRP, UHD, RFNoC
View all threadsX310/UBX Retuning Performance
Largely: Yes; the UBX160 and UBX40 only differ in their baseband
filters' passive component values (see the schematics).
There's a bit of a difference on how you can clock the UBX on N210, but
that won't change behaviour all that much. Also, due to the 100 MHz
instead of X3xx's 200 MHz master clock rate, your timing granularity is
twice as bad :)
Best regards,
Marcus
On 24.02.2017 21:24, Dave NotTelling via USRP-users wrote:
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 mailto:usrp-users@lists.ettus.com> wrote:
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
<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
<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 <mailto:usrp-users@lists.ettus.com>>
wrote:
On 02/24/2017 01:24 PM, Michael West via USRP-users 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.
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
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
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
USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
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
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Thanks!
On Fri, Feb 24, 2017 at 3:32 PM, Marcus Müller via USRP-users <
usrp-users@lists.ettus.com> wrote:
Largely: Yes; the UBX160 and UBX40 only differ in their baseband filters'
passive component values (see the schematics).
There's a bit of a difference on how you can clock the UBX on N210, but
that won't change behaviour all that much. Also, due to the 100 MHz instead
of X3xx's 200 MHz master clock rate, your timing granularity is twice as
bad :)
Best regards,
Marcus
On 24.02.2017 21:24, Dave NotTelling via USRP-users wrote:
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:
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:
On 02/24/2017 01:24 PM, Michael West via USRP-users 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.
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
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 listUSRP-users@lists.ettus.comhttp://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
Hi Jason,
- 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.
no! You're the one that defines at which time tuning, and stream
starting should take place. There's nothing to query. You can also set
the device time to any arbitrary time you like. This is a very usual
thing to do: user sets device time to 0, tunes at 0.5s, starts streaming
at 1s, first retune happens at 1.5s, 2s, 2.5s and so on.
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).
Nonono! You're doing it wrong :) The link and host latency is
non-detetministic, so you must never think the time you've gotten from
the device using a get_time_now call is more of a rough indication.
What you do is take the metadata that the USRP gives you, including the
first sample timestamp, and the sample count.
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.
As said, since there's nothing to query, and all can be calculated from
absolute times that you are in control of, none of that applies :)
- 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).
Exactly!
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.
Very true. I'd have to scourge the source code for the command FIFO
depth (though I'd argue that if that happens to become an issue, we
might as well just increase that number. No negative side effects aside
from FPGA utilization I can think of), but you're right! The FIFO depth
is a very limiting factor here, especially since tuning, especially if
it involves both DSP and analog frontend, might be multiple commands at
once.
Let's do a rough calculation: take the highest sample rate, 200 MS/s, so
that the time we wait until we get a reasonable observation (a single
sample from frequency f_0 certainly doesn't make much sense). So, we're
doing the 500 µs discarding (that's 100k samples for the dustbin), then
acquire 128 samples, move on. So all reasonable rounding involved, 100k
Samples per tune. With 8 kB per network packet, and 4 B per sample,
that's 49 packets going in USRP->host direction, and then you'd need one
to four packets containing commands going in the other direction.
That does sound feasible, but it really might eventually break down,
since PCs aren't designed for that kind of hard real-time constraints.
Admittedly, I don't have an easy answer. Probably, the answer lies in
this being a special case where FPGA modifications might be the easiest
solution. It's not overly hard to implement that (a writer to the
settings bus), but it's something that might be relatively application
specific.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.
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.
I do, myself, technically lean a bit towards the side that USRPs should
be more autonomous in the sense that I really like when transactions
such as tuning are atomic. But it's a big step from our current
architecture, and I don't know whether RFNoC has made that easier from a
conceptual point of view to do "right". An interesting topic!
Best regards,
Marcus
On 02/24/2017 03:47 PM, Marcus Müller via USRP-users wrote:
Hi Jason,
- 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.
no! You're the one that defines at which time tuning, and stream
starting should take place. There's nothing to query. You can also set
the device time to any arbitrary time you like. This is a very usual
thing to do: user sets device time to 0, tunes at 0.5s, starts streaming
at 1s, first retune happens at 1.5s, 2s, 2.5s and so on.
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).
Nonono! You're doing it wrong :) The link and host latency is
non-detetministic, so you must never think the time you've gotten from
the device using a get_time_now call is more of a rough indication.
What you do is take the metadata that the USRP gives you, including the
first sample timestamp, and the sample count.
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.
As said, since there's nothing to query, and all can be calculated from
absolute times that you are in control of, none of that applies :)
I don't think I'm doing it wrong, I think the example that you cite,
where all of the tune times are known a priori, is a bit contrived. In
the situation I described, where I'm streaming data at frequency f1 and
want to tune to frequency f2, assume that said decision is made
asynchronously to the signal processing flow (for instance, via a human
operator clicking a button in a UI, or by some other means; the exact
mechanism isn't important, just the fact that the application doesn't
have any prior knowledge that it's going to want to make the tune happen
at this point).
In this situation, the logic that decides "I need to tune the radio now"
doesn't have high-precision knowledge of the timing of the data stream
(as you noted, the link and host latency is non-deterministic). In
addition, there could be buffering at many stages of processing that
would make it undesirable to just say something like "the current device
time is the time of the last sample I got, plus one sample delta." The
most robust way seems to be the approach of reading the time out of the
device, adding some delay, and commanding the tune.
If there's a better way to accomplish this, I'm all for it, but I don't
see how you would be able to take a tuning decision that is asynchronous
with the data stream and safely communicate it to the device using timed
commands, which are inherently synchronous with the data stream.
Jason
Hi Jason,
On 24.02.2017 22:02, Jason Roehm via USRP-users wrote:
I don't think I'm doing it wrong,
ah sorry, that came out wrong. I didn't mean to say you're personally
doing it wrong. Just that you must never rely on get_time_now's value
when scheduling something
I think the example that you cite, where all of the tune times are
known a priori, is a bit contrived.
It really is not. That's what I, and a lot of other people, are doing.
In the situation I described, where I'm streaming data at frequency f1
and want to tune to frequency f2, assume that said decision is made
asynchronously to the signal processing flow (for instance, via a
human operator clicking a button in a UI, or by some other means; the
exact mechanism isn't important, just the fact that the application
doesn't have any prior knowledge that it's going to want to make the
tune happen at this point).
That's a very usual thing, I agree. For example, when you receive some
frequency-agile standard, that based on anything, might decide to switch
channels. (compared to clicking, where we have hundreds of milliseconds
tolerance)
In this situation, the logic that decides "I need to tune the radio
now" doesn't have high-precision knowledge of the timing of the data
stream (as you noted, the link and host latency is non-deterministic).
Link latency is non-deterministic, but sampling rate is not. You always
know how many samples you've received, and you know the time you
received the first one. You've got a fairly good idea of "how late" it
is on the device without explicitly asking. All you'll need to do is
take that time, add enough security margin for the host OS and link
latency to not break everything, and use that as the next command time.
You take note of that time and issue the timed tune command. Really,
nothing magical happening here. Yes, you'll need to keep tab of your own
commands, but that's a pretty low cost, both on CPU and on application
performance compared to having a separate high-rate sidechannel! Think
about all the synchronization you'd have to do with that side channel if
you needed to coordinate two USRPs with the same device time, but as
usual non-deterministic link latencies!
Really, your only way out of the synchronization dilemma is being the
one who sets the command times. And if you already set them, it's
relatively easy to keep track of them.
In addition, there could be buffering at many stages of processing
that would make it undesirable to just say something like "the current
device time is the time of the last sample I got, plus one sample
delta." The most robust way seems to be the approach of reading the
time out of the device, adding some delay, and commanding the tune.
If there's a better way to accomplish this, I'm all for it, but I
don't see how you would be able to take a tuning decision that is
asynchronous with the data stream and safely communicate it to the
device using timed commands, which are inherently synchronous with the
data stream.
Well, positively putting it: it works for most people! Looking at it a
bit more critical: you're right, this is a non-trivial problem. But as
long as PC OSes are not real-time systems, you don't want to rely on
timely command delivery, so you have to define the command times
sufficiently before the event should take place. That's where the
proverbial snake bites its tail: if you're the one defining the time,
you should also be the one telling your application when things happened.
Of course, I'd also agree it'd be nice if we had some great and easy way
to annotate the sample stream with more metadata than just the timestamp
of the first sample in a sample packet. But that's a conceptually hard
problem, because that would either require multiple independent streams,
of which synchronization will be a serious performance bottleneck¹, OR
flexible-length headers, which break a lot of comfortable deterministic
behaviour that again, will make the data handling a lot less efficient.
So, I'd say, the case where you can't know beforehand when you want
something to happen and need the USRP to tell you is probably a corner case.
In fact, if you compare the timings of LTE and UMTS, you'll notice that
the cellular standards reflect exactly that sentiment: Though data rates
and analog bandwidths went up, the latency constraints for the radio
hardware to react didn't go down – they instead got longer! That means
that it's more realistic that you can have software deal with your
protocol stack, since that software has enough time to receive the
digital signal, decode it sufficiently to know what the reaction needs
to be, calculate the time of that reaction (notice that mobile standards
have things like timing advances to adjust to different path lengths, so
this is not static), issue the necessary commands to hardware and
generate and send the response.
I hope that illustrates how well you can actually fare with the
"proactive" command time vs the "reactive" sidechannel approach.
Best regard,
Marcus
¹ Feel invited to benchmark a multi-USRP streaming application. You'll
notice UHD spends most CPU cycles getting data out of the network
packets into a number format the CPU can deal with, but second to that
is usually keeping streams in sync.
Can performance mode help with the > 100ms tuning time between the two
bands? I seem to recall the performance mode setting relating to when the
unused PA is powered off. Also, is the long tuning time something that the
UHD code causes or is that just a number that the developer should keep in
mind when switching bands?
Thanks!
On Fri, Feb 24, 2017 at 3:41 PM, Dave NotTelling dmp250net@gmail.com
wrote:
Thanks!
On Fri, Feb 24, 2017 at 3:32 PM, Marcus Müller via USRP-users <
usrp-users@lists.ettus.com> wrote:
Largely: Yes; the UBX160 and UBX40 only differ in their baseband filters'
passive component values (see the schematics).
There's a bit of a difference on how you can clock the UBX on N210, but
that won't change behaviour all that much. Also, due to the 100 MHz instead
of X3xx's 200 MHz master clock rate, your timing granularity is twice as
bad :)
Best regards,
Marcus
On 24.02.2017 21:24, Dave NotTelling via USRP-users wrote:
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:
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/exampl
es/test_timed_commands.cpp#L96
An example of starting streaming at a set time:
https://github.com/EttusResearch/uhd/blob/master/host/exampl
es/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:
On 02/24/2017 01:24 PM, Michael West via USRP-users 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.
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
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 listUSRP-users@lists.ettus.comhttp://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
bump
On Fri, Mar 3, 2017 at 10:27 AM, Dave NotTelling dmp250net@gmail.com
wrote:
Can performance mode help with the > 100ms tuning time between the two
bands? I seem to recall the performance mode setting relating to when the
unused PA is powered off. Also, is the long tuning time something that the
UHD code causes or is that just a number that the developer should keep in
mind when switching bands?
Thanks!
On Fri, Feb 24, 2017 at 3:41 PM, Dave NotTelling dmp250net@gmail.com
wrote:
Thanks!
On Fri, Feb 24, 2017 at 3:32 PM, Marcus Müller via USRP-users <
usrp-users@lists.ettus.com> wrote:
Largely: Yes; the UBX160 and UBX40 only differ in their baseband
filters' passive component values (see the schematics).
There's a bit of a difference on how you can clock the UBX on N210, but
that won't change behaviour all that much. Also, due to the 100 MHz instead
of X3xx's 200 MHz master clock rate, your timing granularity is twice as
bad :)
Best regards,
Marcus
On 24.02.2017 21:24, Dave NotTelling via USRP-users wrote:
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:
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/exampl
es/test_timed_commands.cpp#L96
An example of starting streaming at a set time:
https://github.com/EttusResearch/uhd/blob/master/host/exampl
es/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:
On 02/24/2017 01:24 PM, Michael West via USRP-users 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.
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
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 listUSRP-users@lists.ettus.comhttp://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
Anyone have any information about whether or not changing to performance
mode from power save will help speed up the transition between the two
bands?
On Mon, Mar 6, 2017 at 12:37 PM, Dave NotTelling dmp250net@gmail.com
wrote:
bump
On Fri, Mar 3, 2017 at 10:27 AM, Dave NotTelling dmp250net@gmail.com
wrote:
Can performance mode help with the > 100ms tuning time between the two
bands? I seem to recall the performance mode setting relating to when the
unused PA is powered off. Also, is the long tuning time something that the
UHD code causes or is that just a number that the developer should keep in
mind when switching bands?
Thanks!
On Fri, Feb 24, 2017 at 3:41 PM, Dave NotTelling dmp250net@gmail.com
wrote:
Thanks!
On Fri, Feb 24, 2017 at 3:32 PM, Marcus Müller via USRP-users <
usrp-users@lists.ettus.com> wrote:
Largely: Yes; the UBX160 and UBX40 only differ in their baseband
filters' passive component values (see the schematics).
There's a bit of a difference on how you can clock the UBX on N210, but
that won't change behaviour all that much. Also, due to the 100 MHz instead
of X3xx's 200 MHz master clock rate, your timing granularity is twice as
bad :)
Best regards,
Marcus
On 24.02.2017 21:24, Dave NotTelling via USRP-users wrote:
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:
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/exampl
es/test_timed_commands.cpp#L96
An example of starting streaming at a set time:
https://github.com/EttusResearch/uhd/blob/master/host/exampl
es/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:
On 02/24/2017 01:24 PM, Michael West via USRP-users 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.
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
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 listUSRP-users@lists.ettus.comhttp://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
Hi Dave,
Sorry for the delay. Performance mode is the default mode and will not
help speed up the transition. One option is to have a pair of UBX boards
with one on the low band and one on the high band.
Regards,
Michael
On Wed, Mar 8, 2017 at 4:54 AM, Dave NotTelling via USRP-users <
usrp-users@lists.ettus.com> wrote:
Anyone have any information about whether or not changing to performance
mode from power save will help speed up the transition between the two
bands?
On Mon, Mar 6, 2017 at 12:37 PM, Dave NotTelling dmp250net@gmail.com
wrote:
bump
On Fri, Mar 3, 2017 at 10:27 AM, Dave NotTelling dmp250net@gmail.com
wrote:
Can performance mode help with the > 100ms tuning time between the two
bands? I seem to recall the performance mode setting relating to when the
unused PA is powered off. Also, is the long tuning time something that the
UHD code causes or is that just a number that the developer should keep in
mind when switching bands?
Thanks!
On Fri, Feb 24, 2017 at 3:41 PM, Dave NotTelling dmp250net@gmail.com
wrote:
Thanks!
On Fri, Feb 24, 2017 at 3:32 PM, Marcus Müller via USRP-users <
usrp-users@lists.ettus.com> wrote:
Largely: Yes; the UBX160 and UBX40 only differ in their baseband
filters' passive component values (see the schematics).
There's a bit of a difference on how you can clock the UBX on N210,
but that won't change behaviour all that much. Also, due to the 100 MHz
instead of X3xx's 200 MHz master clock rate, your timing granularity is
twice as bad :)
Best regards,
Marcus
On 24.02.2017 21:24, Dave NotTelling via USRP-users wrote:
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:
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/exampl
es/test_timed_commands.cpp#L96
An example of starting streaming at a set time:
https://github.com/EttusResearch/uhd/blob/master/host/exampl
es/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:
On 02/24/2017 01:24 PM, Michael West via USRP-users 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.
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
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 listUSRP-users@lists.ettus.comhttp://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
Well poop. Thank you for the information!
On Wed, Mar 8, 2017 at 11:28 AM, Michael West michael.west@ettus.com
wrote:
Hi Dave,
Sorry for the delay. Performance mode is the default mode and will not
help speed up the transition. One option is to have a pair of UBX boards
with one on the low band and one on the high band.
Regards,
Michael
On Wed, Mar 8, 2017 at 4:54 AM, Dave NotTelling via USRP-users <
usrp-users@lists.ettus.com> wrote:
Anyone have any information about whether or not changing to performance
mode from power save will help speed up the transition between the two
bands?
On Mon, Mar 6, 2017 at 12:37 PM, Dave NotTelling dmp250net@gmail.com
wrote:
bump
On Fri, Mar 3, 2017 at 10:27 AM, Dave NotTelling dmp250net@gmail.com
wrote:
Can performance mode help with the > 100ms tuning time between the two
bands? I seem to recall the performance mode setting relating to when the
unused PA is powered off. Also, is the long tuning time something that the
UHD code causes or is that just a number that the developer should keep in
mind when switching bands?
Thanks!
On Fri, Feb 24, 2017 at 3:41 PM, Dave NotTelling dmp250net@gmail.com
wrote:
Thanks!
On Fri, Feb 24, 2017 at 3:32 PM, Marcus Müller via USRP-users <
usrp-users@lists.ettus.com> wrote:
Largely: Yes; the UBX160 and UBX40 only differ in their baseband
filters' passive component values (see the schematics).
There's a bit of a difference on how you can clock the UBX on N210,
but that won't change behaviour all that much. Also, due to the 100 MHz
instead of X3xx's 200 MHz master clock rate, your timing granularity is
twice as bad :)
Best regards,
Marcus
On 24.02.2017 21:24, Dave NotTelling via USRP-users wrote:
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:
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/exampl
es/test_timed_commands.cpp#L96
An example of starting streaming at a set time:
https://github.com/EttusResearch/uhd/blob/master/host/exampl
es/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:
On 02/24/2017 01:24 PM, Michael West via USRP-users 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.
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
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 listUSRP-users@lists.ettus.comhttp://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