GNU Radio USRP软件无线电平台文档详解

4星 · 超过85%的资源需积分: 10 30 浏览量更新于2024-08-01 收藏 991KB PDF 举报

"GNU Radio USRP文档" GNU Radio是一个开源软件开发工具包，专门用于实现软件定义无线电（SDR）系统。它与USRP（Universal Software Radio Peripheral）硬件相结合，提供了从设计到实现的全套解决方案，允许用户创建自定义的无线通信系统。USRP是由Ettus Research制造的一系列硬件平台，可作为SDR系统中的物理层，处理实际的射频（RF）信号收发。在文档中，作者Firas Abbas Hamza详细介绍了USRP在GNU Radio环境下的使用。文档的开头表达了对GNU Radio社区，尤其是开发团队的敬意，并指出GNU Radio遵循GNU General Public License（GPL），这是一种自由软件许可证，鼓励代码共享和修改。 USRP部分讲解了硬件的基本结构和功能。USRP包含： 1. **ADC（模拟数字转换器）部分**：负责将接收到的模拟射频信号转换为数字信号，以便在软件中进行处理。这部分涉及到采样率和分辨率等关键参数，它们影响着信号的质量和处理能力。 2. **DAC（数字模拟转换器）部分**：在发送端，将经过处理的数字信号转化为模拟信号，然后通过天线发射出去。同样，DAC的性能也会影响信号的传输质量。 3. **辅助输入/输出模拟通道**：除了主要的射频通道，USRP还可能包含额外的模拟输入和输出，可以用于监测、控制或者添加额外的信号处理功能。 4. **辅助数字I/O端口**：这些接口允许与外部设备进行数字通信，例如同步信号、控制信号或数据传输。 5. **FPGA（现场可编程门阵列）**：这是一个可编程的硬件组件，能够根据需要配置为执行各种数字信号处理任务，提高了系统的灵活性和效率。 6. **daughterboards**：USRP可以配有不同的子板，以适应不同的频率范围和应用场景。文档中提到了基本的发射/接收子板、低频发射/接收子板以及电视接收子板等，展示了USRP的广泛应用范围。文档的后续章节可能涉及如何配置和使用这些组件，以及具体的SDR应用示例，如建立无线通信链路、信号解调和调制等。对于想要深入了解和实践软件无线电技术的读者来说，这是一份非常有价值的资源。

Page 15 of 90

src = usrp.source_c (0, decim)

src.set_rx_freq (0, IF_freq)

src.set_pga(0,20)

How actually it gets translated and conveyed to the FPGA master_control module on FPGA to do

the needful?

A) 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 usrp/firmware/include/usrp_spi_defs.h contains the definition for the SPI bus. The

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.

Q) How big are the USRP buffers?

A) 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.

Q) 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?

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

CH1-I

CH1-Q

CH2-I

CH2-Q

etc.

Q) I wish to build just one RX with halfband filter and one TX. The present usrp_std.vh has 2rx,

1tx or 4rx. What do I need to do to?

A) Edit the file config.vh , then uncommented the line:

//`include "../include/common_config_1rxhb_1tx.vh"

And comment the line:

Page 16 of 90

`include "../include/common_config_2rxhb_2tx.vh"

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

Q) 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?

A) 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).

Q) 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?

A) I usually prefer to do this kind of experimentation from Python, but in any event you're

probably using an invalid I2C address. See 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

Q) How we control auto transmit/receive switch delay?

A) 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

Page 17 of 90

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.atr_set_tx_delay(clock_ticks_to_delay_tx) # Rising edge

subdev.atr_set_rx_delay(clock_ticks_to_delay_rx) # Falling edge

that would be 'set_atr_tx_delay' and 'set_atr_rx_delay'.

...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.

Q) What is the USRP Clock reference instability?

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

Q) How the expected in-band TX timestamps may work?

A) Here is the order I was thinking:

- 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 do 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

Page 18 of 90

appropriate flag

- Else wait until the current time is reached

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

Q) I was just wondering whether the USRP has got some temperature specs that I should take into

account.

A) 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.

Q) Is the loopback interface working on the USRP, and how to enable it?

A) 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}

Q) 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?

A) 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!

Q) 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?

A) 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.

剩余89页未读，继续阅读

z3hyz3hy

粉丝: 0
资源: 5

GNU Radio USRP软件无线电平台文档详解

低成本GNU Radio USRP入门教程

GNUradio与USRP入门：AM信号接收解调

GNURadio与USRP：软件无线电的深度解析

gnuradio usrp使用

USRP.rar_GNU Radio_Gnu usrp_python usrp_usrp_usrp原理

GNUradio与USRP入门：修改build_gnuradio脚本

GNU radio 和USRP入门指导

权重系数确定matlab代码-gnuradio-quick-start:一个GNURadio及USRP的快速入门教程

软件无线电GNURadio和USRP的分析与研究.pdf-综合文档

GNU Radio与USRP设备入门指南

最新资源