Acuariofilia Madrid

Versión completa: Aula Arduino para principiantes.
Actualmente estas viendo una versión simplificada de nuestro contenido. Ver la versión completa con el formato correcto.
¿que tas pillao un LCD 16x2? por 23 lereles -nj.gif


Encimita serial -mu.gif

Pero si por dos lereles tienes ya el LCD 16x02 con su modulito I2C ya soldado o por menos sin soldar.

O por 4.36 la tocha 20x04 con su I2C compatible con el Cao01


Si no recuerdo mal en los LCD HD44780 el tema de la luz de fondo se gestionaba por un pin de salida analógica por fuera del I2C a un contacto del LCD
(22-02-2016, 12:23 AM)ArturoS escribió: [ -> ]¿que tas pillao un LCD 16x2? por 23 lereles -nj.gif


Encimita serial -mu.gif

Pero si por dos lereles tienes ya el LCD 16x02 con su modulito I2C ya soldado o por menos sin soldar.

O por 4.36 la tocha 20x04 con su I2C compatible con el Cao01


Si no recuerdo mal en los LCD HD44780 el tema de la luz de fondo se gestionaba por un pin de salida analógica por fuera del I2C a un contacto del LCD

Por lo que sé esos LCD pueden trabajar con protocolos diferentes: paralelo,
Serie, I2C y creo que también SPI.

Yo cuando empecé tenía más conocimientos que Pedro y me pasó exactamente lo mismo con el LCD. No localicé librerías para ese Hardware y pensé que serial y i2c eran sinónimos para diferenciarlo del LCD en paralelo.

No fue la única vez que metí la pata. La avalancha de información para los que empiezan es brutal y despues de intentar entender algunos datasheets, la compra de hardware a lo que más se parecía para mí, era a cruzar un campo minado.

Decidí usar una estrategia que recomiendo para cruzar los campos de minas. Ponerse a una distancia prudencial del compañero que va delante y pisar sobre sus huellas. -happy.gif

Nunca supe de nadie que comprara un LCD Serial así que..., gracias Pedro, ahora vamos a pisar los demás tras tus huellas. Soy optimista, pero tú vas a abrir camino. Big Grin
(21-02-2016, 06:20 PM)Agamenon escribió: [ -> ]Magnífico trabajo depurando para la 1.6.7. Realmente esto del software funciona así, los estándares van cambiando, igual que la metodología, los patrones de diseño y la propia tecnología. Es muy habitual tener que refactorizar el código. En un código tan modular como CAO, aunque sean muchas líneas de código totales, es más fácil refactorizar porque el sistema está mucho más desacoplado.

Si estás depurando cosas Antonio, echa un ojo a un bug que he detectado en la versión actual de CAO.

Cuando activas el modo autosleep me ha ocurrido varias veces (no siempre) que cuando llega la hora de volver a encenderse y comenzar el día se queda el arduino pillado. Hay que resetearlo. Ya digo que solo pasa a veces. Evidentemente no es algo crítico, simplemente desactivas el modo autosleep y listo, pero es un bug que tiene una funcionalidad que podría ser interesante.

Otra cosa y como sugerencia para ese modo... no hay forma de apagar la pantalla?? porque el modo autosleep realmente lo que hace (o al menos en mi versión) es dejar la pantalla encendida pero sin que se refresquen caracteres. Es decir, se queda iluminada y en completo azul. Un comportamiento más deseable sería apagarla, y luego volver a encenderla al salir del modo sleep, no?

He revisado el código y no me parece muy probable que el fallo tenga que ver con el MODO_AUTOSLEEP, o por lo menos yo no he detectado nada sospechoso en el único lugar donde se hace algo con ello.

Código:
Noche= (Dimmer.GetZn()==0); // si estamos en periodo nocturno  
    if (Noche){
        // Si la botonera no registra cambios desde hace minuto y medio, y esta activo el modo AutoSleep
        if ( (Pulsad.DcSegDsdCambBotonera()>900) && Parm.EEP_Read(EP_AUTO_SLEEP)){
            LCD.Cls();
        }
        else{
            LCD.Refresh();
        }
    }
    else{
        LCD.Refresh();
    }

Tambien he repasado la función DcSegDsdCambBotonera() sin encontrar nada y esta se usa en varios lugares de la aplicación y no parece sospechosa.

Respecto a la retroalimentación veo que hay un jumper y compruebo de es un jumper para la retroalimentación del LCD.
[Imagen: ser-lcd-adapt.jpg]

He logrado localizar las especificaciones de LCD API 1.0

Creo que la LiquidCrystal no incluye esta api completa pero la LiquidCrystal_I2C ¡SÍ!

setBacklight(val)
Set the backlight off/on, or set Backlight brightness (0-255)
If the display only has the option to turn the backlight on and off, 0-off >0 = on

setContrast(val)
Set the contrast value of the display (0-255)

He probado estas nuevas funcionalidades en mi LCD y el resultado es que setBacklight(0) apaga el LED y cualquier otro valor (incluso el 1) enciende el LED al 100%. Es decir, el api viene preparado para esa funcionalidad pero lo único que puede hacer mi LCD es un todo o nada, lo cual ya es algo, y... permite hacer lo que tú querías.

Veré como implementarlo. Lo lógico sería que se pudiriera parametrizar el brillo y el contraste con un valor normal y un valor nocturno que podría ser el LED apagado completamente.

Tal como está ahor el LCD, proporciona una suave luz nocturna azul al acuario y evita tropezar con las cosas de noche cuando decides no encender la luz, pero dudo que esto sea lo que todo el mundo necesita, je, je. -happy.gif
(22-02-2016, 03:33 PM)Antonio Castro escribió: [ -> ]
(21-02-2016, 06:20 PM)Agamenon escribió: [ -> ]Magnífico trabajo depurando para la 1.6.7. Realmente esto del software funciona así, los estándares van cambiando, igual que la metodología, los patrones de diseño y la propia tecnología. Es muy habitual tener que refactorizar el código. En un código tan modular como CAO, aunque sean muchas líneas de código totales, es más fácil refactorizar porque el sistema está mucho más desacoplado.

Si estás depurando cosas Antonio, echa un ojo a un bug que he detectado en la versión actual de CAO.

Cuando activas el modo autosleep me ha ocurrido varias veces (no siempre) que cuando llega la hora de volver a encenderse y comenzar el día se queda el arduino pillado. Hay que resetearlo. Ya digo que solo pasa a veces. Evidentemente no es algo crítico, simplemente desactivas el modo autosleep y listo, pero es un bug que tiene una funcionalidad que podría ser interesante.

Otra cosa y como sugerencia para ese modo... no hay forma de apagar la pantalla?? porque el modo autosleep realmente lo que hace (o al menos en mi versión) es dejar la pantalla encendida pero sin que se refresquen caracteres. Es decir, se queda iluminada y en completo azul. Un comportamiento más deseable sería apagarla, y luego volver a encenderla al salir del modo sleep, no?

He revisado el código y no me parece muy probable que el fallo tenga que ver con el MODO_AUTOSLEEP, o por lo menos yo no he detectado nada sospechoso en el único lugar donde se hace algo con ello.

Código:
Noche= (Dimmer.GetZn()==0); // si estamos en periodo nocturno  
    if (Noche){
        // Si la botonera no registra cambios desde hace minuto y medio, y esta activo el modo AutoSleep
        if ( (Pulsad.DcSegDsdCambBotonera()>900) && Parm.EEP_Read(EP_AUTO_SLEEP)){
            LCD.Cls();
        }
        else{
            LCD.Refresh();
        }
    }
    else{
        LCD.Refresh();
    }

Tambien he repasado la función DcSegDsdCambBotonera() sin encontrar nada y esta se usa en varios lugares de la aplicación y no parece sospechosa.

Respecto a la retroalimentación veo que hay un jumper y compruebo de es un jumper para la retroalimentación del LCD.
[Imagen: ser-lcd-adapt.jpg]

He logrado localizar las especificaciones de LCD API 1.0

Creo que la LiquidCrystal no incluye esta api completa pero la LiquidCrystal_I2C ¡SÍ!

setBacklight(val)
Set the backlight off/on, or set Backlight brightness (0-255)
If the display only has the option to turn the backlight on and off, 0-off >0 = on

setContrast(val)
Set the contrast value of the display (0-255)

He probado estas nuevas funcionalidades en mi LCD y el resultado es que setBacklight(0) apaga el LED y cualquier otro valor (incluso el 1) enciende el LED al 100%. Es decir, el api viene preparado para esa funcionalidad pero lo único que puede hacer mi LCD es un todo o nada, lo cual ya es algo, y... permite hacer lo que tú querías.

Veré como implementarlo. Lo lógico sería que se pudiriera parametrizar el brillo y el contraste con un valor normal y un valor nocturno que podría ser el LED apagado completamente.

Tal como está ahor el LCD, proporciona una suave luz nocturna azul al acuario y evita tropezar con las cosas de noche cuando decides no encender la luz, pero dudo que esto sea lo que todo el mundo necesita, je, je. -happy.gif

No se exactamente donde estará el bug que cuelga el arduino claro, pero solo me ha ocurrido teniendo el autosleep activo. En cuanto lo he vuelto a desactivar nunca más me ha ocurrido.

Respecto a apagar la pantalla es exactamente la funcionalidad que buscábamos. No es ya solo por molestar, sino que el apagar la pantalla cuando no se está utilizando por la noche seguro que ampliará su periodo de vida y tampoco estamos desperdiciando energía inútilmente. Que aunque la pantalla por si sola consuma muy poco, teniendo en cuenta que en un acuario está funcionando las 24/365 si reducimos ese tiempo a la mitad, año tras año seguro que algo ahorramos Smile

La librería que has probado es esta? http://wentztech.com/radio/arduino/files/LCDI2C.html
Realmente una modificación rápida para quien quiera hacerla sería modificar el código de noche que has puesto para que en vez de hacer un cls y un refresh haga un setBacklight a 0 y a 255
(22-02-2016, 03:48 PM)Agamenon escribió: [ -> ][...]
La librería que has probado es esta? http://wentztech.com/radio/arduino/files/LCDI2C.html
Realmente una modificación rápida para quien quiera hacerla sería modificar el código de noche que has puesto para que en vez de hacer un cls y un refresh haga un setBacklight a 0 y a 255

Exacto, así es, pero no he cambiado de librería. Es la LiquidCrystal_I2C, lo que ocurre es en documentos como los que yo había consultado se refieren a la API de la LiquidCrystal que es un subconjunto de la más reciente LiquidCrystal_I2C
(15-02-2016, 08:34 PM)Antonio Castro escribió: [ -> ]
(15-02-2016, 02:22 PM)Agamenon escribió: [ -> ]
(15-02-2016, 12:55 PM)ArturoS escribió: [ -> ]El tip actúa mas como interruptor conectando a masa la linea de leds alimentada desde la fuente y cuyo cierre de circuito a masa es interrumpido por el tip que cuando entra en conducción actúa como interuptor. La onda cuadrada recibida por la base es la que habilita estas conducciones y su alta frecuencia es la que hace imperceptible para el ojo humano esos cortes, observandose como una bajada de la intensidad lumínica.

La corriente generada por el pin es débil y mas tendente a debilitarse por la distancia, pero creo que en el rango de 1m no es significativa. Otro tema es que un cable, y cuanto mas largo mas, es susceptible de coger interferencias electromagnéticas cercanas que deformen su señal inicial, pero si no está cerca de cables que alimentan motores potentes el efecto puede ser insignificante.

Yo probaría conectando los tip alejados por un cable apantallado, conectando la camisa a GND (creo que los tipo telefonillo o ethernet pueden servir). Y si llegara a detectar cosas raras ya me pensaría poner ferritas, cambiar trazados o cosas mas complejas.

Vale, estaba confundido entonces. Así que es el propio tip el que hace de conmutador y no de amplificador. Por tanto es lógico que con mi montaje actual donde el tip está cerca de arduino pero lejos de la pantalla no tenga problemas, puesto que el pulso PWM de arduino tiene muy poco recorrido.

Tendré que hacer pruebas para ver si me puedo fiar para montar 4 cables de 1 metro llevando los pulsos PWM de arduino hacia los TIPS, y que esas señales no se corrompan. Con un cable ethernet (que tienen 8 pines) podría mandar por cada pin una señal PWM y 3 pines más de los restantes para conectar la sonda de temperatura de la pantalla, por ejemplo?

Te doy mi opinión. Un metro para PWM no me parece una gran distancia.

Los cables de los sensores, es mejor que vallan apantallados por separado cada un de ellos.

Los cables de salida en teoría pueden apantallarse juntos para evitar que emitan señales que puedan causar interferencias, pero puede no hacer falta, yo no he visto montajes con cable apantallado para PWM.

Los cables de salida PWM de Arduino a 5v creo que aguantarán perfectamente sin perder señal en cables de uno o dos metros.

Para proteger los LEDs de las deformaciones indeseables de ondas con pico, se podría poner una ferrita en los cables que llevan la potencia, pero tampoco creo que haga falta.

Y al hilo de esto, una última duda. La resistencia de 2k2 que hay que poner entre cada salida PWM y la base del TIP141, teniendo en cuenta que habrá casi 1 metro entre la salida PWM y el TIP... es mejor poner la resistencia más cerca del TIP, más cerca de la salida PWM, o es indiferente? se me había pasado por la cabeza que al poner la resistencia más cerca de la salida PWM esta pudiese restarle demasiado voltaje teniendo en cuenta que aún queda todo el largo del cable por delante. No se si eso funciona así o no y da igual donde pongas la resistencia.
Esa resistencia creo que tiene como misión limitar la corriente del pin PWM, para evitar que este se fría por un exceso de demanda de corriente.

Creo que eléctricamente sería indiferente el lugar, pero para evitar algún altercado y que un indeseable corto se pueda producir en los cables, yo la situaría lo mas cerca del pin arduino.
(22-02-2016, 10:40 PM)Agamenon escribió: [ -> ][...]
se me había pasado por la cabeza que al poner la resistencia más cerca de la salida PWM esta pudiese restarle demasiado voltaje teniendo en cuenta que aún queda todo el largo del cable por delante. No se si eso funciona así o no y da igual donde pongas la resistencia.
La resistencia es para la correcta polarización del transistor. Limita la corriente de base del transistor. Lo más probable es que dé lo mismo el lugar donde la pongas. La resistencia de un cable de un metro es despreciable frente a los 2k2.
los radioaficcionados usamos cables apantallados y la emisora conectada a masa o toma de tierra, y solo usamos las ferritas apartir de 100 watios en los cables de la antena y aun asi colocando la ferrita en el cable, los magnetotermicos de la casa saltan por induccion elctromagnetica, yo con mis 600W a 7.100Mhz tengo que tener un unun por que ni no la radiofrecuencia residual o de retorno me desconecta el magnetotermico.
creo que en baja potencia y hablando de pwm seria recomendable el uso de cables apantallados para minimizar esos pulsos que salgan al exterior o hacia los led para que no creen un loop alrededor del cable en decimas o centesimas de segundo de arranque del PWM, el cable largo es una antena y el pulso PWM es la emisora y las interferencias son los armonicos producidos por el PWM y si ponemos un transistor ese PWM se amplifica de alguna manera por lo tanto ya estamos amplificando el PWM, ese PWM hace que en algun momento el arduino no le guste y se cuelge, y alguna interferencia atraves del cable el arduino se cuelge, quizas si se contruyera alguna caja de metal para proteger el arduino de señales externas y la fuente de alimentación perfectamente filtrada nada de fuentes conmutadas que esas ya meten ruido de conmutacion de la fuente, todo con una buena masa, en mi impresora 3D los motores funcionan erraticamente con una fuente de alimentacion de un ordenador nueva, que con mi fuente de alimentacion de mi emisora que tiene 30A a 12V y 45 de picos funciona mejor la impresora 3D.
(23-02-2016, 05:19 PM)miguelangel escribió: [ -> ]los radioaficcionados usamos cables apantallados y la emisora conectada a masa o toma de tierra, y solo usamos las ferritas apartir de 100 watios en los cables de la antena y aun asi colocando la ferrita en el cable, los magnetotermicos de la casa saltan por induccion elctromagnetica, yo con mis 600W a 7.100Mhz tengo que tener un unun por que ni no la radiofrecuencia residual o de retorno me desconecta el magnetotermico.
creo que en baja potencia y hablando de pwm seria recomendable el uso de cables apantallados para minimizar esos pulsos que salgan al exterior o hacia los led para que no creen un loop alrededor del cable en decimas o centesimas de segundo de arranque del PWM, el cable largo es una antena y el pulso PWM es la emisora y las interferencias son los armonicos producidos por el PWM y si ponemos un transistor ese PWM se amplifica de alguna manera por lo tanto ya estamos amplificando el PWM, ese PWM hace que en algun momento el arduino no le guste y se cuelge, y alguna interferencia atraves del cable el arduino se cuelge, quizas si se contruyera alguna caja de metal para proteger el arduino de señales externas y la fuente de alimentación perfectamente filtrada nada de fuentes conmutadas que esas ya meten ruido de conmutacion de la fuente, todo con una buena masa, en mi impresora 3D los motores funcionan erraticamente con una fuente de alimentacion de un ordenador nueva, que con mi fuente de alimentacion de mi emisora que tiene 30A a 12V y 45 de picos funciona mejor la impresora 3D.

Tiene lógica, pero con las radiofrecuencias prefiero fijarme en lo que hacen los ingenieros en sus soluciones comerciales y no he localizado ejemplos de fabricantes que monten drivers PWM para LEDs con cable apantallado lo cual me sorprende porque pensaba igual que tú. He mirado drivers de Meanwell. ¿No deberían aparecer los cables apantallados en algunas imágenes?

Arduino es muy sensible a la radiofrecuencia y con fuentes conmutadas yo suelo meter una ferrita en el cable y la fuente la tengo alejada del Arduino.
Hola a todos, este mes quiero comenzar el montaje de un controlador para mi acuario, el tema es que no conozco nada del tema por lo que debo comenzar poco a poco. Buscando en Amazon he encontrado varios kits para comenzar, pero por mi desconocimiento preferiría me aconsejaran de los que he encontrado cual creen que vale la pena.

http://www.amazon.es/Kuman-Project-Start...ds=arduino

http://www.amazon.es/SunFounder-Starter-...ds=arduino

http://www.amazon.es/SainSmart-Master-Va...ds=arduino
Es bastante complicado decidirse, porque todos me parecen bastante buenos, pero voy a mojarme.

Yo me decantaría por el SunFounder porque se han tomado la molestia de editar un libro de prácticas que tiene buena pinta y ponen los ejemplos en un CD. Eso te permitirá avanzar muy rápido. Además trae dos breadboard (pequeña y grande) y una protoboard para desarrrollar un escudo arduino (shield).

Me ha parecido que en todos los kits se usa un LCD16x2 paralelo cuando lo ideal sería un I2C.
Esos kits, aunque carillos, están bien para iniciar prácticas de arduino a nivel general, pero para preparar un controlador de acuario, por ejemplo siguiendo el Cao01, o otro similar que tu desarrolles deberías centrarte en los componentes que se necesitan para el Cao01 o si quieres empezar mas despacio en el Programador Básico de Acuario. Porque muchas de los módulos de esos kits no los utilizarás nunca.

Y aunque en amazon se encuentran buenas cosas, sale mas rentables comprarlos en aliexpress o a lo sumo ebay o banggood.
(26-02-2016, 11:57 AM)Antonio Castro escribió: [ -> ]Yo me decantaría por el SunFounder porque se han tomado la molestia de editar un libro de prácticas que tiene buena pinta y ponen los ejemplos en un CD. Eso te permitirá avanzar muy rápido. Además trae dos breadboard (pequeña y grande) y una protoboard para desarrrollar un escudo arduino (shield)
Buenos días Antonio, gracias por la recomendación lo tomaré en cuenta, estube investigando hoy y este kit es uno de los que más recomiendan.

(26-02-2016, 12:07 PM)ArturoS escribió: [ -> ]Esos kits, aunque carillos, están bien para iniciar prácticas de arduino a nivel general, pero para preparar un controlador de acuario, por ejemplo siguiendo el Cao01, o otro similar que tu desarrolles deberías centrarte en los componentes que se necesitan para el Cao01 o si quieres empezar mas despacio en el Programador Básico de Acuario. Porque muchas de los módulos de esos kits no los utilizarás nunca.

Y aunque en amazon se encuentran buenas cosas, sale mas rentables comprarlos en aliexpress o a lo sumo ebay o banggood.

Buenos días Arturo gracias por tu respuesta, la idea es primero hacer muchas prácticas de las que vienen en los kits ya que aunque sé programar no sé nada de electrónica y mucho menos de arduino. Estuve leyendo los componentes que trae y trae cosas como nivel de agua y temperatura por lo que creo que esos los podré reutilizar Smile Sobre lo de comprar en Amazon, es pq tengo la suscripción premium pagada, por lo que si pago hoy la placa el martes a lo sumo lo tengo y en aliexpress tardan hasta 45 días, no obstante el resto de los componentes necesarios los iré comprando en dx o aliexpress para que lleguen cuando estimo comenzaré el montaje.

Perdonen si mezclo algo, pero ayer leí informaciones sobre sensores para arduino que miden amoniaco e incluso alguna para nitritos, puede que parezca tonto pero ¿esas se pueden utilizar para medir los parámetros de nuestros acuarios?
Habría que consultar detenidamente las especificaciones de los sensores, para conocer que niveles de sensibilidad tienen, en acuarios esos compuestos se miden en valores por debajo de 1 ppm o en ese orden de magnitud, ademas de que sean sensores para medio acuoso y no aéreo. Y siendo algo poco común, no me hago una idea del precio que pueden tener.