Acuariofilia Madrid

(19-02-2015, 07:11 PM)Antonio Castro escribió: [ -> ]Las modificaciones que he pensado hacer se asociarían a un nuevo parametro cuyo valor permite varios modos de funcionamiento del dimmer:

MOD_DIMM_AUTO=0, // Automatico gobernado por fotoperiodo (modo normal como ahora)
MOD_DIMM_OFF=1, // Luces siempre apagadas.
MOD_DIMM_NOCT=2, // Luces siempre en modo nocturno.
MOD_DIMM_DARK=3, // Luces siempre en modo poca luz
MOD_DIMM_NOON=4 // Luces siempre en modo mediodia

Las intensidades máximas de la luz diurna, crepuscular y nocturna ya se pueden modificar el la versión actual por parámetro.

Lo que se podría hacer seria añadir algunos modos más, pero todo lo relativo a trabajar con lapsos de tiempo que tengan relación con el fotoperiodo son más fáciles de imaginar que de implementar.

Vale, eso resolvería el encender la luz fuera de horario; con los modos de poca luz y luz máxima debería valer, aunque poder modificar en tiempo real la intensidad de luz para uno de esos modos manuales pulsando dos botones sería para nota.

Lo que no veo es como con estos modos se podría automatizar la hora de corte de la luz de luna. Yo lo vería tan sencillo como incluir un nuevo parámetro de fin de luz de luna, donde se le establezca la hora. No es necesario ajustarlo de forma relativa al fotoperíodo, aunque por coherencia con el funcionamiento del software tal vez debería ser la forma de hacerlo. Se establecen la duración del fotoperíodo, duración del crepúsculo y momento del zenit como hasta ahora y un cuarto parámetro de duración de luz nocturna. Podría ser más coherente con la aplicación que establecer una hora de apagado aunque tal vez más complicado de integrar... pero para complicado el control de fotoperíodo que has hecho, al lado esto es una migaja

(19-02-2015, 07:11 PM)Antonio Castro escribió: [ -> ]Te comento lo que estoy mirando últimamente:
Últimamente he estado mirando un cacharrito muy baratito que permite conexión WiFi. se trata del ESP8266. Parece que lo han pensado para que sea muy fácil de usar ocultando el el procesador interno todos los detalles de la gestión del TCP. En la práctica se puede implementar un pseudo-servidor-web con muchas limitaciones sobre un servicio web clásico. Yo no veo la forma de poder hacer conexiones autenticadas para proteger el acceso a ese pseudo-servidor-web, pero es tan barato que creoi que podría interesar a mucha gente.

Lo ideal sería que el cacharrito wifi conecte arduino a la red de casa, de forma que así puedan enviarsele mensajes TCP directamente... ya sea a través de otro dispositivo conectado a la misma red local o desde remoto a través de la ip pública. Si se puede evitar que se le manden señales wifi directas y no a través de la red a la que debe conectarse, yo creo que con la capa física y lógica del router sería protección suficiente para un sistema de control de acuario. Ni idea si las librerías del dispositivo permiten eso.


Entonces Antonio me pones en un dilema. Ya estás trabajando en la nueva versión de CAO que tiene integradas gran parte de las mejoras que yo tenía pensadas. Me pones en el dilema de si merece la pena programar yo para una versión que será obsoleta algo que tu ya estás programando también para la nueva versión... Siendo así descarto implementar una solución trabajada y elegante, dependiendo de qué plazos tengas estimados para lanzar la nueva versión creo que directamente ñapearé el código actual para incluir las funcionalidades más imprescindibles que quiero.

(19-02-2015, 07:38 PM)Agamenon escribió: [ -> ][...]
Vale, eso resolvería el encender la luz fuera de horario; con los modos de poca luz y luz máxima debería valer, aunque poder modificar en tiempo real la intensidad de luz para uno de esos modos manuales pulsando dos botones sería para nota.

Todo debería poderse manejar a través del interfaz.

Ahora mismo el dimmer es el que gobierna los distintos canales LEDs.
Se podría añadir controles para ajustar la luminosidad incrementado o decrementando el valor final obtenido por el dimmer de forma individual para cada canal. Por defecto la corrección des canal estaría a cero y podría ajustarse para tomar valores positivos o negativos. Con este enfoque no tendría mucho sentido hacer permanentes estos ajustes porque el fotoperiodo quedaría desvirtuado. Si tu incrementas la luz blanca en 20 unidades de forma permanente en ese canal tendrías algo de luz blanca por la noche.

Lo que tendría algo más de sentido es que se pudiera pasar del modo automático gobernado por fotoperiodod a un modo manual, que podría iniciarse siempre con los valores actuales entregados por el dimmer, pero que interactivamente se puedan ajustar el valor de cada canal y dejar los valores fijos de cada canal según nos interese. Una vez ajustado quedaría fijo hasta que se decida volver al modo automático gobernado por fotoperiodo. Yo lo que tengo diseñado son colecciones de valores fijos para cada canal y de hacer lo que sugiero, quizás no harían falta ya que podemos poner las luces exactamente con el tono y la intensidad deseada controlando cada canal de forma individual. No sé cual de estos dos enfoque sería mejor, auque tampoco son excluyentes.

(19-02-2015, 07:38 PM)Agamenon escribió: [ -> ]Lo que no veo es como con estos modos se podría automatizar la hora de corte de la luz de luna. Yo lo vería tan sencillo como incluir un nuevo parámetro de fin de luz de luna, donde se le establezca la hora. No es necesario ajustarlo de forma relativa al fotoperíodo, aunque por coherencia con el funcionamiento del software tal vez debería ser la forma de hacerlo. Se establecen la duración del fotoperíodo, duración del crepúsculo y momento del zenit como hasta ahora y un cuarto parámetro de duración de luz nocturna. Podría ser más coherente con la aplicación que establecer una hora de apagado aunque tal vez más complicado de integrar... pero para complicado el control de fotoperíodo que has hecho, al lado esto es una migaja

[...]

En efecto, es más coherente hacerlo en función del fotoperiodo. Se puede hacer, pero me temo que no es algo trivial. Cuando hablamos de fotoperiodo hablamos de un tipo de datos con unas reglas artiméticas especiales y un poco puñeteras.

(19-02-2015, 07:38 PM)Agamenon escribió: [ -> ]Lo ideal sería que el cacharrito wifi conecte arduino a la red de casa, de forma que así puedan enviarsele mensajes TCP directamente... ya sea a través de otro dispositivo conectado a la misma red local o desde remoto a través de la ip pública. Si se puede evitar que se le manden señales wifi directas y no a través de la red a la que debe conectarse, yo creo que con la capa física y lógica del router sería protección suficiente para un sistema de control de acuario. Ni idea si las librerías del dispositivo permiten eso.

ESP8266 detectará las redes WiFi y en el código le pones el nombre de tu WiFi y tu clave de acceso. La accesibilidad desde el exterior necesitaría o bien que tu proveedor de acceso te conceda una IP fija (lo cual tiene un precio superior), o bien usar un servicio No-IP. Para usarlo desde casa no parece que exista problema especial de vulnerabilidad, pero para usarlo desde Internet, sí por las razones que ya te expliqué.

(19-02-2015, 07:38 PM)Agamenon escribió: [ -> ]Entonces Antonio me pones en un dilema. Ya estás trabajando en la nueva versión de CAO que tiene integradas gran parte de las mejoras que yo tenía pensadas. Me pones en el dilema de si merece la pena programar yo para una versión que será obsoleta algo que tu ya estás programando también para la nueva versión... Siendo así descarto implementar una solución trabajada y elegante, dependiendo de qué plazos tengas estimados para lanzar la nueva versión creo que directamente ñapearé el código actual para incluir las funcionalidades más imprescindibles que quiero.

Si quieres puedes mandarme por privado las cosas que has estado probando y te comento si las puedo integrar en lo que yo llevo hecho. No te puedo dar una fecha. Me gustaría tener una beta para mediados de Marzo o Abril, pero como se me meta entre ceja y ceja algún tema atractivo, me retrasaré.

Hay partes como el dimmer que son delicadas. Otras partes no lo son tanto y hacer lago trabajado y elegante no tendría porqué ser un problema porque la adaptación del software a la nueva versión podría ser sencilla.

Si te apetece programar una solución trabajada y elegante, dime que tipo de cosas pretendes hacer y yo te comentaré las posibles incompatibilidades que pueden surgir con la nueva versión. Incluso te podría pasar el módulo nuevo que necesites si eso tuviera sentido claro. Todo es cuestión de hablarlo.

(19-02-2015, 09:59 PM)Antonio Castro escribió: [ -> ]Si te apetece programar una solución trabajada y elegante, dime que tipo de cosas pretendes hacer y yo te comentaré las posibles incompatibilidades que pueden surgir con la nueva versión. Incluso te podría pasar el módulo nuevo que necesites si eso tuviera sentido claro. Todo es cuestión de hablarlo.

Aún no me he metido con el código, ando escaso de tiempo y por ahora estoy dedicando todo a la electrónica y el bricolaje. Una vez ponga todo el sistema funcionando de forma estable con la versión actual de CAO (aunque tenga que seguir usando programadores horarios analógicos para el CO2 por ejemplo) me meteré con el código.

Mi idea inicial era directamente seguir la filosofía de tu software y programar desde el menú la elección de horario de los pines digitales para activar/desactivar relés. Así como incluir el seteo de la duración de luz nocturna y el encendido fuera de horario. Pero como me has dicho que ya lo estás preparando para la nueva versión de CAO, tal vez reinventar la rueda y hacer lo mismo dos veces no tenga sentido, y directamente para mi solución personal y rápida me puedo programar mi configuración en el software sin hacerla configurable desde interfaz (que es lo que a priori tendría mayor trabajo creo yo).

Respecto a lo de acceder a un dispositivo wifi desde internet, los servicios no-ip funcionan perfectamente. He usado dyndns, pero cambiaron la política y sin pagar el servicio era muy malo. Actualmente yo uso http://freedns.no-ip.com que funciona perfectamente. Únicamente tienes que reactivar el servicio una vez al mes, pero siempre de forma gratuita. Cualquier router actual tiene el sincronizado automático de la ip con los servicios no-ip. Yo lo uso por ejemplo para poder conectarme de forma remota al equipo de mi casa desde cualquier sitio. También lo he usado para conectarme a dispositivos concretos fijando el puerto e ip fijos en el router.

(20-02-2015, 01:35 PM)Agamenon escribió: [ -> ][...]
tal vez reinventar la rueda y hacer lo mismo dos veces no tenga sentido, y directamente para mi solución personal y rápida me puedo programar mi configuración en el software sin hacerla configurable desde interfaz (que es lo que a priori tendría mayor trabajo creo yo).
[...]

No necesariamente. Según podrá comprobar en "Cao1_Parm.h"

Los parámetros del sistema van numerados 0, 1, 2, ...
Se usa un tipo enumerado para mejorar la legibilidad del programa.



Y definimos una serie de características de los parametros que nunca van a variar y las guardamos en la PROGMEM.

Antonio, pondré hoy a funcionar esto ya, he terminado con el bricolaje y la circuitería. Pero me surge una duda. Estaré espeso y no lo encuentro, pero no se podía definir un pin determinado que active un relé como decrementador o incrementador de un parámetro?? No encuentro donde se define eso.

Por lo que había leído en este hilo en teoría se podía coger uno de los pines definidos para relés (por ejemplo el de 220v del calentador), y definir que sea decrementador de la temperatura, de forma que cuando se pase de la temperatura definida como alta se apague (en caso de mis relés poner a HIGH). Obviamente el calentador tiene control de temperatura propio, es un jager, pero mete muchas oscilaciones y mi idea era fijar un valor máximo de temperatura detectada en la cuál el calentador se apague (aunque no haya saltado el termostato incluido en el mismo).

Pero no encuentro el sitio donde definir ese pin como decrementador de la temperatura del acuario y que decremente poniendo el valor HIGH. Creía que se podía hacer en CAO.

Otra cosa. He terminado de montar la pantalla y he probado el dimer de CAO con TIP141. Y el problema es que no consigo que los leds se enciendan suavemente. Necesitan bastante voltaje para empezar a dar luz al mínimo. De forma que si se establecen 45 minutos de amanecer por ejemplo, hasta el minuto 30 del mismo no empiezan a lucir... y luego claro el aumento de intensidad es muy rápido. La solución "chapucera" que he hecho es configurar hora y media de amanecer y de anocher, de forma que así realmente están unos 45 minutos amaneciendo. Pero hay algún sitio donde tengas definida la intensidad inicial o la función de dimeo siempre empieza en 0 y va progresivo hasta los 255 o el máximo fijado? Me pondré a hacer pruebas, pero creo que mi pantalla hasta que no le metes unos 130 o así de pwm no se ve luz ninguna en los leds (powerleds de 3w).

Un saludo!



EDITO: he encontrado donde está en el código la solución a la primera parte (que activar un pin sea LOW en vez de HIGH) y hay que modificarlo a mano.

Lo voy a definir como constante en el cao1_1.h:


En el Cao1_Sensor.cpp sustituyo las líneas 388 a 408 por:

En el fichero incluyo el CAO1_1.h.

Creo que el ser configurable facilitará que la gente pueda usar ambos tipos de relés con facilidad. Los activos a alta y los activos a baja.

(21-02-2015, 08:51 PM)Agamenon escribió: [ -> ]Antonio, pondré hoy a funcionar esto ya, he terminado con el bricolaje y la circuitería. Pero me surge una duda. Estaré espeso y no lo encuentro, pero no se podía definir un pin determinado que active un relé como decrementador o incrementador de un parámetro?? No encuentro donde se define eso.

Cuando se inicializa un sensor dentro del procedimiento setup(), estás haciendo eso. Por ejemplo al inicializar el sensor de temperatura del acuario.

SensTempAcua.Ini(EP_MIN_TMP_ACU, Pin_ReleCalefAcua, Pin_ReleRefrigAcua, false, false, GetTempAcu, 1, StrUnitSensor, true);

La función Ini() de un sensor está declarada de la siguiente forma:

void Cao1_Sensor::Ini( int PosFirstParm, int PinIncr, int PinDecr, boolean DoIncreaseDefault, boolean DoDecreaseDefault, int (* FuncRead)(), int Dec, char *StrUnit, boolean Ok){

Puedes ver que estás comunicando el pin para incrementar el parámetro que mide el sensor (temperatura por ejemplo) y el pin para decrementar ese mismo parámetro. En el primer caso el pin activaría el relé para activar un ventilador, y en el segundo un calefactor. Si el pin viene a cero, significara que no conectaremos ningún relé. Por ejemplo calentar los LEDs es una cosa que nunca nos va a interesar.

Dado que un sensor puede entregar la información de muchas maneras diferentes dependiendo de su diseño hardware lo que haremos es pasr el puntero a una función de lectura del sensor implementada por nosotros y que devolverá un valor entero. Dentro de esa función puedes hacer lectura de pines analógicos, o lecuras de un dispositivo I2C, o lecturas que usen otros protocolos diferentes. De esa forma nos garantizamos el uso de cualquier sensor.

(21-02-2015, 08:51 PM)Agamenon escribió: [ -> ]Por lo que había leído en este hilo en teoría se podía coger uno de los pines definidos para relés (por ejemplo el de 220v del calentador), y definir que sea decrementador de la temperatura, de forma que cuando se pase de la temperatura definida como alta se apague (en caso de mis relés poner a HIGH). Obviamente el calentador tiene control de temperatura propio, es un jager, pero mete muchas oscilaciones y mi idea era fijar un valor máximo de temperatura detectada en la cuál el calentador se apague (aunque no haya saltado el termostato incluido en el mismo).


Pero no encuentro el sitio donde definir ese pin como decrementador de la temperatura del acuario y que decremente poniendo el valor HIGH. Creía que se podía hacer en CAO.

Una vez que has inicializado el sensor este funcionará con arreglo a los parámetros definidos en la EEPROM para ese sensor y que se puede modificar por menú.

Para el sensor de temperatura de los LEDS tienes: EP_LOW_TMP_LED, EP_HGH_TMP_LED, EP_MAX_TMP_LED, EP_HST_TMP_LED, EP_ALA_TMP_LED, EP_ENA_TMP_LED.
Para el sensor de temperatura del acuario tienes: EP_LOW_TMP_ACU, EP_HGH_TMP_ACU, EP_MAX_TMP_ACU, EP_HST_TMP_ACU, EP_ALA_TMP_ACU, EP_ENA_TMP_ACU.
Para el sensor de PH tienes: EP_LOW_PH, EP_HGH_PH, EP_MAX_PH, EP_HST_PH, EP_ALA_PH, EP_ENA_PH

Me refiero a que esos valores que se guardan en esos parámetros en EEPROM, determinan cuando salta la alarma, y cuando se activan los relés decrementadores e incrementadores conectados a los pines que hemos definido en el sensor.

(21-02-2015, 08:51 PM)Agamenon escribió: [ -> ]Otra cosa. He terminado de montar la pantalla y he probado el dimer de CAO con TIP141. Y el problema es que no consigo que los leds se enciendan suavemente. Necesitan bastante voltaje para empezar a dar luz al mínimo. De forma que si se establecen 45 minutos de amanecer por ejemplo, hasta el minuto 30 del mismo no empiezan a lucir... y luego claro el aumento de intensidad es muy rápido. La solución "chapucera" que he hecho es configurar hora y media de amanecer y de anocher, de forma que así realmente están unos 45 minutos amaneciendo. Pero hay algún sitio donde tengas definida la intensidad inicial o la función de dimeo siempre empieza en 0 y va progresivo hasta los 255 o el máximo fijado? Me pondré a hacer pruebas, pero creo que mi pantalla hasta que no le metes unos 130 o así de pwm no se ve luz ninguna en los leds (powerleds de 3w).

Un saludo!

Si mandas un analogWrite a un pin que no admite PWM creo que se comporta de una manera extraña que podría encajar con lo que dices.

Si el dimmeo está funcionando y la intensidad no parece que sea progresiva puede ser que en el dimmer no estés usando la funcion Conv_Led_PWM_Exp2((int i))
Un valor entre 0..255 será transformado en otro dentro del mismo rango, pero con un valor proporcional al cuadrado del valor pasado como argumento.

También podría existir algún motivo hardware por un uso extraño e inadecuado. Por ejemplo, el dimeo funciona con pulsos de anchura variable pero voltaje constante. No se pueden usar condensadores ni a la salida de los impulsos generados por el TIP ni a la entrada de la señal del TIP.

Para descartar problemas de hardware, puedes probar el efecto de la salida digital PWM sobre un led directamente, sin usar la amplificacion del TIP. bastará con conectar un LED en serie con una resistencia de 1K ohm a la salida PWM de Arduino.

Eso lo puedes hacerlo en una protoboard. Es decir, usar un pequeño prototipo para cerciorarte de que la partes que deseas probar deberían funcionar según lo esperado.
Si luego las cosas no funcionan como en el prototipo ya puedes descartar una serie de fallos.

A mí el hardware me resulta un tanto puñetero, y procuro avanzar despacio y pisando sobre seguro.

(21-02-2015, 10:08 PM)Antonio Castro escribió: [ -> ]Si mandas un analogWrite a un pin que no admite PWM creo que se comporta de una manera extraña que podría encajar con lo que dices.

Si el dimmeo está funcionando y la intensidad no parece que sea progresiva puede ser que en el dimmer no estés usando la funcion Conv_Led_PWM_Exp2((int i))
Un valor entre 0..255 será transformado en otro dentro del mismo rango, pero con un valor proporcional al cuadrado del valor pasado como argumento.

También podría existir algún motivo hardware por un uso extraño e inadecuado. Por ejemplo, el dimeo funciona con pulsos de anchura variable pero voltaje constante. No se pueden usar condensadores ni a la salida de los impulsos generados por el TIP ni a la entrada de la señal del TIP.

Para descartar problemas de hardware, puedes probar el efecto de la salida digital PWM sobre un led directamente, sin usar la amplificacion del TIP. bastará con conectar un LED en serie con una resistencia de 1K ohm a la salida PWM de Arduino.

Estoy usando los pines definidos por defecto en CAO para el dimeo, tengo un arduino mega. Tampoco he tocado nada de código en CAO para el dimeo, así que lo que hace, es lo que está programado por defecto.

Con un led de los de toda la vida y su resistencia de 220 he probado el dimeo con la función fade por defecto y es progresivo. Con la pantalla no he podido hacer muchas más pruebas porque llevan ya unos cuantos días las plantas con otra pantalla secundaria que tengo mucho menos potente y las plantas rojas ya estoy viendo que se empiezan a resentir... es el problema que tengo, mantengo un high tech con algunas plantas difíciles, no puedo hacer excesivas pruebas con la pantalla desmontada. Estamos hablando que estoy usando unos 70lm por litro en powerleds. A vatio/litro, como si de fluorescentes se tratase.

No obstante ya para el fin de semana que viene volveré a hacer pruebas. Esta semana se queda ya como está. Al menos se apaga y se enciende jeje según el horario programado jeje.


El resto que me has citado creo que no has leído mi edit. Ya encontré y solventé eso en el código.

Son cuestiones de diseño discutibles. A mí no me parece que esa modificación sea buena idea. La mayoría de los relés tienen dos salidas con lógica invertida y tu puedes conectar en los bornes adecuados tu circuito de potencia para que una bombilla se encienda con un relé en reposo o con un relé activo dependiendo de esa conexión hardware.

Hacer algo, ya sea decrementar temperatura o incrementar temperatura, es muy distinto a no hacer nada.

Hay que asegurarse de que que un aparato que no funcione no haga nada salvo para la refrigeración de los LEDs que en caso de no poder medir su temperatura mas vale que la dejemos permanentemente conectada por si acaso.

Existe un procedimiento SafeMode(), implementado en el programa principal, que lo que hace es colocar todas las salidas en el modo menos peligroso posible para el acuario. Se supone que cada una de las salidas, mantenidas por tiempo indefinido en ese estado, no resultan tan peligrosas como en el estado contrario.

Vigila que SafeMode() se comporte como tú quieres.

(21-02-2015, 10:51 PM)Antonio Castro escribió: [ -> ]Son cuestiones de diseño discutibles. A mí no me parece que esa modificación sea buena idea. La mayoría de los relés tienen dos salidas con lógica invertida y tu puedes conectar en los bornes adecuados tu circuito de potencia para que una bombilla se encienda con un relé en reposo o con un relé activo dependiendo de esa conexión hardware.

Hacer algo, ya sea decrementar temperatura o incrementar temperatura, es muy distinto a no hacer nada.

Hay que asegurarse de que que un aparato que no funcione no haga nada salvo para la refrigeración de los LEDs que en caso de no poder medir su temperatura mas vale que la dejemos permanentemente conectada por si acaso.

Existe un procedimiento SafeMode(), implementado en el programa principal, que lo que hace es colocar todas las salidas en el modo menos peligroso posible para el acuario. Se supone que cada una de las salidas, mantenidas por tiempo indefinido en ese estado, no resultan tan peligrosas como en el estado contrario.

Vigila que SafeMode() se comporte como tú quieres.

Ok, tienes razón que es más lógico activar algo poniéndolo a 1 que a 0. Veré si mis relés permiten la lógica inversa, en la documentación dicen que se activan a baja.

En otro orden de cosas, he actualizado el IDE a la 1.6 que ya es final y está pública. Cao1_Lcd20x4.cpp no compila. Esta tarde si encuentro un rato me pongo a mirar qué pasa.

Cuando tenga tiempo intentaré compilarlo con IDE 1.6. Gracias por el aviso.
Se está quejando de que ese tipo no está definido cosa que suele solucionarse con un typedef pero buscando el motivo de por qué en el nuevo IDE no quieren seguir usando esa definición, he encontrado esto. deprecated typedef avr-libc v1.8.0

Veo que es un error que está afectando a mucha gente pero no parece complicado de solucionar. Ya se verá.

He visto a bastante gente desanimarse con el C++. No te cortes preguntando, me encanta poder explicar los entresijos de mi código a alguien capaz de entenderlo. Soy todo oidos.

(22-02-2015, 02:11 PM)Antonio Castro escribió: [ -> ]Cuando tenga tiempo intentaré compilarlo con IDE 1.6. Gracias por el aviso.
Se está quejando de que ese tipo no está definido cosa que suele solucionarse con un typedef pero buscando el motivo de por qué en el nuevo IDE no quieren seguir usando esa definición, he encontrado esto. deprecated typedef avr-libc v1.8.0

Veo que es un error que está afectando a mucha gente pero no parece complicado de solucionar. Ya se verá.

He visto a bastante gente desanimarse con el C++. No te cortes preguntando, me encanta poder explicar los entresijos de mi código a alguien capaz de entenderlo. Soy todo oidos.

Probé ayer en un momento a meter el typedef char PROGMEM prog_char; en el .h del Cao1_Lcd20x4 y ya compilaba ese fichero. Aunque al resto de clases le pasa lo mismo. Meter ese typedef en todas las clases es un poco coñazo, sería mejor meterlo en un sitio común digo yo. Mañana tendré un rato y echaré un vistazo.


Por cierto, ya he tenido este fin de semana el sistema montado en el acuario y funcionando. Me reitero en que el amanecer y el anochecer va a saltos, no es para nada suave, sino que da saltos visibles de iluminación. Y hasta que no está el proceso de amanecer al 60% aproximadamente no se ve luz ninguna en los leds. Puede ser que para tu montaje antonio uses unos leds que se encienden desde mucho más abajo?? los powerleds de 3w los tengo funcionando a unos 3,5v a tope, pero he visto que el mínimo voltaje para que se enciendan es 2,7 aprox. Con menos de eso no se encienden.
Midiendo con voltímetro durante el proceso de amanecer, se comprueba como poco a poco va subiendo el voltaje en los leds según se va haciendo el dimeo, pero claro, hasta llegar a los 2,7v en que empieza a haber luz ha pasado ya el 60% del tiempo del amanecer. Un dimeo que empiece desde 0v hasta el 100% del voltaje del canal en el caso de powerleds al menos puede que no sea del todo válido, sino que el 0% del dimeo debería empezar justo por debajo de esos 2,7v de encendido y comprender el rango entre los 2.7 y 3.5. O es esta explicación o algo raro está pasando en mi dimeo.


Otra cosa rara que me está dando desconfianza, el sensor de temperatura. En mi acuario tenía un sensor digital normalito, pero que funciona muy bien. Al montar CAO y el sensor de dallas he dejado el otro también funcionando, y he añadido un termómetro clásico para tener una referencia triple de la temperatura y poder testear bien las discrepancias.

Pues el sensor de dallas es con absoluta diferencia el que peor está funcionando. Me explico: tarda muchísimo en variar la temperatura, y le cuesta mucho variar hacia abajo. Entorno a 25,5 grados los 3 termómetros marcan lo mismo. Si apago el calentador un rato, puedo ver como en el termómetro digital que tenía antes empieza a bajar la temperatura a 25.4, 25.3, 25.2... y así sucesivamente mientras que en el dallas conectado al arduino solo ha bajado a 25.4. Cuando en mi termómetro digital antiguo la temperatura va por 24.2, en el dallas marca 25.1. Mirando el termómetro clásico analógico marca por la línea de los 24º.

Cuando la temperatura sube el comportamiento es al revés... el dallas está a 25.9 y el digital anterior mío va por 25.6. En el analógico se puede ver la lectura entorno a 25.5.

Qué está pasando? Tengo conectados 2 sensores dallas al mismo pin digital, uno en el acuario y otro en la pantalla. No estoy usando un cable apantallado metálico, pero si uno de 3 cables de cobre de 2,5mm, que van encapsulados en un único cable gordo con aislamiento térmico. De los que se usan Para las instalaciones eléctricas de las casas vamos.

La cuestión es que por el comportamiento observado, no me fío un pelo de dejar ahora mismo al arduino controlar la temperatura del acuario con el sensor dallas.

(23-02-2015, 12:16 PM)Agamenon escribió: [ -> ]Probé ayer en un momento a meter el typedef char PROGMEM prog_char; en el .h del Cao1_Lcd20x4 y ya compilaba ese fichero. Aunque al resto de clases le pasa lo mismo. Meter ese typedef en todas las clases es un poco coñazo, sería mejor meterlo en un sitio común digo yo. Mañana tendré un rato y echaré un vistazo.

Puedes meter el typedef en "CAO1_CONFIG.h" en incluir ese fichero en los cpp que se quejen. En efecto ,es una modificación masiva impuesta por el nuevo IDE.

(23-02-2015, 12:16 PM)Agamenon escribió: [ -> ]Por cierto, ya he tenido este fin de semana el sistema montado en el acuario y funcionando. Me reitero en que el amanecer y el anochecer va a saltos, no es para nada suave, sino que da saltos visibles de iluminación. Y hasta que no está el proceso de amanecer al 60% aproximadamente no se ve luz ninguna en los leds. Puede ser que para tu montaje antonio uses unos leds que se encienden desde mucho más abajo?? los powerleds de 3w los tengo funcionando a unos 3,5v a tope, pero he visto que el mínimo voltaje para que se enciendan es 2,7 aprox. Con menos de eso no se encienden.
Midiendo con voltímetro durante el proceso de amanecer, se comprueba como poco a poco va subiendo el voltaje en los leds según se va haciendo el dimeo, pero claro, hasta llegar a los 2,7v en que empieza a haber luz ha pasado ya el 60% del tiempo del amanecer. Un dimeo que empiece desde 0v hasta el 100% del voltaje del canal en el caso de powerleds al menos puede que no sea del todo válido, sino que el 0% del dimeo debería empezar justo por debajo de esos 2,7v de encendido y comprender el rango entre los 2.7 y 3.5. O es esta explicación o algo raro está pasando en mi dimeo.

Medir voltajes en una salida dimeada es algo que no tiene sentido. De hecho yo lo probé con mi voltímetro y no detecta voltaje alguno. La respuesta del voltímetro será indeterminada y dependerá de como esté realizado. Tus conclusiones parecen estar basadas en esas medidas y me temo que sean erróneas.

Para medir voltajes en una salida dimeada tendrías que usar un osciloscopio. Lo mismo así averiguabas que es lo que está pasando con la señal. Yo no tengo osciloscopio, pero para verificar este tipo de cosas es muy útil.

(23-02-2015, 12:16 PM)Agamenon escribió: [ -> ]Otra cosa rara que me está dando desconfianza, el sensor de temperatura. En mi acuario tenía un sensor digital normalito, pero que funciona muy bien. Al montar CAO y el sensor de dallas he dejado el otro también funcionando, y he añadido un termómetro clásico para tener una referencia triple de la temperatura y poder testear bien las discrepancias.

Pues el sensor de dallas es con absoluta diferencia el que peor está funcionando. Me explico: tarda muchísimo en variar la temperatura, y le cuesta mucho variar hacia abajo. Entorno a 25,5 grados los 3 termómetros marcan lo mismo. Si apago el calentador un rato, puedo ver como en el termómetro digital que tenía antes empieza a bajar la temperatura a 25.4, 25.3, 25.2... y así sucesivamente mientras que en el dallas conectado al arduino solo ha bajado a 25.4. Cuando en mi termómetro digital antiguo la temperatura va por 24.2, en el dallas marca 25.1. Mirando el termómetro clásico analógico marca por la línea de los 24º.

La inercia de un sensor no tiene nada que ver con su precisión. Ten en cuenta que el encapsulado plástico del sensor de Dallas puede no ser un buen conductor térmico. Eso no tiene ninguna importancia en una aplicación como la nuestra. Tardará más en coger temperatura y perderla.

Hay termoresistores caros y muy rápidos que tienen un encapsulado de cristal y un termoresistor diminuto en la punta que reacciona con mucha rapidez, pero eso no es lo importante para nosotros.

Es incluso indeseable que reaccione rápidamente. De hecho mi software ralentiza la respuesta intencionadamente para ahorrar excesivos cambios de estado en los relés y prolongar su vida útil. Un sensor muy rápido podría incluso provocar vibraciones en los relés reduciendo su vida útil en miles de veces.

Un relé se puede averiar de dos formas. 1) No se activa. 2) Permanece siempre activado. Estó último puede pasar por sobre uso. Los contactos se pueden quedar soldados por la chispa y el calefactor quedaría enchufado permanentemente haciendo subir la temperatura del acuario hasta convertir su contenido en sopa de pescado.

(23-02-2015, 12:16 PM)Agamenon escribió: [ -> ]Cuando la temperatura sube el comportamiento es al revés... el dallas está a 25.9 y el digital anterior mío va por 25.6. En el analógico se puede ver la lectura entorno a 25.5.

Qué está pasando? Tengo conectados 2 sensores dallas al mismo pin digital, uno en el acuario y otro en la pantalla. No estoy usando un cable apantallado metálico, pero si uno de 3 cables de cobre de 2,5mm, que van encapsulados en un único cable gordo con aislamiento térmico. De los que se usan Para las instalaciones eléctricas de las casas vamos.

La cuestión es que por el comportamiento observado, no me fío un pelo de dejar ahora mismo al arduino controlar la temperatura del acuario con el sensor dallas.

¿Estás alimentando los sensores dallas con alimentación parásita?
La conexión en alimentación parásita no es adecuada para usar con varios sensores ni para usar con conectores largos.

El sensor de Dallas es buenísimo.

(23-02-2015, 02:06 PM)Antonio Castro escribió: [ -> ]Medir voltajes en una salida dimeada es algo que no tiene sentido. De hecho yo lo probé con mi voltímetro y no detecta voltaje alguno. La respuesta del voltímetro será indeterminada y dependerá de como esté realizado. Tus conclusiones parecen estar basadas en esas medidas y me temo que sean erróneas.

Para medir voltajes en una salida dimeada tendrías que usar un osciloscopio. Lo mismo así averiguabas que es lo que está pasando con la señal. Yo no tengo osciloscopio, pero para verificar este tipo de cosas es muy útil.

Pues Antonio, yo mido voltaje perfectamente. De hecho si pongo el voltímetro en la clema que empalma el cable del canal que va hasta los leds antes de empezar el dimeo es 0v, y según va realizándose el dimeo veo que va aumentando progresivamente hasta llegar a los 12v de dicho canal. Vamos, que se puede medir perfectamente. Eso por qué? por lo que dices no debería ocurrir? Tengo montado el TIP exactamente como en tu documentación de CAO. Positivo de la fuente a los leds directo, y la masa pasándo a través del TIP141. Además he conectado una salida de masa de la fuente a un pin ground del arduino, no es exactamente el mismo cable de masa que va al TIP porque por montaje me resultaba más sencillo sacarlo a través de otro, pero entiendo que internamente las masas de la fuente de alimentación son la misma. El pin PWM del arduino tiene la resistencia indicada en su conexión con el TIP.

(23-02-2015, 02:06 PM)Antonio Castro escribió: [ -> ]La inercia de un sensor no tiene nada que ver con su precisión. Ten en cuenta que el encapsulado plástico del sensor de Dallas puede no ser un buen conductor térmico. Eso no tiene ninguna importancia en una aplicación como la nuestra. Tardará más en coger temperatura y perderla.

Hay termoresistores caros y muy rápidos que tienen un encapsulado de cristal y un termoresistor diminuto en la punta que reacciona con mucha rapidez, pero eso no es lo importante para nosotros.

Es incluso indeseable que reaccione rápidamente. De hecho mi software ralentiza la respuesta intencionadamente para ahorrar excesivos cambios de estado en los relés y prolongar su vida útil. Un sensor muy rápido podría incluso provocar vibraciones en los relés reduciendo su vida útil en miles de veces.

Un relé se puede averiar de dos formas. 1) No se activa. 2) Permanece siempre activado. Estó último puede pasar por sobre uso. Los contactos se pueden quedar soldados por la chispa y el calefactor quedaría enchufado permanentemente haciendo subir la temperatura del acuario hasta convertir su contenido en sopa de pescado.

¿Estás alimentando los sensores dallas con alimentación parásita?
La conexión en alimentación parásita no es adecuada para usar con varios sensores ni para usar con conectores largos.

El sensor de Dallas es buenísimo.

Los sensores van en modo normal, los 3 cables independientes... vcc, ground y data. Lo que interconecto antes de conectar al arduino son esos 3 cables independientes entre los dos sensores.

El dallas que está en el acuario tiene encapsulado metálico, no plástico, así que entiendo que la conductancia térmica debe ser buena. El dato puede estar en que ralentizas la medición de temperatura por software. Haré la prueba haciéndome un código que la lea en tiempo real, a ver si los datos entre ambos sensores cuadran más.

Tengo puesto el calentador que se active en la temperatura baja del acuario, de hecho en mi caso voy a poner que en el modo seguro sea el calentador siempre encendido ya que es un jagger de eheim y tiene termostato propio para desconectarse a la temperatura indicada. Quería que estuviese controlado por arduino precisamente para mejorar su precisión. Actualmente va metiendo oscilaciones de temperatura de más de medio grado cuando se activa y desactiva, pero lo peor es que depende de la altura de la columna de agua ya que el termostato lo tiene en la parte de arriba... detectando menor temperatura cuanto más baja está el agua del acuario (la superficie está más fría por contacto con el ambiente). Eso hace que según pasan los días de la semana y va bajando el agua, el calentador esté más conectado porque se le falsea la medición.

Mi intención era tener controlado mucho mejor el calentador mediante arduino. Estableciendo una temperatura entre la que baile lo menos posible y evidentemente sin importar la altura de la columna de agua (tengo el acuario destapado y como me vaya una semana y no rellene me baja casi 20 litros el nivel, el irme 2 semanas por ejemplo sí que puede provocar una sopa de pescado por medición errónea del termostato del calentador). Como la temperatura baja y sube de forma gradual, el relé del calentador no debería activarse/desactivarse más de 4 o 5 veces a la hora. No creo que ese uso dañase el relé no?


Y ya que estoy hablando del software hay un punto que no se como evitar: el pitidito. Quiero que el buzzer suene cuando hay una alarma grave (temperatura por encima o por debajo del máximo por ejemplo), pero en ningún caso más. Ni cuando pulso botones, ni mucho menos cada vez que cambia el estado de un relé. Es eso posible de configurar o hay que tocarlo en el código? Tengo todo el día eso pitando cada vez que la temperatura del agua baja o sube del LOW y por tanto se activa o desactiva el relé del calentador.

(23-02-2015, 02:49 PM)Agamenon escribió: [ -> ]

(23-02-2015, 02:06 PM)Antonio Castro escribió: [ -> ]Medir voltajes en una salida dimeada es algo que no tiene sentido. [...]

Pues Antonio, yo mido voltaje perfectamente. De hecho si pongo el voltímetro en la clema que empalma el cable del canal que va hasta los leds antes de empezar el dimeo es 0v, y según va realizándose el dimeo veo que va aumentando progresivamente hasta llegar a los 12v de dicho canal. Vamos, que se puede medir perfectamente.

(23-02-2015, 02:49 PM)Agamenon escribió: [ -> ]Eso por qué? por lo que dices no debería ocurrir? Tengo montado el TIP exactamente como en tu documentación de CAO. Positivo de la fuente a los leds directo, y la masa pasándo a través del TIP141. Además he conectado una salida de masa de la fuente a un pin ground del arduino, no es exactamente el mismo cable de masa que va al TIP porque por montaje me resultaba más sencillo sacarlo a través de otro, pero entiendo que internamente las masas de la fuente de alimentación son la misma. El pin PWM del arduino tiene la resistencia indicada en su conexión con el TIP.

El voltímetro asume un valor eficaz que en el caso de una resistencia se comportaría igual. Es decir, la resistencia generará la misma cantidad de calor que con un voltaje constante de ese valor. En el caso de un LED no te vale. El LED lo que hace es encenderse y apagarse con suma rapidez. La diferente intensidad de luz es un efecto óptico. Al LED le está llegando la totalidad del voltaje o ningún voltaje. El TIP en este circiuito funciona dejando pasar toda la corriente o ninguna.

(23-02-2015, 02:06 PM)Antonio Castro escribió: [ -> ]La inercia de un sensor no tiene nada que ver con su precisión.
[...]
El sensor de Dallas es buenísimo.

Los sensores van en modo normal, los 3 cables independientes... vcc, ground y data. Lo que interconecto antes de conectar al arduino son esos 3 cables independientes entre los dos sensores.

El dallas que está en el acuario tiene encapsulado metálico, no plástico, así que entiendo que la conductancia térmica debe ser buena.

En realidad no es un encapsulado. Es una funda para impermeabilizar. Las que yo usé terminaron fallando en pocos días. Me dió muchos quebraderos de cabeza y hablo de ello en mi libro. Uso mi propio sistema para impermeabilizar estos sensores porque terminaban fallando.

(23-02-2015, 02:06 PM)Antonio Castro escribió: [ -> ]El dato puede estar en que ralentizas la medición de temperatura por software. Haré la prueba haciéndome un código que la lea en tiempo real, a ver si los datos entre ambos sensores cuadran más.

Tengo puesto el calentador que se active en la temperatura baja del acuario, de hecho en mi caso voy a poner que en el modo seguro sea el calentador siempre encendido ya que es un jagger de eheim y tiene termostato propio para desconectarse a la temperatura indicada. Quería que estuviese controlado por arduino precisamente para mejorar su precisión.

El planteamiento es correcto. Debería funcionar.

(23-02-2015, 02:06 PM)Antonio Castro escribió: [ -> ]Actualmente va metiendo oscilaciones de temperatura de más de medio grado cuando se activa y desactiva, pero lo peor es que depende de la altura de la columna de agua ya que el termostato lo tiene en la parte de arriba... detectando menor temperatura cuanto más baja está el agua del acuario (la superficie está más fría por contacto con el ambiente). Eso hace que según pasan los días de la semana y va bajando el agua, el calentador esté más conectado porque se le falsea la medición.

Mi intención era tener controlado mucho mejor el calentador mediante arduino. Estableciendo una temperatura entre la que baile lo menos posible y evidentemente sin importar la altura de la columna de agua (tengo el acuario destapado y como me vaya una semana y no rellene me baja casi 20 litros el nivel, el irme 2 semanas por ejemplo sí que puede provocar una sopa de pescado por medición errónea del termostato del calentador). Como la temperatura baja y sube de forma gradual, el relé del calentador no debería activarse/desactivarse más de 4 o 5 veces a la hora. No creo que ese uso dañase el relé no?

Lo que me comentas parece una chapuza realizada nada menos que por la ingeniería alemana.

La vida útil varía mucho con cada relé. Viene en el datasheet pero con un uso razonable no hay problema. Yo creo que un relé conmutando una vez por segundo duraría años.

(23-02-2015, 02:06 PM)Antonio Castro escribió: [ -> ]Y ya que estoy hablando del software hay un punto que no se como evitar: el pitidito. Quiero que el buzzer suene cuando hay una alarma grave (temperatura por encima o por debajo del máximo por ejemplo), pero en ningún caso más. Ni cuando pulso botones, ni mucho menos cada vez que cambia el estado de un relé. Es eso posible de configurar o hay que tocarlo en el código? Tengo todo el día eso pitando cada vez que la temperatura del agua baja o sube del LOW y por tanto se activa o desactiva el relé del calentador.

Puedes quitar ese aviso. Lo puedes localizar por "AvisoCambio"

Lo de acompañar de sonidos las acciones de la botonera a mí me resulta muy útil, pero puedes quitarlo aunque para eso hay que tocar algo el código.

La forma más cómoda de hacerlo es implementar un nuevo modulo con las mismas definiciones que existen en Buzz.h pero en la implementación de las funciones simplemente no haría nada. De esa forma te basta sustituir los
#include "Cao1_Buzz.h" (por ejemplo por #include "NullBuzz.h"). Puedes dejar solamente a alarma. Las demás funciones las pones vacías. De hecho. es hacer una copia del módulo Buzz con ese otro nombre y vaciar algunas funciones.

De esa forma podrás silenciar más módulos cambiando el include.

(23-02-2015, 03:51 PM)Antonio Castro escribió: [ -> ]El voltímetro asume un valor eficaz que en el caso de una resistencia se comportaría igual. Es decir, la resistencia generará la misma cantidad de calor que con un voltaje constante de ese valor. En el caso de un LED no te vale. El LED lo que hace es encenderse y apagarse con suma rapidez. La diferente intensidad de luz es un efecto óptico. Al LED le está llegando la totalidad del voltaje o ningún voltaje. El TIP en este circiuito funciona dejando pasar toda la corriente o ninguna.

No quiero que esto se convierta en un chat, aunque esta información seguro que le es útil también a más gente con powerleds como los míos. Pero no me gusta quedarme con dudas sobre ningún tema, y me gustaría comprender bien como va el asunto de los leds y los tips.

Dices que el tip siempre deja pasar el voltaje total, pero simplemente conmuta a velocidad ultrarrápida. Que el poner el voltímetro midiendo no me asegura que los valores leídos sean correctos (aunque parezcan correctos por lógica... un aumento progresivo de 0v a 12v). Entonces en primer lugar, cómo puedo con el montaje completo hecho (tips, leds y cabes soldados) medir por ejemplo el voltaje total que está llegando a los leds?? para que entiendas la necesidad: yo estoy completando las series de leds con resistencias, para llegar a los teóricos 12 voltios que da la fuente; pero al hacer el montaje completo, entre soldaduras y empalmes con clemas se están añadiendo resistencias y el voltaje que le está llegando a los leds es de 11v (aunque en los ejemplos anteriores hablo de 0 a 12 para que sea menos confuso de entender, realmente sería hasta 11v). Eso lo medí antes de soldar los tips, y después de estar soldados coincide al estar a tope. Pero claro, si yo varío el montaje y por ejemplo donde antes empalmaba dos cables con una clema ahora los sueldo, como puedo medir el voltaje que está llegando a cada serie de leds si me dices que usando un tip la medida del voltímetro NO es fiable??

Porque veo totalmente necesario poder medir en cualquier momento a que voltaje está trabajando cada led, para ajustar las resistencias que estoy usando por serie.

Y atando cabos, es posible que por usar resistencias en cada serie de leds, el dimeo no está funcionando como se supone que debe porque metan un comportamiento extraño?? si partimos del supuesto de que siempre llega el voltaje total a cada led este DEBERÍA siempre encenderse a cada pulso. Por tanto aunque lo que se le mande por PWM sea 30, un mínimo de iluminación debería verse porque el led SE ENCENDERÍA... aunque con una intensidad visual baja por los intervalos entre pulsos. Pero en la práctica en mi sistema, al dimear con CAO, no veo absolutamente nada de luz en los leds hasta que el PWM está por 160 al menos... y luego la intensidad lumínica va subiendo a escalones, en golpes donde el cambio de luz es claramente visible del actual al siguiente, como en escalones. Una vez estando PWM a 255 que es como he fijado el máximo, la luz ya se mantiene a tope hasta que llega el anochecer y empieza a ocurrir lo mismo pero al contrario: la bajada de luz no es continua y suave, sino a escalones, y si tengo puesto que el anochecer termine a las 22:45 desde las 22:00, a las 22:20 ya se apaga la luz del todo.

Recuerdo que tengo un cañón de luz, una pantalla de 7000 lúmenes y más de 100 vatios en powerleds, y puede que por eso los cambios de luz también se noten más, no lo se, pero quiero comprender que está ocurriendo para mejorarlo y conseguir un dimeo fluido.