[Antonio Castro]

Yo entiendo que a William le seduzca un proyecto tan atractivo, tan completo y tan bien hecho como Ferduino que entre otras cosas ya incluye una serie de hardware para conectar sondas sumergibles caras, y claramente está orientado a una serie de usuarios que pueden permitirse gastos importantes.

El problema es que pagar más no va a garantizar la necesaria simplicidad de puesta en marcha y de uso de un sistema que ha de ser montado y configurado conforme a las necesidades particulares de cada usuario, que además de dinero necesitará tener unos conocimientos técnicos mínimos para instalarlo y hacerlo funcionar salvo que exista posibilidad de contratar eso servicios.

Dudo que un controlador de acuario completo pueda ser diseñado como un producto acabado de propósito general porque en acuariofilia no existe una única forma de hacer las cosas. Un acuario es un ecosistema artificial y la forma en que cada usuario logra la sostenibilidad de un determinado ecosistema acuático puede ser muy diferente.

Ferduino ha intentado incluir integrado en una placa prácticamente cualquier cosa que se pudiera necesitar, pero yo lo que procuro es hacer un sistema que pueda crecer y evolucionar fácilmente.

Un controlador de acuario ha de ser algo parecido a un Transformer y para eso se necesita una arquitectura modular tanto para el hardware como para el software.

Fijaros que Ferduino tienen integrado en su placa un Arduino Mega 2560 que en su momento sería lo más avanzado que existía para esta plataforma, pero que ya no lo es.

Si no evoluciona no podrá sacar partido de Arduino DUE y si evoluciona los que tengan la placa con Arduino Mega no podrán reutilizar una buena parte del hardware anterior.

Ferduino es un buen diseño, y creo que CAO también. Cada diseño tiene su pros y sus contras.

[xavi]

Yo estoy totalmente de acuerdo con Suce y Antonio.

Lo importante de un controlador es que funcione sin cuelgues y que cumpla tus expectativas y necesidades.

Que tengas información en una pantalla LCD, gráfica, OLED, es lo de menos; que tenga botonera para interactuar con Arduino, tantas veces haces modificaciones?. Yo tengo un controlador con botonera, y el otro fin de semana cambié la hora ( 1 modificación en 1 año)...creo el esfuerzo de fabricacion y aumento complejidad del controlador no esta justificado.

He diseñado una pantalla les para un acuario de 30 litros con un Arduino mini pro para el dimeo de 4 canales y para la refrigeración de la misma; para cambiar la hora conecto la pantalla con un alargo al PC y modifico, sencillo. La próxima pantalla que tengo en proyecto será igual.

Para acabar, los que solo sabemos trastear con Arduino, hemos de seguir al dedillo las instrucciones que dan los maestros, y evidentemente utilizar exactamente los componentes que el proyecto inicial tienen.

Antonio, no desfallezcas ante nuestras preguntas, y ahora a por el Due.

Saludos

[william]

hola unas preguntas Antonio espero entiendas jajja
porque al hacer por ejemplo el RTC pones dos ventanas una rtc.cpp y la otra rtc.h gracias

[Antonio Castro]

hola unas preguntas Antonio espero entiendas jajja
porque al hacer por ejemplo el RTC pones dos ventanas una rtc.cpp y la otra rtc.h gracias

En el borrador del libro que fue adelantado en este foro antes de su publicación no vienen algunas cosas como esta, pero en el libro sí. Copio y pego el fragmento relativo a este tema que te interesa.

Los ficheros de la aplicación CAO1:
La aplicación CAO1 consta de varios módulos. Los módulos de la aplicación se reconocen fácilmente por tener en su nombre el prefijo 'Cao1_'. Deben de residir en el mismo directorio que el programa principal. Para aquellos que carezcan de las nociones básicas de programación en C++, comentaremos muy brevemente los tipos de ficheros de una aplicación y para que se usan.
Ficheros de cabecera (header) (.h)
Se trata de unos ficheros de declaraciones de variables y de prototipado de funciones y procedimientos. No generan código ejecutable en el procesador, pero son imprescindibles para poder compilar. Un fichero de cabecera (header) puede ser incluido, con la sentencia #include “fichero.h” o #include <fichero.h> dentro de un fichero de procedimientos y funciones (*.cpp) o dentro de otro header. Un fichero de cabecera no puede ser incluido más que una vez en la compilación, pero se puede proteger el header para que en el caso de que se intente incluir más de una vez en cada unidad de compilación, no genere problemas por duplicación de símbolos. Esto se consigue mediante el uso de macros #ifndef. Ejemplo:
#ifndef Cao1_Botonera5Puls_h
#define Cao1_Botonera5Puls_h
(… resto del header …)
#endif
Respecto a las dos formas de usar include, (#include “fichero.h” o #include <fichero.h>) la primera con comillas, indica que el preprocesador busca primero en el directorio que contiene el archivo de código fuente principal. (En nuestro caso en el directorio donde tengamos 'CAO1_1.ino'.) En realidad una sentencia include lo que hace es incluir todo el contenido del fichero especificado en sustitución de dicha sentencia. En la declaración de las classes conviene declarar en el header el ámbito de los atributos de dicha clase. Estos pueden ser: public, private, protected.
Fichero de procedimientos y funciones (.cpp).
Es la parte que describe la lógica del programa con sus algoritmos. Contiene código fuente que el compilador traducirá a código ejecutable. Cada fichero de procedimientos se compila por separado generando un fichero de código objeto. Este código depende de la tarjeta que seleccionemos en el IDE. Todo ello en Arduino se hace de forma totalmente transparente para el usuario. Una vez que se han compilado todos los ficheros de procedimientos y que se han generado todos los ficheros de código objeto se ejecuta un linker que enlazará todo ello en un único fichero ejecutable que será cargado en nuestra tarjeta de Arduino.

[Davidmadrid]

Estos dias atras pedi a traves de Bricogeek un modulo TLC59711 y hoy me ha llegado, tiene 12 canales con PWM a 12Bit, lo malo que las librerias no estan portadas para el DUE.

Este integrado ofrece 65536 pasos de PWM, asi que creo que solucionare el problema que tenia con mis led de que cada paso se notaba demasiado, imagino que sera asi con cualquier led, pero en mi caso era bastante acusado.

Ahora estoy liado con ciertos asusntos pero segun lo instale posteare resultados.

Os dejo unas fotitos.....




Saludos.

[Antonio Castro]

Eso está genial, ya nos contarás.

Yo también estoy bastante liado. Lo último que hice fueron prueba de dimeados con ventiladores a 12v usando el TIP120. Se escucha la frecuencia de dimeo en el motor., es lógico. Resulta molesto. La idea de dimeo de ventiladores es la de reducir el ruido y si te mete un ruido agudo de dimeo la cosa no queda nada bien.

Probé variando la frecuencia, y no conseguí gran cosa. Probé a usar filtros mediante condensadores y ferritas toroidales. Estas para radiofrecuencia van bien pero para para frecuencias audibles (de 20 a 20.000Hz) no hacen practicamente nada. Se necesitarían muchas espiras y no lo veo práctico.

Decidí reducir la frecuencia de dimeo por debajo de los 20Hz que es capaz de escuchar el ser humano, pero los timers de Arduino no manejan frecuencias tan bajas, así que tuve que programarme mi propio PWM usando un servicio de interrupción. La verdad es que ha resultado sencillo.

Al ser una onda cuadrada se escuchan algunos armónicos audibles. Concretamente un suave repiqueteo cuando gira muy despacio, pero es muy poco molesto. Cuando pueda haré un pequeño vídeo explicativo para que lo veáis. El código lo he hecho para Arduino DUE porque localicé una librería para el manejo de interrupciones que me gustó.

[Davidmadrid]

Esperamos ese video, a ver si voy aprendiendo poco a poco, aunque me estoy dando cuenta que sin una base de programacion esto se hace muy cuesta arriba.

Saludos.

[Antonio Castro]

El lenguaje C++ no es el más apropiado para aprender programación, así que la dificultad es doble. Tanto C como C++ son lenguajes que permiten generar un código muy eficiente y esto es un prioridad tratándose de programar un controlador. Son lenguajes algo alejados de los humanos y más próximos a las máquinas.

Os cuento una simple anecdota:
Estoy programando algunas mejoras que tenía pendiente para CAO1 y surgió un problema. La botonera dejó de funcionar y parecía un error de hardware. En la entrada analógica los valores que entregaban los pulsadores ya no tenían nada que ver con los que tenían que ser. Tuve que testear con el polímetro el funcionamiento de la botonera, revisé los contactos, pero todo parecía estar bien. CAO reconocía solo un botón pero con un valor equivocado. No había tocado nada en el módulo de la botonera así que no podía estar ahí el error. Recompilé varias veces y nada. Recuperé la versión antigua que funciona bien, pero con ella también seguía fallando.

Pensé que se me había jodido el Arduino. Llegué a pensar que esa entrada analógica se había quemado sin motivo alguno. Se me ocurrió apagar el Arduino. Al recompilar funcionó todo al principio, pero al funcionar con la versión modificada, pasado un tiempo volvía a ocurrir el mismo error.

Dado que el Arduino UNO no previene ciertos errores de acceso a memoria que deberían provocar violación de segmento de memoria imaginé que el programa tenía algún error con tipos de datos, conversiones de tipos, punteros o algo así y repasando el código encontré una sentencia que en una función devolvía un tipo de dato entero de distinto tamaño al esperado. (Un int en lugar de un int16_t). No daba error pero creo que machacaba algo en memoria que terminaba desconfigurando el Arduino. He tenido mucha suerte encontrando el error tan rápido.

Recuerdo que un error me costó meses para localizarlo. Me provocaba cuelgues aleatorios en el Arduino. Estaba en la función de interpolación lineal, es una función muy sencilla que tiene una sola línea y muchas veces funcionaba bien.

Yo odio el C++, pero me encanta el Arduino. Profesionalmente usé bastante el C++, pero llevaba cerca de 10 años sin usarlo. Mi lenguaje favorito, es el lenguaje Python. (muy lento para usar en Arduino). En Ingeniería hay herramientas para generar código en C++.

Lo que quiero decir con todo esto, es que en Arduino al usar C++ y al tener una gestión muy rudimentaria de los fallos de acceso a la memoria, te puedes topar con errores nada triviales de localizar porque en Arduino esos errores pueden no indicar nada sobre la parte del código donde tienes que buscarlo. Dependes mucho de los conocimientos sobre el funcionamiento de los compiladores y de como generan código para guiarte a la hora de buscar ciertos fallos.

Por eso es tan importante que la funcionalidad de un controlador de acuarios sea modular para ocultar al máximo la complejidad del código y que personas con menos conocimientos puedan manejar el código como si fueran grandes piezas de un puzle que pueden ser encajadas unas con otras para conformar una aplicación.

Las librerías de Arduino son geniales. Para aplicaciones sencillas no es necesario saber mucho porque hay mucho software de librería para gestionar toda clase de hardware que simplifican mucho las aplicaciones. Muchas de estas aplicaciones son de muy pocas líneas y aparecen en forma de tutoriales y ejemplos.

Lo que yo pretendo es generar módulos que sean una base para programar controladores de acuarios.

[Antonio Castro]

Acabo de releer mi último comentario y además de muy largo, estába pésimamente escrito. Ya lo he mejorado un poco.

[Davidmadrid]

Yo si te soy sincero abri el sketch de CAO en su dia y vi tal cantidad de modulos que no entendia nada, en defeinitiva no entiendo como se referencian entre ellos, aunque es verdad que es una forma muy comoda de ir a hacer ajustes al modulo especifico, imposible perderte. Yo en mi sketch, unas 1000 lineas, todo de los mas sencillo posible y posiblemente lleno de errores y hecho de una manera continua, pues me pierdo cuando tengo que modificar algo jeje.

La verdad que me da envidia sana ver CAO tan ordenadito jeje.

[Antonio Castro]

Yo lo que puedo hacer es desatascar a todo aquel que se quede atascado intentando aprender algo por su cuenta. Si os animáis alguno a programar algún modulito orientado a objeto aquí me tenéis. Los primeros pasos son siempre los más difíciles.

[Antonio Castro]

Según puede verse en el vídeo, he realizado una serie de pruebas con Arduino UNO y Arduino DUE para el dimeo de cargas inductivas. El objetivo es el de poder regular la velocidad de rotación de un ventilador.

He consultado bastante documentación, y el transistor TIP141 que venimos usando para el dimeo de LEDs no parece ser el adecuado para dimear cargas inductivas. He visto que se han publicado soluciones con transistores CMOS, pero dado que no podrían funcionar a 3.3v he preferido usar un transistor TIP120 que es ampliamente utilizado tanto para controladores a 5V como para controladores a 3.3 voltios. TIP120 permite dimear cargas de 5 amperios con hasta 60 voltios.

Las dos primeras pruebas sirven para demostrar que este transistor puede funcionar con ambos voltajes de control, porque funciona igual con Arduino UNO que con Arduino DUE. El problema es que aparece un tomo molesto a 1000 herzios que se corresponde con la frecuencia de la señal PWM usada para el dimeo.

Código:

#include <Arduino.h>

int led        = 6;
int brightness = 0;
int Dimeo      = 0;

// ***************************
void setup()  {
  pinMode(led, OUTPUT);
  Serial.begin(9600);
}

// ***************************
void loop()  {
  // analogWriteResolution(12);
  brightness++;
  if (brightness>255){
      brightness=0;
  }
  analogWrite(led, brightness);
  Serial.println(brightness);
  if (brightness==0){
      delay(7000);
  }
  delay(150);
}

Las frecuencias audibles van desde los 20Hz hasta los 20Khz. Yo no he querido aumentar la frecuencia por encima de los 20khz porque emitiría ultrasonidos que aunque inaudibles para nosotros podrían causar molestias a ciertos animales, pero realmente se podría haber optado por una versión de dimeo con ultrasonidos.

Las frecuencias de PWM del Arduino se pueden variar configurando los registros de algunos Timers con los valores adecuados. Existe una página con información muy completa en:
http://playground.arduino.cc/Main/TimerPWMCheatsheet

Una de las cosas que interesa saber es que para los pines 5 y 6 que tienen una frecuencia por defecto de 1kHz se usa el Timer 0 que también se usa para la función millis() y para la función delay(). De cambiar esta frecuencia se alterarían estas funciones.

La frecuencia de PWM por defecto en los pines 9, 10, 11, y 3 es de 500Hz y también puede ser variada. Esto sería para Arduino UNO, en Arduino DUE hay más Timers disponibles.

En ninguno de estos casos podremos obtener un infrasonido porque la menor frecuencia que podremos obtener son 30Hz.

Yo finalmente opté por implementar una funcion PWM para obtener una frecuencia de dimeo de 16Hz que corresponde a un infrasonido.

Código:

#include <Arduino.h>

int led        = 6;
int brightness = 0;
int Dimeo      = 0;

// ***************************
void setup()  {
  pinMode(led, OUTPUT);
  Serial.begin(9600);
}

// ***************************
void loop()  {
  // analogWriteResolution(12);
  brightness++;
  if (brightness>255){
      brightness=0;
  }
  analogWrite(led, brightness);
  Serial.println(brightness);
  if (brightness==0){
      delay(7000);
  }
  delay(150);
}

Para ello lo que hice fue programar un par de interrupciones en los Timers 7 y 8 para Arduino DUE de forma que se generará una señal PWM en la salida del pin 6.

La he programado a 16 Hz y el resultado es el que puede apreciarse en el vídeo. El programita es muy sencillito y bastaría explicar en que consiste eso de usar un servicio de interrupción. De hecho este programa es un buen ejemplo para ilustrar ese concepto. Si alguien tiene curiosidad lo puedo explicar.

No he probado con ultrasonidos, pero es una cuestión de gustos. La implementación con ultrasonidos parece incluso más fácil de conseguir. Podría lograrse 31Khz para los pines 9, 10, 11, y 3 de Arduino UNO. Para los pines 5 y 6 se podría obtener el doble de hercios pero se afectarían las funciones millis() y delay(). Concretamente millis() devolvería el doble y delay() duraría la mitad. Ambas cosas podrían ser tenidas en cuenta en un programa en caso necesario.

[william]

hola para todo el mundo dejo un enlace para los que tienen en due

http://www.ebay.com/itm/TFT-3-2-400-240-...3f25251e03

[Antonio Castro]

hola para todo el mundo dejo un enlace para los que tienen en due

http://www.ebay.com/itm/TFT-3-2-400-240-...3f25251e03

Yo creo que con un Interface sencillo para poder interactuar físicamente con el controlador usando un LCD y una botonera da para mucho.

Para un interfaz gráfico y pantalla táctil lo mejor es dar un salto cualitativo y pasar a usar un Interface Web

Arduino + Interface Web

De esa forma puedes interactuar con tu controlador desde cualquier punto del planeta. Incluso desde una tumbona en la playa, je, je.

Este es un tema que me interesó desde el principio.
CAO-6 Instalación de un servidor web doméstico en Linux. (20- marzo de 2013)

Investigué lo suficiente como para saber que se podía hacer llegado el caso.
Incluso desarrollé un protocolo para intercambiar comandos por un puerto seríe.

Enlacé el Arduino con un Raspberry Pi usando una conexión serie bidireccional realizada en lenguaje Python. Este sí que es un lenguaje mucho más sencillo que el lenguaje C++. Es mucho más adecuado para aprender programación, pwero es un lenguaje interpretado y no puede proporcionar la velocidad de ejecución necesaria para controlar ciertos automatismos hardware. Para la parte de comunicaciones en un Raspberry Pi conectado a Arduino va muy bien.

El protocolo de comunicación me consumía mucha memoria y llegó un momento que tuve que partir de cero y optar por un interfaz más modesto.

Por el momento el proyecto CAO funciona en una placa Arduino Mega, pero habrá que ampliar funcionalidad y existen varias posibles direcciones para ampliar el diseño actual. El tener el controlador funcionando me está proporcionando nuevas ideas.

Me interesan las posibilidades de Arduino DUE, de Raspberry Pi, y de Arduino pro mini 328 entre otras.

Antes de pasar a otros diseños, creo que el diseño actual (CAO1) puede ser mejorado con algunas cosas, y quiero implementar algunas de las cosas que dejé pendientes de mejora para CAO1.

[Antonio Castro]

Sobre el dimeo de motores a 16Hz, era imposible que con el código que yo puse entendierais algo.

Me equivoqué de fuente al subirla y no me he dado cuenta hasta ahora. Siento el error y siento haber tardado tanto en darme cuenta. Tengo bastante lío últimamente.

Voy a la cita del mensaje anterior y voy a editarla aquí.

También voy a ampliar este tema con algo más de información.

Según puede verse en el vídeo, he realizado una serie de pruebas con Arduino UNO y Arduino DUE para el dimeo de cargas inductivas. El objetivo es el de poder regular la velocidad de rotación de un ventilador.

He consultado bastante documentación, y el transistor TIP141 que venimos usando para el dimeo de LEDs no parece ser el adecuado para dimear cargas inductivas. He visto que se han publicado soluciones con transistores CMOS, pero dado que no podrían funcionar a 3.3v he preferido usar un transistor TIP120 que es ampliamente utilizado tanto para controladores a 5V como para controladores a 3.3 voltios. TIP120 permite dimear cargas de 5 amperios con hasta 60 voltios.

Las dos primeras pruebas sirven para demostrar que este transistor puede funcionar con ambos voltajes de control, porque funciona igual con Arduino UNO que con Arduino DUE. El problema es que aparece un tomo molesto a 1000 herzios que se corresponde con la frecuencia de la señal PWM usada para el dimeo.

Código:

#include <Arduino.h>

int led        = 6;
int brightness = 0;
int Dimeo      = 0;

// ***************************
void setup()  {
  pinMode(led, OUTPUT);
  Serial.begin(9600);
}

// ***************************
void loop()  {
  // analogWriteResolution(12);
  brightness++;
  if (brightness>255){
      brightness=0;
  }
  analogWrite(led, brightness);
  Serial.println(brightness);
  if (brightness==0){
      delay(7000);
  }
  delay(150);
}

Las frecuencias audibles van desde los 20Hz hasta los 20Khz. Yo no he querido aumentar la frecuencia por encima de los 20khz porque emitiría ultrasonidos que aunque inaudibles para nosotros podrían causar molestias a ciertos animales, pero realmente se podría haber optado por una versión de dimeo con ultrasonidos.

Las frecuencias de PWM del Arduino se pueden variar configurando los registros de algunos Timers con los valores adecuados. Existe una página con información muy completa en:
http://playground.arduino.cc/Main/TimerPWMCheatsheet

Una de las cosas que interesa saber es que para los pines 5 y 6 que tienen una frecuencia por defecto de 1kHz se usa el Timer 0 que también se usa para la función millis() y para la función delay(). De cambiar esta frecuencia se alterarían estas funciones.

La frecuencia de PWM por defecto en los pines 9, 10, 11, y 3 es de 500Hz y también puede ser variada. Esto sería para Arduino UNO, en Arduino DUE hay más Timers disponibles.

En ninguno de estos casos podremos obtener un infrasonido porque la menor frecuencia que podremos obtener son 30Hz.

Yo finalmente opté por implementar una funcion PWM para obtener una frecuencia de dimeo de 16Hz que corresponde a un infrasonido.

AQUI PUSE UN CÓDIGO QUE NO CORRESPONDE
SE PUEDE VER QUE NI SE PARECE AL DEL VIDEO

Para ello lo que hice fue programar un par de interrupciones en los Timers 7 y 8 para Arduino DUE de forma que se generará una señal PWM en la salida del pin 6.

La he programado a 16 Hz y el resultado es el que puede apreciarse en el vídeo. El programita es muy sencillito y bastaría explicar en que consiste eso de usar un servicio de interrupción. De hecho este programa es un buen ejemplo para ilustrar ese concepto. Si alguien tiene curiosidad lo puedo explicar.

No he probado con ultrasonidos, pero es una cuestión de gustos. La implementación con ultrasonidos parece incluso más fácil de conseguir. Podría lograrse 31Khz para los pines 9, 10, 11, y 3 de Arduino UNO. Para los pines 5 y 6 se podría obtener el doble de hercios pero se afectarían las funciones millis() y delay(). Concretamente millis() devolvería el doble y delay() duraría la mitad. Ambas cosas podrían ser tenidas en cuenta en un programa en caso necesario.

El código que debí subir es el siguiente.

Código:

#include "DueTimer.h"

int PeriodMcrS=62500;  // Para 16 Hz son 62.5 Ms
int CountPwm=0;

// La resolucion en un Arduino UNO es 255 nosotros podemos elegir un valor
// arbitrario ya que se trata de un PWM propio.
int Resolution=2500;
int ValPWM;

// ***********************
void HandPeriod(){
    CountPwm=0;
}

// **************************************************************************
//  Se ejecutará cada: PeriodMcrS/Resolution = 62500/2500 = 25 MicroSegundos
// **************************************************************************
void HandCountPWM(){
    CountPwm++;
    if (CountPwm<ValPWM){
    digitalWrite(13, HIGH); digitalWrite(6, HIGH);
    }
    else{
    digitalWrite(13, LOW); digitalWrite(6, LOW);
    }
}

// **********************************************
void setup(){
    pinMode(13, OUTPUT); pinMode(6, OUTPUT);
    Timer7.attachInterrupt(HandPeriod);
    Timer7.start(PeriodMcrS);  
    Timer8.attachInterrupt(HandCountPWM);
    Timer8.start(PeriodMcrS/Resolution);  
}

// ******************************************
void loop(){
    for (int i=0; i<Resolution; i++){
        ValPWM=i;
        delay(10);
    }
    Timer8.stop();
    digitalWrite(13, LOW); digitalWrite(6, LOW);
    delay(7000);
    Timer8.start(PeriodMcrS/Resolution);  
}

Esta solución que quise poner, solo servía para Arduino DUE así que he buscado alguna alternativa que pueda servir tanto para DUE como para Mega, en incluso para UNO.

Existe una librería Timer que simula interrupciones pero que en realidad funciona usando únicamente la función millis(). Tiene limitaciones de velocidad precisamente por trabajar en milisegundos, pero salvando este inconveniente resulta muy útil y no consume ningún Timer que es un recurso que conviene no usar y reservarlo para un montón de funcionalidades bastante críticas.

Para usar este sistema hay que reservar el uso del bucle principal loop() a la actualización de los Timers que implementemos con esta librería.

Es una cuestión de adaptarse a su uso. Para usarlo dentro de CAO aun no sé lo que eso implicaría. Es algo que merece ser estudiado.

Es una librería interesante. Permite crear tantos temporizadores virtuales intependientes como necesitemos.
La limitación principal de esta librería va a ser la velocidad de respuesta de estos temporizadores que tienen una resolución de milisegundos.
En principio para implementar un PWM propio a baja frecuencia para control de motores a unos 16Hz creo que sería útil.

Lo ideal sería aplicar todo esto a la nueva versión de CAO1 en la que estoy trabajando para que podáis jugar cómodamente con ello sin demasiadas complicaciones.

Los ventiladores de los LEDs en lugar de activarse y desactivarse, deberían acelerar o desacelerar las revoluciones en función de la temperatura.