Arme su osciloscopio (analógico ó digital)

Hoy encontré un enlace que había perdido: el desarrollo de BITSCOPE. La web completa está aquí, de donde se pueden bajar desde los esquemáticos del osciloscopio digital hasta el código para hacer un generador de señal con un pic. También tiene una página de descargas para empacharse tranquilos!!!

Me propongo desarrollar una placa de captura digital.
Las novedades las iré posteando aquí en forma de blog.
Mi desarrollo lo voy a ir reportando acá.

Estos son los esquemáticos de un osciloscopio transistorizado, publicados en Argentina, en
la revista Radio Técnica, en sus números del 16 y 23 de marzo de 1977, en dos artículos
escritos por Salvador Amalfa.
He copiado en el enlace el texto explicativo más relevante.

Figura 1. Esquema de bloques

Figura 2. Amplificador vertical

Figura 3. Base de tiempos

Figura 4. Amplificador horizontal

Figura 5. Fuente de alimentación

Figura 6. Polarización del tubo de rayos catódicos

Saludos
 
En ésta página hay buena información sobre un proyecto de osciloscopio digital.
Sin embargo sigue siendo algo en lo que uno no llega a ponerle las manos encima a lo más interesante, que a mi juicio es el manejo de datos en altas frecuencias.

Yo tengo algunas ideas para poner a prueba con 32MHz, que es el tope manejable con los TTL que se consiguen fácil.
Temas a resolver:

- Captura pre-trigger,
- Display de los datos a diferentes escalas,
- Multiplexado de memorias,
- Sincronización de la captura,

Esto último teniendo en cuenta:
- la señal de trigger,
- el llenado de la memoria,
- el reloj de alta frecuencia para captura,
- el reloj generado por el micro, para salida de datos.

En alta frecuencia se suman otros problemas:
- latches para el bus de datos,
- gestión de varios chips de memoria,
- la respuesta de la placa de impreso para > 32 MHz,
- conseguir los mismos integrados pero para más de 32MHz, :cry:
- o trabajar con FPGA.

Bueno, son ideas como para organizar el trabajo.
No es para desmoralizar a nadie. :cool:
 
Que TRC se podría usar para este aparato? Porque no se, como que no sabría donde conseguir las pantallitas verdes esas, que usan las plaquitas para la deflección.
 
Un lindo desafío podría ser desarrollar una placa de captura con las mejores prestaciones
posibles pero con los componentes discretos disponibles en el mercado.
Teniendo en cuenta que la electrónica se va superando cada día, podría ser un tema
de interés didáctico.
En cuanto a los componentes:
- En Buenos Aires, un display gráfico de 128x64 pixels se consigue por 32 U$S, lo que no
es demasiado para la función que cumple,
- un conversor A/D de 100 MHz "te lo tiran por la cabeza" por unos pocos dólares (15-20 U$S),
- contadores, latches y memorias rápidas se consiguen, ...

Hace poco conseguí de "muestra gratis" unos opamp rápidos de Maxim para amplificar hasta
100 MHz. Claro que si no hubiera sido por el favor que me hizo un amigo que viajaba hacia
Argentina el transporte internacional me hubiera salido mucho más caro que el valor del chip.
... bueno, alguna contra tiene que haber.
 
Para amenizar un poco esta charla de café, les comparto algunos esquemas de sincronización "inteligente"
para ir pensando un sistema de captura digital con almacenamiento en memoria RAM de acceso paralelo.
El primero es el diagrama de bloques del sistema de adquisición completo, con salida a PC.
Figura 1

El segundo es un esquema para barrido lento, que permite al micro ir leyendo el fin de memoria "OVR"
para bloquear el contador a tiempo. Además no permite capturas pre-trigger.
Figura 2

El tercero es un BORRADOR de un circuito para sincronizar trigger, memoria y bloquear cuando se llega
al final. Etc.
Figura 3

Recibo preguntas, dudas y críticas. !

Y ya que estamos también recibo donaciones para avanzar con el proyecto.
Todos los que colabor€n recibirán de regalo una copia de la placa al finalizar el desarrollo.
 
Hola de nuevo:

Me propongo desarrollar una placa de captura digital para 32 MHz.
Las novedades las iré posteando aquí en forma de blog.
El desarrollo completo lo voy a ir subiendo acá.

Saludos
 
Está muy interesante el proyecto. Pero me quedaron algunas dudas: los puertos como los USB, por ejemplo, no tienen la velocidad necesaria para enviar la señal digital "en vivo"? Quizás no me quedó muy claro como pretendes mandar los datos a la PC.
 
Lo importante es que la velocidad de captura sea alta, para lograr menor tiempo
entre muestras (mayor resolución).
La lentitud de la transferencia a PC o un GLCD, sólo afecta la velocidad de refresco
de la pantalla.
Con el puerto paralelo (sin USB por medio) he logrado transferir a la PC hasta 100 kBytes/seg.
Para que la tasa de transferencia no me limite la tasa de captura es que me complico
la vida poniendo una memoria entre medio: justamente para separar el proceso de
captura del proceso de display.
De esa forma se pueden aprovechar los conversores actuales de 1 GSPS
GSPS=Giga Sample Por Segundo = 1.000.000.000 muestras por segundo.

Aún así, hay que saber manejar esa cantidad de datos entregados por el conversor.
La cosa no es fácil porque la lógica disponible es infinitamente más lenta.
Los esquemas que he visto para poder capturar a tasas del orden de 100 MSPS
no son muy complejos pero sí voluminosos porque usan varias memorias.
Las memorias en sí son lentas, pero al multiplexarlas se logra subir la tasa de
captura. Para muestrear a 10 veces más que lo que permite la memoria se necesitan
poner 10 memorias multiplexadas, retrasadas entre sí y con latches que retienen los
datos en la entrada de la memoria el tiempo necesario. Y el circuito se complica.
Además aparecen efectos en alta frecuencia que normalmente uno no tiene en cuenta.
Una vez quise hacer un PLL a 100 MHz con placas de prototipo comunes, sin plano
de masa, y se generaban acoples por todos lados.

Igualmente lo primero que voy a hacer es probar con 32MHz para no tener ese tipo de
problemas. Y para conseguir fácil los componentes !
 
Ya se que para transferir al PC se podría mandar una "imagen" cada cierto tiempo, pero sería mucho mejor enviar todas las muestras, ya que eso aumentaría considerablemente la cantidad de utilidades que se le podrían dar al "osciloscopio", y ya no utilizarlo solo para osciloscopio, si no para cualquier otro proyecto que requiera transferir datos analógicos a la PC a gran velocidad.
Ya me voy dando cuenta de que no es fácil la cosa de transmisión de datos a gran velocidad, pero fijate que la velocidad del USB (en especial el 2.0) es altísima. Veo que el problema va por con que dispositivo enviar tantos datos a tan alta velocidad.
En cuanto a la LCD, no le veo problema en no tener una velocidad de refresco muy alta, porque la única función de la pantalla es mostrar la onda y datos al usuario, que de todas formas no apreciaría mas de 20 cuadros por segundo.
En fin, quizás mi idea sea demasiado ambiciosa.
 
Claro, pero tampoco se puede diseñar algo que sirva para todo.
Cada problema se resuelve cuando se plantea.

Además cada ventaja tiene un precio.
La idea de muestrear y transferir inmediatamente implica gestionar cada dato en un tiempo no
mayor que el de la captura. Eso es un reto mayor cuanto más rápido sea la tasa de captura.
También implica un ancho de banda de la captura limitado por el ancho de banda del display.

Dentro de la utilidad que le veo a corto plazo, trato de ver las limitaciones que puedo resolver yo.
Parto de la idea de muestrear una ráfaga de 32.000 muestras de 8 bits primero, y luego
mandarlos a una pantalla.

Por empezar no puedo ver puntos más cerca que 30 ns.
Capturar 32 kB a 32 MH son cerca de un segundo el barrido total. Este es el menor tiempo de
refresco de pantalla (una pantalla por segundo).
Si me molesta el parpadeo tengo que reducir la cantidad de muestras del barrido, lo que reduce
también la información obtenida.
Capturando 32.000 muestras por vez, y mostrando sólo 128 pixels en el GLCD, puedo ver el barrido
de pantalla completo de un 1 segundo, o hacer ZOOM hasta que abarque sólo 46 us (128 x 30ns).
Si capturo menos muestras gano velocidad de refresco, pero pierdo mucho de la posibilidad de zoom,
aparte de que desperdicio memoria. Podría particionar en varios barridos independientes, pero eso
es complicar las cosas.

Por otra parte subir la tasa de captura complica todo el proyecto, cambian los integrados,
cambia el circuito, etc.
Además se justifica si lo que se quiere es ver más detalle, no más velocidad de refresco.
Para tener un barrido de más puntos en total debo poner un banco de varios chips de memoria
en cascada. El multiplexado de memorias, otro problemita de los que señalé antes en el mensaje 9.
...

Las aplicaciones que se ven por ahí apuntan a aumentar las "features", pero el que usa esto
para el trabajo de calle, necesita más de que sea portátil, a que pueda ver la curva en 3D, o
exportarla a PITOCAD.

Mi estrategia es: Primero resolver todo el circuito en baja tasa de muestreo.
Luego subir la tasa de muestreo y ver que problemas nuevos aparecen.
Total, nadie va a venir a comprarme esto a mí, teniendo los chinos a la vuelta de la esquina.

No vamos a inventar el osciloscopio nosotros !
 
Como dije:
La idea de muestrear y transferir inmediatamente implica gestionar cada dato en un tiempo no
mayor que el de la captura. Eso es un reto mayor cuanto más rápido sea la tasa de captura.
También implica un ancho de banda de la captura limitado por el ancho de banda del display.

Separando los problemas: captura por un lado, y display por otro, se puede lograr algo muy interesante.

Acá hay mucha gente que piensa en armarse un osciloscopio con un TV.
El que arme un osciloscopio con su TV y lo use entrando con la señal analógica adaptada para verla
directamente ya tiene su herramienta, pero para ver señales de audio, a lo sumo. :)

Un segundo paso es armarse la placa de captura para hacer el barrido más rápido, y luego generar la señal
adecuada para entrarle al TV que ya tiene adaptado.
Con mi placa llegarán hasta 32MHz de muestreo, que serían unos 3.2 MHz de ancho de banda.

Más práctico que eso no se me ocurre. :rolleyes:

Aguante el subdesarrollo :LOL:

Editado:

Si quieren ver la velocidad de refresco en un GLCD vean este "fideo":

http://www.youtube.com/watch?v=RKs4RImajNw&feature=channel

Como ven no es tan alta y por eso hago el cambio gráfico -> texto -> gráfico, nunca de gráfico -> gráfico.
Mientras se muestra el texto se refresca la memoria gráfica, lo que se alcanza a apreciar a simple vista
como una cortina que pasa de arriba hacia abajo, toda la pantalla.

Normalmente no se llega a más de 2 cuadros por segundo.
La única forma de superar esa tasa de refresco es no esperar que el micro avise que está libre.
Pero así también ocurre que el micro a veces manda "basura" al display.
 
Atrás
Arriba