# [Proyecto en desarrollo] - Osciloscopio digital 80 MSPS / 64k RAM



## seaarg (Jul 21, 2014)

Foristas,

Creo este tema para empezar a documentar el desarrollo de mi proxima version de osciloscopio digital. Estimo que al ir tirando los avances aqui, puedo no solo compartirlo sino obtener muy buenas ideas.

Aclaracion importante: Es un proyecto en desarrollo y va mutando constantemente. Ya estoy cerca de pasar al diseño de PCB pero primero quiero dejar perfecto esto en la teoria.

Otra aclaracion: Con este osciloscopio se intenta obtener algo "decente", utilizando los materiales mas conseguibles que se pueda.

El esquematico que adjunto es una impresion de la simulacion de proteus de la etapa de captura digital, por lo tanto hay unas cuantas cosas que se han puesto alli solo a fines de simulacion. (ej: inversores, puerto serie rs232, generadores de señal, etc)

Tambien se intenta obtener unas cuantas partes desde el reciclaje de computadoras. Tooooodo este circuito podria implementarse en una FPGA y andaria a los tiros pero lamentablemente no las consigo y con la importacion se me hace prohibitivo. Sin embargo, los PLD estan ahi, ya veran.

El osciloscopio, si despierta interes, vendra con esquematicos, PCB y software (en visual basic .net, pero si alguien quiere colaborar con java o algo que ande en linux, puedo proporcionar toda la informacion del protocolo de comunicacion).

Enumero algunas de las caracteristicas principales:

- Tasa de captura digital de 80 MSPS, real time.
- 64 Kb de profundidad de memoria x canal, cantidad de datos pre-trigger seleccionables
- 2 canales + trigger externo
- Trigger de hardware digital, trigger externo analogico y trigger por software
- Ancho de banda analogico a definir, posiblemente alrededor de los 100mhz
- Conexion USB, alimentacion desde el USB (veremos si con 500ma me alcanza)

Componentes y su decision:

- 2 conversores ADC ADS831 de TI. Estos conversores los obtuve como samples  y van a un maximo de 80MSPS. Entre estos y la ram daran en ultima instancia la velocidad.

- Modulo Oscilador de cristal de 80mhz rescatado de placas viejas de PC

- Transceivers 74LS245 rescatados de lectoras de CD y motherboard viejas. Necesarios para direccionar los datos. (podria usar el 74LS244 pero los pines son super incomodos para el PCB)

- 4 Memorias SRAM de 15ns 61256 rescatadas en este caso de un modulito de memoria cache de mother para 486, pero que tambien se obtienen de lectoras de CD viejas.

- Micro PIC 18F4550 (probablemente un 18F2550 ande OK pero habria que multiplexar pines)

- 74HC4094, serial shifter, simplemente para ahorrar pines 

- flip flop 74F74 (importante la F) y NAND 74F00 rescatados, otra vez, de lectoras de CD y plaqueterio de PC. Estos cumplen la funcion de dividir la captura entre 2 grupos de RAM para asi poder alcanzar 80 MSPS con memorias de 15 nanos. (grabo en una ram en ciclo de reloj alto y en la otra en bajo). Este conjunto estoy evaluando reemplazarlo por una GAL

- Por ultimo, y super importante: GAL22v10 de 5ns de tiempo de propagacion (las mas rapidas que consegui). Simplemente porque las tengo para usarlas y se que esto es una complicacion muy grande para otra persona que quiera hacerlo.

La finalidad de este post NO es proveer un circuito para armar y usar. Eso es imposible dada la complejidad del mismo y la disponibilidad de componentes. La idea es brindar algo que funcione y que sirva de base para sus diseños propios basados en los componentes que tengan.

Por ej: Yo uso 3 GAL 22v10:

- 1r PLD es el trigger digital. Basicamente es un comparador de 2 palabras de 8 bits y tiene 1 pin de salida que dice si A > B. Esto se puede reemplazar por 1 integrado de la serie TTL que ahora no recuerdo la denominacion. Lo que pasa que ese integrado no es tan rapido como la GAL.

- 2do PLD es el contador SINCRONO (importantisimo) de 9 bits con carryout, reemplazable por 74F269 de la serie TTL

- 3r PLD cumple multiple funcion de: 
   a- contador sincrono de los bits restantes
   b- selector de fuente de reloj
   c- determinador de trigger
   d- generador de clock para el contador de desborde (integrado en el PIC pufff 1 integrado menos!)
   Este PLD es reemplazable por otro 74F269 y unas cuantas NAND + flip flops

Como ven, si bien esto asi como esta "no sirve para nada", si es una buena base de ideas si interpretan el esquematico. Voy a ir posteando a medida que avance el proyecto y espero sus ideas o preguntas!

Aca les dejo una captura de pantalla para ir entusiasmando:



Se trata de una senoidal de 50khz en el canal A y una cuadrada de 100khz en canal B sampleadas a 50 MSPS (a 80mhz el proteus me pone impaciente  )

En el programa, cada division tiene 100 puntos de sample.

A 80 mhz, este osciloscopio tendria su escala minima en 1.25us / DIV a 100 samples pero gracias al forista palurdo que me dio una leccion de matematicas, a partir de alli empieza la interpolacion y se lo puede hacer ver muy razonablemente señales en el dominio de los 200ns / DIV.

Ademas, estoy estudiando agregarle al menos 1 disparo retardado de trigger para hacer Equivalent time sampling pero no estoy seguro de querer complicar mas una PCB de por si complicada.

Proximamente, mas avances, sus opiniones, ideas, criticas, etc son bienvenidas!


----------



## seaarg (Jul 22, 2014)

Aqui adjunto una version del esquematico un poco mas prolija y con descripciones de los distintos integrados.

Tambien se reemplazo el conjunto 74F74 + 74LS00 por otro PLD GAL22v10

Adjunto tambien el proyecto completo que se compone de:

- Simulacion en proteus 8
- Firmware de prueba del PIC en CCS C
- Firmware de los 3 PLD GAL22v10 (modelo AM22v10 en proteus)
- Programa de test hecho en Visual Studio 2010, junto con el EXE por si no tienen el entorno (en bin)

Para poder ver el firmware de los PLD, pueden abrir los archivos .PLD con un block de notas, o para cambiar algo, descargarse el WinCUPL de Atmel.

Si usan la simulacion del proteus, recuerden editar los integrados GAL22v10 y el PIC para apuntar correctamente a los archivos .HEX y .JED

Tambien quiero hacer notar que SYSCLK lo deje en 1mhz en vez de 80mhz para hacer que la simulacion ande rapido. A 80mhz hay que ajustar el valor del TMR0 del PIC para que el trigger quede exactamente en el medio.

El potenciometro de nivel de trigger junto con sus selectores son para simulacion exclusivamente. En realidad se transferiran los valores al PIC mediante USB.

No me dejen hablando solo  aporten lo que se les ocurra, todo sirve para mejorar.

PD: Si no tienen acceso a conseguir los GAL 22v10, con ingenio se pueden reemplazar por integrados TTL bastante comunes (ej: 4 contadores de 4 bits, un par de 74F00 y un 74F74) Solo es cuestion de evaluar el codigo del PLD y reemplazarlo por logica fisica. Quiza no se llegue a 80mhz pero a 40mhz seguro. Y si consiguen serie F, es probable que puedan llegar a 80mhz.

PD2: Tengo por ahi unos ADC de 100mhz para ponerlo aun mas interesante, pero trabajan a 3.3v y me preocupa que no lleguen a nivel logico "1" a tales velocidades haciendo interfaz directa con logica 5v.

PD3: El generador de reloj, yo estoy usando un modulo oscilador de 80mhz pero se puede rescatar un chip PLL de motherboard que andan con un cristal de 14mhz y generan esos 80mhz.


----------



## cosmefulanito04 (Jul 22, 2014)

Para los que no tienen OCR, este tema les puede venir muy bien.



seaarg dijo:


> Ademas, estoy estudiando agregarle al menos 1 disparo retardado de trigger para hacer Equivalent time sampling pero no estoy seguro de querer complicar mas una PCB de por si complicada.



Esto es interesante que lo implementes y se supone que en hard no deberías agregar nada.

Para el resto, el "Equivalent time sampling" es muestrear en distintos periodos la señal, esto te ayuda a muestrear señales muy rápidas donde el ADC solo puede capturar pocas muestrar en un periodo y rellena el muestreo a partir de los datos que vienen del próximo periodo. En esta imagen se puede ver la idea:







En este caso, es muy importante tener un buen control sobre el [LATEX]\Delta D[/LATEX], ya sea con un timer o con una rutina en assembler que fije bien esa diferencia de tiempo entre el inicio del periodo y el lugar a muestrear.

*seaarg*, después si podés subí el video que ya subiste en el hilo del generador DDS para que vean como funciona tu OCR actual.


----------



## seaarg (Jul 22, 2014)

Hola Cosme!

El video del que habla cosme es este 





Alli se puede ver al principio el osciloscopio digital que arme hace un tiempo y que, sus defectos y virtudes me llevan a diseñar este que esta en proyecto juntando todo lo aprendido. (en realidad este es mi 3r osci casero que hago pero los anteriores fueron bastante fracaso jeje) En cada version lo voy mejorando.

Sobre equivalent time sampling si, tendria que poner algo de hardware porque el trigger no lo maneja el micro. Si lo manejase el micro seria demasiado lento para reaccionar en el instante que hay un evento de trigger.

Asherar estaba desarrollando algo al respecto de esto en su post de osciloscopio con TTL. No lo implemento aqui porque no termino de entender su solucion, pero basicamente:

Mi PLD de trigger pone un 1 logico cuando la señal > nivel (despues el controlador verifica flanco y opcion ascendente/descendente).

Yo podria agregar algo que me haga distintos retrasos controlados, supongamos, de 1ns desde que hay un "1" logico en la salida del trigger, entonces podria hacerlo. La cuestion es como generar dichos retrasos y que sean exactos porque sino el sistema se hace "sucio" cuando reconstruis la señal.

El problema de generar retrasos, por ej, con compuertas es que el tiempo de propagacion no es exacto sino solamente tipico.

Desde el lado del micro no puedo hacer nada, es una tortuga 

Tal vez podria estudiar mas a fondo una de las ideas de asherar de tener un PLL oscilando a un multiplo de la frecuencia base, pero se pone problematico con los componentes a 80mhz

Entonces, si no se puede hacer esto dentro de terminos razonables, siempre se puede apelar a la matematica para expandir los limites. Haciendo interpolacion e intercalando muestras calculadas (asi lo hice en el osci del video). No sera "real" pero es muy bueno y doy fe que osciloscopios como los Hantek lo hacen.

Otra posibilidad que se me ocurre es que, como yo tengo un dato en la ram que es el momento exacto del trigger, trabajar con los datos de la ram en muestras sucesivas e ir intercalando. Hasta ahora al ETS yo lo entiendo como que si yo tengo muestras cada 20ns (por decir), en una pagina tengo que tener la muestra 20ns, en la proxima, la muestra 21ns, y asi sucesivamente. Quiza no sea tan asi y pueda hacerlo con esas mismas muestras de 20ns descartando de a 1 desde el inicio de trigger para cada pagina. Lo voy a estudiar.


----------



## foso (Jul 22, 2014)

No sé si entendí bien lo que pusiste aca ¿es una muestra real que hiciste o es una simulación? 



seaarg dijo:


> Aca les dejo una captura de pantalla para ir entusiasmando:
> 
> Ver el archivo adjunto 114151
> 
> Se trata de una senoidal de 50khz en el canal A y una cuadrada de 100khz en canal B sampleadas a 50 MSPS (a 80mhz el proteus me pone impaciente  )


----------



## seaarg (Jul 22, 2014)

Hola foso, esa captura de pantalla es del programa en visual basic net. Lo que esta pasando ahi es que uso el COMPIM de proteus para enviar el resultado de la simulacion a mi programa como si fuera un puerto serie (es virtual). El osci aun esta en etapa de diseño asi que para real le falta un poco.

Si alguien quiere experimentar con esto pero no consigue los PLD, una idea que estaba manejando es sacar la memoria flash que viene en los discos duros de desguace. Con una flash de 64k pueden programarla para usar las 16 lineas de direccion como los 8 bits de nivel + 8 bits del ADC y programan los 2^256 resultados posibles en uno de los bits de datos. Lamentablemente las flash mas rapidas que vi son de 50ns y eso bajaria la velocidad del osci, pero al menos con eso se puede obtener un trigger digital bastante bueno! (el PLD de pobre le dicen)

Como ven, la idea es armar algo con lo que se tenga. Entre mis desguaces encontre una SRAM de 64k x 16 bits de un disco duro, ideal para reemplazar las 4 SRAM que estoy usando, pero es de 20ns de tiempo de acceso (12ns pulso de grabado) y al tener solo una, no puedo hacer el doble buffering que estoy haciendo en el esquematico que puse, entonces estaria limitandome a unos 50 msps con un par de arreglos especiales.

A proposito: ¿Alguien sabe como simular en proteus una senoidal con ruido? (picos, glitches, cosas asi) Quiero darle un poco mas de pruebas al trigger digital. Como funciona a traves del integrado de control como una maquina de estados (menor que -> mayor que -> disparo y viceversa) estoy 99% seguro de que va a funcionar bien en la realidad, pero estaria bueno probar mas variantes por si hay que corregir.

PD: Otra idea que estaba pensando es en dejar libres los pines RS232 del PIC para ponerle un modulito bluetooth. Usando un smartphone puedo hacer una aplicacion para aprovechar la pantalla del telefono y tener un osciloscopio totalmente portatil e independiente de la PC. Como la alimentacion de este bicho vendra desde el USB, bien puede venir de una bateria tambien. Idea feliz


----------



## seaarg (Jul 24, 2014)

Agrego un link (en ingles) con informacion sobre los osciloscopios hantek. Lo considero relevante porque tiene unos diagramas de bloques de funcionamiento que son muy similares a la arquitectura que estoy realizando.

http://fabiobaltieri.com/2013/07/10/inside-a-hantek-dso-2090-usb-oscilloscope/

Tambien les comento que proximamente subo otro esquematico. Estoy empezando a hacer el diseño del PCB y mientras rebuscaba entre mis cosas encontre una memoria cache de compu vieja con 10 chips sram de 15ns. Esto significa que voy a ampliar la memoria de los 64kb originales a 96kb. Podria llevarlo a 128kb (mientras mas memoria, mejor y ademas se plantea menos exigencia a la velocidad de los contadores) pero poner 8 chips de ram en el PCB se hace muy grande, por eso me quedo con 6.

Anoche pensaba y si pusiera los 128kb, la velocidad a la cual cambia de direccion la memoria seria de solo 20mhz, un valor aceptable para reemplazar los PLD de contador con integrados TTL o un simple 74HC4040 (que, a mayores velocidades, como es ripple counter no sirve). Creo que finalmente usare el PLD porque es rapido y sincronico, pero lo menciono aca porque el que no consiga PLD, pone 4 contadores de 4 bits TTL y agrega RAM y con eso puede mantener la velocidad de 80 o incluso 100msps


----------



## seaarg (Jul 30, 2014)

Queria postear unos avances.

Estoy haciendo la PCB de la parte de captura digital (todo SMD y doble faz), mi primer intento:



Sin embargo, son lineas de 0.3mm con muy poca separacion entre ellas. Si bien he hecho varias placas con esos parametros y es factible hacerlas, en este caso son demasiadas lineas y muy propenso a error al planchar la placa (basicamente, renegar demasiado para hacerla).

Entonces, cambie el enfoque y decidi redistribuir los integrados y las capas de la placa para hacerlo con lineas de 0.5mm con mas separacion, pads mas grandes, etc, ademas, evitando pasar entre pines de integrados smd.

Este es el resultado hasta ahora (falta adicionar los 4 PLD)



Logre el mismo tamaño fisico de placa, solamente que tengo mas vias entre las 2 faz de la misma. Y la placa es muchisimo mas "planchable"

Queria saber, mientras la voy haciendo, si alguien tiene sugerencias u observaciones del tipo "eso no conviene hacerlo a altas frecuencias" etc. Las vias no son demasiado largas y todo lo que es bus de direccion en realidad corre a 40mhz. Lo que va a 80mhz es el bus de datos.

Me preocupa no tener lugar para ubicar resistores de terminacion en las lineas de direccion para evitar reflexiones. No se si esto sera critico para mejorar las señales o no. No me queda claro en los datasheet de los 74F245 si estos poseen diodos de proteccion en las entradas. Si hay un parametro que dice "input clamp diode voltage". Si tuviesen diodos, probablemente no necesito terminadores ya que los diodos hacen el recorte.

Tampoco estoy seguro si las entradas de direccion de las memorias poseen dichos diodos. 

A quien pueda dar sugerencias, le agradezco

PD: Ah! termine haciendo 2 canales de 64kb cada uno nomas (4 memorias) porque cada una consume 90 mA y pretendo alimentar esto con el USB o baterias... 8 memorias era demasiado consumo.


----------



## Chico3001 (Ago 4, 2014)

En altas frecuencias ya comienzan a ser un problema las dimensiones fisicas de las pistas, asi que buscaria hacerlas lo mas cortas posibles y sobretodo añadir planos tierra por todos lados, tambien poner pistas horizontales de un lado y pistas verticales del otro.. aunque se incrementen el numero de vias de conexion entre pistas

Y sobretodo leer mucha literatura de apoyo de los expertos:

http://www.ti.com/lit/an/scaa082/scaa082.pdf
http://www.ti.com/lit/ml/sloa089/sloa089.pdf
http://www.ti.com/lit/ml/slyp173/slyp173.pdf

http://es.slideshare.net/AnalogDevicesInc/pcb-layout-fundementals


----------



## seaarg (Ago 5, 2014)

Estoy en un 90% casi a punto de terminar la parte de captura digital.



Siempre me pasa lo mismo, una vez que ruteo casi todo me queda muy poco espacio para la alimentacion de los integrados 

Sin embargo, voy a volver un poco atras porque estaba observando que me han quedado varias pistas paralelas en ambas caras, formando un capacitor entre ellas. No corren a 80mhz sino a 40mhz (son lineas de direccion no de datos) pero igualmente, para evitar problemas las voy a trabajar un poco mas.

A la izquierda de la se encuentran los 2 ADC, luego los buffer y el PLD de control. En el medio las memorias y hacia la derecha otros 2 buffer, los PLD de direccion, el PLD de trigger y el micro.

Hacia abajo de esta placa estara ubicada la entrada USB, la fuente, etc. Hacia la izquierda de los ADC quedara la etapa analogica y el trigger externo.

El layout general es muy parecido a como tiene distribuidos los componentes el osciloscopio comercial Hantek, salvando las distancias claro.

Las dimensiones fisicas de esta etapa son de 11 x 6 cm

Cabe aclarar que en esta imagen faltan los rellenos de masa de ambas caras. Sin embargo al medio esta tan apretado que casi no hay plano de masa. Eso no me gusta. Voy a trabajar para mejorarlo.


----------



## seaarg (Ago 18, 2014)

Despues de un tiempo diseñando la PCB, en la parte de la captura digital, esta esta casi casi lista.

Es tiempo de diseñar la etapa analogica. 

Tengo 2 opciones de amplificador operacional.

1- El OPA4354
    rail-to-rail I/O CMOS de 100-250mhz de ancho de banda, 150 V/uS

2- El LM318 que es mas humilde
    15mhz ancho de banda, 50 V/uS y puede llegar a 150 V/uS con sobrecompensacion (tambien aumenta el ancho de banda)

La opcion por defecto seria el OPA4354 pero tiene la desventaja de que lo puedo alimentar con 5.5vpp (+-2.75v) como maximo. El ADC (ADS831) necesita un level shift que se sale de rango de alimentacion del opamp a 2vpp de rango de señal. Puedo llevarlo a 1vpp de rango de señal y quiza ahi pueda hacer entrar la señal en el rango de alimentacion del opamp.

Mas alla de este "detallito", la etapa de entrada va a necesitar si o si un divisor de tension porque si quiero que este osciloscopio tenga un rango de entrada aceptable, de al menos +-20v (mis aspiraciones son bastante mas) no hay forma de que pueda tener ese rango con este operacional sin divisor.

Entonces, mirando trabajos de mucha gente (Con foco en el MK3 de jones http://alternatezone.com/electronics/dsoamk3.htm) vi que puedo hacer un divisor en la entrada similar al x10 de la punta del osciloscopio.

Se me ocurrio que, dado que tengo una resistencia en serie con una capacitancia (parasita del PCB + entradas del mux) de 6pF aprox, estoy teniendo un filtro pasabajos importante.

Adjunto el esquematico de lo que estoy probando (entrada_primera_prueba.pdf) Descripcion breve:

1- La señal entra en directa hacia OX1 con diodos + resistencia limitadores y de ahi a el primer mux
2- Tambien tengo una division OX10 (/10) hacia el mux
3- Una tercera division OX20 (/20) hacia el mux.
4- Este mux (U3) selecciona:
    a- Sin atenuacion
    b- Sin atenuacion, multiplicado x 2
    c- Atenuacion /10
    d- Atenuacion /20

5- Este mux (U3) maneja la realimentacion del primer operacional buffer.

Aclaro que el operacional CMOS tiene diodos clamp adentro, por eso no estan en el esquematico (excepto para directa, a fin de proteger el mux)

6- Luego voy a una etapa de amplificacion, donde con el segundo MUX tengo x1, x2, x5, x10

7- El soft del osciloscopio tiene su rango vertical dividido en 10 cuadrados, 5 para arriba, 5 para abajo de GND.

8- Esto me da: (en V/Div)


```
10mv	01 11	/1  x2 x10
20mv	01 10 	/1  x2 x5
50mv	01 01	/1  x2 x2
100mv	01 00	/1  x2 x1

200mv	00 00	/1  x1 x1

500mv	10 10	/10 x1 x5
1v	10 01	/10 x1 x2
2v	10 00	/10 x1 x1
5v	11 00	/20 x1 x1

limite fisico: 110vpp
```

9- Los ultimos 2 operacionales aun no esta determinada su conexion pero son el level shifter y buffer de ADC. Aun estoy pensando si poner o no un DAC en el level shifter para tener control de offset. Me pregunto si sirve ya que electricamente tengo muchas opciones de V/Div y el cambio de posicion "visual" lo puedo hacer desde el soft. Tendria mas sentido si tuviera menos opciones de V/Div para ajustar la señal dentro del rango de los opamp.

OK, eso fue la descripcion, ahora la consulta:

Pongo lo siguiente en proteus para analizar la respuesta en frecuencia del atenuador



Y obtengo el siguiente grafico:



Se puede ver el grafico mas grande en los links de abajo.

Mas alla del corte en el trazo azul (que es directa) no tan importante porque es bastante alta la FC (no olvidemos que esto samplea a 80mhz por lo que el ancho de banda analogico util estara alrededor de los 10mhz para tener 8 puntos minimos por onda completa)

Queria saber: El grafico me muestra el trazo verde (/10) por los -20 db y el rojo (/20) por los -26 db. ¿Es esto normal y causado por el divisor de tension o es que tengo algo filtrando demasiado?

Mas preguntas: Para ustedes, ¿es recomendable atenuar la señal cruda 10 o 20 veces para luego amplificar (manteniendose dentro de los 2vpp o 1vpp del ADC) o me conviene mas usar un operacional en todo su rango de alimentacion (supongamos +-20 volts) y no atenuar la entrada?

Tambien tengo que tener presente que el MUX 74HC4052 se puede alimentar hasta 10vpp (-5+5) limitando todo, aunque en mi otro OCR lo estoy alimentando con +9-9 y no habia leido esto en el datasheet (doh! no se quema!)

Otra: ¿Vale la pena renegar con el limitado rango de alimentacion del OPA4354 considerando sus prestaciones superiores, o irse a un opamp mas humilde como el LM318?

Por ultimo: ¿Se puede configurar un op-amp como "reductor"? Puesto que tambien tengo disponibles unos hermosos ths3001 que son op-amp de 420mhz current feedback con mas rango de alimentacion, pero solo dispongo de 3  Si se pudiera hacer que el op-amp sea un divisor x10 entonces podria poner 1 en cada entrada antes del op-amp CMOS

Aclaro que tambien tengo unos JFET J309 para imitar la entrada del bitscope y usarlos de buffer con alimentacion grande pero estoy en la misma, despues de ellos tengo que reducir si o si.

Sin mas, muchisimas gracias por leer todo esto. Cualquier idea u observacion del diseño es mas que bienvenida.

Edito: Viendo mas en profundidad la pagina que puse mas arriba con el analisis de los hantek, veo que los diseñadores utilizan solo 1 op-amp (candidato el que tengo de 420mhz) y mediante los reles conectan un divisor /10 en serie con otro /10 totalizando division x100 desde la señal cruda y luego eso al amplificador x1, x5, etc. Ademas, alimentan todo con +5-5v. Quiza imitando esto puedo obtener gran rango de entrada con 1 solo op-amp. ¿Que opinan? Cuestion de conseguir unos relecitos que consuman poco. Ademas, chusmeando las fotos de esta pagina rusa http://www.artem.ru/cgi-bin/photo?c=l&cid=115 vi una forma de rutear las memorias bastante interesante que puede hacer mi PCB menos propensa a efectos de alta frecuencia.

Adjunto imagen del analisis del hantek:


----------



## seaarg (Sep 1, 2014)

He vuelto,

Luche mucho diseñando la entrada analogica de este bicho. Queria aprovechar los samples que dispongo, que son:

3x OPA4354 - Quad CMOS op-amp rail-to-rail I/O 250mhz (5.5vpp alimentacion max)
3x THS3001 - Single CBF op-amp 450mhz

Hubiera hecho todo con el ths3001 pero dispongo de solo 3 y necesitaria al menos 4.

Descripcion del esquematico (1 canal, hay que duplicarlo).

- Se empieza con un selector AC/DC (candidato a reemplazar por llave electronica)

- De ahi, la señal va a un divisor compensado /1, /10, /20. La resistencia de 10K en paralelo con un capacitor de 22nF protegen la entrada del mux en directa, limitando 100vpp a 10ma, suficientes para ser recortados por los diodos de entrada internos del mux.

- Luego, la señal va a un mux 74HC4052 alimentado con 10vpp que selecciona una de las 3 divisiones previas o una amplificacion x2 de la entrada directa.

- El mux va a un op-amp no inversor puesto como buffer de ganancia unitaria

- El buffer va al segundo mux de divisores /1, /2, /5 y amplificador x5 (que sumado al previo x2 logran una amplificacion x10). En el divisor /5 hay un capacitor de compensacion de HF a determinar aun.

- La salida del mux, va a un ultimo buffer de ganancia unitaria.

- Este ultimo buffer se asocia con el THS3001 que hace de buffer ADC + Level shifter. Si le aplico 1.25V a su entrada no inversora establezco un CMV de 2.5v

- La señal resultante al ADC es de 1vpp

Con este esquema, tengo la siguiente tabla de escalas, para los distintos rangos de entrada:


```
100vpp > 1vpp = /20 5vpp > /5 1vpp	|	10V/div
50vpp > 1vpp = /10 5vpp > /5 1vpp	|	5V/div
20vpp > 1vpp = /10 2vpp > /2 1vpp	|	2V/div
10vpp > 1vpp = /10 1vpp > /1 1vpp	|	1V/div
5vpp > 1vpp = /1 5vpp > /5 1vpp		|	0.5V/div
2vpp > 1vpp = /1 2vpp > /2 1vpp		|	0.2V/div
1vpp > 1vpp = /1 1vpp > /1 1vpp		|	0.1V/div
0.5vpp > 1vpp = /1 0.5vpp > x2 1vpp	|	0.05V/div
0.2vpp > 1vpp = /1 0.2vpp > x5 1vpp	|	0.02V/div
0.1vpp > 1vpp = /1 0.1vpp > X10 1vpp	|	0.01V/div
```

Esto no incluye el divisor /10 de la punta del osciloscopio. Con eso se llegaria a 1000vpp (miedo!)

Cada pequeña etapa la fui pasando por el analisis de frecuencia de proteus, agregando capacitores y resistencias segun los parametros de datasheet de cada componente (impedancias de entrada, capacitancia de entrada, etc) cuidando mucho de no fabricar algun pasabajos en la señal. Segun proteus, esta etapa soporta una respuesta plana en frecuencia hasta los 50mhz. A partir de ahi empieza a caer un poquito. Por los 100mhz creo que caia un par de dBs.

Lo que me genera duda es la resistencia de 1K sugerida en datasheet en la entrada del ultimo operacional. Ahi no estoy seguro de no estar formando un pasabajos con la capacitancia de entrada.

Por ultimo, quiero aclarar que esto tene 2 fuentes de alimentacion:

- una fuente para los mux y ultimo op-amp de +5 -5 v y otra para los op-amp cmos de +2.75 y -2.75v.

La primera fuente (+-5v) planeo hacerla a partir de los 5v del usb por medio de 2 MC34063 (uno como regulador 5v y el otro como generador -5v)

La segunda fuente, Estoy pensando en realizarla con zeners a partir de la primera, pero no estoy seguro de lograr una buena regulacion para tener un voltaje exacto en los op-amp. Tambien se me ocurrio poner un par de transistores en modo emisor-seguidor cosa de regularlos con un preset en la base como divisor de tension. ¿Que opinan? cada uno va a disipar 2.25v x algunos milamperes que consuman los operacionales.

Por ultimo: hay alguna forma con un par de JFETs de reemplazar la llave mecanica AC/DC? Se tendrian que bancar 100vpp supongo. No se si es practico.

Cualquier sugerencia o problema que vean en este esquematico, antes que me ponga a hacer el PCB, se agradece un monton.


----------



## Chico3001 (Sep 1, 2014)

Las entradas de señal no son optoaisladas?? te recomiendo usar un opto lineal como el HCNR201 de Avago

http://www.avagotech.com/pages/en/o...ic_high_linearity_analog_optocoupler/hcnr201/


----------



## seaarg (Sep 2, 2014)

Lamentablemente no. De todos modos, conseguir esos componentes aqui (cordoba, argentina) debe ser imposible y por otro lado, si bien es lineal la frecuencia maxima no debe ser mucha.

La situacion ideal seria usar un transformador de aislacion en las entradas (el adc que uso tiene entrada diferencial). Pero lograr que eso sea lineal y de al menos 40mhz de ancho de banda supera mis conocimientos.

Habra que lidiar con que no este aislado, como la mayoria de los dso usb. Igualmente este bicho esta pensado para funcionar tambien con bateria y sin PC (bluetooth al telefono) asi que la aislacion deja de importar demasiado en ese caso... (creo no estoy seguro)


----------



## seaarg (Sep 14, 2014)

Compartiendo avances:



Esta foto es el component side de la placa de captura digital. Como se puede observar esta al limite de lo realizable con plancha. Los tracks mas finos son de 0.4mm y pasan entre los pines de las memorias. Tuve que plancharla unas cinco veces hasta que salio.

Casi la descarto y hago una version "modular" donde las memorias estarian en otra placa para poder hacer tracks mas gruesos, pero luego de comprobarla con el tester no salio demasiado mal. Voy a probarla.

Hay que hacele un par de arreglitos en unos lados donde se me salto el toner. Ahora voy a hacer el solder side pero este es mas facil (cruzando dedos).

Si la placa funciona OK, subire por aqui el PCB hecho en circuit wizard.


----------



## seaarg (Oct 4, 2014)

Solamente queria comentarles que la placa la descarte, porque si bien parece estar todo OK, resulto ser insoldable en la parte de las memorias. Se me hacian corto en los pines hasta que termine cortando algunas pistas y no queria ponerme a reparar algo nuevo. Si tuviera solder mask seria otra cosa 

La cuestion es que estoy haciendo una version de la PCB en forma modular. Es decir: 1 plaquita doble faz para las memorias y los PLD de direccion y esta se conecta a traves de un "peine" a la placa principal.

Esto me permite no tener que pasar entre pines de la memoria y poner tracks mas gruesos. Lo unico que espero es que la conexion a traves de un peine soldado no perjudique el rendimiento en frecuencia del PCB. Estoy intentando tener cuidado con eso y como distribuyo las cosas pero a esta altura es prueba-error.

Saludos!


----------



## Sebastian1989 (Abr 13, 2015)

Excelente post seaarg, actualmente estoy a la espera de que me lleguen unos ADC de 100Msps para empezar a diseñar mi propio osciloscopio digital, tengo pensado usar memorias FIFO AL422B, en un principio hacerlo funcionar a 50MHz y si todo va bien pasar a 100MHz.

Me preocupa el diseño del PCB, va a ser la primera vez que haga algo a una frecuencia tan alta.
Tienes algunas recomendaciones que aun no hallas puesto en el post? 
Como quedo finalmente tu osciloscopio? 


ADC:http://datasheets.maximintegrated.com/en/ds/MAX1198.pdf

AL422B:http://pdf.datasheetcatalog.com/datasheet/Averlogic/mXruvvz.pdf


Por cierto Maxim hace envío de muestras gratis, tienen varios integrados interesantes.


----------



## seaarg (Abr 16, 2015)

Hola Sebastian bienvenido al post

Te envidio que puedas conseguir esa memoria, es ideal para este proyecto y de alta capacidad por lo que vas a poder tener muchas muestras y te va a simplificar muchisimo el diseño.

Si la memoria es de 20ns la velocidad maxima de sampling teorica de tu proyecto va a ser de 50mhz, lo cual es muy bueno igualmente. Si queres llevarlo a 100mhz vas a tener que hacer un esquema de double buffering como estoy haciendo yo, utilizando 2 de ellas x canal.

La version anterior de mi osci lleva una memoria FIFO tambien pero lamentablemente solo de 1000 muestras. Con estas memorias eliminas lo mas complicado de "cablear" que son los contadores de direccion.

Sobre tus preguntas, el diseño del PCB empieza a ser menos critico ya que tenes muchisimas menos pistas pero aun asi, aplican los conceptos de PCB de alta velocidad. Si te fijas en todo este post los compañeros han puesto unos articulos donde se explica todo lo que hay que saber, pero para resumirte:

- PCB de fibra de vidrio, doble cara aunque uses una cara entera como plano de masa. La mayor area posible de planos de masa.
- Muchos puntos de interconexion entre planos de masa de las dos caras (si haces doble faz)
- Evitar ground loops, lineas de masa que se cierren sobre si mismas.
- Tener plano de masa digital (repito, GRANDE) y plano de masa analogico separados y unidos en 1 solo punto
- Capacitores de desacople y si es posible, electroliticos asociados tambien en todos los integrados, lo mas cerca posible de ellos. Vas a leer en la bibliografia sobre los ruidos enormes que mete en la linea de masa un integrado digital al hacer switching. No queres que los ruidos generados por uno vayan a los otros y ahi es donde una linea de gnd grande y capacitores ayudan.
- Si podes pone un inductor asociado a los capacitores de alimentacion de cada integrado, formando un pasabajos. Quiza haya que calcularlo segun la fundamental del ruido
- Pistas cortas y directas, especialmente en clock
- Si tenes pistas largas entre integrados digitales, considera resistores de terminacion en las lineas a menos que el integrado "destino" tenga diodos clamp en sus entradas.

Parte analogica:

- Todo lo anterior, con el agregado muy importante de que calcules y simules el comportamiento en frecuencia de la entrada. Es decir, hay que agregar conjuntos de resistencias + capacitores que van logrando una respuesta lineal hasta la frecuencia maxima. Por no calcular esto me paso de tener amplificadores operacionales de 100mhz que atenuaban la señal a partir de 1mhz 

Pensa mucho acerca de como vas a diseñar los siguientes puntos:

- Trigger, control de trigger, detencion de captura
- Reloj simple fijo o variable.

Dada la capacidad de tu memoria, yo haria reloj fijo a 50mhz, donde, si estas en la escala menor, graficas las muestras seguidas, una atras de otra. En la siguiente escala graficas cada 2 muestras y asi. Es como ir "reduciendo el zoom" en la señal graficada. Con esto te evitas el terrible despelote que seria tener un generador de clock multiple para los distintos dominios de tiempo. Basicamente, tu osci puede capturar a todo lo que de para luego determinar QUE mostras en pantalla segun tu escala horizontal.

Tambien tene en cuenta los rangos de voltaje de señal que quieras soportar. Mientras mas reducido (y escalado) mejor porque tendrias mejor respuesta en frecuencia en los operacionales, dado que necesitas menos V/us para lograr tus objetivos. Vale decir, si queres soportar, suponte, 100vpp, seria bueno hacer una escala que reduzca /100 de forma tal que al operacional le entre 1vpp. Si haces un /10 tendrias 10vpp en el operacional y tiene que ser capaz de subir 10 voltios en 20 ns, digamos (numeros pensados asi nomas, sin mucho criterio)

Pensa como manejar, en la parte analogica, el offset de la señal. En mi caso lo estoy haciendo con un DAC que inyecta un nivel de continua.

Trigger: Tiene que ser RAPIDO y automatico (no a traves del micro) y, segun mi criterio, me gustan mas los triggers digitales pero no se como lo tenes pensado vos.

Detencion de captura: Tambien tiene que ser rapida y podrias implementarla con un contador habilitado con trigger

Sobre tu memoria: Es DRAM, fijate bien en el datasheet si tenes un limite de tiempo antes de que los datos almacenados se borren (asi era la FIFO mia) aunque segun vi, tiene el controlador dram interno, probablemente se comporte como una SRAM.

Con que micro vas a controlar todo? Vas a transferir a la PC a traves de USB? Y el soft? Si por casualidad sabes programar Android, aqui va una idea: En mi caso, voy a tener una conexion usb a la pc, pero tambien me reserve el puerto serial del micro para hacer transferencia bluetooth al telefono, usandolo de pantalla e interfaz de entrada. Esto, sumado a que le estuve haciendo una fuente capaz de funcionar con baterias, me permite hacer un osciloscopio portatil, que ademas tiene la ventaja de estar aislado de masa con respecto al aparato a medir.

En fin, he sufrido bastante por lo que podria seguir tirando tips pero preferiria responderte preguntas concretas que puedas tener, o si tenes un diseño, que lo pongas aqui para analizarlo.

Sobre el mio, esta en pausa. Desde la ultima vez que postee se agrego un nuevo integrante a la familia  asi que no me pude buscar el tiempo para terminarlo. Tengo un PCB diseñado de la parte de captura digital. Le falta agregarle la parte analogica (que tengo diseñada ya por suerte) y plancharlo!

Muchos exitos en tu diseño! y partis de una muy buena base que es esa memoria. Si te parece bien, postea tus avances aqui para que podamos verlos.


----------



## Sebastian1989 (Abr 18, 2015)

Gracias por los tips, la verdad es que gran parte de lo que dijiste ya lo había considerado pero siempre es bueno tener una segunda opinión.

En un principio tengo pensado usar un solo canal con una sola memoria para ver como se comporta de forma análoga mi circuito y encontrar problemas en general, luego tengo pensado implementar el sistema double buffering por lo que usare 4 memorias en total ya que tengo 2 canales.

Los operacionales que voy a usar serán el MAX4104, tiene un ancho de banda de 625MHz y 400V/us de slew rate (bastante seguro que es una exageración, pero son gratis por lo que no me quejo).

El micro que usare es un propeller, este micro tiene 8 núcleos de 32bits corriendo a 100MHz, con los contadores de este micro puedo generar fácilmente una señal cuadrada variable entre 1Hz y 120Mhz con una resolución de 1Hz y una exactitud tan buena como el cristal que use para el propeller, ademas estoy casi seguro que podría escribir un programa para controlar la cantidad de pulsos generados por lo que si todo va bien podría tener pleno control de la frecuencia y la cantidad de pulsos generados.

La transmisión de datos la haría por serial al computador, usando lógicamente un IC para pasar de USB a serie, probablemente un clásico FT232R a 3M baud, ademas tengo pensado agregarle un puerto ethernet con un ENC28j60, este se usaría para poder transmitir los datos por red y tener la opción de agregar mas de estos osciloscopios para tener varios mas canales a disposición dentro del mismo software.

Ademas de ser un osciloscopio tengo pensado usarlo como analizador lógico, tendría dos canales análogos o 8 entradas digitales y uno análogo o 16 entradas digitales.

Sinceramente aun no me pongo a diseñar la parte análoga, por ahora me estoy preocupando mas de la parte digital, sin embargo tengo ciertas inquietudes en la etapa de ganancia, en un principio pensé en usar al igual que tu un 74hc4052 para seleccionar las distintas ganancias pero luego leí en un foro gringo que a altas frecuencias (no especifican que tan altas) no funcionan muy bien debido a que los switch tienen una capacitancia algo elevada cuando están abiertos por lo que parte de la señal se "filtra" por todos los switch, has observado algo de esto en tus pruebas?. En cuanto al offset aun no he pensado en nada, podrías explayarte un poco en como usaste el DAC?.

El software probablemente lo haga en C# o C++, buscare algunas librerías gráficas y dependiendo de donde vea los mejores resultados veré con cual me quede. 

Cuando me lleguen los componentes y tenga algunos avances los iré posteando.


----------



## seaarg (Abr 18, 2015)

Teniendo semejante micro, ¿aun te es necesario hacer tanto hard? Desconozco ese micro pero, es microcontrolador o microprocesador? Por ahi, si tiene ram interna, debe tener bastante y quiza podrias almacenar directamente en el las muestras si le da la velocidad. (conexion ADC-micro directa)

Por mi parte, leyendo la hoja de datos de la FIFO que vas a usar, me convenci y mande a pedir algunas a china. Seguramente tarden al menos 2 meses pero, con solo 2 de esas tendria los 2 canales que necesito y a 50mhz. Me ahorro muchisimo consumo y circuiteria.

Ya estuve pensando como puedo implementar el trigger con ellas, manteniendo un requerimiento mio que es disponer de una visualizacion pre-trigger.

Entonces, mi diseño hara lo siguiente:

CLK compartido para escritura y lectura, de esta forma, el puntero de direccion de la ram es igual en escritura y en lectura.

Pongo a grabar a la ram a maxima velocidad (a la vez esta habilitado el clock de lectura), siendo esta circular.

Cuando llega un trigger, detengo el clock de lectura y dejo que el clock de escritura continue durante capacidad ram / 2 muestras.

En este punto paro los clocks y el puntero de lectura esta posicionado exactamente en el momento del trigger. Entonces leo la cantidad de muestras que almacena la ram completa donde:

Primera mitad: Muestras post-trigger, Segunda mitad: Muestras pre-trigger.

Algo similar hacia en mi diseño previo pero con esta FIFO (no sabia que venian de esta capacidad y velocidad!) me saco de encima 2 PLD y reemplazo 4 chips de sram por 2 de fifo, amen de simplificar enormemente el diseño del PCB.

Te cuento que mi primer osci que funciono (el del video de mas arriba) estaba hecho con una fifo pero de tan solo 1K, y no tenia pre-trigger, es decir, funcionaba como los osciloscopios analogicos. Ahora teniendo +300K de ram, puedo simplificar el reloj tambien. (reloj unico para todo el sistema)

En la practica, osciloscopios comerciales que he usado, que tienen 512K de ram, etc.etc utilizan no mas de 10K

Muy buena data! conseguis esas memorias en Chile o las importas?

La parte analoga mia aun no la experimente, es solo diseño y simulacion. Le tengo fe, de todas maneras.


----------



## Sebastian1989 (Abr 20, 2015)

El propeller es un microcontrolador, el problema es que es algo viejo por lo que tiene poca RAM (32KB para datos y programa) y necesita 4 ciclos de reloj por instrucción por lo que no podría aprovechar al máximo los ADC, por lo mencionado anteriormente es que decidí agregar el hardware necesario para aumentar lo mas posible las muestras por segundo.

Excelente idea la de tener muestras pre-trigger, en mi caso creo que también lo implementare pero haré que sea configurable por software la cantidad, así dependiendo de lo que se quiera medir se podría cambiar este valor.

Las memorias las compre por ebay a un chino, compre 5 por 22.5USD, en Chile es difícil encontrar integrados poco conocidos.

Con el sistema double buffering tendría 768K muestra por canal, por lo que en total habrían 12Mb, si transfiero hacia el PC por serial a 3Mb/s tardare alrededor de 5.2 segundos en pasar la información de todas las memorias, para mi gusto es lento, se que 12Mbit es bastante y que probablemente no es necesario ocupar toda la memoria pero ya que la memoria va a estar disponible prefiero usarla. Cual es la tasa de transferencia que logras con el pic?.


----------



## seaarg (Abr 21, 2015)

Los 4 ciclos por instruccion descartan el manejo directo porque una transferencia desde un puerto a la ram implica al menos 2 o 3 instrucciones (hablo desde mi conocimiento de pic)

Lo de las muestras pre-trigger es algo fundamental para mi: "Quiero ver que pasaba en la señal antes de un transitorio". Como mi contador de desborde (para saber cuando llene la memoria desde el evento de trigger) esta implementado en su mayoria con el contador TMR1 externo del pic, puedo configurar desde soft cuantas muestras pre-trigger necesito asi que estamos en la misma idea.

En mi experiencia, no hace falta TANTA memoria, a menos que quieras medir señales muy lentas. Yo diseñe con double buffering por lo siguiente:

- Implica poder usar memorias mas lentas (12ns de tiempo de grabacion, las que dispongo, para una tasa de captura de 80msps). Si usase 1 sola memoria, esta tendria que grabar el dato con un pulso de escritura de 6.25ns. Hay un truco, si se requiere, con un capacitor, resistencia y una compuerta AND creo, que permite que de los 12.5ns de periodo, tener en estado bajo la señal por la mayoria de ese tiempo, permitiendo usar una memoria mas lenta pero de todos modos aun con este truco no llego al tiempo requerido. Por eso el double buffering.

- Desventaja: Las memorias consumen mucho. Para 2 canales implica 4 memorias, lo que representa cerca de 360ma solo para las memorias.

Con las FIFO que me indicaste, acepto su limitacion de 50mhz pero al sacar 2 memorias y 2 PLD para la direccion, no solo simplifico ENORMEMENTE el pcb sino que tambien reduzco el consumo por al menos 90+90+100+100 = 380ma

En mi experiencia, la FIFO de 1k que use en mi proyecto anterior iba, en teoria, a algo de 25-30mhz, y la hice funcionar sin ningun problema a 40mhz. Si estas se pueden exprimir de esa manera, quiza podria llevarlas a 60mhz. Teniendo en cuenta que mis ADC son de 80mhz creo que esta bastante bien.

La transferencia a la PC en mi caso va por USB full speed, 12m Transferir 1 Kbytes (1 pantalla) toma algunos milisegundos.

En mi diseño, se transfiere lo necesario. Es decir, si estoy tomando 1 muestra cada 2, no transfiero 2 muestras sino 1. Esto acelera muchisimo todo. Cuando quiera hacer zoom a la señal (cambiando hDIV) se hace una transferencia nueva.

Te comento: Usando memorias de 32KB en mis primeras pruebas, la transferencia completa de esta cantidad por usb a todo trapo se hacia apreciablemente lenta e insoportable (un segundo mas o menos x frame) NO te recomiendo que manejes esa cantidad de datos y menos por puerto serial comun. Pensa en si, obtener muchas muestras, pero transferir solo lo necesario.

Para la parte analogica, recorde que habia posteado un PDF con mi esquematico.

Acerca de tus dudas de los 4052 estoy de acuerdo, es posible. Sin embargo este osciloscopio http://fabiobaltieri.com/2013/07/10/inside-a-hantek-dso-2090-usb-oscilloscope/ los usa y anda mas que bien!

PD: Casi casi le compro al mismo chino  pero no me gusto el tipo de shipping por lo que elegi otro con un shipping mas normal, que algunos comentarios lo denuncian por componentes usados. Arriesgue y elegi ese, ojala que lleguen y sirvan!



Estuve viendo un poco de info acerca de el micro que estas usando. Viejo decis? que le queda a mi pobre pic entonces!

Veo que tiene generadores de señal compatibles con video. Pensaste en conectar un monitor directamente al micro y no usar computador? Si almacenar la señal para verla despues es una razon, bien podes usar una microSD 

Si yo conociese de esos micros y tuviese alguno, intentaria exprimirlo. Se le ve muchisimo potencial.

Si por casualidad tenes acceso a alguna FPGA, considera implementar casi todo el osciloscopio en una de esas. Simplificarias muchisimo todo.

Por mi parte, me complico con el hard por simple disponibilidad de componentes.


----------



## Sebastian1989 (Abr 21, 2015)

Al igual que tu el sistema double buffering no lo uso para aumentar la RAM, solo lo uso para poder llegar a los 100MS/s del ADC.

Me interesa usar y transferir toda la memoria ya que cuando este en el modo analizador lógico leyendo datos rápidos esto sera fundamental, mi idea es que el software decodifique varios protocolos de comunicación y luego yo pueda buscar un paquete especifico dentro de todos esos datos, por lo mismo sera necesario que tenga toda la muestra en el PC.

Para la transferencia de datos voy a probar distintas opciones, una de esas es usar uno o dos FT245R, en el caso que use 2 agregaría un HUB USB, podría ser un TUSB2046B. Con dos FT245R tendria una tasa de transferencia de 2MB/s por lo que podría transferir todos los datos en menos de 1 segundo.

Pensé en usar un monitor directo con el micro para visualizar los datos (nada de análisis) pero no se si pueda ya que para generar una imagen de 512x384 pixeles necesita casi 24KB de RAM, dejándome solo 8KB disponible para mi programa.

Por el momento no tengo FPGA ni se como usarlas, tengo teoría básica de las cyclone IV de altera pero nunca las he usado.


PD: Hace ya varios años que esta en diseño el propeller 2, por el momento han dicho de forma no oficial que tendrá 16 cogs ("núcleos"), 512KB de RAM, funcionara al menos a 200MHz y solo necesita 1 ciclo de reloj por instrucción, estiman que estará listo a finales de este año o principio del próximo. Son sumamente abierto con el desarrollo, tanto que hicieron al propeller 1 open source liberando el "código" de verilog de este, y tiene disponible el verilog de una versión sin actualizar del propeller 2.

Hojas de dato:
FT245R:http://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT245R.pdf
TUSB2046B:http://www.ti.com/lit/ds/symlink/tusb2046b.pdf


----------



## seaarg (Abr 22, 2015)

Seba, (tambien soy seba!)

Que tenes pensado usar para generar 100mhz ? Quiza pueda aplicar algo de lo que estes haciendo, ya que estas memorias trabajan a 3.3v tambien, y tengo un par de samples de ADC de 100mhz que no los usaba por ser 3.3v

Podria implementar los ADC + memoria en 3.3v y el resto de la logica con 5V. No se como se comportaran mis GAL teniendo ese nivel en sus entradas a altas velocidades pero podria probar. El micro no me preocupa porque el PIC si funciona con nivel "alto" mas bajo mientras no sea demasiada velocidad.

En un momento pense en usar este PLL http://www.alldatasheet.com/datasheet-pdf/pdf/65570/ICST/ICS9169CJ-271.html que lo obtenes de casi cualquier motherboard vieja de pentium.

Con el me aseguro el minimo jitter posible (estimo) a partir de un cristal de relativamente baja frecuencia. El problema es que tiran hasta 80mhz con el cristal de referencia.

Quiza, poniendo un cristal mayor funcione bien, pero de todos modos dudo que pueda conseguir 100mhz exactos.

Entonces, en mi diseño, estaba usando un crystal clock oscillator de esos cuadrados metalicos, que dispongo de varias velocidades, entre ellas 80mhz justos.


----------



## seaarg (Abr 23, 2015)

Me desvio un poco del tema para indicarle a Sebastian1989 lo siguiente que justo encontre: http://www.todopic.com.ar/foros/index.php?topic=18106.0

Ahi hay mucha informacion util sobre parametros que afectan el funcionamiento de algo como lo que estamos haciendo.


----------



## Sebastian1989 (Abr 24, 2015)

El clock del ADC y las memorias lo voy a generar con el micro, usando los contadores internos puedo generar sin problema esa señal.

Tiene bastante información útil el link que encontraste, ahora solo hay que ponerlo en practica.

Ayer recibí los ADC de maxim, hoy terminé el footprint del encapsulado, por lo que empezare a diseñar algunas tarjetas de prueba, por suerte hay una placa de evaluación para el ADC que usare y en el datasheet esta el diseño del PCB y bastante información adicional, el único problema del PCB es que es de 4 capas, aun así sirve de referencia. 

Es excelente el servicio de muestras de maxim, desde mi pedido de muestras gratis hasta que los recibí pasaron solo 6 días, hacen el envió por fedex.

Ahora me queda esperar por las memorias y los FT245R.

Link del PCB de evaluación de mi ADC:http://datasheets.maximintegrated.com/en/ds/MAX1198EVKIT.pdf


----------



## seaarg (May 5, 2015)

Queria comentarles, luego de la informacion de las memorias FIFO presentada por Sebastian1989 voy a retomar el proyecto, encarado de otra forma para facilitarme la vida:

Hace rato que ando con ganas de entrar en las FPGA, asi que, como paso intermedio:

- Encargue las mismas memorias FIFO + unos cuantos CLPD de Altera, concretamente: EPM240T100C5N, EPM7064SLC44-10, EPM7128SLC84-15, EPM7032STC44-7N que estan baratisimos en china.

Por lo tanto, voy a sacar un monton de integrados del diseño para reducirlos a los mas escenciales. Con esto no solo bajo el consumo, sino que mantengo el double buffering con una PCB mucho mas sencilla, mas barata y con mucha memoria (768 KB por canal). El double buffering lo mantengo para llevar el bicho este a 100 mhz, ya que tanto el CPLD como las memorias funcionan a 3.3v por lo que puedo usar los ADC08100 que tengo de samples.

Solo espero que el crystal clock oscillator que compre de 100 mhz funcione a 3.3v (hare la prueba antes) sino voy a tener que meterme con un PLL de pentium.

Ademas, con este CPLD, teniendo 2 canales (2 ADC) puedo agregar un switch analogico previo a los ADC para hacer que, si uso un solo canal, entre ellos hagan interleaving llevando la velocidad de sample a 200 mhz.

Aclaro que el switch analogico no estaria haciendo transiciones a esta frecuencia (imposible!) sino que selecciona si cada linea desde el frontend analogico va a distintos ADC, o si una linea (canal A o B) va a ambos ADC. En este ultimo caso, el CPLD es el que toma la informacion de ambos, en el estado alto del reloj de uno, y en el estado bajo, del otro (en este caso, los ADC tienen el clock complementario, invertido uno respecto al otro)

Por lo pronto, aprendiendo VHDL (yo trabajaba con winCUPL), los mantendre al tanto! Gracias Seba por la info de las memorias! le dio un giro completo a mis planes


----------



## seaarg (May 31, 2015)

Novedades:

Me llegaron las memorias FIFO, los CPLD de altera y etc.etc.etc desde china.

Adjunto aqui el codigo VHDL preparado para funcionar en un EPM7064S

El codigo es para un primer osciloscopio de prueba con cpld que estoy haciendo, caracteristicas principales:

- Totalmente portatil y aislado de masa. Funciona con una bateria de litio de esas que se usan como "cargador" de celulares.
- 1 canal, 384 Kb de ram @ 50msps, con captura pre-trigger y trigger externo
- funcionamiento bluetooth: Cualquier telefono android con una pantalla que soporte al menos 1000px en landscape hace las veces de pantalla e interfaz tactil. En mi caso estoy usando un Moto G. El modulo BT es el archiconocido HC-05 funcionando a 115200 bauds.

El codigo consta de:
1- trigger.vhd: Todas las funciones del trigger digital
2- overflow counter: Este contador cuenta media memoria (pre-llenado de fifo) y habilita el trigger para capturar el resto. Tambien determina el fin de captura.
3- osciloscopio.vhd: El resto de las ecuaciones para manejar la FIFO y controlar los circuitos.

Este bicho puede andar tranquilamente con un PIC 16F88 como micro, de hecho, lo diseñe para controlar el CPLD con este micro. Pero como no tengo las suficientes salidas en el micro y no tengo ganas de renegar multiplexando, voy a pasar a un 18F2550 o 4550 agregando ademas, la posibilidad de que sea bluetooth o USB. (de paso cañazo, ya que lo tengo!)

Proximamente posteo avances. Con el uso de un CPLD pase de un diseño de unos 10 integrados a uno de 4 (adc, cpld, memoria, pic)

Los cpld de altera son ridiculamente baratos. El 7064 como es viejito es un poco mas caro, algo de US$ 3.8 pero hay CPLD de 100 pines, de la serie MAX II al ridiculo precio de US$ 1.8, es decir, no vale la pena renegar diseñando la PCB para muchos mas integrados menores. El programador es el altera byteblaster (pirata, chino) que tambien sale 2 mangos.


----------



## seaarg (Jun 17, 2015)

Señores, el experimento esta vivo! 

Les comparto algunas fotos. Mañana tengo que ir a buscar unos zeners y las fichas BNC para asi poder soldar el operacional que falta en la entrada y voy a poder empezar a trabajar en el software y probarlo bien.

La placa es doble faz de fibra, hecha con el metodo de la plancha y papel de revista. Las pistas mas finas son de 0.34mm y salieron ambas caras a la primera! Mide unos 12x8 cm

Lo fui haciendo de a poco y haciendo pruebas de cada parte critica antes de soldar mas componentes, primero el CPLD... programarlo, funciona? ok, el micro... programarlo, funciona? ok y asi.

Para el divisor compensado en la entrada probe individualmente cada resistencia smd antes de soldarla, para asi tener exactitud en el mismo. Ahora, armando, me avivo que tendria que haberle puesto un preset!!! a pesar de ser resistencias smd tuve que compensar un poco para obtener exactamente 900K + 50K + 50K

Les comparto algunas caracteristicas y luego unas fotos:

- 50 MSPS, limite debido a que puse solo 1 memoria de 50mhz.
- ADC de 80mhz, usado a 50mhz
- 384Kb de ram, 1/2 pre-trigger, 1/2 post-trigger
- Trigger digital (adentro del CPLD). Posibilidad a evaluar: oversampling x2 usando trigger en flanco ascendente Y descendente de clock para la segunda ronda de muestras. (en este momento solo es por flanco ascendente... ahhhh que lindo que es vhdl  )
- Conectividad USB (12mbps) y bluetooth (115200bauds) si se usa con bateria (la misma se conecta a la entrada usb)
- Etapa analogica de hasta 250mhz de ancho de banda en ganancia unitaria. Creo que eran 100mhz amplificando.
- Divisor /1, /10, /20 en la entrada
- Multiplicador x2, x5, x10 (combinacion)
- Control de offset digital por medio del DAC, 16 bits de resolucion.
- Selector AC/DC controlado por micro (rele)
- Trigger externo, sencillo y lento, manejado por el ADC del micro

En estas primeras pruebas, puse la entrada del op-amp buffer a GND y obtengo, en el programita de prueba que hice, una señal con algo de ruido (a revisar la causa cuando lo termine de armar!) pero es muy aceptable, similar a osciloscopios USB comerciales baratos que he probado.

El trigger es bastante estable, aunque estoy considerando cambiarlo de 8 bits a los 7 bits mas significativos para que no sea TAN "sensible" (es solo un pequeño cambio en el codigo VHDL). Ya lo evaluare cuando pueda hacerle una prueba con señales validas.

Aca van las fotitos

Soldando el CPLD



Soldando el micro



Solder side



Component side terminado, solo que sin el op-amp



Marcados componentes principales


----------



## seaarg (Jun 21, 2015)

Aca dejo una imagen de lo logrado hasta el momento 

Luego de renegar como condenado intentando descubrir porque quedaba desenganchado el trigger y la señal "partida al medio" me di cuenta que en el software del micro estaba leyendo media memoria menos de lo necesario.

Una vez descubierto ese problema, obtuve esto:



Es una señal de 50 Khz sampleada a 50 Mhz. Cada division son 100 samples por lo que obtengo exactamente 1 ciclo de la senoidal en 1 pantalla.

El trigger esta ajustado exactamente a 127, es decir el punto GND. Si ven en la imagen, queda exactamente clavado al medio, le acerte al hacer el trigger digital en el CPLD porque casi NI se mueve por lo que me va a permitir hacer oversampling y tener hasta 100 Mhz de tasa de captura.

La señal se sigue mostrando perfecta en amplitud hasta 1 Mhz que es donde mi generador de señales empieza a atenuar. Las imperfecciones de captura que se ven en la senoidal son en realidad causadas por el pobre filtro de salida de mi generador digital casero, no es problema del osciloscopio.

Ahora, a seguir trabajando un poco mas en el soft para asi darlo por terminado y publicar aqui los archivos.


----------



## cosmefulanito04 (Jun 21, 2015)

Excelente, te felicito. Además la placa te quedó muy bien.

Podrías tirarle un promedio para matar el ruido, que por cierto parece ser bastante razonable.

Más allá hasta donde llegues con el proyecto (bastante lejos llegaste), el conocimiento y el laburo no te lo quita nadie.   [emoji106]


----------



## seaarg (Jun 22, 2015)

Gracias cosme!

Promedio ya esta implementado en el soft (ahi esta desactivado), es un checkbox en la UI. Queda bastante lisa la onda si se aplica.

Ahora me estoy concentrando en algunos perfeccionamientos. En el momento  que el osciloscopio marca que la captura esta lista, el puntero de la ram esta ubicado en el momento del trigger por lo que hay que recorrer la memoria entera - 500 muestras para ponerse en el punto de inicio de grafico y transferir. Esta recorrida demora unos 360 ms lo que me deja unos 2 FPS.

Implemente una rutina de prefetch en el CPLD para que luego de la captura, dejar el puntero en el comienzo de las muestras pre-trigger. Esto redujo el tiempo a la mitad.

Ahora estoy trabajando en el algoritmo de "salteo" de muestras del micro para acelerarlo. Asi a los ponchazos y rapido habia hecho un loop con un indice de 32 bits (cuando en realidad uso menos de 24 bits). Optimizando esto acelero mucho las cosas. 

Una cosa que probe es generar un PWM de 12mhz por un tiempo exacto para saltear las muestras pre-trigger que no interesan (esto actua sobre el clock de lectura) pero, si bien era rapidisimo y obtenia muchos FPS, se torna incontrolable.

Asi que lo que voy a hacer es optimizar el loop de salteo para ahorrar ciclos de micro. Creo poder lograr una mejor tasa de refresco de esa forma.

Sobre el ruido: No olvidemos que esto es una placa al aire, puesta al lado de una computadora. Creo que cuando la ponga en gabinete y la blinde (asi como blindarla del modulo BT) va a ser aun mejor.

Y si, en este proyecto desde sus comienzos alla por 2009 he gastado plata como para comprar 3 osciloscopios pero lo que aprendi haciendolo a traves de sus varias versiones es impresionante. 

Al final, las opciones de trigger que quedaron son:

- Automatico: SI hay evento de trigger captura, sino espera timeout y captura igual.
- Normal: Espera trigger, captura continua
- Single shot: 1 sola captura desde el trigger. Luego de esto, si cambia la timebase se re-transfiere mas o menos ram (Sirve para ampliar / reducir la onda o ver hacia atras o hacia adelante en la traza de captura)
- Slope + / -
- Nivel de trigger de 8 bits, cuyo valor de voltaje depende de la division / multiplicacion de la entrada.
- Trigger externo, con las mismas opciones que el normal.
- Trigger interno: Solo en flanco ascendente de reloj de captura, o en ascendente / descendente. Esto sirve para hacer oversampling x2 @100 mhz (aun no probado)


----------



## seaarg (Jun 29, 2015)

Sebastian1989,

Antes hablamos acerca del uso de 74HC4052 como mux en la parte analogica. Queria comentarte esto mientras aun estas diseñando:

Luego de hacer mis primeras pruebas en este nuevo prototipo, me encuentro con las siguientes limitantes, quiza no son tan graves, pero hay que tenerlas en cuenta:

- (Esta ya la sabia yo), Su voltaje maximo es 10vpp, cuidado con el rango de entrada
- (esta no la sabia y fue un mal descubrimiento jeje): En mi entrada, si ves un diagrama varios posts mas atras, tengo un divisor /1, /10, /20 antes del primer mux y este selecciona uno de esos tres divisores o una cuarta opcion que es un amplificador X2 tomando /1 como origen.

Pues bien, resulta que por mas que yo tenga seleccionada la entrada /10, si en cualquiera de los otros puntos de entrada del mux se supera VCC o VEE por 500mv (en mi caso, si pongo en la entrada algo mas de 5.5 volts) empieza a generarse una especie de senoidal en la salida montada sobre una continua de 5v (max VCC) que obviamente lleva el rango al desastre.

Es decir, va todo perfecto mientras en cualquiera de sus entradas no superes VCC o VEE. Lo cual me parecio en principio raro porque lo que estoy haciendo pasar (mux seleccionado) es 1 VPP max (es decir, 10 vpp divididos /10) pero, intuyo que la entrada 1:1 del mux al tener que recortar con sus diodos internos de clamping provoca este efecto en el resto de las entradas.

En mi caso lo arregle eliminando la entrada 1:1, puenteandola a la 10:1 y usarla como 10:1 x2 (para no desperdiciarla) es decir 5:1

Lo iba a arreglar haciendola 2:1 (20vpp rango) en vez de 1:1 pero como estaba hecha la PCB, implicaba poner resistores "bajos" en paralelo al 1M de entrada tirandome abajo la impedancia de entrada del osci por lo que preferi resignarla a una opcion secundaria.

En mi caso, como el ADC esta configurado para 1vpp full-range, la entrada 10:1 siempre hace las veces de 1:1 por lo que es la entrada seleccionada por defecto.

En este momento estoy depurando unos problemitas de estabilidad del offset generado por el DAC. Se me corre el punto GND con la temperatura y estoy viendo si es causado por el DAC o porque se calienta el ADC y la referencia interna cambia (SABIA que tenia que usar referencia externa!!! asi lo hice en mis otros osci, como me arrepiento!). Ya tengo un plan para solucionarlo haciendo una compensacion con un feedback loop implementado en el ADC del micro, pero como odio hacer parches 





cosmefulanito04 dijo:


> Podrías tirarle un promedio para matar el ruido, que por cierto parece ser bastante razonable.



Agrego info: En el CPLD, active el bit de configuracion de "Slow slew rate" y el ruido se redujo bastante. Ademas, agregue sendos capacitores de 10uF (consegui unos tamaño capacitor 100nF SMD hermosos) a lo largo de las lineas de alimentacion y en los integrados analogicos y mejoro aun mas. Tenia un poquito de ripple en las fuentecitas que, -gracioso-, lo encontre con el mismo osciloscopio es decir, analizandose a si mismo jeje

Segunda edicion, agrego mas info:

Resulta que no necesite hacer un feedback loop para estabilizar el punto GND. El problema es que el DAC que estoy usando (reciclado de un cdrom) es el TDA1311. Se supone que es de calibracion continua o al menos eso entendi yo, y supuse que una vez que le doy un dato, se queda estable. Resulta que no, si lo dejo quieto a medida que va pasando el tiempo va "patinando".

El problema no es temperatura sino simplemente perdida en su calibracion continua, estimo yo. Lo solucione haciendo que el micro cada cierto tiempo le re-envie el ultimo dato, forzandolo a actualizarse. Con esto tengo la linea de GND quieta hace rato, en diferentes temperaturas.


----------



## seaarg (Jul 20, 2015)

Sigo trabajando en el soft del bichito este 

Queria traerles un video de adelanto:

Como les conte antes, este osciloscopio es de "solo" 50 mhz de captura, pero la conectividad es tanto USB como Bluetooth.

Para usb, adapte un programa de mi osciloscopio anterior asi que fue rapido. Ya esta listo salvo alguna que otra cosita a mejorar. En version usb es muy rapido!

Pero lo mas interesante es la aplicacion android. Este video son unos segundos de demostracion mientras voy construyendo y depurando la aplicacion. La transferencia es bluetooth, por lo que el telefono es solo pantalla e interfaz de usuario, no tiene conexion alguna al aparato a medir.

Como acabo de descubrir que con android a traves de adb se puede capturar video, aca va. Es una senoidal de unos 5vpp (aun no ajuste escalas) a 100 khz, capturada a 50mhz, a razon de 100 puntos por division.

En este videito tambien se aprecia lo quieto del trigger digital x hardware en el cpld.

Por supuesto, no tiene tantos fps como cuando lo conecto por usb pero creo yo que esta bastante bueno tener la opcion portatil 

Me estoy imaginando que tal se veria en una tablet!

Son muchas opciones para meter en una interfaz tactil. Me interesaria si tienen sugerencias para la interfaz de usuario, las ideas son bienvenidas 

Proximas mejoras: Poner los datos de la señal en pantalla (vpp, frecuencia, vmax, vmin, etc) y, si el micro del telefono se la aguanta, con un comando de la interfaz graficar la FFT. (eso ya lo tengo en la version PC)






PD: Todavia estoy pensando como hacer para compartir el esquematico para quien quiera construirlo. La parte analogica es facil hacerla con proteus, pero para la parte digital no tengo en ese programa los integrados. Tienen alguna sugerencia para eso? Quisiera poder completar el aporte mas alla de compartir el soft. Si comparto el PCB sin esquematico no les va a servir de mucho porque son componentes smd y es jodido seguirlo.


----------



## jatoncel (Jul 20, 2015)

Buenas tardes compañero,
hace tiempo que estoy siguiendo este hilo.
soy estudiante de ingeniería y estoy trabajando en un proyecto de un osciloscopio android bluetooth, como el que mencionas. me puedes compartir la aplicación android y el diagrama de flujo del hardware para el envio de los datos a travez de bluetooth.

saludos


----------



## seaarg (Jul 21, 2015)

Ningun problema, aqui te adjunto el source de la aplicacion android. Aclaro que NO esta completa aun pero te sirve para ir estudiando algunas cosas.

Diagrama de flujo no tengo, no hago eso 

Tambien adjunto un zip con todo el proyecto. No va a servirles para "planchar y armar" pero si puede servir para quien se este haciendo uno, sacar ideas o usar partes.

- Software version USB, para windows, hecho en Visual Basic .NET 2010
- Firmware del PIC (18F4550)
- Firmware del CPLD Altera 7064S en VHDL
- Una simulacion en proteus 8 de la entrada, aunque la que termino siendo tiene alguna que otra modificacion pequeña.
- El PCB hecho en pcb wizard, sin plano de masa (siempre lo pongo al momento de imprimir, con el circuit wizard)

El pcb esta hecho para componentes superficiales (ver foto en un post mas arriba) y al momento de armado le hice algunos pequeños cambios que no estan documentados. En escencia un divisor de tension en la salida del DAC (y entrada de offset del operacional buffer de adc) y muchos capacitores a lo largo de las lineas de corriente.

Supongo que el pcb asi, sin esquematico, no se va a entender nada pero lo pongo para quien le sirva. El esquematico, como dije antes, no es que no quiera publicarlo sino que no lo tengo, normalmente diseño sobre el pcb, sin esquematico (de memoria bah )

Por ultimo, la aplicacion android esta basada en http://projectproto.blogspot.com.ar/2010/09/android-bluetooth-oscilloscope.html pero muy modificada ya que la de ese blog tiene ciertas limitaciones.

Breve (muy) explicacion tecnica del soft, tanto de usb como de bluetooth:

- Se basa en una cola fifo de comandos, con prioridad (en caso BT, porque sino es lento). Los comandos de usuario tienen prioridad sobre los de captura.

- Todo comando que se envia al hardware es puesto en cola y a medida que se libera el hard se va procesando la cola.

- Los comandos y sus datos resultantes son auto-contenidos. Es decir, no necesita buffer de recepcion de datos pues el buffer pertenece a cada comando.

- La cola de comando funciona en su propio thread.

- Los graficos tambien funcionan en su propio thread

- El pedido de captura al hard funciona de acuerdo a ciertos parametros: 

a- Se envia el comando captura. El hard reacciona con una captura automatica segun parametros (ver firmware del pic, comando "2" = captura)
b- Hay un parametro que especifica cuantas muestras pre-trigger se requieren. Con ese parametro, se calcula donde posicionar la memoria FIFO del hard para empezar a transferir.
c- Hay un algoritmo para "saltear" muestras de transferencia, que depende del timebase. La tasa de captura siempre es fija a 50 msps y los distintos timebase se obtienen determinando la cantidad de muestras a obviar
d- Para la grafica: Se asume que las 10 divisiones verticales representan los valores 0-255 del ADC, por lo que hay un poco de matematicas sencillas en el programa con respecto a escalar el grafico de acuerdo a el valor del divisor/multiplicador de entrada, el valor de V/div, y por ultimo, el valor de la vertical del punto GND (que actua sobre el DAC de offset)

Cualquier pregunta concisa sobre como funciona alguna parte, adelante! respondere lo mejor que pueda.


----------



## jatoncel (Jul 21, 2015)

muchas gracias por tu pronta y excelente respuesta...
analizaré los archivos que adjuntaste.... me serán de mucha ayuda..


----------



## Sebastian1989 (Jul 21, 2015)

Como siempre excelente aporte seaarg, viendo tus avances se nota que le has dedicado una cantidad considerable de tiempo a tu desarrollo.

Por mi parte he estado ocupado con otros proyectos por lo que no he podido avanzar mucho en mi diseño del osciloscopio, al menos pude probar las memorias FIFO y el ADC trabajando en conjunto a baja velocidad, he tenido bastante problemas tratando de coordinar los distintos clocks con el micro por lo que estoy pensando en agregar un CPLD, el problema es que mis conocimientos de verilog o vhdl tienden a cero por lo que tendría que dedicarme un buen tiempo a aprender, por lo mismo compre una pequeña tarjeta con un epm240 para empezar a jugar con leds y pulsadores (hay que partir por algo).

seaarg no se si sabes pero uno en proteus puede crear sus propios integrados, no los puedes simular pero es bastante útil para hacer los esquemas que tienen integrados que no están en proteus. Pongo un link en donde muestran como:


----------



## seaarg (Jul 21, 2015)

Excelente Seba! no lo sabia. Ahora podria hacer el esquematico sin problemas!

Yo tampoco sabia nada de vhdl pero me resulto sencillo. Si sabes ingles, un excelente libro es "free range vhdl" se puede bajar libremente como pdf sin incurrir en pirateria.

Por otro lado, que mejor ejemplo para aprender vhdl en tu caso que mirar el codigo que puse en el post, ya que es un osciloscopio


----------



## Sebastian1989 (Jul 21, 2015)

Definitivamente revisare los archivos que subiste, seguro que serán muy útiles, gracias por recomendar un libro aunque creo que partiré aprendiendo Verilog, como domino C me parece algo mas intuitivo.

Hace uno días conocí este sitio:http://www.edaplayground.com/
Permite hacer simulaciones de HDL (Hardware Description Language) directo desde el navegador,
un buen ejemplo http://www.edaplayground.com/s/example/8 si a la izquierda activan la casilla epwave y presionan Run, el compilador mostrara un diagrama de tiempo de las señales.

Agrego un video donde muestran las funciones basicas


----------



## jatoncel (Jul 23, 2015)

Hola, Actualmente estoy desarrollando mi prototipo de osciloscopio con DSP.
pero con lo mencionado por ustedes, creo que me encaminaré tambien por FPGA - CPLD.


Una pregunta seaarg, ¿como generas la señal de reloj para el adc y la fifo?


----------



## seaarg (Jul 24, 2015)

Hola jatoncel, bienvenido al post.

La señal de reloj es generada por un oscilador a cristal integrado. Es el cuadrado metalico que ves en esta foto:

Ver el archivo adjunto 130958

En este caso, de 50mhz. Los alimentas con 5V y en uno de sus pines te da el clock. Conseguibles hay hasta de 125mhz.

Agrego info: En placas de partes de computadora, lectoras de CD, etc, hay de esos pero muy chiquitos en SMD. He visto normalmente de 33mhz pero tambien vi de 48 y 50mhz.

Algo asi:







Este oscilador maneja el clock del CPLD y en el codigo del mismo esta la generacion de las distintas señales de clock para el adc, la fifo, etc.

Ejemplo:

- Entra el clock al pin principal de clock del cpld. Este clock maneja todo lo interno del cpld.
- Se deriva a traves de un pin de salida, un clock igual al principal para el WCLK de la fifo (es necesario que el read clock o el write clock esten permanente porque la fifo es internamente DRAM y lo usa en su circuito de refresco) Por lo que la grabacion en si se controla con WE (write enable)
- Se deriva tambien por otro pin el clock del ADC. Este clock esta activo solo cuando se captura. En el caso de mi adc, el mismo tiene un pipeline por lo que las primeras 4 muestras no son validas, pero jamas se transfieren al software. Ademas, el flanco de este clock es negado con respecto al de la FIFO, si mal no recuerdo. Todo depende del adc que se use y sus graficas de cuando el dato en la salida es valido para grabar.

Sino hay opciones de integrados PLL generadores de clock, les pones un cristal de referencia y ellos generan hasta 200mhz o mas, depende de una configuracion pero son un poco caros.

Como sugerencia, si tenes que comprar algo, fijate las caracteristicas de deriva que tengan las distintas opciones. No se exactamente que tan precisos son estos osciladores comparados con los integrados PLL. (si alguien sabe, me gustaria que lo comente asi me saca la duda!)

-------------------------------------------------------------------------------------

Parrafo aparte: Estuve investigando un poquito sobre el procesador software NIOS. Quiza no me alcance el CPLD pero para el proximo osciloscopio (2 canales, 100mhz, blabla) voy a evaluar la posibilidad de resumir todo en el cpld, sacando el pic de la ecuacion. Esto seria el controlador de captura + procesador todo dentro del cpld y un FT232 externo para conectividad usb.


----------



## seaarg (Ago 27, 2015)

Una pequeña actualizacion:

Estoy en proceso de intentar integrar dentro del trigger digital, un filtro HF digital, de forma tal que se puedan disparar señales como las de video sin problemas.

Para hacerlo, tome un conjunto de samples reales de una señal de video, los puse en excel y genere un grafico.

Luego, a esos samples les aplique esta formula:

sample_actual = (sample_actual * 0.01) + (calculo_previo * 0.99)

Con esto, logro un filtro pasabajos digital "barato" en terminos de recursos, ya que es muy similar a promediar 100 muestras, pero ocupando solamente 1 byte para la memoria de sample calculado previo.

Asi, genero un nuevo grafico en excel y la verdad que promete. La señal queda muy limpia y se ve bien claro donde comienza el pulso de vertical para hacer trigger ahi.

Se puede variar el filtro cambiando el peso de la ponderacion y, por ejemplo, tomar 10 muestras virtuales de esta forma:

sample_actual = (sample_actual * 0.1) + (calculo_previo * 0.9)

Adjunto link sobre este tema (en ingles) http://www.embedded.com/design/configurable-systems/4025591/Digital-filtering-without-the-pain

Ahora que lo resolvi en la teoria, mi problema va a ser implementarlo en la practica. En el CPLD estoy usando 52 de 64 macroceldas (cada una de ellas es un flip-flop de memoria) y tambien me estoy quedando sin compuertas internas, por lo que voy a tener que apretar al maximo el codigo VHDL a ver si lo puedo hacer entrar en este CPLD.

Saludos!


----------



## seaarg (Oct 14, 2015)

Estoy desaparecido un tiempo porque estoy desarrollando una version mas completa.

Me llego una FPGA de altera, concretamente EP3C16 con la que estoy jugando. Junto con un par de ADC08200 que tienen que llegar estoy haciendo lo siguiente:

- Osciloscopio "de banco" digital
- 2 canales a 200 MSPS o combinacion 1 canal a 400 MSPS (no se si llegare a tanto con los IO del fpga)
- 750mhz ancho de banda analogico
- Totalmente independiente de la PC.

Para esto ultimo, estoy evaluando algunas variantes:

- Tengo una tablet 7" con el digitizer roto. Puedo usarla como pantalla y "cpu" para albergar el programa o el proceso pesado de datos (FFT,etc)
- Tengo un raspberry PI con pantalla de 7" para lo mismo, pero usando un OpenHantek modificado en raspbian.
- Tengo una notebook 17" del año del ñaupa

Aun no se que usar, lo que si tengo claro es que los controles del osci los quiero hacer con encoders rotativos, potenciometros y botones. Es decir, la interfaz NO estaria en el programa.

Tambien podria directamente generar una señal VGA o LVDS con el fpga para hacerlo aun mas directo, pero no estoy seguro de querer desechar la capacidad de proceso de una compu como la tablet o la raspi.

- Manejo VGA: Pro: Rapidez, Contra: Complejidad y limitaciones (ademas de tener que hacer un frame buffer o procesar los datos "on the fly")
- Manejo a traves de raspi GPIO o Tablet USB: Potencia de hard y soft, pero con la contra de funcionamiento igual a cualquier osci usb (rafagas de captura)

En fin, ando estudiando los pro y contra de cada variante. Amen de que no se si llegare a hacer con exito una placa de 200mhz. Quiza tenga que decantar por 100mhz pero veremos hasta donde llego. El core del FPGA llega a funcionar a 400mhz, lo que no estoy seguro es de los IO, ademas de los problemas de PCB a esas frecuencias.

Ademas, en mi investigacion logre hacer andar un Nios II dentro del fpga, que seria el controlador del osciloscopio.

Hasta ahora estoy usando memoria interna del fpga, que tiene bastante pero no suficiente para esta aplicacion.

Queria preguntarles: Si implemento un controlador para SDRAM o mejor aun, para DDR:

- La SDRAM corre a 133mhz maximo segun el Qsys para este fpga.
- La DDR, supongo que se puede llevar a 266mhz

La pregunta es: Tienen idea si se puede hacer grabar continuamente datos a estas velocidades? Entiendo que mientras este haciendo burst si, pero cuando tengo que cambiar de fila en la ram hay un delay de precarga.

Creo haber entendido que puedo estar haciendo grabacion en burst en un banco, mientras que a la vez estoy activando otro banco donde tenga seleccionada otra fila. De esta forma, podria hacer una grabacion continua a tiempo constante? (Dicho tiempo seria un periodo de 5ns a 200mhz, solo alcanzable en DDR)

Sino uso la memoria interna del FPGA pero dispongo en este de unos 16K x 16bits o un poco menos. Para poder hacer esto tendria que hacer una base de tiempos variable con prescalers en el vhdl pero quiero evitarlo a fin de poder tener una "foto" de una captura a la cual le pueda hacer zoom in/out (para ello necesito de todos los samples posibles a maxima velocidad)

Cualquier informacion es apreciada!


----------

