Pico grande en la frecuencia central cuando se usa Ettus X310

El problema que tengo es que siempre tengo un gran pico (10-15 dB) directamente en la frecuencia central (sin importar la frecuencia que establezca). Soy relativamente nuevo en todo esto, por lo que agradecería cualquier sugerencia sobre cómo deshacerse de la espiga.

Ese pico probablemente no sea nada sorprendente: solo la fuga LO / compensación de CC, un artefacto muy común en los receptores de conversión directa.

Ahora, deshacerse de él con un USRP es relativamente simple.

Debe comprender que los USRP tienen un proceso de ajuste de dos pasos:

Hay un oscilador físico, el LO, que se sintetiza por la placa secundaria, y se utiliza para mezclar la señal objetivo con las señales de banda base IQ. Por lo general, los sintetizadores solo pueden generar un conjunto discreto de frecuencias LO . $f_\text{RF}$
Luego, el ADC muestrea estas señales a la velocidad del reloj maestro, y el FPGA desplaza digitalmente ese flujo de muestra en la banda base amplia de la velocidad del reloj maestro (es decir, 200 MHz para el X310 por defecto) al multiplicar esencialmente con , para darle su señal de banda base del : $e^{j2\pi f_\text{offset} n}$ $f_\text{target}$

De manera predeterminada, se establece lo más cerca posible de , minimizando y, por lo tanto, colocando el LO en su ancho de banda observado . $f_\text{RF}$ $f_\text{target}$ $f_\text{offset}$ $b_\text{sample}$

Sin embargo, puede establecer manualmente un "deseado" ; tan pronto como sea más de , ¡el LO está fuera de su banda de observadores! $f_\text{offset}$ $\frac 12 b_\text{sample}$

En lugar de usar 101e6en el campo de entrada Frecuencia central , simplemente use

uhd.tune_request(f_target, f_offset)

p.ej

uhd.tune_request(101e6, 4e6)

Permítanme comentar sobre algunos otros problemas directamente también:

Estoy usando la radio Ettus X310 SDR y GNU.

El X310 es la plataforma, de hecho, pero el procesamiento real de la señal analógica (que genera los LO para la mezcla, mezcla, amplificación, filtrado de banda base) ocurre en la placa secundaria. En tales casos, generalmente es importante especificar qué placa secundaria está utilizando

En el esquema de radio GNU, tengo un bloque fuente UHD USRP estándar conectado a un sumidero GUI FFT, básicamente solo estoy mostrando el espectro de la señal sin procesar del dispositivo.

De hecho, eso debería funcionar. Tenga en cuenta que los bloques WX Gui se están volviendo obsoletos; si recién comienza con GNU Radio y no necesita continuar una aplicación existente basada en WX, le recomiendo cambiar las "opciones de compilación" en el bloque de opciones a "Qt" y reemplazar el "sumidero" WX GUI FFT "con un" sumidero de frecuencia Qt GUI ". Lo mismo, más funcionalidad, menos uso de CPU, por lo general.

Parámetros para el bloque fuente de USRP:

frecuencia de muestreo = 1.024 MS / s,

Probablemente estabas usando una frecuencia de reloj maestro de 184.32 MHz, ¿verdad?

Para futuros lectores, reproducir esto (¡esta tasa específica realmente aparece con más frecuencia de lo que parece!):

¡El X310 no admite esa frecuencia de muestreo en la configuración predeterminada! La ventana de la consola debe contener una advertencia clara de que UHD decidió usar una frecuencia diferente, y qué frecuencia fue, en su caso, probablemente 1.02048 ... MS / s.

UHD Warning:
    The hardware does not support the requested RX sample rate:
    Target sample rate: 1.024000 MSps
    Actual sample rate: 1.020408 MSps

Esto se debe a que el X310 ejecuta su ADC / DAC a lo que se llama la velocidad del reloj maestro , que puede tomar los valores de 200 MHz (predeterminado), 184.32 MHz (típico para algunos estándares de redes celulares), 120 MHz (típico para LabView). La frecuencia de muestreo que entrega a la PC es una secuencia de muestra muestreada a esa frecuencia, diezmada en el FPGA a la frecuencia que está solicitando, y esa eliminación se realiza con filtros FIR "normales", que solo pueden proporcionarle una fracción entera de la tasa de entrada.

Entonces,

1.020408 ... \frac{em}{s} = \frac{200 \frac{em}{s}}{196}

$1.020408… \frac{\text{MS}}{s} = \frac{200\frac{\text{ MS}}{s}}{196}$

es posible,

1.024 \frac{em}{s} = \frac{200 \frac{em}{s}}{195.3125}

$1.024 \frac{\text{MS}}{s} = \frac{200\frac{\text{ MS}}{s}}{195.3125}$

no lo es, cuando el MCR está configurado en su valor predeterminado de 200 MHz.

Con un MCR de , que es , ¡esto es realmente posible! $184.32\text{ MHz}$ $1.024\text{ MHz}*180$

frecuencia central = 101 MHz,

Lo que probablemente significa que estás usando la placa secundaria WBX o UBX,

ganancia = 42 dB,

que no es un ajuste de ganancia compatible con UBX o WBX, sus rangos de ganancia son 0 - 31.5 dB y 0 - 31 dB, respectivamente.

ancho de banda = 130 MHz

Esa es la especificación de ancho de banda analógico; Se aplica a las placas secundarias con filtros de paso bajo de banda base ajustable. Sin embargo, no existe una placa secundaria que tenga un filtro de banda base ajustable y un ancho de banda máximo> 8 MHz.

De hecho, esta configuración no hace nada en UBX o WBX.

Marcus Müller
fuente

¡Muchas gracias por mucha información útil! En cuanto a la placa hija, estoy usando el UBX-160. Tienes razón sobre la frecuencia de muestreo, recibí la advertencia que mencionaste anteriormente. Con respecto al pico, cambié el cable de la antena al SDR y el pico desapareció (para mi sorpresa). Luego me di cuenta de que desapareció con ganancias más altas (~ 30) pero todavía estaba presente en valores de ganancia bajos. Después de usar el truco tune_request, la espiga desapareció por completo incluso con valores de baja ganancia.

Tihomir Meščić

Leyendo esta respuesta nuevamente después de un nuevo material aprendido. La respuesta es dulce para los ojos.

Denis

Pico grande en la frecuencia central cuando se usa Ettus X310

Respuestas: