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

[Sebastian1989]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

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]

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]

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]

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]

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

 

[Sebastian1989]

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]

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]

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