Hardware de radio definido por software

La mayoría de los periféricos de radio definidos por software involucran un FPGA. Al diseñar un periférico SDR, me gustaría saber si es posible diseñar un periférico de hardware SDR compatible con GNU Radio sin ningún FPGA. es decir, enviar directamente la salida de los ADC a una PC a través de USB. Si es posible, creo que ingrese la descripción de la imagen aquími interés en eliminar los FPGA (a algún otro costo) se debe a que el diseño de la soldadura de FPGA es un proceso difícil que la mayoría de los proveedores no explican adecuadamente. Si hay una manera de eliminarlos de mi diseño, sería genial. Mi interés es diseñar algo similar a esto .

En la imagen de arriba que encontré de TI, ¿es posible que conectemos directamente la salida del ADC a la PC a través de algún tipo de conexión USB? Tal vez, la transmisión también sea posible de esta manera.

También me gustaría saber los propósitos exactos del uso de FPGA en diseños de periféricos SDR. Estoy seguro de que puede haber muchos. Pero me gustaría saber los más imperativos.

ACTUALIZAR:

Como sugirió Neil_UK en la sección de respuestas, si la limitación es no poder transmitir las muestras de ADC sin procesar a través de una interfaz USB a la PC debido a la lentitud en la velocidad del USB, ¿cuál sería el ancho de banda práctico más alto que podríamos tener en un sistema? que conecta directamente el ADC a un USB? tal vez un USB 3.0? ¿Es solo el ancho de banda lo que estará limitado por esta decisión? ¿Qué otras características fundamentales se perderían si los SDR se diseñaran de esta manera? (siempre que no sea necesario para operar con señales, por ejemplo, demodularlas)

No puede conectar directamente el ADC a USB a menos que pueda encontrar un ADC con una interfaz USB; deberá encontrar algo que pueda actuar como un punto final USB y comunicarse con el ADC.

Respuestas (5)

Nota: vamos a simplificar demasiado el hardware SDR para ilustrar esta respuesta

ADC --> PC es (una de) las funciones de la FPGA

El FPGA cumple diferentes funciones en diferentes diseños de SDR, pero uno de sus propósitos principales es "simplemente conectar el ADC a la PC". Creo que no aprecia completamente el proceso de mover datos a través del Universal Serial Bus (USB) y el proceso de capturar la señal de radio.

Los SDR generalmente requieren al menos dos flujos ADC (captura en cuadratura después de la conversión descendente) y generalmente tienen múltiples canales en cuadratura para hacer cosas avanzadas como MIMO, RADAR/Formación de haces, etc.

El FPGA es necesario para multiplexar los flujos de datos digitales que salen de los distintos ADC, para formatear los datos de manera compatible con USB (y, en última instancia, con gnuRadio) y para recibir información de control de la PC/gnuRadio y efectuar los diversos cambios en los ADC. y componentes de conversión descendente.

Sin el FPGA, tendría que implementar estas funciones con otro hardware y su diseño terminaría siendo mucho más complejo, en lugar de la simplicidad que busca. Los diseños de SDR han evolucionado hasta su estado actual y son mucho más baratos/más simples hoy que en años anteriores.

Ejemplos

Algunos productos SDR comunes de Ettus y Pervices Devices ilustran la naturaleza de la lógica de unión central de la FPGA en estas arquitecturas. Tenga en cuenta la ubicación de la FPGA entre los convertidores analógicos de alta velocidad y las interfaces de datos externas relevantes.

ingrese la descripción de la imagen aquí

ingrese la descripción de la imagen aquí

Esto es un error. Los SDR típicos basados ​​en FPGA usan un chip de interfaz USB capaz de tomar datos directamente de un ADC, posiblemente con un FIFO de hardware en el medio. El objetivo de tener un FPGA es hacer un preprocesamiento en el hardware para usar mejor el ancho de banda de los estándares USB más antiguos para representar la información que es de mayor interés, en lugar de simplemente tomar muestras sin procesar a la velocidad más alta que se ajuste al tubo.
@Chris: he ampliado la respuesta, ¿tal vez podría reconsiderarlo? (1) Nunca he visto un ADC, sin una MCU/CPU integrada, que tuviera una interfaz USB. ¿Cuál sería el espacio de aplicación para esos chips? Los sistemas modernos basados ​​en FPGA tienen la arquitectura que he descrito y he incluido algunas referencias de productos para ilustrar este punto. (2) Si bien algunos sistemas realizan procesamiento de front-end en FPGA, esto es una responsabilidad de implementación y no el objetivo de diseño de Software Defined Radio. Finalmente, como se señaló originalmente en la respuesta, esta es una de las funciones del FPGA, no es la única función.
Vuelve a leer el comentario. Nadie dijo que había ADC con interfaces USB, sino que los datos de ADC pueden fluir directamente a un USB interface chip- solo necesita el FPGA en el medio si cree que sería más óptimo poner algo más que las muestras de ADC en bruto por esa tubería. ¿Conoces los analizadores lógicos USB simples basados ​​en chips Cypress USB? Un SDR simple puede ser un ADC que alimenta uno de esos, uno más complejo coloca un FPGA en el medio para permitir la aniquilación y el filtrado del hardware.
Sé que sabes lo que estás haciendo. Estamos dividiendo pelos en este punto. Cypress EZUSB no es lo suficientemente rápido para SDR de gama alta, es por eso que ve FPGA (sí, también hace otras cosas). La aniquilación solo es necesaria si su hardware o tubería no es lo suficientemente rápido. Si va a filtrar en el hardware SDR, por extensión, podría hacer todo el filtrado/procesamiento en el FPGA y tiene una radio convencional. El propósito de SDR es (intentar) hacer todo el procesamiento en software donde sea flexible y esté expuesto y donde múltiples cadenas de señales puedan ejecutarse en paralelo.
O la tubería USB en uso puede acomodar el ancho de banda del muestreador, o no puede; si puede, no necesita un FPGA a menos que haya peculiaridades de implementación que necesite para solucionar. Pero dado que mencionó la división de pelos, la mayoría no consideraría que las operaciones reconfigurables en un FPGA (si se utilizan) quedan fuera del "software" en la "radio definida por software", sino que son solo un ejemplo de optimización de la arquitectura de computación para la tarea a mano. Tal vez podríamos llamarlo con mayor precisión "radio implementada computacionalmente".

Tasa de datos => ancho de banda.

USB manejará solo una tasa de datos limitada, y todo el ancho de banda digitalizado tendría que caber en este canal.

Con un FPGA en el extremo remoto, puede reducir el ancho de banda digitalizado al ancho de banda real del canal, que podría ser uno o dos órdenes de magnitud más pequeño, y enviarlo por el USB. Podría ir más allá y demodular los datos, para otro orden o dos de reducción de la tasa de datos.

Creo que la PC se comunica con el SDR y le dice al PLL que sintonice la frecuencia requerida solicitada por GNU Radio. Entonces, el sistema solo captura finalmente el ancho de banda del ADC. Quiero decir que la tasa de datos es una dependencia directa de la velocidad del ADC. por ejemplo, el popular hakrf tiene un ancho de banda de 20 MHz. Lo que significa que el ADC tendrá que funcionar al menos a 40 MHz. A 40 millones de muestras por segundo, los datos producidos son 40 millones * 8 bytes por segundo si el ADC tiene una precisión de 8 bits. Creo que esta cantidad de bits se puede transferir a través de USB, al menos a través de USB3.0. Entonces, ¿podría decirme por favor?
@qwertylicious: está asumiendo que el muestreo que hace hackrf es real si cree que f_sample debe ser el doble del ancho de banda. Ese no es el caso aquí: hackrf, al igual que otros dispositivos de conversión directa, usa una banda base compleja , lo que significa que el ancho de banda de Nyquist es igual al muestreo raro.
Pero tiene razón, cada muestra en realidad consta de una parte real y otra imaginaria, por lo tanto, su cálculo de ancho de banda aún es correcto. USB2 de alta velocidad hace hasta 480 Mb/s menos gastos generales (que es sustancial)
Se ha visto que USB2, en la práctica, hace alrededor de 310 Mbps. Suponiendo muestras de 8 bits (RTLSDR barato) y 2 canales (señales I y Q) que lo limitan a 20 MSamples/seg. Muchos buenos SDR tienen resoluciones de muestra y velocidad más altas, y usan el FPGA para reducir la muestra/selección de canal, etc. Para reducir el rendimiento de datos a algo que USB2 pueda manejar.

Sí, es posible, esto es lo que hacen los receptores DVB. También puede hacer un diseño USB 3.0, por ejemplo, basado en EZ-USB FX3 , estos se pueden conectar fácilmente a ADC y DAC, y el firmware simplemente configura una tubería entre un punto final masivo y los periféricos.

La desventaja de esto es que los datos están completamente sin procesar. Necesita al menos una corrección de compensación de CC por ADC y una compensación por la forma del filtro de aliasing. Implementar esto en el software consumirá bastante tiempo de CPU. Al mismo tiempo, el costo adicional de la FPGA no es tan grande en comparación con las partes analógicas.

Dato curioso: trabajo para Ettus, la serie b2xx usa el fx3, y en realidad, el manejo de hardware ADC/DAC complicado tiende a ser tan complejo que los FPGA como pegamento resultan ser necesarios. Sin afirmar que es imposible prescindir de un FPGA, solo mucho más difícil, funcionalmente, como usted dice, restringido y en su mayoría "no vale la pena"
Hola Marcus, me alegro de saber de ti de nuevo. Gracias por actuar en mis comentarios anteriores. es decir, la eliminación de comentarios relacionados con la identidad. El objetivo de esta pregunta era aclarar algunas dudas que tenía cuando estaba buscando varios hardware SDR. Quería diseñar una placa de prueba SDR (sé que estoy loco). No quiero que esté en el llamativo rango de GHz. La prueba de concepto está bien. Es decir ¡Recibe algo del aire! ¡Si puedo hacer eso, puedo hacer que todos mis alumnos obtengan un SDR para una tarea! y obligarlos a entrar en el mundo de SDR por medio de una asignación. Creo que debería. Bt lamentablemente la vida no es simple.

Su propuesta de una radio definida por software que consiste en un convertidor de analógico a digital, alimentando una PC (lenta) es posible, pero no práctica.
La velocidad a la que la PC puede procesar muestras establece la velocidad de muestreo del ADC. Para mucho trabajo de radio, esta tasa sería relativamente baja, lo que requeriría que el ADC submuestree su voltaje de entrada.
Para evitar la formación de alias, un filtro de paso de banda de ancho de banda estrecho analógico debe preceder al ADC. Además, el ADC requeriría un muestreador de alto rendimiento en su interfaz. Estos dos requisitos hacen que el esquema sea poco práctico.

Estoy de acuerdo con "deje que el FPGA haga el trabajo pesado de alta velocidad", pero tenga en cuenta que incluso las computadoras portátiles en estos días manejan fácilmente más de 20 MS / s.
No estás equivocado conceptualmente, pero estás bastante equivocado en la práctica. Cosas como un mezclador de conmutación que alimenta un filtro de paso bajo de amplificador operacional hacen posible construir grandes receptores utilizando un ancho de banda de muestra relativamente bajo: clásicamente, ADC de audio de alta gama. Puede usar la misma técnica con un ADC correspondiente a la velocidad de datos máxima que puede reducir un estándar USB determinado.

Busque los kits SDR de "roca blanda".

Limitados a HF, estos programan un oscilador (si570) para mezclar el canal deseado hasta el rango de audio. Luego capturan los datos usando una tarjeta de sonido de computadora.

La calidad depende de la tarjeta de sonido que utilice. Hay tarjetas de sonido externas basadas en USB que puede usar con el kit, que pueden dar mejores resultados que la tarjeta de sonido integrada de [por ejemplo] una computadora portátil barata.

Enlaces:

http://fivedash.com/

http://www.wb5rvz.com/sdr/

Hardware de radio definido por software
RespuestasAquíPolítica de privacidad1y, 0v