Pregunta de diseño: adquisición de datos de 20 MS / s

0

Permítame decirle que soy bastante nuevo en el trabajo con el muestreo de señales de alta velocidad. Específicamente, quiero hacer un procesamiento en señales NTSC ligeramente corruptas. Para esto, necesito muestrear por encima de 14.3 MHz. Supongamos que quiero tomar muestras de 12 a 16 bits a 16 MS / s con un ADC, esa cifra es lo suficientemente razonable como para ser evaluada por la selección disponible. Sin embargo, el reto está en almacenar este resultado. ¿Alguien me puede dar alguna sugerencia para resolver este problema?

Todavía no tengo los esquemas, ya que aún se encuentra en una etapa temprana del proceso de diseño. Pero la idea general es que tendré un ADC, que recolectará muestras y un microcontrolador que facilitará el almacenamiento de esas muestras.

En términos de tamaño total, estoy mirando (en el peor de los casos) decir:

$$ \ frac {16 \ MS} {s} \ cdot \ frac {16 \ bits} {S} \ cdot \ frac {byte} {8 \ bit} = \ frac {32 \ MB} {s} $$

Y la fuente de video NTSC que estoy tratando de recuperar es de aproximadamente 2 horas en el peor de los casos, por lo que:

$$ \ frac {32 \ MB} {s} \ cdot \ frac {3600 \ s} {hr} \ cdot \ frac {2 \ hr} {tape} \ cdot \ frac {GB} {1000 \ MB } = \ frac {230.4 \ GB} {cinta} $$

Otras aclaraciones:

¿Por qué tengo que hacer esto en tiempo real? El video que estoy intentando restaurar proviene de una cinta Video8 , que solo se puede leer utilizando una grabadora de video analógica antigua. La grabadora escupe el contenido de la cinta en su puerto NTSC, pero los datos están ligeramente dañados (falta la señal de sincronización vertical, los datos de la línea horizontal están bien). Esto no debería ser demasiado difícil de arreglar en el software si solo pudiera digitalizar la cinta.

Es el video NTSC en color: Sí. Pero mientras pueda digitalizar la señal NTSC, podré procesarla en software y convertirla de líneas - > campos - > marcos

¿Por qué no usar un capturador de fotogramas? Porque la señal de video está dañada. Como mencioné anteriormente, falta la señal de sincronización vertical adecuada. Sin embargo, los datos de la línea están completamente bien, así que creo que se pueden salvar con el software. Por lo general, un capturador de fotogramas utiliza decodificación de hardware para NTSC, que no funcionará en este caso porque la señal debe procesarse primero.

    
pregunta Alex H

2 respuestas

1

Un microcontrolador no es apropiado para lo que está tratando de hacer. Los datos llegan demasiado rápido para que un micro pueda hacer algo útil con ellos.

Digamos que obtienes un micro que funciona a 100 MIPs. Eso es muy rápido para un micro. Las nuevas palabras de datos están llegando a una velocidad de 16 MHz. Eso deja solo 6¼ instrucciones por muestra, lo que probablemente no es suficiente para tomarlo de algún puerto de entrada y enviarlo a otro lugar.

Según su descripción, creo que tiene razón en que el software que procesa el flujo de muestras puede permitir la reconstrucción de video. Sin embargo, de manera realista, eso no va a suceder en tiempo real. Todo lo que puede esperar hacer en tiempo real es almacenar los datos totales, luego procesarlos en buenos videos o marcos, o lo que desee, en un proceso por lotes más adelante. Eso puede permitirse correr todo el tiempo necesario para producir el resultado limpio.

Las unidades de disco modernas que puede sacar del estante para PC pueden manejar tanto la velocidad de datos como el volumen de datos. 32 Mbytes / sy 230 Gbytes no están superando ningún límite. Un puerto USB 3.0 en una PC moderna puede manejar esa velocidad de datos.

Por lo tanto, su problema es cómo obtener un flujo de palabras de 16 bits a una velocidad de 16 MHz en un puerto USB 3.0. Miraría a mi alrededor en busca de chips de estantería que puedan hacer esto. Comenzaría observando lo que FTDI tiene para ofrecer, pero también verificaría a TI y otros. Es posible que necesite usar un pequeño FPGA para sincronizar el A / D, capturar los datos, presentarlos como dos bytes al chip USB, etc. Es un proceso bastante sencillo, pero de alta velocidad, adecuado para un pequeño FPGA.

    
respondido por el Olin Lathrop
0

Bueno, lo que haría es algo como esto: ADC - > uC / FPGA / ARM - > PC - > HDD. Mi HDD en mi PC puede hacer 100 MB / s, lo que le da suficiente ancho de banda. Puede usar algo como el USB 3.0 FTDI o un Ethernet IC para transmitir los datos a la PC. Todo depende de lo que esté familiarizado, del presupuesto, del equipo que tenga, etc. Debe asegurarse de que el procesador que está utilizando sea lo suficientemente rápido para manejar el ancho de banda.

Deberá escribir algún código para que la PC capture y almacene los paquetes. Piense también cómo los va a leer para procesarlos. Si va a leerlos secuencialmente, puede simplemente volcarlos en un archivo. De lo contrario, puede ser realmente molesto tratar de encontrar un paquete en medio de un volcado de 200GB. Mira algo como los árboles B, si necesitas algo de estructura para los datos.

Para obtener el máximo ancho de banda de la unidad de disco duro, debe usar tamaños de búfer grandes. Algo como un búfer de 1MB debería permitirte obtener la velocidad máxima de escritura. Si utiliza un búfer pequeño, la aguja se moverá más allá de su sector, y tendrá que esperar a que gire el disco duro, lo que disminuirá la velocidad máxima de escritura posible.

P.S. Nada aquí parece demasiado difícil. 20 MSPS no es tan rápido para ser honesto. He tenido que lidiar con sistemas 4GSPS antes, y eso era factible, por lo que su sistema debería ser relativamente sencillo. No estoy completamente seguro de dónde está tu principal dificultad. Supongo que es la transferencia de datos a la PC, pero el uso de USB 3.0, Gigabit Ethernet o PCIe puede manejar fácilmente esos anchos de banda.

    
respondido por el user110971

Lea otras preguntas en las etiquetas