Con la sana intención de enfocarnos decidimos hace unas semanas terminar uno de los prototipos, fabricar algunas unidades, atender una cierta demanda que tenemos y pasar al siguiente.
Mirando el orden de los artículos del blog se ve claro el desenfoque, es lo que nos pasa a los apasionados, empezamos las cosas y, antes de acabarlas ya nos hemos enganchado a una nueva.
El producto elegido es el bMotesETH, sensor de temperatura y humedad por Ethernet. Hemos migrado el sketch a Arduino 1.0, no sin pocos problemas, relacionados con webduino, el tamaño de la memoria y hemos hecho algunas mejoras. El FW es ahora mucho más maduro, está mejor organizado y mucho más optimizado.
Hemos rediseñado la placa, hemos hecho la caja, hemos empezado con los manuales, hemos cambiado un poco el JSON que intercambia información entre máquinas, hemos adaptado el script de Python para Nagios y hemos hecho las pruebas de tenerlos algunos días funcionando en diversos escenarios de temperatura y humedad, de hecho uno de la versión anterior lleva más de 6 meses.
Como no nos gustó en la versión anterior que el sensor fuera externo porque daba una imagen mucho menos compacta del producto buscamos un contenedor con una amplia rejilla para ponerlo interno. El caso es que después de un tiempo de pruebas hemos verificado un problema que habíamos intuido y del que ya hemos hablado. La contaminación de la lectura del sensor provocada por el calor desprendido por la placa. No es despreciable, la placa incorpora un chip Wiznet que se calienta unos 30 ºC por encima de la temperatura ambiente.
Intentando segmentar el problema estos han sido los pasos:
- ¿Se contamina la lectura por el calor desprendido por el propio sensor? Hay una nota del fabricante del sensor DHT1x que indica que si se toman temperaturas a intervalos menores que un definido (6 segundos creo) la propia temperatura del sensor puede afectar a la medida. Verificamos que no es el caso, la temperatura no se lee a intervalos regulares, la lectura se hace bajo demanda cada vez que se solicita, este no es el problema.
- ¿Quizás el hecho de estar alimentado constantemente provoque la contaminación de la lectura? Hemos modificado el sketch para que el sensor no esté alimentado, antes de cada lectura se activa la alimentación, se hace la lectura y se interrumpe de nuevo, sin cambios aparentes
- ¿Es un problema de la tensión de alimentación del sensor? Hemos alimentado el sensor a 3,3V en lugar de los 5V, sin cambios aparentes.
- ¿La contaminación de temperatura viene provocada por la elevación de la temperatura de la placa que lo soporta? Hemos separado el sensor de la placa que lo soporta dejando un espacio de aire para aislar, sin cambios. Hemos incorporado un aislante térmico entre la placa con el Wiznet y la que soporta el sensor, sin cambios. Hemos incorporado una placa de aluminio antes del aislante para que refleje las radiaciones infrarrojas, sin cambios.
- ¿Quizás el problema es que como el chip que se calienta no tiene disipador se calientan los componentes y se transmite la temperatura a través de las placas y la caja? Hemos puesto un disipador en el chip, y tampoco hemos observado mejoras aparentes.
Lo siguiente es intentar averiguar como han resuelto situaciones similares en productos parecidos, en la información que encuentro (ahhh pillines) lo que veo es que los fabricantes se han limitado a estimar el incremento de temperatura y restarlo de la lectura del sensor. No descarto eso como solución para un sensor compacto, pero no puedes adjuntar el certificado de calibración de un sensor y después resolver el problema de una forma tan grosera.
Finalmente, la prueba que si que funciona es la de mover el aire, si el sensor se coloca de forma que una corriente mueva el aire la temperatura es correcta, está claro, la elevación de temperatura del chip Ethernet provoca bolsas de aire más caliente, si el aire no se renueva la temperatura sube.
La solución más obvia es poner el sensor fuera de la caja, como el sensor que estamos utilizando tiene un problema de formato he probado un DHT11 (de los chinos). El formato es correcto, el color es feo, la resolución de temperatura es muy mala (1ºC) y la precisión no muy buena, eso si, el precio inmejorable.
Finalmente he pedido unos DHT22 (también conocidos como AM2302) la resolución es mucho mejor, la precisión también y el precio es intermedio.
Resulta curioso las pocas opciones de sensor de temperatura y humedad que hay en el mercado, provocado sin duda porque la humedad se sensa con corrientes alternas de un cierto voltaje y, para conseguir una cierta precisión, hay que calibrarlos individualmente. En este momento estoy comparando las lecturas del DHT22 con las del Sensirión y son bastante precisos, eso sí el precio del DHT22 es más o menos la mitad.
La solución final:
Ponemos un conector para el sensor externo, por simplicidad utilizaremos un RJ11 de 6 pines. aprovecharemos para cambiar el sketch y las prestaciones, de forma que podamos instalar el DHT22, sensores 1wire, analógicos, etc. De lo perdido saca lo que puedas…
Con la sana intención de enfocarnos decidimos hace unas semanas terminar uno de los prototipos, fabricar algunas unidades, atender una cierta demanda que tenemos y pasar al siguiente.
Mirando el orden de los artículos del blog se ve claro el desenfoque, es lo que nos pasa a los apasionados, empezamos las cosas y, antes de acabarlas ya nos hemos enganchado a una nueva.
El producto elegido es el bMotesETH, sensor de temperatura y humedad por Ethernet. Hemos migrado el sketch a Arduino 1.0, no sin pocos problemas, relacionados con webduino, el tamaño de la memoria y hemos hecho algunas mejoras. El FW es ahora mucho más maduro, está mejor organizado y mucho más optimizado.
Hemos rediseñado la placa, hemos hecho la caja, hemos empezado con los manuales, hemos cambiado un poco el JSON que intercambia información entre máquinas, hemos adaptado el script de Python para Nagios y hemos hecho las pruebas de tenerlos algunos días funcionando en diversos escenarios de temperatura y humedad, de hecho uno de la versión anterior lleva más de 6 meses.
Como no nos gustó en la versión anterior que el sensor fuera externo porque daba una imagen mucho menos compacta del producto buscamos un contenedor con una amplia rejilla para ponerlo interno. El caso es que después de un tiempo de pruebas hemos verificado un problema que habíamos intuido y del que ya hemos hablado. La contaminación de la lectura del sensor provocada por el calor desprendido por la placa. No es despreciable, la placa incorpora un chip Wiznet que se calienta unos 30 ºC por encima de la temperatura ambiente.
Intentando segmentar el problema estos han sido los pasos:
- ¿Se contamina la lectura por el calor desprendido por el propio sensor? Hay una nota del fabricante del sensor DHT1x que indica que si se toman temperaturas a intervalos menores que un definido (6 segundos creo) la propia temperatura del sensor puede afectar a la medida. Verificamos que no es el caso, la temperatura no se lee a intervalos regulares, la lectura se hace bajo demanda cada vez que se solicita, este no es el problema.
- ¿Quizás el hecho de estar alimentado constantemente provoque la contaminación de la lectura? Hemos modificado el sketch para que el sensor no esté alimentado, antes de cada lectura se activa la alimentación, se hace la lectura y se interrumpe de nuevo, sin cambios aparentes
- ¿Es un problema de la tensión de alimentación del sensor? Hemos alimentado el sensor a 3,3V en lugar de los 5V, sin cambios aparentes.
- ¿La contaminación de temperatura viene provocada por la elevación de la temperatura de la placa que lo soporta? Hemos separado el sensor de la placa que lo soporta dejando un espacio de aire para aislar, sin cambios. Hemos incorporado un aislante térmico entre la placa con el Wiznet y la que soporta el sensor, sin cambios. Hemos incorporado una placa de aluminio antes del aislante para que refleje las radiaciones infrarrojas, sin cambios.
- ¿Quizás el problema es que como el chip que se calienta no tiene disipador se calientan los componentes y se transmite la temperatura a través de las placas y la caja? Hemos puesto un disipador en el chip, y tampoco hemos observado mejoras aparentes.
Lo siguiente es intentar averiguar como han resuelto situaciones similares en productos parecidos, en la información que encuentro (ahhh pillines) lo que veo es que los fabricantes se han limitado a estimar el incremento de temperatura y restarlo de la lectura del sensor. No descarto eso como solución para un sensor compacto, pero no puedes adjuntar el certificado de calibración de un sensor y después resolver el problema de una forma tan grosera.
Finalmente, la prueba que si que funciona es la de mover el aire, si el sensor se coloca de forma que una corriente mueva el aire la temperatura es correcta, está claro, la elevación de temperatura del chip Ethernet provoca bolsas de aire más caliente, si el aire no se renueva la temperatura sube.
La solución más obvia es poner el sensor fuera de la caja, como el sensor que estamos utilizando tiene un problema de formato he probado un DHT11 (de los chinos). El formato es correcto, el color es feo, la resolución de temperatura es muy mala (1ºC) y la precisión no muy buena, eso si, el precio inmejorable.
Finalmente he pedido unos DHT22 (también conocidos como AM2302) la resolución es mucho mejor, la precisión también y el precio es intermedio.
Resulta curioso las pocas opciones de sensor de temperatura y humedad que hay en el mercado, provocado sin duda porque la humedad se sensa con corrientes alternas de un cierto voltaje y, para conseguir una cierta precisión, hay que calibrarlos individualmente. En este momento estoy comparando las lecturas del DHT22 con las del Sensirión y son bastante precisos, eso sí el precio del DHT22 es más o menos la mitad.
La solución final:
Ponemos un conector para el sensor externo, por simplicidad utilizaremos un RJ11 de 6 pines. aprovecharemos para cambiar el sketch y las prestaciones, de forma que podamos instalar el DHT22, sensores 1wire, analógicos, etc. De lo perdido saca lo que puedas…
Pingback: El estado de las cosas | Zigbee labs