Back to UsrpFAQ

PageOutline

General Questions¶

The blinking LED¶

When the USRP is plugged in, the LED to the right of the USB controller blinks at a fast rate of about 3 times per second. Once a USRP application starts, that rate slows down to about 1 time per second. What controls the blinking of the LEDs?::
  The LEDs are controlled by the onboard FX2 USB controller.  When you first power the usrp up, a very small program is loaded out of the 256 byte EEPROM.  That code puts the AD9862's into a low-power state and runs a tight loop that blinks the led about 3 times per second. See [source:gnuradio/trunk/usrp/firmware/src/usrp2/eeprom_init.c usrp/firmware/src/usrp2/eeprom_init.c].

Once the "regular" firmware is loaded, the slow blinking is done in the timer interrupt service routine, isr_tick. See [source:gnuradio/trunk/usrp/firmware/src/usrp2/usrp_main.c usrp/firmware/src/usrp2/usrp_main.c]

"O" "U" "u" "a" in output¶

_ I see "O" "U" "u" "a" characters appear on the screen when I run my gnuradio program.  I understand they appear when data flow from USRP to PC is stopped or something.  I am curious what is the meaning of these characters is?  Does faster PC help reducing such data flow troubles? _::
  "u" = USRP

"a" = audio (sound card)

"O" = overrun (PC not keeping up with received data from usrp or audio card)

"U" = underrun (PC not providing data quickly enough)

aUaU  audio underrun (not enough samples ready to send to sound card sink)

uUuU  USRP underrun (not enough sample ready to send to USRP sink)

uOuO == USRP overrun (USRP samples dropped because they weren't read in time.

Yes, a faster machine will generally cure this problem.  This assumes that you're not asking the USB to do something that it can't.  In our best case, we sustain 32MB/s across the USB.  I suggest avoiding Intel Celeron or other "cache crippled" parts.

Does the number of 'uO's correspond to the number of samples dropped?¶

_ Does the number of 'uO's correspond to the number of samples dropped? _::

No.  Overrun detection is currently implemented by polling at approximately 10Hz.  If you're trying to receive constantly streaming data, you shouldn't see any uO's.

How the USRP boots¶

_ What happens after plugging in power and USB? What is the booting sequence? _::

The USRP itself contains no ROM-based firmware, merely a few bytes that specify the vendor ID (VID), product ID (PID) and revision. When the USRP is plugged in to the USB for the first time, the host-side library sees an un-configured USRP. It can tell it's un-configured by reading the VID, PID and revision. The first thing the library code does is download the 8051 code that defines the behavior of the USB peripheral controller. When this code boots, the USRP simulates a USB disconnect and reconnect.

When it reconnects, the host sees a different device: the VID, PID and revision are different. The firmware now running defines the USB endpoints, interfaces and command handlers. One of the commands the USB controller now understands is load the FPGA. The library code, after seeing the USRP reconnect as the new device, goes to the next stage of the boot process and downloads the FPGA configuration bit stream.

Once the firmware has been downloaded to the FX2, it sets an internal register and reboots itself, this time presenting custom product and vendor ID’s, which the host detects as the FX2 disconnecting followed by the connection of a custom USB device.

What tools are you using¶

_ What tools are you using to do the FPGA programming? And which tools did you use to layout the USRP motherboard? _::

The FPGA is programmed in Verilog, and compiled with Quartus from Altera. The motherboard layout was done in PADS, but the layout files are not distributed.  The schematics are done in gEDA.

Is 5V enough to power USRP¶

_ Can we use DC-DC converter with outputs 5V to power USRP? _::

The USRP motherboard can operate from 5V, but most of the daughterboards regulate the 6V down to 5V, so we really need about 5.5 to 5.75 V to operate correctly. Only the [[BasicRX]] and [[BasicTX]] really don't need 6V.  Everything else basically does.

Maximum supply voltage for the USRP¶

_  What is the maximum DC supply voltage for the USRP? Can we use 13.8V? _::

No, it isn't.  The USRP itself uses a linear regulator, so putting 13.8 V in will result in more than 10 additional watts being dissipated. Also, many of the capacitors on the daughterboards are sized for 6V input, and might blow with more than 10 V.

USRP motherboard fuse¶

_ What is USRP motherboard fuse rating? _::

The fuse size is 0603. Rating is 3Amps.

FPGA clock speed¶

_ I think the EP1C12Q240C8 FPGA runs at much higher clock speeds than 64MHz. _::

When the FPGA is routed, there isn't much more slack above the 64MHz for Fmax (or so I thought).

Control and Protocol¶

_ How control signaling is done? What is the protocol for it? How does it actually get translated and conveyed to the FPGA master_control module on FPGA, when I write code like..._::
 src = usrp.source_c (0, decim)
 src.set_rx_freq (0, IF_freq)
 src.set_pga(0,20)

Please take a look at the code in usrp_standard.{h,cc}, usrp_basic.{h,cc}, and usrp_prims.{h,cc}.  They all go over the USB as control messages to endpoint 0.  The control messages are parsed in the FX2 and acted upon.  Generally speaking they end up issuing transactions on the I2C bus or SPI bus.

The FPGA registers, AD9862 registers and daughterboards appear on the SPI bus. The configuration EEPROM’s and daughterboards appear on the I2C bus. See the USRP schematics for details. The [source:gnuradio/trunk/usrp/firmware/include/usrp_spi_defs.h usrp/firmware/include/usrp_spi_defs.h] contains the definition for the SPI bus. The [source:gnuradio/trunk/usrp/firmware/include/usrp_i2c_addr.h usrp/firmware/include/usrp_i2c_addr.h] contains the standard I2C addresses. Some daughterboards use others that are a function of which slot the daughterboard is plugged into.

Buffer size¶

_ How big are the USRP buffers? _::

The USRP has buffers at three points in the path:

On the host: currently 8MB TX, 8MB Rx. (   #FIXME#   )

On the Cypress FX2 USB peripheral: 2KB TX and 2KB Rx. (   #FIXME#   )

On the FPGA: 4KB TX and 4KB RX.

Buffering two RX Channels¶

_ When I have two RX Channels, then how exactly is the rx_buffer used to store and keep the data coming from 2 RX paths separated? _::

The different paths alternate in the FIFO.  The data is in this order: 

CH1-I

CH1-Q

CH2-I

CH2-Q

etc...

Configuration for 1 TX, 1RX¶

_ I wish to build just one RX with halfband filter and one TX. The present [source:gnuradio/trunk/usrp/fpga/toplevel/usrp_std/usrp_std.vh usrp_std.vh] has 2rx, 1tx or 4rx. What do I need to do to? _::

Edit the file config.vh , then uncomment the line:

 //@include "../include/common_config_1rxhb_1tx.vh" 

And comment the line:

 @include "../include/common_config_2rxhb_2tx.vh" 

By using “//”, this will now includes 1 TX and 1 RX with halfband filter.

Parameters controllable in Python¶

_ Things which could be controlled from Python on FPGA and AD/DA converters are:  _::
 Gains and Decimation Rate. Can bits/sample of AD/DA converters be controlled from python?  What else is controllable from Python?

The ADCs always sample at 12 bits.  The DACs are always 14 bits.  The data processed in the USRP is always 16 bits.  From python you can switch to 8-bit samples over the USB.  This allows you to double your sample rate make it (16MSPS).

control I2C, memory map, read EEPROM¶

_ I've been playing with the usrper application. I am able to read and write to the 9862 chips okay but all attempts at using i2c_read fail? What is the memory map? _::

I usually prefer to do this kind of experimentation from Python, but in any event you're probably using an invalid I2C address. See [source:gnuradio/trunk/usrp/firmware/include/usrp_i2c_addr.h usrp/firmware/include/usrp_i2c_addr.h].

Note also, that if what you're really trying to do is read the contents of one of the EEPROM's, you're much better off using read_eeprom.

From python: 
 u = usrp.sink_c(0)         # or u = usrp.source_c(0) 

 # returns a string 
 s = u.read_eeprom(i2c_addr, eeprom_offset, nbytes) 
 print s 

 # returns a string 
 s = u.read_i2c(i2c_addr, nbytes) 
 print s

transmit/receive switch delay¶

_ How we control auto transmit/receive switch delay? _::

This allows someone (from Python) to manually adjust the timing offset of the auto-transmit/receive switching to better align with the transmitted data when using an external transmit/receive switch.

In a previous code, the auto transmit/receive function would switch based on whether or not there was data in the transmit FIFO of the FPGA. Unfortunately, this would not take into account the pipeline delay of the FPGA interpolator and AD9862 DAC up converter. Depending on the interpolation ratio used in the transmit side, this could result in the ATR switching signal going high up to 25 us early, and going low up to 35 us before the data was completely transmitted. If someone were using a fast external Rx/Tx switch, this could result in slicing off the end of a transmission.

The new capability adds an independent, configurable delay to the rising and falling edges of the ATR signal, measured in clock ticks.  To use, once one has already configured ATR operation as needed, one needs to call two new daughterboard functions: 
 subdev.set_atr_tx_delay(clock_ticks_to_delay_tx) # Rising edge 
 subdev.set_atr_rx_delay(clock_ticks_to_delay_rx) # Falling edge 

 ...where 'subdev' is the object created for the daughterboard in use.

Unfortunately, the best way (right now) is to figure out what values to poke in here are to measure the offset on an oscilloscope between the onset of the ATR signal and the power output from the daughterboard.

We're working on a way to ask the FPGA itself what values should be set (or even set these by default), but haven't worked out yet the best way to do this.  Different external Rx/Tx switches have different needs so there isn't a one size fits all.

Empirically measured, though, the pipeline delay through the USRP transmit path is about 50 ticks + 3 ticks * interpolation rate. It seems the falling edge needs somewhat longer than this to completely drop to zero energy and this may be data dependent, so again, the best course is to measure with your particular application.

USRP Clock reference instability¶

_ What is the USRP Clock reference instability? _::

The clock has a 20 ppm specification, but at room temperature, It is typically within 5 ppm.

In-Band TX timestamps

• FX2 receives packet to be sent to FPGA
• FX2 sends entire 512 byte packet to the FPGA
• FPGA has state machine to process the packet which does the following
  • Check to be sure it can figure out where the packet has to go
  • Check to be sure the FIFO is not full
  • Read the length of the packet
  • Fill up the receiving FIFO until it is full or total length of packet has been reached
  • If the packet length was reached (which might be less than 512), skip the rest since it's padding
  • Else if the FIFO is full, loop and fill the FIFO until the packet length has been reached
• FPGA has command and channel state machines which does the following with the tx_cmd and tx_channel FIFOs
  • Read out timestamp and length from packet
  • Ensure timestamp is in the future
  • If timestamp is in the past, skip the rest of the packet and set the appropriate flag
  • Else wait until the current time is reached

_ How is the in-band TX timestamps expected to work? _::

• If current time is reached, send out the size of the packet

Temperature specifications¶

_ I was just wondering whether the USRP has got some temperature specs that I should take into account. *::

All of the chips in the USRP are specified over at least the 0-70C range.  At room temperature the USRP can run all-out continuously for days at a time.  Any enclosure should take the power consumption of the system into account.  This can be as high as 15-18 Watts depending on what daughterboards you use.

Loopback¶

_ Is the loopback interface working on the USRP, and how to enable it? _::

There is a loopback interface in the current FPGA code.  It's enabled by writing to the FR_MODE register.  Grep the verilog for "loopback", and look at fpga_regs_common.{h,v}

USB: 480MBit/sec => 32MByte/sec¶

_   I was wondering why can the USRP "only" achieve 32 MBytes/sec, i.e. 256  Mbits/sec whereas the USB 2.0 specifications are 480 MBits/sec? _:

The USRP easily does 256 megabits per second (32 megabytes/s).  The USB 2.0 raw signaling rate is 480 megabits per second, or 60 megabytes per second.  You can't get the full 480 because there is overhead from packet headers, time between packets, etc.  We could probably squeeze a little more bandwidth out of the bus, but it isn't a priority for now. The USRP needs data to go both ways, so there are some firmware delays in the 8-bit processor that runs in the interface chip.

If someone cared, it is probably possible to reprogram the firmware so that when no data is being transmitted, the automatic hardware mode is used.  The firmware would have to know, or be told, when to switch in and out of this mode.  But this would gain 25% more bandwidth!

RFX: 20MHz-wide signals¶

_ The USRP RFX boards have about 20 MHz bandwidth on both TX and RX sides, and can operate full duplex as long as you separate the TX and RX frequencies (TX and RX have separate PLL synthesizers). Is there a way to move 20MHz-wide signals between the host machine and the RFX? _::

20 MHz bandwidth indicates the width of the baseband filters.  Thus, you can tune digitally anywhere +/- 10 MHz from the LO.  If you use 16 bit samples, you can't get that much over the USB bus at once.

So why is 20 MHz useful?  Here are 3 example scenarios:

- You could simultaneously receive or transmit 2 separate signals which are 4 MHz wide each, which are separated by 12 MHz.

- You can use 8 bit samples, and get 16 MHz of bandwidth.  If you were a radio astronomer, you could use 4-bit samples and get 32 MHz of bandwidth.

- You could do a wideband modulation and demodulation in the FPGA.  You would be able to deal with much wider signals, and send a lower bit rate over the bus.

DC offset removal¶

_ The DC offset is automatically removed in hardware, but we can turn this feature off. Is there a software flag in the code I can switch it off? _::

See: [[UsrpFPGA|USRP FPGA] Under "Common Registers" [ 15 FR_DC_OFFSET_CL_EN DC offset control loop enable ]]

Back to UsrpFAQ