Arme su osciloscopio (analógico ó digital)

[seaarg]

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]

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]

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]

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]

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]

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.

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]

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]

Estamos buscando algo como esto:

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

Está como para recorrer y mirar los precios.

 

[asherar]

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]

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]

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]

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?

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]

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]

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.