Guardando trazas del osciloscopio como flujo de bits comprimido

Dependiendo de la relación entre el período promedio y la frecuencia de los cambios de estado, alguna forma de codificación de longitud de ejecución puede ser el enfoque más efectivo. Eso sería especialmente cierto si las únicas cosas de interés son las carreras largas de altas, largas o bajas, o los períodos que no se pueden caracterizar como otros [por ejemplo, si las carreras de interés más cortas son la longitud 4, entonces algo como

 111111110010100010000000

se reduciría a "ocho unos, seguidos de nueve bits inestables, seguidos de Ocho ceros ". En los casos en que el número de bits inestables sea cero o uno, no habría necesidad de almacenar la polaridad de la siguiente ejecución estable [después de cero bits inestables, sería lo opuesto a la anterior; sería el mismo que el anterior].

Un analizador lógico es una opción, pero es posible que tenga limitaciones similares en cuanto a la duración y el almacenamiento de la traza. Probablemente querrá buscar una solución más personalizada, por ejemplo, usar un FPGA para distribuir los datos en la DRAM y / o transferirlos a un SSD o incluso a una tarjeta SD. Si el flujo de datos es en realidad algún tipo de datos en serie, entonces recomendaría un enfoque basado en FPGA en el que pueda realizar la recuperación de reloj / datos en el FPGA, por lo que solo necesita almacenar 1 bit por bit de datos y posiblemente implementar algún tipo de compresión de transmisión. Luego, descargue los datos en algún tipo de solución de almacenamiento masivo, ya sea un SSD grande a través de SATA o quizás a una computadora a través de USB, Ethernet o PCIe. También es posible que pueda transferir datos no comprimidos (20 Mbps no es tan malo en comparación con USB 2 a 480 Mbps o Gigabit Ethernet) y luego comprimirlos con cualquier software del lado del host que utilice para almacenar los datos. Esto permitiría usar un algoritmo de compresión mucho más complejo que resultará en una mejor relación de compresión.

Tal vez un poco tarde, pero ha sido golpeado.

¿Estás seguro de que trabajar más es la respuesta? Yo sugeriría que más inteligente es un mejor enfoque. Hay una diferencia enorme y fundamental entre los datos y la información. La información nace de los datos. Los datos puros son bastante inútiles sin análisis. ¿Realmente necesitas almacenar gigabytes de datos? ¿Qué es lo que está buscando en el flujo de bits que no puede identificar en 2 millones de bits (valor de 0.1 s)? Existen métodos estadísticos para inferir información de muestrear una población más grande. No es necesario mantener la población si tiene las estadísticas descriptivas.

No nos ha dicho lo que está buscando, pero sugeriría que es probable que no necesite tanto almacenamiento permanente. Y esto tiene una influencia directa en el sistema de captura.

Existen muchas soluciones comerciales desde $ 10k y hasta para los registradores de datos militares y de vuelo. AXIS, AMPEX etc.

Para rodar el suyo, considere una transmisión SERDES a SIPO a FIFO a una caja i7 de Linux con unos pocos Unidades de 2TB con drivers de código abierto. Si esto está fuera de su presupuesto o capacidad, no es posible.

Añadido

Su solicitud es irrazonable y no cómo medir la tasa de error de bits, BER. Si desea grabar la integridad de la señal durante mucho tiempo, es decir. La BER o el margen de tiempo o el patrón de ojo o el margen de la ventana, entonces puedo sugerir un enfoque más sensato.

1) diseñe su reloj ideal y separador de datos de "flujo de bits" 2) define tus patrones de datos BER vs SNR vs o equivalentes.

3) Compare el reloj y la entrada de datos con la salida Rx para jitter, margen, offset, deriva, asimétrica, ISI, etc. con diferentes patrones de datos

4) Elija el método para inyectar diferentes tipos de ruido.

5) por ejemplo, después de inyectar un contador de tasa de error de mensaje de diseño de ruido 1 error en 10 ^ x bits    - por ejemplo, 1k de carga útil para BER = 10e-3    - ajuste la medida de nivel de ruido SNR y luego repita cada década hasta 10e-7 (1 error por segundo)    - continúe con 1e-9 (1 error por 100 s).

Luego, traza esto y observa todos los cambios en las líneas rectas o puntos de interrupción para diferentes patrones de datos.

6) ANALIZAR DATOS

• Algunas de estas constantes de punto de interrupción y pendiente se relacionan con SNR, asimetría o compensación en el comparador, ISI dependiente del patrón, distorsión de retardo de grupo en los filtros, ruido aleatorio, fluctuación de fase del reloj de PLL y BW, error de fase, etc. y más.

experiencia personal

Esto fue una rutina cuando lo hice hace 30 años a principios de los 80 para los diseños T1 y más tarde el flujo de bits de 10Mb / s para los primeros 5,25 "datos de los HDD con tasas de error suaves < 10e-9 y las tasas de errores difíciles < 10e -12 y teníamos muchas formas de medir esto.

Una máquina tuvo un incremento de 2 ns que reduce las ventanas de recuperación del reloj para detectar errores de bits de datos y +/- "margen de ventana".

Pero el más simple fue 2 líneas de retardo con tomas LC con selector de datos de secuencia pseudo aleatorias para datos tardíos normales tempranos con varios incrementos de ns.

• por ejemplo 10% de 100ns = 10ns. Esto se inyectó digitalmente entre la salida del comparador y el reloj SERDES y la recuperación de datos para acelerar la tasa de BER al reducir el margen de la ventana o agregar jitter.

Ahora hay soluciones más sofisticadas, ¡pero grabar GB / s de señal sin formato no es la mejor manera de analizar el diseño de un sistema! a menos que tenga algún otro propósito real no especificado ... luego lea la primera respuesta