Tengamos una visión general de alto nivel de lo que tiene un osciloscopio:
Primero tenemos el front-end analógico. Aquí tenemos una red de coincidencia de impedancia para las sondas (pero las sondas también tendrán que tener una parte de adaptación de capacitancia), sección de atenuación (muy importante, por lo que no sobrecargamos el ADC ni permitimos que entren altos voltajes), activación y conexión a Conversor analógico a digital. No hablaré demasiado sobre esto, ya que no soy demasiado bueno con cosas analógicas, pero la conclusión es: no hay nada que podamos hacer con Pi en esta sección.
A continuación tenemos la parte del convertidor analógico a digital. Necesitará al menos un ADC para cada canal. Se puede usar más para una frecuencia de muestreo más alta. En el ámbito tradicional, el ADC está conectado a un dispositivo ASIC o FPGA. Se usan porque las computadoras tradicionales no son lo suficientemente en tiempo real (¡y no confundan en tiempo real con rápido!) Para procesar los datos proporcionados por el ADC. Esos datos se almacenan en la RAM de algún tipo. Algunos dispositivos usarán RAM estática, mientras que otros usarán RAM dinámica. En general, el enfoque SRAM es más tradicional y se ve en fabricantes de renombre, mientras que el uso de DRAM parece ser el enfoque más nuevo visto en las unidades más baratas diseñadas en China.
La cantidad de RAM y su velocidad determinarán cuántas muestras se pueden almacenar. Casi siempre el ADC será ADC de 8 bits, por lo que, por ejemplo, necesitaremos 8 b por 100000 = 8 Mb o 1 MB de RAM. Para un MSa / s, necesitaremos RAM que pueda funcionar a esa velocidad. Hoy, eso debería ser relativamente fácil de obtener. El FPGA generalmente maneja la RAM directamente y es responsable del almacenamiento de datos en ella. Funciona al llenar la memoria de muestra mientras todavía hay espacio vacío y luego sobrescribirla cuando está llena. Cuando hay varios ADC por canal, el FPGA los configurará de manera que primero comience el muestreo, luego en el segundo reloj y así sucesivamente. Cuando terminen el muestreo, la muestra del primer ADC se escribirá primero en la memoria, luego la segunda muestra del ADC. Esto hará que parezca que los ADC están muestreando más rápido de lo que realmente son.
El siguiente punto en esta sección es que las muestras deben ser equidistantes en el tiempo. Este es el principal problema con el uso de PC en osciloscopios y la razón por la cual los FPGA y ASIC son predominantes. Si algunas muestras llegan tarde o temprano, la imagen representada en la pantalla será incorrecta.
En esta parte vemos el primer uso posible de Pi. Si la frecuencia de muestreo es lo suficientemente baja, podríamos controlar los ADC directamente desde el Pi y almacenar sus resultados en la RAM de Pi. Qué tan rápido podemos ir depende de la forma en que el ADC está conectado a la Pi y cómo Pi hace su E / S. Por lo que he leído, la velocidad más alta de los puertos I ^ 2C de Pi es de 150 MHz (lo fácil que sería lograr en GNU / Linux es otra pregunta) mientras que la velocidad estandarizada más alta es de 5 MHz y para SPI la velocidad más alta en Pi es de 250 MHz. No estoy seguro de cuál es la velocidad estándar más alta de SPI, pero espero que esté en el rango de 100 MHz como máximo.
Entonces, en teoría, tenemos una velocidad más que suficiente en Pi para ejecutar un ADC en un rango bajo de MSa / s. Tengo la sensación de que la velocidad de RAM no será un problema aquí, pero no tengo ningún dato que respalde eso. Si ese es el caso, tendríamos un beneficio importante sobre los alcances habituales: habría una gran cantidad de memoria de captura disponible. Por ejemplo, si dedicamos 32 MiB de RAM al programa para memoria de muestra y tenemos dos canales, eso nos dejaría con 16 MiB para cada canal o un poco más de 134 Mb o 134 megamuestras por canal. Eso es algo que incluso hoy en día muchos osciloscopios no tienen.
La desventaja es que necesitaríamos grandes modificaciones en el sistema operativo para poder obtener un muestreo preciso aquí. No tengo ninguna experiencia con Linux en tiempo real, así que no sé lo fácil que sería.
De todos modos, vayamos al siguiente paso. Entonces tenemos un sistema de muestreo que está llenando la RAM. La siguiente parte es el disparador. El disparador está estrechamente relacionado con la frecuencia de actualización de la pantalla. Lo que básicamente hace es encontrar una muestra interesante y guardarla en la memoria. Cuando se dispara el osciloscopio, continúa muestreando después del disparador hasta que se haya llenado la memoria y luego lo envía para ser procesado y mostrado en la pantalla. Mientras se procesan los datos, el sistema de muestreo a menudo se congela y espera a que se muestren los datos. Es por eso que los ámbitos de gama baja tienen tasas de actualización más bajas, mientras que los ámbitos de gama alta tendrán pantallas especiales de tasa de actualización alta y pasarán mucho menos tiempo esperando que se muestren los datos.
En esta sección, a menudo habrá otro ASIC o FPGA que realizará el procesamiento de la señal en las muestras, cualquier decodificación de protocolo si el alcance lo admite y realmente controla la pantalla.
Esta es la parte donde, por lo que puedo ver, el Pi realmente puede brillar. Puede manejar una bonita pantalla de 1920x1080 (mientras que los ámbitos suelen estar en el terreno sub 800x600) y puede decodificar el protocolo muy bien. El único problema que puedo ver sería la velocidad y cómo el procesamiento afectaría el tiempo de espera. Si buscamos una frecuencia de actualización baja, podemos obtener un analizador lógico realmente bueno.
Finalmente, una palabra sobre los osciloscopios USB y por qué el USB es malo en general para este tipo de proyecto: el osciloscopio USB tradicional ingresa y toma muestras y envía los datos de muestreo a la PC para el procesamiento para el cual existe una aplicación host. Básicamente, algo muy similar se haría con Pi también. Por lo general, las aplicaciones de PC están mal diseñadas y llenas de errores. La siguiente parte mala es el propio USB. Se anuncia como bus rápido que puede hacer 480 Mb / s en modo "Hi-Speed". La verdad es que es extremadamente raro encontrar un controlador USB que pueda soportar velocidades tan altas (el promedio parece estar alrededor de 250 Mb / s de lo que he visto) y que, como protocolo, no es muy adecuado para ningún -aplicación de tiempo. Primero se comparte entre todos los dispositivos en un hub (y Pi solo tiene un puerto USB al que está conectado Ethernet + USB Hub), tiene una sobrecarga relativamente alta (en comparación con SPI) y una alta latencia (recuerde que a 1 MSa / s cada muestra dura solo 1 µs, por lo que debemos tener memoria en nuestra placa ya que no podemos enviar muestras en tiempo real por USB). Finalmente, usar USB haría que la adquisición de datos sea parte del alcance de ser solo otro osciloscopio USB y es ahí donde perdemos cualquier beneficio de usar Pi: las computadoras de escritorio tradicionales son mucho más comunes, más rápidas, más fáciles de obtener y tienen capacidades USB mucho mejores.
EDITAR
He leído una publicación relativamente reciente de Gert van Loo y, según él, las tasas realistas para el I ^ 2C de Pi son 400 kHz y para SPI son 20 MHz.
Hemos descubierto que Raspberry Pi es una excelente plataforma para ejecutar el software que necesitarías para un proyecto como este. El problema es obtener las señales en el RPi en primer lugar y realizar una captura de señal en tiempo real sin fluctuaciones de alta velocidad en la misma CPU que ejecuta el software de aplicación y O / S. Nuestra solución es el osciloscopio Raspberry Pi de BitScope que combina un BitScope (para captura de forma de onda de señal mixta de alta velocidad) con el Raspberry Pi que ejecuta todo el software necesario.
fuente
NB: Esto es más un texto 'pensando en voz alta' que una respuesta real
La idea también se me pasó por la cabeza hace algún tiempo, ¡y todavía me gusta la idea general!
Hasta donde sé, los alcances de gama alta son desde hace 15 años (o incluso más) solo computadoras (PC) con un montón de E / S especializadas de alta velocidad. Creo que cuando se diseñan / conectan E / S similares al RPi, el resultado puede ser sorprendentemente bueno.
En mi humilde opinión, una buena manera de hacerlo es dejar que el RPi simplemente almacene y muestre los datos recopilados (recibidos, por ejemplo, a través del puerto USB) y deje que algún hardware especializado realice la medición de alta velocidad. Esta unidad de medición de alta velocidad también puede ser controlada por el RPi basado en la entrada del usuario o algo similar.
En la primera versión del RPi hubo / hay algunos problemas con los puertos USB, no he buscado últimamente si están resueltos en este momento. También escuché un rumor de que la nueva versión 2.0 del RPi no debería tener estos problemas, pero tampoco he verificado este rumor.
Creo que los resultados sin ningún hardware externo (especializado) son limitados debido a la cantidad de puertos de E / S y al hecho de que se está ejecutando un sistema operativo completo (lo que limita las opciones en tiempo real). ¿A menos que estés planeando escribir tu propio sistema operativo?
También usar, por ejemplo, chips I2C para este propósito no tendrá la velocidad suficiente para hacer algo realmente bueno. SPI ya ofrece mucho más ancho de banda (hasta 100Mhz desde la parte superior de mi cabeza), pero elegiría USB y, si fuera necesario, comprimiría o usaría un buen esquema de codificación antes de enviar los datos para obtener más ancho de banda.
Así que supongo que es posible, pero el hardware que debe agregarse al RPi será mucho más costoso que el RPi mismo.
Por último, pero no menos importante (antes de dejar de soñar despierto sobre este tema), no me sorprendería si una búsqueda en Internet resultara en algún grupo que ya está ocupado haciendo esto.
fuente
La respuesta es sí.
¡Es lo suficientemente poderoso! Pero solo para ciertas frecuencias: como ya se señaló debido a las limitaciones.
¡ENTONCES! -> ¿Tienes que preguntarte qué quieres medir?
Los osciladores pueden variar desde frecuencias bajas simples que cuestan 5 USD, y luego otros pueden manejar hasta 50 Ghz +, ¡que cuestan tanto como una casa pequeña! 75,000USD-100,000USD!
Creo que la Raspberry será lo suficientemente buena como para medir frecuencias sub Giga, como señales inalámbricas de 433 mhz, comunicaciones de bus de CPU de baja velocidad, TTS / UART, depuración I2C, no mucho más en realidad. Y las frecuencias más altas no serán realmente precisas, ya que, por diseño, la Raspberry no ejecuta SO en tiempo real. Por lo tanto, deberá comenzar con el sistema operativo (o como se mencionó en los dispositivos externos en tiempo real, pero ¿cuál es el punto entonces?)
Pero si realmente quisiera medir señales, puede comprar un dispositivo realmente bueno y con un precio razonable que esté a la par con las especificaciones de Raspberry. Pero ya está bien diseñado, lleno de características, tiene un diseño realmente maduro y demostró ser práctico en un ambiente de aficionado.
No hay necesidad de reinventar la rueda aquí. Por ejemplo, un DSO Nano para menos de 100 USD de un solo canal.
Un DSO Nano Quad Channel para menos de 200 USD
Y luego, ¡qué Raspberry o dispositivo similar NO PUEDE HACER!
Y cuesta una pequeña fortuna ...
fuente
Puede conectar uno de nuestros osciloscopios / generadores de formas de onda arbitrarias Handyscope HS5 de TiePie Engineering al puerto USB. Una biblioteca compilada para que Raspberry Pi use uno o varios osciloscopios simultáneamente está disponible para descargar. El instrumento utiliza su propio tiempo y memoria, por lo que no hay pérdida de rendimiento. Entonces, sí, el Pi es lo suficientemente potente como para un proyecto de osciloscopio.
Especificaciones clave del osciloscopio: 2 canales, 14 bits, 500 MS / s, ancho de banda de 250 MHz, 20 MS / s de transmisión continua sin espacio de 14 bits, 32 MS de memoria por canal, precisión de base de tiempo de 1 ppm.
Especificaciones clave del generador de formas de onda arbitrarias: formas de onda de 1 µHz a 30 MHz, 240 MS / s, 14 bits, memoria de 64 MS, salida de -12 a 12 V (24 Vpp), precisión de base de tiempo de 1 ppm.
fuente
Su mejor oportunidad es probar si se puede compilar sigrok y su interfaz de usuario libsigrok en Pi, y luego comprar un hardware de osciloscopio compatible. De esa manera, puede capturar señales de hasta 24 mega muestras por segundo. Con suficiente conocimiento, puede personalizar el software de la forma que desee, incluida la transmisión inalámbrica a dispositivos móviles.
fuente
Alguien hablando de Sigrok. Creo que la forma más cercana es usar CY7C68013A bien documentado con el controlador EZ-USB FX2LP. En PC de escritorio no funcionaba con Weezy, pero en Jessy funciona bien. Aquí está la limitación conocida sobre 24 Msps. Estoy pensando en otra forma, usando la interfaz de la cámara. Esta interfaz podría administrar 2.1 mega píxeles y 30 cuadros por segundo, lo que significa que podría transferir datos a la GPU con una velocidad de más de 60 mega "muestras" por segundo. Suena más útil que 20MHz SPI o USB.
fuente
Si no le importa limitarse a las frecuencias de audio, utilizo un convertidor A / D de doble canal MCP3202 de 12 bits de bajo costo para adquirir en el pi con spidev y pydatascope para mostrar los datos pasados a través de Ethernet a través del zócalo TCP. ¡Pydatascope también actúa como un analizador de espectro!
Hice cambios relativamente triviales en el código fuente abierto de pydatascope para tener canales duales, principalmente porque era fácil y no es que realmente lo necesitara.
Publique seguimientos o envíeme un correo electrónico directamente si tiene alguna pregunta, con gusto lo ayudaré.
fuente