[DHT22] (AM2302) Sensor de temperatura y humedad.

[Democrito]

Hola!

Necesitaba hacer un ejercicio de tri-estado (en plan fácil) y me acordé de que tenía un DHT22 (AM2302). Hace mucho tiempo lo probé con Arduino y he aprovechado para pasarlo a FPGA. Sólo tiene una línea de comunicación y tiene una forma peculiar de hacerlo. Pongo dos gráficos temporales porque ambos nos sirven para comprender el funcionamiento, ya sea por exceso o por defecto (lo que no se ve en una aparece en la otra).

En el gráfico vemos una señal roja y el resto en azul. En realidad no es tan.. tan.. así, pero os comento cómo funciona realmente:

• La señal se mantiene en alto siempre a través de una resistencia pull-up.

• Cuando dicha señal la llevamos a 0, le estamos comunicando al DHT22 que queremos leer los datos de temperatura y humedad. Es lo que aparece en rojo, pero en realidad sólo la parte baja (0) corresponde al micro o FPGA.
• Una vez hecho eso, hay que poner la FPGA a escuchar.
• Nos saldrá un nivel bajo y otro alto del mismo periodo (80us).
• Y después comienza la transmisión de datos, primero de humedad (16 bits) y luego de temperatura (otros 16 bits), tb nos saldrá un checksum (8 bits), en total hemos de leer 40 bits. En los bits de temperatura el bit más alto (el bit 15) es de signo, para saber si sobre cero o bajo cero.
• Finalizada la transmisión de datos la línea de comunicación quedará a 1, por la resistencia pull-up.

Para pasarlo a FPGA hice lo siguiente:

• Cree 4 ciclos (ciclo 0 al 3).
• Ciclo 0: No hacer nada.
• Ciclo 1: Poner a 0 la línea de comunicación.
• Ciclo 2: Ponerse a escuchar y esperar dos flancos de bajada.
• Ciclo 3: Traducir los anchos de pulsos a 0s y 1s. Reunida esa información en un registro de desplazamiento de 40 bits, sacarlo en paralelo para ser utilizado en cualquier ámbito.

La lectura de esos bits me trajo bastante problemas, no por la lectura en sí, sino porque este integrado por alguna razón u otra a veces crea bits de muy corta duración que son espúreos. Me inventé un filtro digital que funciona estupendamente bien para este caso (son simples flip-flops puestos en cascada con dos condiciones para saber cuándo es un 1 o un 0). Esto luego me obligó a variar el tiempo real de lectura, porque modifica los periodos, pero una vez atinado, no falla ni un bit. Es por esta razón que la parte checksum pese a que la dejo ahí por si alguien quiere comprobar que todo está correcto, en el circuito de ejemplo no la uso.

Adjunto dos ICEs. El driver y un ejemplo para verlo en funcionamiento a través del serial, también los módulos creados para tal finalidad.

• DHT22.ice: Driver en sí, para que lo tendrás según lo quieras usar.
• Serial_DHT22.ice: Ejemplo de funcionamiento a través del serial.
  
• Modulos&svg.zip: Ahí está todo lo que he utilizado. Hay módulos que pueden ser interesantes, como los conversores de binario a ASCII y tb de binario a serial (se pueden adaptar a otras necesidades).
  

Como de costumbre voy creando post en plan cuaderno de bitácora, es decir, que en cualquier momento iré comentando cosas que se me olvidó comentar, posibles errores, etc.

Más adelante pondré lo mismo aplicado al DHT11, que funciona casi exactamente igual, con la peculiariedad de que la información que saca es de menor resolución y los bytes de información tiene otra configuración.

Saludos.

Post Data: Recuerda que en Icezum Alhambra, para poder hacer triestado sólo es posible con los pines amarillos (GPx). En Alhambra II puedes usar cualquier pin, yo uso el pin D0.

[Democrito]

En el módulo para pasar de binario a BCD (esto es una fase esencial cuando se quiere enviar datos) cree un circuito poco común.

Normalmente para pasar de binario a BCD existen circuitos ya hechos, pero como este proyecto el tiempo de muestreo es muy amplio (no ha de ser menor de 2 segundos), me decidí a hacer el mío propio (es otra forma más de hacer lo mismo y que ya estaba inventado).

Se trata de que para pasar de binario a BCD, poner dos contadores, el binario de siempre, y otro en BCD. Cuando termina de contar el contador binario, como el contador BCD tenía la misma clk, tendrá dicho valor pero en BCD. Eso es todo. No es eficiente porque para convertir depende del número que quieres convertir, es decir, cuanto más alto sea ese número, más tiempo. Pero como comentaba, aquí los tiempos son muy amplios y da tiempo de sobra a hacer esa conversión, además de que avisa de cuándo ha terminado.

[Democrito]

Acabo de ver un pequeño error. Sólo es el signo que no sale cuando la temperatura es menor de 0 y me acabo de dar cuenta de la razón. En el próximo post adjuntaré el circuito corregido.

[Democrito]

Arreglado. Adjunto circuito reparado. Es la demo serial que ha de interpretar si se está por debajo de cero o no. El driver principal no tiene cambios, sólo afecta a la demo (enviar los datos por el serial).

Ya de paso pongo lo que captura Script communicator y Pulse View (en este último no me dio tiempo de tomar la temperatura bajo cero, pero es ejemplificativo de ver la señal real).

Ahora sale bien los datos de la temperatura. Es normal que la humedad siempre salga 99.9%H porque al salir del congelador condensa la humedad y se mantiene en el valor máximo.

No he conseguido poner "º" de grado, no sale bien, entonces lo he sustituido por "*".

Ahora pongo una imagen de lo que sale en Pulse View, que por cierto, es capaz de interpretar muchos sensores, entre ellos los AM23X (DHTxx) como podéis comprobar.

En esta imagen la temperatura ya es superior a cero grados.

Y ahora pongo una imagen de un registro normal y corriente, de la temperatura y humedad que hay en el lugar donde vivo (casi en pleno monte, por eso la humedad es alta).

Se puede utilizar cualquier terminal serie, por ejemplo el de Arduino, aunque en las imágenes siempre he puesto las que sale en Script Communicator.

[Democrito]

Si alguien profundiza en el funcionamiento del DHTxx cuando se envía la información de humedad y temperatura te darás cuenta que no envía bits normales, sino que nos hemos de fijar en la anchura del pulso para saber si es un 1 ó un 0 (sólo midiendo el estado alto de dicho bit).

Cuando tuve que diseñar esa parte antes me hice un pequeño diseño para comprobar si era adecuado o no. Se trata de diseñar un circuito que a nivel humano podamos decir que algo es un 0 o es un 1. Pongamos que arbitrariamente digamos:

• La señal es 0 si mide menos de 500 milisegundos.
• La señal es 1 si mide igual o más de 500 milisegundos.

Adjunto este circuito comprensible para "humanos". Luego sólo tuve que adaptar los tiempos para "sensar" los 1s y 0s del DHT22.

El circuito sólo se fija en el estado alto, al igual que en el sensor DHT22.

[Juan Gonzalez Gomez]

¡Hola Demócrito!,

Los circuitos que has hecho me parecen alucinantes! Son muy fáciles de entender y están muy bien pensados. Muchísimas gracias 😀

El conversor binario-BCD me ha encantado. Es una idea muy simple y fácil de entender por cualquiera, que es uno de los objetivos: hacer la electrónica digital lo más intuitiva y fácil posible para la gente nueva. Después ya vienen las optimizaciones, pero el primer paso es hacerlo fácil

Así que gracias otra vez 😀

Saludos, Obijuan

--
Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/082c4dc9-a4b7-45e9-8bea-210b8b29c12e%40googlegroups.com.

[Democrito]

Gracias a vosotros que sois las locomotoras que movéis este pedazo de proyecto!

[Democrito]

Hola de nuevo!

El driver que adjunté en el primer post (DHT22.ice) es también válido para el DHT11. En este post lo voy a volver a adjuntar pero renombrado como "DHT_driver.ice".

Lo que cambia es el cableado para enviar la información y de eso se encarga el módulo "bin2serial_dht11.ice". Pongo una imagen y comento el diseño.

El DHT11 tiene menos resolución y las tolerancias son mayores, por tanto aún menos precisión. Si alguien quiere realizar este proyecto le aconsejo que no dude en comprarse el DHT22. Además el DHT11 he visto que mide la humedad hasta unos 20 puntos por debajo de la realidad. No tengo higrómetro para poder dar fé de ello, pero lo he comparado con las medidas que daba el DHT22. Además, el DHT11 puede llegar a dar una temperatura superior a 2ºC de más y esto sí que lo he podido contrastar con un termómetro independiente. Por otra parte, para saber si los datos que mostraba eran válidos (que realmente saca los valores correctos) lo he contrastado con los valores que muestra el programa Pulse View.

El DHT11 sólo mide temperaturas de 0 hasta 50ºC, y humedad de 20 hasta 90%.

En cambio, el DHT22 mide temperaturas de -40ºC hasta 80ºC, y humedad de 0 hasta 100% (99,9% real), y con bastante precisión.

Por otra parte he visto que los datos que envía el DHT11 fallan mucho, con demasiada frecuencia, poniéndole un checksum falla menos, pero me vi obligado a crear un circuito aparte de validación para asegurarme aún más de que los datos de salida eran estables. Con respecto a la temperatura tiene una evolución estable, pero los datos de humedad a veces daba saltos extremos y es por ello que le he tenido que hacer una doble validación. Con este diseño es muy raro que salgan errores (sería demasiada casualidad). He estado observando datos de salida (H&T) durante más de 15 minutos sin errores (sin saltos extremos, una evolución natural).

El módulo de validación para el DHT11 son dos registros de 16bits puestos como desplazamiento, en el que se compara la temperatura anterior con la actual (lo mismo para la humedad), y si todo es coincidente entonces permitirá mostrar los datos.

Y con respecto al DHT22 tiene un comportamiento muy estable y hasta ahora no he visto nada extraño. Aún así le he añadido un "checksum" para completar el proyecto. El checksum no es otra cosa que sumar todos los bytes (2 de humedad y 2 de temperatura) y el resultado de esa suma ha de coincidir con el valor que da el propio DHTxx como checksum.

Adjunto los siguientes archivos:

• DHT_Driver.ice:       Driver como tal, y sirve tanto para el DHT11 como el DHT22.
• DHT11_serial.ice:    Ejemplo para el DHT11 con salida de datos por el puerto serie. Posee doble validación de datos.
• DHT22_serial.ice:    Ejemplo para el DHT22 con salida de datos por el puerto serie. Circuito mejorado y añadida la parte "checksum".
• Modulos&SVG.zip:  Contiene los módulos utilizados en estos dos proyectos y los SVG correspondientes.

Entre esta tarde y mañana voy a hacer un último proyecto con este sensor y lo daré por finalizado. Voy a intentar sacar los datos por otro medio que no sea el puerto serie, para variar un poco.

Saludos.

 

[Jose Pico]

  Increíble!  Muchas Gracias!

  Me lo apunto....

  Esto va viento en popa y a toda máquina....

[Democrito]

Ey José! gracias por echar un ojo a este proyecto!

Antes de comenzar pongo un vídeo: https://youtu.be/7f0YcMLGF18

Al comienzo se aprecia la temperatura de mi habitación y su alta humedad. Después enciendo un mechero y caliento el sensor. Se aprecia un pico de humedad de 81.8%H; parece extraño pero es normal que suceda porque el gas butano (propano, etc) al arder desprende CO2+agua. Es por eso que cuando se utiliza estufa de gas en casa se empañan los cristales, sin embargo con calefacción de radiadores (calefacción central) es muy raro que suceda. Al subir la temperatura en el sensor inmediatamente después baja la humedad porque dicha humedad se evapora muy rápido. La cosa era ver bailar las cifras de temperatura y humedad. Las cifras izquierdas es la temperatura y la de las derechas es la humedad relativa. Hoy no he logrado grabar temperaturas bajo cero, subía muy rápido la temperatura (aparte de que mi cogelador no enfría a menos de -10ºC) y para cuando consigo llegar con el sensor (de la nevera a la protoboard), enchufar el sensor y darle al "rec" de la cámara, ya estaba por encima de cero grados. Pero sale el guión, comprobado.

En este proyecto se hace el ejercicio combinado de utilizar el DHT22 y el MAX7912, éste último fue tratado hace dos meses. El esquema principal me ha quedado así:

Estuve buscando en Internet SVG que fuesen atractivos, especialmente para los más jóvenes y que vea que cada elemento tiene su función (y personalidad!).

En realidad cumple la misma filosofía que los post anteriores, se trata de traducir los datos al medio que quieras representarlo. La siguiente imagen se puede apreciar "el medio" que transforma esos datos para poder aplicarlo al MAX7912, por SPI.

Este circuito hace exactamente lo mismo que en los post anteriores, pero los datos son tratados para poder ser enviados por SPI.

Adjunto el ejemplo que he utilizado en este post.

Saludos.

[Pedro Peralta]

Hola Democrito

Muy interesante tu laboratorio, me peguntaba para poder lograr temperaturas más bajas que tal si congelas el sensor, desde luego aislando las partes eléctricas con plástico.

Excelente demostración,

Saludos,

Pedro P.

--

Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/db71253a-2528-4962-bce3-831e0d1b1e32%40googlegroups.com.

[Democrito]

Hola Pedro!

Eso es exactamente lo que hago, meto el sensor en el congelador. Intentaré mañana ver si da tiempo de que aparezca temperaturas negativas.

Saludos!

[Pedro Peralta]

Hola Demócrito,

Si te entiendo, pero considero que si el sensor está dentro de un cubo de hielo, la temperatura debería de llegar más abajo de -10 grados, dado que el agua ya se solidificó y además si lo rocías con sal, la temperatura del hielo debería bajar más, bueno esto según las clases de química que me acuerdo, pero bueno es solo una sugerencia.

Me parece excelente tu experiencia. gracias por compartirla. voy a estudiar tu propuesta.

Saludos,

Pedro P.

--

Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/fad0f1c7-f93d-4cff-af1a-6433435c5a7c%40googlegroups.com.

[Democrito]

Donde digo "pero los datos son tratados para poder ser enviados por SPI" quise decir "Para ser mostrados por el MAX7912" (y que funciona por SPI) pero no es el único display que funciona por SPI. Este tratamiento sólo es válido para el MAX7912, al menos hasta donde conozco.

[Democrito]

Tienes razón Pedro, eso de la sal y el agua lo hago en fiestas al aire libre (para enfriar refrescos, cervezas, etc) y funciona muy bien! Es un efecto muy curioso.

[Democrito]

Metiendo hielo... (se me escapó ese detalle).

[Jose Pico]

 El domingo, 20 de octubre de 2019, 2:12:43 (UTC+2), Democrito escribió:

Ey José! gracias por echar un ojo a este proyecto!

    GRACIAS a tí por todo lo que nos aportas.

     Siempre te sigo de cerca.  Mil Gracias y ánimo con todo lo que haces ( siempre interesante).

[Democrito]

Un abrazo fuerte José!

Pongo otro vídeo donde se aprecia temperaturas bajo cero, luego va subiendo de forma natural. La humedad siempre se mantendrá al 99.9%H porque el frío condensa humedad en el sensor al sacarlo del congelador (lo mismo que pasa en verano cuando nos sirven (o nos servimos) una bebida fresquita).

https://youtu.be/_ttQ9lj5VUk

Saludos.

[flip ma]

Democrito eres un MAQUINA, me ha gustado mucho tu trabajo para el DHTxx,

lo he probado con el ScriptCommunicator y funciona bien, estoy esperando que me llegue el MAX7219 para probarlo. Un saludo y muchas gracias por el trabajo. 

[charli va]

Que trabajazo Demócrito! enhorabuena y mil gracias por compartir todo esto! 

Estoy deseando probarlo!

--

Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/5d15a00b-5218-40aa-bc8d-b018234bc4a9%40googlegroups.com.

[Democrito]

Muchísimas gracias por las pruebas y comentarios "flip ma" y Carlos.

Iba a aparcar este proyecto, pero con el DHT11 se me quedó la mosca detrás de la oreja. Los datos que da falla más que una escopeta de feria, y estoy investigando en reconstruir la señal original sabiendo que tiene un patrón conocido. Si lo consigo sacaré un nuevo driver (independientemente que sea para el DHT11 o 22). Lo último publicado sobre el DHT11 va bien, pero sé que no es perfecto y también sé que se puede mejorar.

Si realmente alguien quiere profundizar en este tema, en el driver "DHTxx.ice" si hace doble clic en "Ciclo 3" verá un módulo llamado filtro. Si eliminas dicho filtro y haces conexión directa, nos encontramos con "la escopeta de feria". La solución fácil ya la tengo, poner el doble de flip-flops que se ve dentro del módulo "filtro", con sus and y nor correspondientes, pero no me gusta esa solución, es sólo un parche.

Lo que quiero es que vaya todo lo bien que sea posible de una forma más elegante y sin el checksum, aunque en el diseño final lo llevará de todas formas (si lo consigo, claro).

Saludos.

[Democrito]

Cuando comentaba lo del "parche" es que estamos sujetos a una velocidad de clk, si en vez de 12MHz fuese a 500MHz podría no servir y estos pequeñísimos detalles que parece que no tiene importancia los tiene cuando cambias de ambiente. Uno puede dar por hecho algo, creer que funciona siempre, cuando un simple detalle puede dar al trate con todo.

[diego fernando godoy rojas]

Democrito, para la BlackIceMX que tiene un reloj de 25 Mhz que modificaciones deberia realizarle ? Pues me confunde un poco el tema de los tiempos. gracias.

[Democrito]

Hola Diego,

Si una FPGA usa otra velocidad que no es 12MHz hay que hacer modificaciones a todos los módulos que dependan del tiempo para que funcione igual. De hecho casi todos los módulos tienen capacidad para modificar ese parámetro de forma sencilla y rápida, en otro hay que hacer deducciones pero no es nada complicado.

Lo que a continuación comento nunca lo he hecho, pero si experimentas seguro que sale y más fácilmente de lo que parece. Lo que viene a continuación son deducciones lógicas.

Ejemplo 1. Modificar el bombeo (tics por segundos).  Vemos esto si hacemos doble clic al módulo de "corazon-tic-sec" (es un bombeo en segundos).

Modificas el valor de 12000000 por 25000000 y debería darte un tic por segundo.

Ejemplo 2. Timer de micro-segundos. Es un temporizador de micro-segundos. Es decir, que cuando reciba un tic, a la salida te dará otro con el retraso que le hayas dado en micro-segundos.

Lo mismo que antes, pero ahora como micro-segundos, en vez de 12, pones 25.

Y es así con todos los módulos que dependan del tiempo, pero vamos a poner un caso complejo, por ejemplo el receptor serie, aunque no venga al caso.

Ejemplo 3. Receptor serie (UART). Este ejemplo es menos claro pero se deduce muy fácilmente.

Entonces has de cambiar los valores que ponen en el recuadro en rojo y haces la división de 25000000/baudios y lo sustituyes.

Por último, en este proyecto está el SPI que funciona a 2 MHz para controlar los displays, y dentro tiene un contador de tics. Esta parte yo no la sé deducir ahora mismo y me tendría que poner. Pero de todas formas no creo que haya problema en mantener el mismo módulo porque es capaz de funcionar hasta 10MHz si mal no recuerdo. Si funcionas con 25 en vez de 12, supongo que te dará una velocidad de un poquito más del doble, pero no debería de afectar al funcionamiento de los displays SPI. No he profundizado y no puedo probar con otra velocidad pero me da la nariz de que no tendrás problemas con ese módulo.

Por otra parte te recomiendo guardar tus módulos modificados aparte, o bien, si modificas una parte de un circuito, primero haz aquello de copiar y clonar (en vez de pegar), es decir, copiar ----> control+C y clonar ----> (es como un control+V y se hace pulsando control+shift+V, pero pega una copia que se identifica diferente a la copia original).

Saludos.

[Democrito]

Cometí un error en una imagen.

Donde veas esto:

En realidad quise decir esto:

[diego fernando godoy rojas]

Vale gracias entendí muy bien el concepto, y ya esta arrojando resultados, pero como mencionas arriba es necesario poner un detector de estado alto debido al funcionamiento del DHT, quería saber si así esta bien conectado ? Por ultimo, de cuanto pusiste el tiempo para "sensar" los 1s y 0s del DHT22.

[Democrito]

La conexión es directa al pin TX, dentro del módulo "Binary to Serial" ya lleva el transmisor serial. Te ha de quedar así:

Entonces has de hace doble clic a ese módulo y luego doble clic de nuevo al módulo transmisor serie y modificar los tiempos como te indiqué en el post anterior. Por ejemplo, para que funcione a 115200 baudios has de dividir 25000000/115200 y te dará como parámetro el resultado = 217. Es decir, que has de sustituir el 104 por 217 si vas a usar la frecuencia de 115200 baudios. Y creo que no hará falta modificar nada más de ese módulo.

Dentro del módulo DHT22 (o DHTXX) verás un módulo llamado Cycle3. Haces doble clic ahí y verás esto:

Tiene dos temporizadores de micro-segundos (señalado en rojo). Pues has de "corregir" dentro de esos temporizadores para que te funcione a 25MHz como te indiqué en el post anterior. Lo ideal para asegurarse de que todo los cambios que estás haciendo son correctos sería que además de modificarlos, probarlos junto a un osciloscopio o analizador lógico de señales, especialmente cuando te encuentres un elemento nuevo a modificar, más que nada para asegurarte.

Te aconsejo que vayas creando aparte tu propia biblioteca adaptada a tus 25 MHz para todos los elementos temporales y así sólo tendrás que ir sustituyendo esos módulos. 

[R-Hidalgo]

Hola, 

Dejaré por acá otro bloque del DHT22, con manejo del signo y checksum,  sin SPI ni filtros adicionales, solo va al Scriptcomunicator. 

                     

[Democrito]

Hola R-Hidalgo,

He visto tu trabajo y está realmente genial y además es fácil de comprender cómo lo has ido resolviendo. Cada persona es un mundo en sí y ver cómo otros resuelven circuitos es súper didáctico porque así vemos otra manera de pensar en el que podemos aprender soluciones que de otro modo no las hubiéramos pensado.  Me ha gustado mucho "DHT22_bloque" en especial, porque en la misma ventana principal está todo lo importante, incluyendo una imagen que si estás conectado a Internet te la muestra.

Me gustaría que incluyeses este proyecto en la Biblioteca de Charli, de esta manera quien quiera usar este periférico podrá elegir. Si yo tuviera que usar un periférico que yo no he diseñado utilizaría el que mejor llego a comprender, y tener varias versiones ayuda a que esto sea posible.

Enhorabuena por tan buen trabajo! 

Muchísimas gracias por darlo a conocer.

[Democrito]

Donde digo "porque en la misma ventana principal está todo lo importante" me refería a la información que contiene, todo bien detallado.

[Democrito]

Te voy a comentar una curiosidad que tuve al finalizar este proyecto. El DHT11 (que es la versión anterior) en teoría no se puede poner un decimal, pero se me ocurrió una idea de cómo una medida entera se le podía extraer decimales. Cuando hacemos mediciones (sea la que sea) el último dígito suele "bailar" entre dos número; si medimos el tiempo de ese "baile" se le puede extraer el decimal (lo que queda a la derecha del punto).

Para entender esto imagina que tomamos una medida, la que sea, pongamos que pone "22" y el último dígito está "bailando" entre 22 y 23. Si dura el mismo tiempo en esos cambios significa que es 22.5. Y si por ejemplo muchas veces pone 23 y pocas veces 22, significa que está más cerca del 23 ese decimal, por ejemplo 22.8.

Estuve haciendo pequeñas pruebas (haciendo media aritmética) pero no lo concluí porque al poco ya me concentré en otro proyecto.

[charli va]

Muchas gracias por compartir!

Como dice Demócrito si puedes añadirlo al excel sería genial, dentro de poco no hará falta y psaremos a utilizar otra cosa pero de momento está valiendo para recopilar ahí la información.

Gracias de nuevo!

--

Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/4200b5dd-0678-4c99-bea2-acbd4685723dn%40googlegroups.com.

[R-Hidalgo]

Gracias a ustedes!  

Ya fue subido a  Biblioteca de Charli.

Sobre la cifra bailando entre el nivel alto y el nivel bajo, me parece que solo hay que contar. Aunque hay que definir dos cosas, el tiempo de muestreo, tamaño del contador o el intervalo. Si la cifra sale fuera de los niveles alto o bajo antes del tiempo de muestreo hay que reiniciar todo.

Saludos,

[Obijuan]

¡Muchísimas gracias por compartir! Acabo de bajar el diseño para verlo y está muy bien documentado y se entiende muy bien. ¡Muchísimas gracias! 😀️

Saludos, Obijuan

[gustavo arriaga]

Hola hidalgo te interesaria un grupo de watsat participar para los que quedamos atrasados con obijuan y las fpga ayudarnos a avanzar

--

Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/2222e22a-6597-4734-85da-3d9944413342n%40googlegroups.com.