the contents of this page refer to the original raw ethernet implementation of the usrp2 firmware and may not accurately reflect currently used configurations. all current users should upgrade to uhd firmware and drivers.
http://code.ettus.com/redmine/ettus/projects/uhd/wiki
please refer to the ettus research website for information on current products.
http://www.ettus.com/products
this wiki page remains available for legacy users and archival purposes.
usrp1
usrp2
interface
usb 2.0
gigabit ethernet
fpga
ltera ep1c12
xilinx spartan 3 2000
rf bandwidth to/from host
8 mhz @ 16bits
25 mhz @ 16bits
cost
$700
$1400
adc samples
12-bit, 64 ms/s
14-bit, 100 ms/s
dac samples
14-bit, 128 ms/s
16-bit, 400 ms/s
daughterboard capacity
2 tx, 2 rx
1 tx, 1 rx
sram
none
1 megabyte
power
6v, 3a
xc3s2000-5fgg456, that is the spartan 3 2000, fast speed grade (-5), 456 pin bga package.
no, a single usrp2 can only support either
1 rx and 1 tx daughterboard.
or
1 transceiver daughterboard
you would need two usrp2s linked with a mimo cable in order to have 2 coherent receivers. the exception is if you use your own external rf downconverters, in which case you can connect two of them to one basicrx.
please note that the usrp2 uses a spartan 3-2000 chip. this means that if you intend to do your own fpga development, you need to use the full version of the xilinx tools in order to generate an image for it. you cannot use the free web pack version. thus
there are several options for you:
just use the prebuilt fpga images we provide
purchase the full version of ise from xilinx
get a 60 day demo version from the xilinx web site
convince your xilinx apps engineer to get you a free copy
universities often get the tools free of charge
release your changes to the community and we can find some sort of way to build them for you (if anybody wants to work on putting together some scripts to do this automatically, let me know).
there are 3 things necessary to get mimo working.
1. all systems need to be phase-locked to a common clock (10 mhz in this case)
2. all systems need to have a common time reference (often a 1 pps signal) so that they know which sample in one system corresponds to which sample in the other
3. all the data needs to come from / go to the same place
the mimo expansion interface on the usrp2 carries all 3 of those.
scenario 1 - two usrp2 systems connected by a mimo cable:
the master usrp2 is the one connected to both ethernet and the mimo cable.
the slave usrp2 is the one connected to just the mimo cable.
the master provides a clock to the slave over the mimo cable.
the master provides the time reference to the slave over the mimo cable.
on transmit, the host sends all data over the ethernet to the master.
the master uses the data which is intended for the master, and passes the data for the slave over the mimo cable.
on receive, the slave sends all data over the mimo cable to the master, and the master passes it back to the host over ethernet. it also sends its own data over the ethernet to the host.
the firmware and host driver code to do this is not ready yet, but is in progress. (14 november 2008)
scenario 2 - up to four usrp2 systems connected by mimo cables to the not-yet-in-existence hub:
the hub has a big fpga on it.
the hub provides clock and time reference to all usrp2 systems.
the hub communicates with the host computer by ethernet or pci express, or operates standalone.
all usrp2 systems send data back and forth to the hub.
the hub is not ready yet, but the design is in progress. we hope to have it ready in 9-12 months. (14 november 2008)
scenario 3 - an arbitrary number of usrp2 systems, no mimo cables, no hub:
some means of providing the same 10 mhz reference to all usrp2 systems must be set up. typically this would be the 10 mhz output of some lab reference like a gps-locked reference. that reference would be put through some sort of active splitter, and fed
into all the usrp2s by sma connector on the front panel.
some means of providing the same time reference to all usrp2 systems is also needed. this would normally be a 1 pps signal generated by the same reference. it will need to go through some sort of active splitter and send into the pps input of all the usrp2
systems.
all the usrp2 systems will need to be connected to the host computer by gigabit ethernet. you can probably use an ethernet switch, but there will be issues with sharing the bandwidth.
the firmware to do this is ready. the host code to do it is not ready yet. (14 november 2008)
the usrp2 uses a 100 mhz clock internally. that clock will be locked to the 10 mhz reference you provide.
samples can be time stamped, and that time can be calibrated to the 1 pps signal. in the most general case, that 1 pps input just goes directly to the fpga, so internally you can do whatever you want with it.
the 1 pps input goes to an fpga pin, so you can program the fpga to do whatever you want. this includes accepting faster sync pulses, encoded timestamps, morse code, etc.
the reference input can take a square or sine wave input that is dc-blocked and terminated in 50 ohms. the input should be less than 3v pk-pk.
the pps input is not dc blocked. it is ac terminated in 50 ohms, dc terminated in 1k ohms. the digital signal you put in should be between 0 and 5 v. it should never go below 0v and never above 6v.
the pps signal should be synchronous to the 10 mhz reference. nearly any gps frequency reference should work. everything fromhttp://jackson-labs.com would
suffice.
it's there as a tx buffer for iq data, so you can use timestamped tx packets to say "send this data at exactly time x". previously it wasn't used, so if you didn't update your fpga image for a long time, it may be not used at all.
the mimo connector brings the frequency reference from one usrp2 to the other. if you wish to use an external frequency reference to lock both usrp2s, you would feed it to the first usrp2, and the mimo connector will deliver it to the 2nd.
not directly. eventually, we will be selling another device to allow you to connect more than 2 usrp2s together (most likely 4), but for now you would be limited to 2.
when the 4-way usrp2 link device discussed above is used, and each usrp2 is used with 2 separate rf channels via the basicrx and basictx,
you would get 8 channels.
usually the 2 are used for i and q from the downconverters, but you can use them separately as well by using the basicrx.
actually, you can use 100 mhz as well, you will just need to change one line of the firmware to set the r-divider on the pll. you can use any frequency for which the following equation has a solution:
the internal clock (a very clean vcxo) is locked to the external reference if one is applied. you have a lot of flexibility in selecting the reference frequency (see previous question), but you cannot pull the vcxo further than a few khz, and you cannot
use the reference as the main system clock. so there is no way, for example, to put in a 120 mhz clock and have everything run off of that. you are basically stuck with 100 mhz unless you are willing to solder.
if you are willing to do some soldering, there are pin-compatible vcxos in other frequencies which are available. the part is the cvhd950 from crystek, and you can get them from mouser. note than anything over 100 mhz may make it hard to get the fpga to
meet timing requirements. also, the adc is only specified to 105 mhz, but there is a pin-compatible version spec'ed to 125 mhz.
the 10 mhz reference input on the front is optional. if you connect it and enable locking, the 100 mhz main oscillator will lock to it, otherwise it will free run. everything inside the fpga runs at 100 mhz (dsp) or 50 mhz (processor).
there is also a 10 mhz reference clock sent out on the mimo connector. when turned on, it will be the 100 mhz clock divided down by 10.
it's done with an open source mac implemented in the fpga and a national semicondutor phy chip, dp83865.
the cpld (a xilinx xc9572) reads the first megabyte from the sd card and
writes it to the fpga config pins in slave-serial mode. once the fpga is
configured, it requests the firmware for the aemb processor from the sd
card. after that, the cpld is switched over to passthru mode, and the
fpga has direct access to the sd card under program control.
the main adc is the dual 14-bit ltc2284, used at 100 ms/s. there is an auxiliary 2 channels, 12-bit
adc (the ad7922) for each dboard connector.
the main dac is the dual 16-bit ad9777 fed with 100 ms/s and produces 400 ms/s based analog output. the auxiliary dacs are the dual 12-bit ad5623.
the same usrp1 16 digital ios, spi, and i2c to each daughterboard connector. the whole interface to the daughterboards is the same as the usrp1, except instead of it being implemented all in the ad9862, it is done with the following set:
ltc2284
ad9777
2x ad5623
2x ad7922
the ddcs are very similar to the usrp1 with
a 4 stage cic but with 2 hbf filters. the cic can decimate in the range [1..128]. the high rate hbf has 7 taps and it decimates by 2. the low rate hbf has 31 taps and also decimates by 2.
again, very similar. there us
a 4 stage cic and 2 hbf filters each working in interpolation mode.
it is identical to the one of the interpolator, see above.
i will explain the rx side, the tx side is basically the same.
small_hb_dec is the short filter which works at the higher rate. there are 2 of them instantiated, one for i and one for q. it has 7 taps. one of those taps is the center tap which only requires a shift and not a multiply, and 2 of those taps are zeros.
that leaves 4 taps. the taps are symmetric, which leaves 2 multiplies per output. since we have at least 2 cycles to produce each output, we can use a single multiplier.
hb_dec is 2nd halfband filter and it works at the lower rate. there are 2 of them instantiated, one for i and one for q. it has 31 taps. one of those taps is the center tap which only requires a shift and not a multiply, and half of the remainder are zeros.
that leaves 16 taps. they are symmetric, so that means we need to do 8 multiplies to produce each output. there are at least 4 cycles to produce each output, so we need to do 2 multiplies at a time.
one of those multipliers does the "outer" coefficients, meaning the ones at the very beginning and end of the impulse response, and one does the "inner" coefficients, meaning the ones around the center of the impulse response. this division is purely an
implementation choice, and does not affect the output. i could have put the odd ones on one mult and the even ones on the other, or any other split you could imagine. it doesn't matter.
minimum interpolation and decimation is 4 and maximum is 512. if you use odd decimation or interpolation, you just get a cic with no halfbands. if you use an even rate but not a multiple of 4, you just get one halfband (the low rate one). if your rate is
a multiple of 4, you use both halfbands.
the fpga talks to the dac at 100 ms/s just like it talks to the adc at 100 ms/s. the interpolation from 100 ms/s to 400 ms/s happens inside the dac chip itself. unless you are doing something fancy, you can think of the
dac as operating at 100 ms/s.
the primary reason for the x4 interpolation to 400 ms/s is to simplify the analog reconstruction filters. it also allows for a coarse modulation up to 150 mhz, but i don't anticipate that being used very often.
the standard usrp2 fpga image does not use ip, just raw ethernet.
no, but we have our own, find_usrps
about 20 ppm unless you lock to an external reference.
44 mhz is the highest frequency in the first nyquist zone on the usrp1.
much higher frequencies can be used in the higher zones. the usrp2 takes 100 ms/s rates and interpolates up to 400 ms/s. direct
frequencies up to ~170 mhz should be usable. the code that initializes the dac is in u2_init.c
currently, overruns are shown on the uart port and not on the host. they
are shown with a "o". the reality is that you should never see them.
if the host computer can't keep up, you will see an "s" messages in the
terminal on the host that indicates a sequence number error.
under runs are shown on the uart port as "u".
in the fpga code, the tx_control.v and rx_control.v show inband
signalling, dsp_core_rx and dsp_core_tx show the dsp, and u2_core.v is
the top level. in the firmware, start with txrx.c.
37 out of 40 block rams, 16 or 18 of the 40 multipliers, and about 35 to
40% of the logic area.
the serial is ttl level with 230400 baud, 8n1 format
the scaling itself is done in the dsp pipeline in the fpga.
the aemb processor is a fully synthesized cpu that forms the heart of
the usrp2 fpga system-on-a-chip design. it performs configuration and
status reporting for all the fpga peripherals, manages the control
channel for the gbe transport, and handles rf daughterboard operation.
it does not perform any dsp functions; these are done purely in logic
in the dsp rx and tx pipelines. it is clocked at 50 mhz, half the
system clock rate.
the usrp2's mac address is stored on the usrp2's motherboard eeprom.
at start-up, all 6 leds will flash and 2 will remain on. the bottom one shows that the fpga is configured. the next one up shows that the firmware is running. the others are unused.