USRP tuning time

Rafa_F · August 9, 2015, 7:05pm

Dear all,

After quite some searching, I wasn’t able to find information about how
long it takes to retune a USRP (say, change the centre frequency). Do
you guys know anything about that? Specifically, I’m using a USRP X300
with a UBX160 daughterboard. Does anyone know how long it takes in this
specific setup to retune the daughterboard to a different centre
frequency?

Kind regards and many thanks,
Mat

okcomputer · August 9, 2015, 8:03pm

Hi Mat,

the answer is a bit more complicated, I’m afraid:

so first of all, we need to distinguish latency from time it takes to
tune.
Latency happens if you want the device to tune as soon as possible, and
will be mainly dominated by the latency of your general purpose OS
running on your general purpose computer. It wildly varies, but good
estimates on a properly configured PC might be around 5ms; your actual
time might be different.

Now, you can /hide/ that latency by using timed commands if you know in
advance when you want your tuning process to start. Then all there’s
left is the “invalid” signal during the time the device actually tuned.

USRPs have a two-stage tuning: You get the configurable synthesizer that
generates the LO for mixing down (and up), and you have the digital
frequency shifter [1].
The digital tuning happens /almost/ instantly. Basically, the moment the
right register is set, the CORDIC uses a different phase increment [2];
that can happen at every clock cycle of the master clock (ie. 200MHz by
default on X300)[2].

Then, there’s the analog part. That’s where things get tricky, because
a) we now have to take the time into account it takes to tell the LO
synthesizer what we want to do, and b) the time it takes for the
synthesizer to get stable, and c) there might be DC offset filters that
might distort your signal.

a) communication time

This depends on the synthesizers used. The UBX uses MAX2871
synthesizers. These are SPI chips; from the top of my head I don’t know
at which rates the bus is clocked, but let’s assume it’s “sufficiently
fast” (>>1Mb/s). So let’s subsume that with 20?s max.
Now a speciality for the UBX: if the LO synthesizer you want to tune is
turned off, it must be started first. Typically, you’d only have that at
initialization, but since the UBX spans so much spectrum, different
clock lines have been introduced, and hence, a separate synthesizer for
frequencies below and above 500MHz each. So when crossing that boundary,
assume at least 20ms additional startup time.

b) analog/real-world hardware stuff

Things get tricky here, and I can’t actually give you a definite answer.
Tuning speed depends on too many factors, some of which aren’t even
controllable. Looking through datasheets and at the loop filter
components, I’d say a locking time of up to 100?s might be realistic.
However, that’s a bit up to you as user; the less accuracy you need, the
shorter you can wait for the LO to successfully lock. After all,
“locked” is just the notion that PLL oscillations have dropped below an
arbitrary level.

_c) DC offset filtering
_
RX only:
To eliminate the DC offset that the ADC might measure, there’s a DC
offset filter. It’s an IIR whose sole accumulator gets reset at every
tune. Depending on how far the real DC offset is from 0, the IIR’s step
response might or might not be visible for up to 40ms, if I remember
correctly. You can disable the DC offset removal, however, with the
multi_usrp::set_rx_dc_offset(false); however, DC offset removal is then
up to you; this might or might not be a problem for your application.

Best regards,
Marcus

[1]
http://files.ettus.com/manual/page_general.html#general_tuning_process
[2a]

github.com

EttusResearch/fpga/blob/master/usrp3/lib/dsp/duc_chain.v#L41


      
          );
          
          
genvar 	 i;
          
          

          
wire [17:0] scale_factor;
          wire [31:0] phase_inc;
          reg [31:0]  phase;
          wire [7:0]  interp_rate;
          wire [3:0]  tx_femux_a, tx_femux_b;
          wire        enable_hb1, enable_hb2;
          wire        rate_change;
          
          
setting_reg #(.my_addr(BASE+0)) sr_0
            (.clk(clk),.rst(rst),.strobe(set_stb),.addr(set_addr),
             .in(set_data),.out(phase_inc),.changed());
          
          
setting_reg #(.my_addr(BASE+1), .width(18)) sr_1
            (.clk(clk),.rst(rst),.strobe(set_stb),.addr(set_addr),
             .in(set_data),.out(scale_factor),.changed());

[2b]

github.com

EttusResearch/fpga/blob/master/usrp3/lib/dsp/duc_chain.v#L82


      
          		 .strobe_fast(strobe_hb2_pre),.strobe_slow(strobe_hb1_pre) );
          
          
   always @(posedge clk) strobe_hb1 <= strobe_hb1_pre;
             always @(posedge clk) strobe_hb2 <= strobe_hb2_pre;
             always @(posedge clk) strobe_cic <= strobe_cic_pre;
          
          
   // NCO
             always @(posedge clk)
               if(rst)
                 phase <= 0;
               else if(~run)
                 phase <= 0;
               else
                 phase <= phase + phase_inc;
          
          
   wire        signed [17:0] da, db;
             wire        signed [35:0] prod_i, prod_q;
          
          
   wire [17:0] i_interp, q_interp;
          
          
   wire [17:0] hb1_i, hb1_q, hb2_i, hb2_q;

[2c]

github.com

EttusResearch/fpga/blob/master/usrp3/lib/dsp/duc_chain.v#L193


      
             cic_interp  #(.bw(18),.N(4),.log2_of_max_rate(7))
               cic_interp_q(.clock(clk),.reset(rst),.enable(run & ~rate_change),.rate(interp_rate),
          		  .strobe_in(strobe_cic),.strobe_out(1'd1),
          		  .signal_in(hb2_q),.signal_out(q_interp));
          
          
   localparam  cwidth = WIDTH;  // was 18
             localparam  zwidth = 24;  // was 16
          
          
   wire [cwidth-1:0] da_c, db_c;
             //
             // Note. No head room has been added to the CORDIC to accomodate gain in excess of the input signals dynamic range.
             // The CORDIC has algorithmic gain of 1.647, implementation gain of 0.5 and potential gain associated with rotation of 1.414.
             // Thus the CORDIC will overflow when rotating and an input CW with (clipped) effective amplitude of 1.22 is applied.
             //
             cordic_z24 #(.bitwidth(cwidth))
               cordic(.clock(clk), .reset(rst), .enable(run),
          	    .xi({i_interp,{(cwidth-18){1'b0}}}),.yi({q_interp,{(cwidth-18){1'b0}}}),
          	    .zi(phase[31:32-zwidth]),
          	    .xo(da_c),.yo(db_c),.zo() );
          
          
   MULT_MACRO #(.DEVICE(DEVICE),  // Target Device: "VIRTEX5", "VIRTEX6", "SPARTAN6","7SERIES"

[2d]

github.com

EttusResearch/fpga/blob/master/usrp3/lib/dsp/cordic_z24.v

// -*- verilog -*-
//
//  USRP - Universal Software Radio Peripheral
//
//  Copyright (C) 2003, 2007 Matt Ettus
// 
//  SPDX-License-Identifier: LGPL-3.0-or-later
//

//

module cordic_z24(clock, reset, enable, xi, yi, zi, xo, yo, zo );
   parameter bitwidth = 16;
   parameter stages = 19;
   localparam zwidth = 24;
   
   input clock;
   input reset;
   input enable;
   input [bitwidth-1:0] xi, yi;

This file has been truncated. show original

okcomputer · August 10, 2015, 2:00pm

hey man,

many many thanks for the detailed reply! Based on it, I decided to
achieve frequency hopping not by changing the centre frequency of the
USRP, but by multiplying my signal with a sine of a certain frequency
offset and then transmit that signal over the USRP with a fixed USRP.
Unfortunately, a new problem has arisen. you can see my flowgraph
attached

I want my signal to be transmitted on 5.804GHz. to this end, the centre
frequency is set to 5.799GHz, and the signal that I wish to transmit is
multiplied with a sine wave of 5MHz. (I’m storing everything as a file
before transmitting, as things are otherwise too slow). The problem now
is that when I transmit the signal over the USRP, it is not transmitted
on 5804 MHz but on approx. 5802 MHz. Furthermore, this error appears to
become bigger with bigger frequency offsets: When I want the signal to
be transmitted with 20MHz offset to the centre frequency of the usrp
(thus using a sine wave of 20MHz), the difference between the intended
signal frequency and the true signal frequency is almost 10 MHz!

Am I doing anything wrong here??

kind regards and thanks so much,
Mat

okcomputer · August 10, 2015, 3:05pm

well here’s the thing: I need to transmit a burst every 7ms (in each
burst transmit 37bytes at 1 MBit/s). From what
you’ve written about tuning times, i got somewhat pessimistic as to
whether this is enough time to retune. Or would you say that this should
be enough?

okcomputer · August 10, 2015, 3:25pm

I’d just try. Clearly, physically retuning is bad in this case, but if
you haven’t tried with the stream tag approach, you should.

Other than that, I think a relatively small patch to the USRP sink would
add a tx_tune tag, doing the same as the message of the same name,
namely allowing you to specify exactly how you want to tune
(DSP/analog).

Best regards,
Marcus

okcomputer · August 10, 2015, 3:36pm

Hell. I haven’t tried this, but:
If you’re building GNU Radio from source, you can use this:

ie. in your gnu radio directory do something like (assuming you’re on
the master branch)

git pull GitHub - marcusmueller/gnuradio: GNU Radio
uhd_add_tx_tune_tag_handling

Best regards,
Marcus

PS: You’re a regular poster now. Get rid of ruby-forum and directly sign
up for the mailing list!
Ruby-Forum doesn’t properly reply to the mail you content-wisely reply
reliably.

okcomputer · August 10, 2015, 3:00pm

Hi Mat,

I decided to achieve frequency hopping not by changing the centre
frequency of the USRP, but by multiplying my signal with a sine of a
certain frequency offset and then transmit that signal over the USRP
with a fixed USRP.
That’s cool, but it’s exactly what the FPGA of the USRP would have done
for you if you just used DSP tuning; but without having to use the full
sampling rate that covers the whole analog band. I do agree, it’s often
easier to implement things this way, because everything stays within
control of your software.

The errors you describe sound like your USRP is actually running at a
different rate than what you’ve set. And in fact, the 150MHz you set are
not a rate that is possible with any master clock rate. You’ll need to
use an integer factor of your master clock rate, which by default is
200MHz (but can also be configured to be 120MHz or 184.3MHz). So
possible rates are 200MS/s / 1, 200MS/s / 2, 200MS/s / 3 and so on. The
console output of your script should actually tell you that the rate is
unsupported and a different rate was used.

I’d say that it might really be a good choice to let the FPGA do this;
it’s nothing you must task your CPU with if your USRP can do it! In
fact, it would not be overly hard to add the DSP-only tuning via stream
tags to the USRP sink, but since this might solve your problem
sufficiently well, why don’t you try adding stream tags? For example,
replace your sinus source with a vector source with a constant list as
value (e.g. [1.0] * 1000* 3000) and a tags parameter, like the
following:

[ gr.tag_utils.python_to_tag( (n1000, pmt.intern(“tx_freq”),
pmt.from_double(2.5e9 + n1000), pmt.intern(“src”)) ) for n in
xrange(3000) ]

that should instruct the USRP sink to tune every 1000 samples. That way,
you don’t have to interpolate to the full physical DAC rate, but just
enough to allow your frequency mod to work (which probably is much much
less).

Best regards,
Marcus