# Arme su osciloscopio (analógico ó digital)



## asherar (Jun 6, 2009)

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


----------



## asherar (Jun 28, 2009)

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,   
  - o trabajar con FPGA.  

Bueno, son ideas como para organizar el trabajo. 
No es para desmoralizar a nadie.


----------



## electrodan (Jun 28, 2009)

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.


----------



## alexus (Jun 28, 2009)

una tv de 5"?


----------



## electrodan (Jun 28, 2009)

El problema es que las TVs usan bobinas para la deflexión. O hay alguna que use las plaquitas?


----------



## alexus (Jun 28, 2009)

ni idea, y si te haces una igtv con avr?


----------



## asherar (Jun 28, 2009)

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.


----------



## electrodan (Jun 28, 2009)

Como que lo digital no me convence mucho... Voy a tener que aprender a dominar esos dispositivos lógicos.


----------



## asherar (Jun 28, 2009)

Te vas a tener que convencer nomás, porque muy pronto, hasta la TV se va a hacer digital !


----------



## electrodan (Jun 28, 2009)

Estoy hablando con alguien que desarrolla sistemas digitales...  Hay que adaptarse.


----------



## elosciloscopio (Jun 30, 2009)

alexus dijo:
			
		

> una tv de 5"?



Eso es exactamente lo que he hecho yo.

Pd: No hay manera de refrigerar los transistores de 15A


----------



## electrodan (Jun 30, 2009)

Bueno, entonces este domingo me voy a comprar una tv portatil de las viejas.


----------



## asherar (Jun 30, 2009)

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.


----------



## asherar (Jul 9, 2009)

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


----------



## asherar (Jul 10, 2009)

Si a alguien le interesa simularlo, le puedo pasar el esquemático en protel. 
Obvio que quiero ver el resultado


----------



## electrodan (Jul 11, 2009)

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.


----------



## asherar (Jul 11, 2009)

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 !


----------



## electrodan (Jul 11, 2009)

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.


----------



## asherar (Jul 11, 2009)

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 !


----------



## asherar (Jul 11, 2009)

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.   

Aguante el subdesarrollo  

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.


----------



## asherar (Nov 18, 2009)

Hola: 

   Hace poco empecé a diseñar un sistema de captura de datos con "aspiraciones" 
de osciloscopio digital. El sistema proyectado tiene como característica principal 
la posibilidad de ser construido con materiales no críticos. Esto es, principalmente, 
en lo que se refiere al reloj de captura, y la velocidad de acceso de componentes 
como memorias, compuertas, etc. 
 Trabajando con lógica TTL, y usando la serie HC, es posible pensar en gatillar un 
conversor digital con un reloj de 32 MHz. A esta velocidad es relativamente sencillo 
manejar contadores digitales TTL y memorias RAM de 12 ns de tiempo de grabación. 

 Sin embargo, con 32 MSPS el ancho de banda nominal según el teorema de Nyquist 
sería de no más de 16 MHz, y teniendo en cuenta consideraciones más prácticas, en 
realidad nunca se verían demasiado bien, señales de más de 3 MHz. Para una 
herramienta de laboratorio, esto limitaba las aplicaciones a algunas mediciones en 
audio, pero no mucho más. 

  Averiguando acerca de cómo se las arreglan los osciloscopios digitales para gestionar 
las enormes cantidades de datos que generan los conversores A/D de más de 1 GSPS, 
encuentro una agradable noticia (ver referencias 1 y 2). 
Resulta que los osc. digitales no necesariamente trabajan siempre a tiempo real. 

No es novedad que se suele componer un barrido de mayor resolución a partir de varios 
barridos efectuados con retrasos prestablecidos. Este método de compaginación es sólo 
aplicable a señales repetitivas y se denomina de "tiempo equivalente". 

 Lo que sí es novedad, al menos para mí, es que habiendo conversores más que rápidos 
(> 1 GSPS) algunos osciloscopios muy conocidos como Tektronix y Agilent, trabajen con 
conversores de 200 kSPS y 40 kSPS, y aún así logren anchos de banda de 70 y 65 GHz, 
respectivamente. 

   Esto muestra a las claras que la mayor énfasis del circuito se pone en generar los retrasos 
entre dos barridos consecutivos. La precisión debe ser alta ya que, para un mismo barrido, 
el valor del retraso debe mantenerse constante dentro del margen de tiempo admitido por 
el jitter (aleatoriedad de fase del disparo del trigger). 
Asimismo, la diferencia de retraso entre dos barridos sucesivos debe establecerse con la 
misma precisión a fin de no complicar el compaginado que le sigue. 
Por si faltaba algo, tengamos en cuenta que para lograr anchos de banda del orden de los 
60-70 GHz es necesario separar dos barridos varias decenas de ps. Este tiempo debe ser 
ajustado como mínimo al 1 por mil, ya que los números de muestras tomadas en el barrido 
rondan los varios miles. Estamos hablando de precisiones del orden del femtosegundo 
(10^-15 seg).!!!!

   Todo esto no hace más que alentarme a continuar mi desarrollo de un sistema de 32 MSPS 
de tasa de captura, que ahora ya no me parece tan baja. Aunque simple en principio, en un 
futuro no tan lejano, este sistema podría mejorarse sustancialmente con un mecanismo de 
tiempo equivalente, gestionado en baja frecuencia por un micro. A todo esto recordemos la
propuesta de retardo variable (RVAR) en mi diseño original, en especial la figura 2. 

Armando un barrido compuesto con apenas 8 barridos simples retrasados, se alcanzaría un 
ancho de banda de aprox. 25 MHz  (250 MSPS). Los retrasos necesarios entre cada dos 
barridos deberían ser de aprox. 4 ns. 
La cosa pasa entonces por generar digitalmente, retardos idénticos del orden de unos pocos 
ns, y con precisiones de ps. Casi nada!
Lo bueno del método de tiempo equivalente es que para lograr buenos anchos de banda no 
se requieren componentes demasiado rápidos. 

Últimamente Tektronix ha resuelto el problema de otra forma (ver Ref. 2) definiendo el 
Tiempo Real Digital (DRT): en lugar de hacer digamos 200 barridos diferentes y desfasados, 
para luego superponer las muestras en tiempo equivalente, directamente pone (no lo dice 
explícitamente) 200 conversores desfasados a trabajar en paralelo sobre el mismo barrido 
y obtiene ancho de banda en tiempo real. 

   El otro detalle que queda para considerar con mayor cuidado es la respuesta en frecuencia 
de la parte analógica. Por rápida y bien gestionada que sea la conversión AD, si la circuitería 
analógica distorsiona la señal, entonces la calidad del sistema se viene irremediablemente 
abajo. 

Hasta pronto.

*
Referencias: *

1.- SEQUENTIAL EQUIVALENT-TIME SAMPLING WITH AN ASYNCHRONOUS REFERENCE CLOCK -                      U. S. Patent Application 20090237072

2.- Tecnología digital de tiempo real Tektronix y mercado       de osciloscopios de bajo costo     
 
3.- DESARROLLO DE UN SISTEMA AUTÓNOMO DE CAPTURA DIGITAL A 32 MHz 
*

Lecturas adicionales:*

Osciloscopios con Memoria Digital (DSO)


----------



## KARAPALIDA (Nov 21, 2009)

Exelente sherar,

despasito pero te voy siguiendo.

Saludos


----------



## asherar (Dic 18, 2009)

Una forma interesante de comprender el concepto de tiempo equivalente se muestra en este video.


----------



## asherar (Dic 21, 2009)

Enlace a un proyecto avanzado: *AQUI*


----------



## turconi (Ene 20, 2010)

Sigo atentamente todos los comentarios hechos en el tema ..... si avanzan en algo mas o precisan algo de Buenos Aires avisen..... 

Tambien ando con un proyecto de Osciloscopio Digital e hicimos una placa pensada desde el desarrollo en este link... ( a mi no me convence para nada pero bueno ya le tenemos montada... falta que alguien la ponga en marcha pero tiene horrores el proyecto en algunos lados ya que no funciona del todo.....) 
Paso link http://pablohoffman.com/cgi-bin/twiki/bin/view/Oscusb/WebHome
y tambien compramos este http://www.justblair.co.uk/seeed-studio-dso-nano-pocket-digital-storage-oscilloscope-review.html
que para las tonterias esta bueno ya que es autonomo y chico... pero nada mas, nada profesional....

Un saludo Diego


----------



## DJ DRACO (Ene 20, 2010)

hola muchachos...soy fanatico de la electronica tambien y me gustan mucho estos aparatos como osciloscopios etc...pero...hago 2 preguntas:

1) por qué en vez de intentar diseñar un osciloscopio rompiendonos la cabeza...mejor no buscamos planos de uno comercial??

2) por otro lado, no sería mas facil digitalizar las señales y trabajarlas digitalmente a alta velocidad, y luego de ahi manejar un LCD o pantallita??

obviamente creo que un osciloscopio es uno de los instrumentos mas complejos y útiles en el ambito de la electronica...y que su construccion no es nada simple...

saludos.


----------



## asherar (Ene 20, 2010)

turconi dijo:


> Sigo atentamente todos los comentarios hechos en el tema ..... si avanzan en algo mas o precisan algo de Buenos Aires avisen.....
> 
> Tambien ando con un proyecto de Osciloscopio Digital e hicimos una placa pensada desde el desarrollo en este link... ( a mi no me convence para nada pero bueno ya le tenemos montada... falta que alguien la ponga en marcha pero tiene horrores el proyecto en algunos lados ya que no funciona del todo.....)
> ...
> ...



Te agradeceré que me hagas notar cualquier "horror" que le encuentres a mi 
proyecto. Seguramente me va a doler en el orgullo pero, si es para aprender, 
igualmente te daré las gracias. 

PD: Si tus comentarios caen demasiado fuera de las normas del foro, podés 
hacerlos por la vía del mensaje privado. En el peor de los casos te responderán 
en el mismo tono.



DJ DRACO dijo:


> 1) por qué en vez de intentar diseñar un osciloscopio rompiendonos la cabeza...mejor no buscamos planos de uno comercial??



Creeme que en los últimos años he buscado pero no he podido encontrar nada simple, 
completo, accesible y profesional.  Además: me gusta romperme la cabeza ... 



DJ DRACO dijo:


> 2) por otro lado, no sería mas facil digitalizar las señales y trabajarlas digitalmente a alta velocidad, y luego de ahi manejar un LCD o pantallita??


Eso es lo que entiendo por "la alternativa profesional", lo que yo intento es algo más 
artesanal, con componentes accesibles para cualquier hobbista, y que requiera algo 
de ingenio y mucho trabajo. 

Saludos


----------



## hackmanice (Feb 16, 2010)

Para Alejandro Sherar

Este proyecto es muy bueno he tratado de desarrollar mi propio osciloscopio digital y quisiera compartir de igual forma mi proyecto, adicionalmente quisiera saber si tienes la parte del conformador y sistema de borrado del osciloscopio analogo que publicaste de la revista Radio Técnica.

Gracias de antemano


----------



## cosmefulanito04 (Feb 16, 2010)

Yo estoy tratando de hacer un osciloscopio de cero, bastante precario diriamos  .

Mi idea es bastante simplona:


```
Entrada => Atenuador -------> Amplificador Variable ----> Conversor A/D ---> uP
                    |
                    ----- Trigger (usando Schmitt)---> uP
```

El uP se encarga de obtener niveles de tension y los tiempos en los que estos fueron tomados, luego por puerto serie mando los datos a una Pc y realizo todos los calculos complicados (en numero flotante y demas) en ella, obviamente tambien grafico la señal (programa hecho en Java).

El uP es un 89s52 ($8 a $9 en Argentina, se banca un cristal hasta 33 MHz => clk=2,75 MHz, lento), el A/D un 0804 (10 kHz max, una lenteja tambien), la idea es tratar de llevarlo hasta 100 kHz lo cual parece complicado con las velocidades de las de los componentes, pero aprovechando que la señal es periodica, me puedo dar el lujo de tomar una sola muestra por periodo e ir armando la señal con c/ periodo.

Hasta ahora hice el programa en java que se comunica con el 8051, el graficador ya estaria hecho, hice prueba basicas con el 8051 y el AD para ver si podia graficar un nivel de continua y hasta ahi habia llegado. Lamentablemente por falta de tiempo lo tengo parado, pero la idea era ir un paso mas y probar señales de baja frecuencia para luego ir aumentando y ver hasta donde llegaria.

Ademas faltaria toda la parte de adaptacion de los niveles, ver si en lo posible se puede trabajar con fuente simple, etc. 

El proyecto en si facil no es, pero para aprender esta bueno, ademas siendo realistas dudo que la precision de las medidas sea buena en altas frecuencias, y habria que ver que sucede en bajas. Pero tenia planeado agregar una funcion en el programa en java que me permita calibrarlo a partir de un osciloscopio profesional.


----------



## hackmanice (Feb 16, 2010)

Bueno yo he hecho algunas pruebas con ADC TI5540 conectado a una memoria Fifo y adquisición por el puerto paralelo con muy buenos resultados, una pagina interesante que puede servir de base es la siguiente:
http://technology.niagarac.on.ca/staff/mcsele/LogicAnalyzer.html
es un proyecto de un analizador logico lo unico necesario es adicionar un ADC, un sistema de triger y acondicionamiento de señal.


----------



## asherar (Feb 17, 2010)

hackmanice dijo:


> Para Alejandro Sherar
> 
> ... adicionalmente quisiera saber si tienes la parte del conformador y sistema de borrado del osciloscopio analogo que publicaste de la revista Radio Técnica.
> 
> Gracias de antemano



Creo que te referís a esto.

Saludos


----------



## hackmanice (Feb 18, 2010)

Alejandro Sherar dijo:


> Creo que te referís a esto.
> 
> Saludos



Alejandro siguiendo con este tema de antemano muchas gracias, me gustaria saber este osciloscopio analogo que ancho de banda tiene, dado que segun comentaste lo construiste, de igual forma me gustaria saber que avances has logrado con el prototipo de osciloscopio digital?


Gracias


----------



## asherar (Feb 18, 2010)

En ningún lado dije que haya construido el analógico. 

El sistema de captura digital contra el que estoy peleando "aspira" a funcionar como osciloscopio, pero para eso falta ...


----------



## Prusoft (Mar 2, 2010)

Hola amigos. Me interesa el tema del osciloscopio, pero fundamentalmente algo que leí en un poster anterior sobre usar la PC como  instrumento por la entrada de audio. 

El problema es que los Software que he encontrado para esto, no graban la señal, solo el espacio en pantalla. Si alguien tiene alguna referencia a un Soft que me permita guardar la medición y verla en otro momento o con otra herramienta se lo agradeseria.


----------



## asherar (Abr 18, 2010)

Si bien hay retardos de ns y fracción como los de *ELMEC* o los *DS1045* de MAXIM, estoy 
buscando una forma práctica (sencilla, poco voluminosa y barata) de generar un conjunto 
de retardos iguales para incorporar el método de tiempo equivalente al muestreo. 
En esta figura iría en el módulo denominado RVAR. 

Los retardos consisten en subdivisiones del tiempo mínimo entre dos muestras sucesivas, 
debido a la máxima frecuencia de muestreo. 
Para un CLK de 32MHz se tiene un período de 31.25 ns. 
Ajustando el retardo con los mismos 4 bits más altos de la RAM, estaría 
generando automáticamente un banco de RAM separado para cada barrido.

Una idea es, con los 4 bits disponibles del contador de desborde conmutar entre 
16 retardos fijos RC, para asignarlos al tren de pulsos que proviene del trigger. 
Este método requiere tener al menos 4 retardos fijos: 1 T, 2 T, 4 T, 8 T, todos 
calibrados al 1 %. 
Para 16 intervalos en 31 ns, esto da aprox. T = 2 ns, (1.95 ns) con precisión de 20 ps. 
Para valores de R del orden de 100 Ohm se requiere valores de los C cercanos a las 
capacidades parásitas. Esta idea es cuanto menos impracticable con 
componentes "normales". *No cumple la premisa de "sencilla"*.

Otra idea es, con los 4 bits conmutar un arreglo de resistencias, para que la 
resultante defina la R de una subida o bajada tipo RC. Una idea parecida a la anterior  
pero con un solo capacitor. Solo que ahora el retardo se ajustaría mediante una tensión 
fija que entra a un comparador junto con la rampa. Al disparar siempre a la misma tensión, 
variando el RC se obtendría un retardo diferente para cada valor de los 4 bits. 
La ventaja de esta forma está en que los componentes RC pueden ser más 
razonables (R y C mayores), dado que el disparo es indirecto por comparación 
de tensiones. 
Había empezado a complicarme armando algo con esta idea, pero se me ocurrió 
otra más simple aún. 

La tercera idea se trata de controlar un transistor 3904 en conmutación, aprovechando 
que su tiempo de retardo depende de las corrientes de base y de colector. 
Estuve probando con un emisor-común variando la R de base, y también levantando 
el emisor con una R variable, y al menos en baja frecuencia parece funcionar. 
Como la rampa de subida (o bajada) de colector cambia su pendiente, al disparar un 
comparador contra una referencia de tensión fija, cambia el retardo respecto del 
disparo de la señal en la base. 
Como simple es muy simple. Ahora veré si resulta práctico por cuestiones de rangos 
y precisión.


----------



## asherar (May 4, 2010)

Prusoft dijo:


> Hola amigos. Me interesa el tema del osciloscopio, pero fundamentalmente algo que leí en un poster anterior sobre usar la PC como  instrumento por la entrada de audio.
> ...



Habría que ver si te sirve el "Winscope 2.51" diseñado    por Konstantin Zeldovich.


----------



## asherar (Dic 14, 2010)

Hola: 

Revivo este tema para subir un enlace que encontré, de un sistema de captura digital que se conecta al puerto paralelo de la compu (yo no lo he armado aún). 
Aquí está el esquemático y la placa que, según dice allí, puede armarse por menos de 6 U$S.
http://sites.google.com/site/scopeonpc/scopeonpc4




También se puede bajar el programa que lo completa para tener un osciloscopio en la PC. Todos los detalles se pueden bajar del sitio original. 
http://sites.google.com/site/scopeonpc/scopeonpc6

Finalmente un esquema de un muestreador para sincronizar la captura digital.
Realmente no recuerdo de dónde lo bajé. 


A experimentar !


----------



## seaarg (Ene 4, 2011)

Alejandro:

Tengo la experiencia de un amigo que armo un osc con el ADC conectado derecho al puerto paralelo. No sirvio ya que si bien el ADC era de 1.5us por sample, la posterior captura y procesamiento para poder recibir el siguiente dato hacia muy lento todo. No pudo samplear aceptablemente señales senoidales de mas de 10khz segun recuerdo.

Personalmente, yo hice uno tambien por puerto paralelo, pero con un conversor de 80msps funcionando a 40msps (mas alla era erratico por diseño de placa supongo) con una memoria sram de lectora de CD entre el conversor y el puerto paralelo.

Funcionaba por paginas, cuando el trigger disparaba activaba la captura a 40mhz hacia la memoria. Cuando esta estaba llena, comenzaba una transferencia desde la memoria al puerto paralelo, controlada por un uC 16F628A.

Como el tiempo de sample era constante, el t/Div del mismo lo hacia visualizando: 1)- todas las muestras (max. resolucion) 2)- Una muestra cada 2, 3)- Etc.

Despues lo abandone por otros problemas y tengo rondando en la cabeza hacer lo mismo pero USB con uC 18F2550.

Y cuando termine unos proyectos, para tener algo minimo funcional voy a hacer uno por usb, utilizando un ADC no tan rapido como para poder usar la memoria del mismo uC. La entrada es la que adjunto, quitandole el ADC ese.

Aqui esta el esquematico de esa entrada.
Ver el archivo adjunto 41833
https://www.forosdeelectronica.com/f24/dudas-consejos-hacer-pic-osciloscopio-45184/#post385080


----------



## dragondgold (Ene 4, 2011)

asherar dijo:


> Hola:
> 
> Hace poco empecé a diseñar un sistema de captura de datos con "aspiraciones"
> de osciloscopio digital. El sistema proyectado tiene como característica principal
> ...



asherar dejame ver si entendí, lo que hace básicamente es tomar una muestra y como la señal es periódica se espera a llegar al mismo punto donde se tomo el muestreo anterior pero se espera por ejemplo 1nS mas asi se obtiene otro punto y así sucesivamente hasta muestrear toda la señal?
Te hago una pregunta porque estoy siguiendo el tema y estoy en el desarrollo de un osciloscopio sobre un LCD TFT Touchscreen. No encuentro cual es la función del trigger en el osciloscopio, deduzco que es el que da la base de tiempo de la señal ya que en cierto voltaje de la señal el trigger se dispara (se pone a 1) y al caer la señal se pone a 0 y se cuenta el tiempo entre esos dos puntos, es así? Sino de qué modo se crea la base de tiempos?
Como haces para tomar un señal negativa? La desplazas con un operacional hacia un valor positivo y en algún pin del micro indicas que es negativa y luego se la corrige por software?

Saludos y gracias!!


----------



## asherar (Ene 4, 2011)

seaarg: 
A mi también me pasó lo mismo con una placa comprada basada en el AD0808 (no recuerdo 
bien el nro, pero era uno muy conocido de Motorola), 
Con un conversor más rápido (fs=25 MHz) y una placa hecha por mí, llegué a 100 KSPS por 
el LPT.

dragondgold
1.- Exactamente. 
2.- El trigger sincroniza el inicio del barrido en la pantalla, con el instante que la señal 
pasa por una condición dada de amplitud y pendiente. 
3.- Como dices, el rango de amplitud de entrada del conversor determina el rango de 
salida que debe ajustarse al Opamp. Los conversores rápidos tienen rangos de entrada 
de 0V a 1V ó de -1V a +1V. 

Además, todas estas cosas se complican a medida que uno trabaja con señales de 
frecuencia mayor a 1 MHz, por los desfasajes que ocurren adentro de los opamp.


----------



## dragondgold (Ene 4, 2011)

Si una de las mas grandes barreras que encontre fue el tema del acondicionamiento de la señal de entrada. Aquí en Argentina no es muy facil conseguir operacionales de gran ancho de banda y no traen samples asi que es un gran impedimento, habia empezado a diseñar un operacional con unos transistores de RF que conseguí de 800MHz pero por cuestiones de tiempo se quedó ahí ahora que entre en vacaciones voy a ver si puedo continuarlo.

Saludos y suerte!!


----------



## asherar (Ene 7, 2011)

Maxim tiene algunos opamp bastante rápidos. 
Los mencioné acá.   
Si tenes suerte te mandan algunos samples. 
El problema no es el costo sino cómo traerlos hasta sudamerica. 
Tal vez con algún amigo que viaja.


----------



## picproblema (Ene 19, 2011)

Buenas! El tema de muestreo en tiempo equivalente me interesa, y buscando por internet encontre Application Note 72 - A Seven-Nanosecond Comparator for Single Supply Operation el circuito "voltage-controlled delay". Por lo que lei en post anteriores ese circuito tiene el inconveniente de que necesita el lt1394 o un comparador con similares caracterisiticas (dificil de conseguir por argentina) y ademas requiere de circuiteria adicional para autoincrementar. A pesar de dichos problemas espero les sirva de algo.


----------



## picproblema (Feb 5, 2011)

Hola a todos! Es posible usar, por ejemplo, el ds1023 y un contador para auto incrementar? Los contadores pueden llegar a 100 Mhz facilmente.


----------



## Nicko_2310 (Feb 6, 2011)

Buenas tambien estoy interesado en el tema aca les dejo algo que encotre 

http://pablohoffman.com/twiki/pub/Oscusb/OscusbDocumentacion/oscusb-documentacion.pdf

ó

http://pablohoffman.com/cgi-bin/twiki/bin/view/Oscusb/WebHome

me parecio muy interesante 

una leida no le vendria nada malll

Saludos


----------



## SKYFALL (Mar 2, 2011)

yo tengo por ahi el diagrama de un osciloscopio que es lo mas artesanal que he visto, pues no utiliza un CRT para visualizar las formas de onda sino que su pantalla esta constituida por leds en una matriz de 20 x 32.


----------



## pandacba (Mar 7, 2011)

En los númros 1602/1 de Radio Práctica, que se publicaba en Argentina, se publico una muy interesante nota para hacer un oscilospio, se puede partir de alli para hacer otras cosas esta muy bien detallado obvio es para utilizar con un TRC, y por alli tengo algo más reciente resuelto en un par de placas bastantees chicas, todo de origen Frances, y tengo varias otras cosas referidas a lo mismo de origen de paises del este euripeo. Si alguno le ientresa lo busco, ya que tengo todo el material pero esta en DVD y de esos por aqui hay todo un arsenal, ya que se recibien diarios promedio 6Gb de info, planos, manules de servicio, datasheete, notas técnicas, y un etc enorme....


----------



## asherar (Mar 8, 2011)

Lo que les parezca que tenga que ver con este tema lo pueden ir subiendo, así le damos una ojeada. 
Saludos y gracias


----------



## foso (Mar 14, 2011)

Hola yo estoy en la misma, pretendo hacer un osciloscopio para la PC como proyecto de fin de carrera. EL proyecto final lo quiero hacer con un micro de Freescale y dos conversores D/A de Texas de 8 bits que muestrean hasta 20 MHz. 

Como todavia estoy probando el programa de la PC hecho en visual C#, estoy utilizando un pic 18F2550 para muestrear datos y pasarlos a la PC por USB. Entonces aprovecho para mostrar unos resultados por si a alguien le interesa. Igual es algo que se puede sacar del manual del micro:

Se trata de la frecuencia máxima de muestreo del ADC del pic 18F2550. Lo que traté de hacer con el programa que adjunto es muestrear dos valores lo mas rápido posible y guardarlos en memoria. Un pin del micro marca el comienzo y el final. Esta señal la medí con un osciloscipio, adjunto una imagen. El tiempo entre muestras es de 15.5 us, lo cual da una frecuencia de muestreo de unos 64.5 kHz.


----------



## pandacba (Mar 14, 2011)

pasa por aqui-> https://www.forosdeelectronica.com/f23/osciloscopios-miniatura-proyectos-53120/


----------



## foso (Mar 14, 2011)

muy bueno el mini osciloscopio. Se conseguiran esos tubos ???


----------



## Eduardo Lucci (Sep 13, 2011)

pandacba dijo:


> En los númros 1602/1 de Radio Práctica, que se publicaba en Argentina, se publico una muy interesante nota para hacer un oscilospio, se puede partir de alli para hacer otras cosas esta muy bien detallado obvio es para utilizar con un TRC, y por alli tengo algo más reciente resuelto en un par de placas bastantees chicas, todo de origen Frances, y tengo varias otras cosas referidas a lo mismo de origen de paises del este euripeo. Si alguno le ientresa lo busco, ya que tengo todo el material pero esta en DVD y de esos por aqui hay todo un arsenal, ya que se recibien diarios promedio 6Gb de info, planos, manules de servicio, datasheete, notas técnicas, y un etc enorme....





Es un placer encontrar gente como Ud. dispuesta a colaborar ofreciendo informacion casi imposible de conseguir...    Con respecto a la informacion sobre el osciloscopio publicado en los Nº 1602/1 de Radio Practica le agradeceria mucho si puede enviarme datos del mismo.- 
Yo arme ese osciloscopio alla por los años 80 y aunque no pude hacerlo funcionar en su momento aun conservo casi todos los materiales para el armado del mismo (menos plaquetas y circuitos), solo que perdi los Nº de la revista y con ellos todos los datos, diseño de las plaquetas y parametros de tensiones de los circuitos (solo me quedo el gabinete con el tubo y la fuente de alimentacion que aun funciona).- 
Como comprendera, me motiva solamente el hecho de cumplir con el sueño de ese momento (ya entre en la terecra edad)  ya que en la actualidad ese instrumento seria de poca utilidad.-
Si tiene algunos circuitos mas actualizados para mejorarlo seria interesante para mi.-
Desde ya muchas gracias...


----------



## pandacba (Sep 13, 2011)

Eduardo Luci,
Ante todo bien venido al foro
Solo te pido que quites el mail de tu mensaje asi te evitas un tirón de orejas ya que hay una norma que no permite hacer eso.

Por aqui podemos comunicarnos perfectamente de paso le servira a otros, que quiean hacer algo asi por el echo de invetigar y conocer un poco màs.

En los próximos días estare subiendo la información

Un cordial saludo



foso dijo:


> muy bueno el mini osciloscopio. Se conseguiran esos tubos ???



Perdón por no contestarte antes, hasta hace un tiempo se conseguian en Ebay


----------



## Eduardo Lucci (Sep 14, 2011)

Gracias por tu respuesta y tu consejo...   realmente no conocia del todo bien las reglas del foro, mil disculpas


----------



## KODIAK_1000 (Mar 6, 2012)

lo mejor es comprarse un DSO NANO, aqui hay un video que hice a modo de demostracion rapida
http://www.youtube.com/results?search_query=dso+nano&page=2
Saludos


----------



## GEORGE747 (Jun 5, 2013)

foso dijo:


> Hola yo estoy en la misma, pretendo hacer un osciloscopio para la PC como proyecto de fin de carrera. EL proyecto final lo quiero hacer con un micro de Freescale y dos conversores D/A de Texas de 8 bits que muestrean hasta 20 MHz.
> 
> Como todavia estoy probando el programa de la PC hecho en visual C#, estoy utilizando un pic 18F2550 para muestrear datos y pasarlos a la PC por USB. Entonces aprovecho para mostrar unos resultados por si a alguien le interesa. Igual es algo que se puede sacar del manual del micro:
> 
> Se trata de la frecuencia máxima de muestreo del ADC del pic 18F2550. Lo que traté de hacer con el programa que adjunto es muestrear dos valores lo mas rápido posible y guardarlos en memoria. Un pin del micro marca el comienzo y el final. Esta señal la medí con un osciloscipio, adjunto una imagen. El tiempo entre muestras es de 15.5 us, lo cual da una frecuencia de muestreo de unos 64.5 kHz.



hey como hago eso en CCS? 
por que sinceramente no se nada de ASM haha, y la clásica me urge terminar el firware de un dispositivo de adquisisión de datos el cual funciona pero no le saco el mayor provecho al ADC


----------



## asherar (Ago 4, 2013)

Hola de nuevo. 

Acá pongo un enlace a mi proyecto de placa de captura (pausado por tiempo indeterminado) para quien pueda interesarle. Estaba subido en un servidor coreano que hace un tiempo simplemente desapareció.
Voy avanzando muy lentamente y no tengo excusa. Espero algún día poderlo terminar. 

Enlace al proyecto en mi página web.

Les dejo algunas imágenes a modo de "anzuelo". 

Saludos

*Diagrama de bloques detallado*​








*Circuito lógico de sincronización (SINCRO)







**Temporización de señales digitales*​





*Una parte del circuito de trigger*
​






* 
*


----------



## foso (Ago 4, 2013)

¿Es mucho pedir un diagrama de flujo del sistema? que muestre la utilización de la RAM por parte de la lógica y por el procesador, como y cuando se toman los datos de la RAM para llevarlos a la pantalla.


----------



## seaarg (Ago 4, 2013)

asherar. Ante todo, muchisimas gracias por actualizar los enlaces, hacia rato que lo queria ver 

Antes de implementar mi placa de captura con memorias FIFO, yo utilizaba una SRAM de 32K y un par de contadores 74HC4040 de 12 bits para direccionarla (12 bits de 1 + 3 del otro). El bit 16 de los contadores me servia para detener la captura y detectar memoria llena.

En tu caso, veo que usas contadores preseteables y tenes barriendo permanentemente la memoria (o asi entendi) hasta tener un trigger, donde habilitas un contador que te dira cuando detener la captura. Estimo que tiene que ver con lo que explicas para tener datos pre-trigger. El fin de hacer eso es simplemente saber que paso antes del trigger o hay alguna otra finalidad?


----------



## asherar (Ago 4, 2013)

foso dijo:


> ¿Es mucho pedir un diagrama de flujo del sistema? que  muestre la utilización de la RAM por parte de la lógica y por el  procesador, como y cuando se toman los datos de la RAM para llevarlos a  la pantalla.


La información solicitada está en el diagrama de temporización digital. 

Hay dos generadores de CLK: CLK1 y CLK3. (Ver diagrama del circuito lógico de sincronización)

La memoria se recorre haciendo oscilar /CS, que se controla por CLK1  (para la captura rápida) 
o por CLK3 (para la descarga lenta). 
Con CLK1 se GRABA y con CLK3 se LEE de las memorias. 

Los contadores se sincronizan con CLK1R y CLK2R, versiones retrasadas de CLK1 y su versión negada CLK2. 
CLK1R cuenta las muestras post-trigger y CLK2R permite recorrer las direcciones de la memoria. 
En una primera etapa CLK2R sigue a CLK2 y sincroniza la conversión A/D. 
Más tarde CLK2R sigue a CLK3 y sincroniza la descarga de los datos guardados por el puerto LPT (hacia una PC) o directo hacia un GLCD. 

El funcionamiento del sincronismo se describe con más detalle en este enlace, al que también se accede desde el enlace principal. Se describe la secuencia paso a paso ilustrando con imágenes de los estados de una simulación del circuito de sincronismo hecha con _LOGISIM_.  



seaarg dijo:


> En tu caso, veo que usas contadores preseteables y tenes barriendo permanentemente la memoria (o asi entendi) hasta tener un trigger, donde habilitas un contador que te dira cuando detener la captura. Estimo que tiene que ver con lo que explicas para tener datos pre-trigger. El fin de hacer eso es simplemente saber que paso antes del trigger o hay alguna otra finalidad?



Si, es justamente para ver qué pasó antes del trigger. 
Son dos contadores separados, cada uno lleva cuatro chips de memoria. 
Tal vez es una complicación exagerada para algo que no es indispensable. 
Se podría eliminar uno de los contadores y cambiar un poco el programa de control. 

Todavía lo tengo montado en placa de prototipos (no me gusta el protoboard, prefiero soldar)
y estoy teniendo algunos problemas con las tensiones al querer sacar los datos hacia la pc. 
Estuve un tiempo largo probando y probando sin poder resolver nada. 
Está bien un poco de obsesión para llegar a resultados superadores, pero realmente me cansó no conseguir nada, y eso tiene que ver con que sea un sistema tan complicado. 
Puedo optoacoplar, pero bueno, eso requiere más placas, más cableado y ... más tiempo !!!  

También me desanimó bastante no poder avanzar con lo del retardo variable para el "tiempo equivalente". Bueno, es por eso que lo tengo medio archivado, y lo retomo cada tanto. 
Igual voy haciendo otras cosas más simples, como para ver resultados positivos y "reacomodar" el alma. 

*seaarg*: qué tasa de captura lograbas con el 74HC4040 ?
Según la HDD llega hasta 90 MHz.


----------



## seaarg (Ago 4, 2013)

Yo tengo una hoja de datos del 74HC4040 que dice que la F maxima es 73mhz. Recuerdo que hasta los 50mhz anda perfecto, entre 50 y 80mhz anda pero las salidas de direccion se veian muy poco cuadradas. Tal vez era el osciloscopio con el que las media simplemente.

Por otro lado, cuantos retardos de tiempo equivalente necesitas? A mi se me ocurrio la idea abstracta de jugar con el retardo de inversores schmitt trigger y seleccionar el conjunto de retardos con un mux digital, estilo 74HC151. El problema de esta idea es que los datasheet te dan un retardo "tipico" pero variante entre un max y min. Esta idea era CLK conectado a 2 inversores, CLK conectado a 4 y asi. Otro problema de esto es que los valores de retardo no suelen ser "redonditos"

De todos modos, vos habias hablado de hacer un retardo variable dado el valor de resistencia de un componente discreto (creo que era un fet) o algo asi, y esa idea suena mejor


----------



## asherar (Ago 4, 2013)

Parece que los muchachos siguen mejorando el diseño. Ya andan por los 90 MHz: 74HC4040.pdf 

Volviendo al retardo variable.
En general todos los parámetros de un transistor dependen de la temperatura. Los capacitores y resistencias también. 
En particular, el retardo entre el flanco de entrada y el de salida en una compuerta es función de la temperatura. Algo así figura en las hojas de datos, y uno casi nunca lo considera. 

Algo más profesional sería regular la temperatura de un cristal con una resistencia calefactora puesta pegadita al lado, algo que ví en una revista hace un tiempo. 

En la figura el sensor y el calefactor van ensanguchados con el cristal oscilador, que no se ilustra.
El operacional puede ser un 741.

La idea ahí era estabilizar la frecuencia del cristal, pero acá uno debería medir y hacer una tabla: 
período del cristal vs. corriente por la R calefactora. 
Luego ver cómo hacer para trabajar solo con un pulso. Y ahí te quiero ver !

Teoría del oscilador a cristal






Como se ve en la gráfica, variando 10ºC sobre los 25ºC del ambiente uno podría aprovechar una 
variación en la frecuencia de aprox. 10 ppm. 
El análisis se debería hacer sobre la respuesta a un flanco, que es el dominio del tiempo, y los 
datos que se tienen son para el dominio de la frecuencia. Problema para don Fourier. 

Otro apunte interesante

Más info


----------



## seaarg (Ago 4, 2013)

Seria necesario trabajar con 1 solo pulso? Con el mismo oscilador a cristal "retardado" podrias mover el clock de un contador como el 4040 que te haga de divisor. Cuando pasaron 2^n pulsos (de que Q tomes la señal) ahi tenes tu trigger. Como el periodo del oscilador va a variar en funcion de la temperatura, asi lo hara el retraso. Supongo que este oscilador a cristal es controlado por, digamos, un pin de una nand, entonces, podrias usar un flip flop como el 74HC74 puesto de la siguiente forma:

Señal de trigger > flip flop > disparo habilita nand salida oscilador > oscilador > 74HC4040 > Qx dispara segundo flip flop > trigger!

Serian unos 3 integrados para hacer retardo variable con este metodo, mas el operacional y lo que haga falta para el circuito de trigger "normal"

Creo que es una idea realizable, un poco compleja pero realizable.

Dicho esto, por temperatura le veo un problema y es la reaccion. Supongamos que tenemos el cristal a 25 grados, y queremos aumentar el retraso para leer la proxima pagina de samples (el "interlineado") en realidad tendriamos que esperar a que caliente y se estabilice la temperatura. Todo esto si te entendi de que la temperatura no es solo para estabilizar sino para variar.

Si el circuito de arriba es para estabilizar, se me ocurre que con un oscilador a cristal estabilizado en temperatura podrias mover el clock de un 4040 y disponer, con un mux + flip flop, de un retardo seleccionable. Esto ultimo me gusta como idea: Q0 = sin retardo, Q1 = retardo de tantos ns proporcionales a la F del cristal, Q2 = 2xQ1 y asi sucesivamente. Digamos Q0 a Q7 pueden ir a un mux como el HC151 y tener Q y Q~ en su salida. Conectamos Q a un flip flop y ahi tenemos 8 retardos posibles de trigger, dandonos 8 posibles paginas desfasadas. La F del oscilador tendria que ser bien grande, para que podamos tener retrasos basados en el periodo de sample dividido en 8


----------



## asherar (Ago 4, 2013)

Si, la idea es experimentar con un pulso aislado. 
La verdad es que tengo algunas ideas sueltas pero nada definitivo. 

Hoy estuve pensando cómo hacer un experimento con retardo controlado por temperatura en forma analógica. De este modo se podría ver si el cambio de temperatura se puede lograr con cierta rapidez, además de medir qué tiempos de retardo se pueden alcanzar. Esto sería la primer cosa a probar antes de pensar en controlarlo digitalmente. 

Una estrategia completamente diferente sería hacer un VCO con un varicap para obtener una frecuencia múltiplo (2f, 4f, etc.) a la del reloj de captura, como se hace normalmente en los PLL. 
Luego recuperar la frecuencia original, pero con el flanco de control desfasado una cantidad que sea la fracción deseada del período. Para eso se debería usar una combinación de compuertas rápidas para quedarse con 1 pulso de cada 2, 4, etc. 
Lo que sí, simple no es.

.....

En principio lo que dije antes se puede hacer de esta manera: 
1.- Partimos del oscilador de muestreo de frecuencia F. 
2.- Con un PLL generamos una frecuencia FN = N x F (N puede ser 2, 3, 4, ... etc., según cuantas muestras se desean intercalar en el muestreo base). 
3.- Con la frecuencia FN se dispara el CLK de un contador en anillo de N bits (un registro de desplazamiento realimentado). Si el contador se resetea con el valor binario 10000000 (para N=8) se obtiene un 1 que va recorriendo las salidas. En todo momento hay una sola salida en 1, y todas las demás en 0. Esto puede verse como N salidas desfasadas en valores multipos de 1/FN. 
4.- Las N señales obtenidas de ese modo se ponen como entradas de un selector "1 de N" cuyos bits de direccionamiento se deben tomar de la dirección de memoria, esos bits que seleccionan el "banco" donde se guarda cada barrido. 

Creo que con eso ya debería funcionar. 
El registro de desplazamiento y los componentes del PLL deben poder funcionar a la frecuencia FN. 
Las primeras pruebas creo que las haré con F=4MHz y N=8 para comparar con lo que da disparando a tiempo real con F=32MHz.

Este sería el contador en anillo funcionando como selector de fase para N=4. 
Cada salida F1, F2, F3, F4 tienen todas la frecuencia F ( o bien f ). 
El pulso en alto de cada una dura 1/(4F) y en bajo 3/(4F), pero luego se usará solo el flanco de subida. 
Las fases relativas al flanco de subida del oscilador a frecuencia F son respectivamente: 
0, 1/4F, 2/4F y 3/4F.


----------



## seaarg (Ago 5, 2013)

Buscando programas que implementen funciones e interpolaciones, he caido en esto:
http://jonw0224.tripod.com/ppmscope.html

Se lo ve prometedor al chiquitin. El soft es bastante completo y tiene interpolaciones splines y sinc

Viene con soft para PC, el firmware del pic (en assembler!) PCB, lista de componentes, etc.etc.


----------



## asherar (Ago 5, 2013)

seaarg dijo:


> Buscando programas que implementen funciones e interpolaciones, he caido en esto:
> http://jonw0224.tripod.com/ppmscope.html
> 
> Se lo ve prometedor al chiquitin. El soft es bastante completo y tiene interpolaciones splines y sinc
> ...



Me queda chico todavía: 


> Improvements to the protection circuitry on the analog front-end improve  protection and the analog bandwidth.  In October, a user pointed out  that the oscilloscope was bandwidth limited.  *The bandwidth limit was  around 1 MHz.*  However, you could see the bandwidth limitation readily  with a lower frequency square wave when the square wave is *sampled at 5  MHz time equivalent sampling mode.*  The changes are simple and can be  implemented without re-etching boards, but by changing out four  components.  The changes raised the analog bandwidth of the scope to 5  MHz or higher.


La limitación del ancho de banda parece venir de la parte analógica 


Esperemos poder superar eso


----------



## seaarg (Ago 6, 2013)

Si, en realidad lo que mas me sorprendio es el software. El hard usa un conversor lento tambien (que bien podria reemplazarse por el conversor del pic para un portatil)


----------



## asherar (Ago 6, 2013)

Estamos buscando algo como esto:




http://www.knjn.com/Flashy.html

Está como para recorrer y mirar los precios.


----------



## asherar (Ago 10, 2013)

Algo más que puede servir de apoyo a este tipo de sistemas de adquisición de datos. 
Lo bueno es que es poderoso y programable en C,C++. 

http://www.elektor.com/news/100-supercomputer.2529525.lynkx


----------



## asherar (Ago 11, 2013)

Esta es la hoja escaneada de donde saqué la idea de controlar la temperatura de un oscilador a cristal, mencionada en el mensaje _#62_. 
En la figura mostrada, el rectángulo oscuro de arriba es un pic con el que se generaría una señal de referencia para el PLL. 
Los comentarios venían en la página anterior así que los pegué yo.


----------



## seaarg (Sep 23, 2013)

asherar,

Antes te comente sobre el 74HC4040. Queria solamente dejar dicho aca que nadie lo use para direccionar una memoria. Resulta ser que era la causa de los problemas que tenia en mis primeras versiones. Al ser este un contador "ripple" y NO sincronico, a altas velocidades direccionaba la ram con ciertos "saltos" cada ciertas potencias de 2. Esto es debido a la cascada formada por los flip-flop internos.

Asi que, a usar contadores sincronicos nomas. En mi caso estoy sintetizandolos con GAL22v10 de 5ns para reducir la cantidad de integrados (y porque las tengo por ahi jeje)



Y agrego una pregunta: En tu esquema habilitas la grabacion en ram mediante chip select (CS). ¿Lo haces asi en vez de usar ~CS y bajar WR, por alguna razon en especial?


----------



## asherar (Sep 25, 2013)

seaarg dijo:


> asherar,
> 
> Antes te comente sobre el 74HC4040. Queria solamente dejar dicho aca que nadie lo use para direccionar una memoria. Resulta ser que era la causa de los problemas que tenia en mis primeras versiones. Al ser este un contador "ripple" y NO sincronico, a altas velocidades direccionaba la ram con ciertos "saltos" cada ciertas potencias de 2. Esto es debido a la cascada formada por los flip-flop internos.
> 
> ...



Interesante lo del ripple. 

Lo de clockear con CS hace un tiempo que lo decidí. Lo más probable es que haya sido por sincronizar sólo una patilla, para mayor velocidad y sencillez.


----------



## seaarg (Sep 25, 2013)

Ah bien, ojo que, si no malinterprete los datasheets, la linea CS es mas lenta para grabar que mantenerla baja y actuar sobre WR. (Porque tiene que cambiar el estado de las salidas a 3state)


----------



## asherar (Sep 25, 2013)

seaarg dijo:


> Ah bien, ojo que, si no malinterprete los datasheets, la linea CS es mas lenta para grabar que mantenerla baja y actuar sobre WR. (Porque tiene que cambiar el estado de las salidas a 3state)


Gracias por el aviso. Voy a revisar y te cuento.


----------

