Calificación:
  • 1 voto(s) - 4 Media
  • 1
  • 2
  • 3
  • 4
  • 5
Estacion Meteorologica
#81
Thorontir escribió:
Triggerr escribió:Poner en modo sleep el arduino y en powerdown el modulo de comunicacion, y enviar datos cada 5 segundos o similar. El problema que me encuentro al hacer esto, es que la estacion interior, en caso de mirar el menu de temperaturas y demas, estaria unos segundos sin recibir datos, por lo que no podria mostrar nada, entonces nos planteamos, si poner un mensaje en plan "ACTUALIZANDO", hasta recibir datos, o transmitir de modo continuado, vamos tener siempre activo el arduino. En la practica es lo mas sencillo, pero en consumos....

¿Pero cual es el problema? ¿Si entras en los menús no puedes atender interrupciones de comunicación? ¿O no va por interrupción? Lo digo por que si lo puedes atender "en segundo plano" y dejarte los datos ahí para cuando salgas del menu, se acaba el problema. De hecho, 5 segundos me parece hasta demasiado, salvo que alguna de las variables cambie muy deprisa, pero dudo que para temperatura o humedad necesites medir más de una vez por minuto. O cada 5 minutos, incluso... ¿Cuanto puede variar la temperatura o humedad ambiente en ese tiempo?

El problema, si se puede llamar asi, es que tenemos un menu principal, que es el de reloj, el cual debe de actualizarse constantemente para mostrar la hora correctamente. En prinicipio no pensaba usar interrupciones para la comunicacion, aparte porque en la estacion interior ya tengo los pines de interrupciones cubiertos.

Podria actualizar esos datos tambien en el menu de reloj, pero no quisiera hacer mas pesado ese menu, nose si se me entiende, meter la funcion de lectura inalambrica implica mas tiempo para ejecutar ese menu. Aunque nose hasta que punto seria critico.

El tiempo de actualizacion como bien dices no es un tema critico, se puede poner 5 segundos, 30 o un minuto.

Es mas que nada por el tema de intentar reducir el consumo, y hacer la estacion exterior totalmente autonoma. Porque sino me daba igual estar enviado datos constantemente eso me es lo de menos, lo que me interesa saber es si seria capaz de sostenerse el sistema con una bateria y un panel solar. Por eso me planteo el echo de usar el WTD del Arduino, y ponerlo en SLEEP mientras no estemos actualizando, para reducir el consumo al minimo, pero volvemos a lo mismo, igual es sostenible un consumo de 40-50mA sin recurrir al WTD

Luego tengo una duda, estaba leyendo un codigo, y me he encontrado con esto:

Código:
if ( prescalar & 8)

Siendo prescalar un entero de tamaño BYTE, cuando entrariamos en ese if?

Un Saludo y Gracias
Citar
#82
Triggerr escribió:El problema, si se puede llamar asi, es que tenemos un menu principal, que es el de reloj, el cual debe de actualizarse constantemente para mostrar la hora correctamente. En prinicipio no pensaba usar interrupciones para la comunicacion, aparte porque en la estacion interior ya tengo los pines de interrupciones cubiertos.

Ya he dicho más de una vez que de Arduino yo poco, pero... ¿No puede generar interrupción al recibir trama de datos? Lo digo por lo que dices de que "tienes los pines de interrupciones cubiertos". No se, si comunicas por UART/I2C/Loquesea es raro que eso no te pueda genera interrupción, guardarlo en un buffer, y mostrarlo al salir del menú.


Triggerr escribió:Luego tengo una duda, estaba leyendo un codigo, y me he encontrado con esto:

Código:
if ( prescalar & 8)

Siendo prescalar un entero de tamaño BYTE, cuando entrariamos en ese if?

Cuando el bit 3 esté a 1. Piensa que ese código equivale a
Código:
if (prescalar & 00001000) // 8 en binario

[EDIT: Ahora que lo pienso, igual te raya la máscara. Fíjarte que pone & y no &&, es decir, está comparando bit por bit, y mirando si da algo distinto de 0. Al ser un Y, para que de distinto de 0 comparando con 00001000 sólo puede ser si prescalar tiene un 1 en esa posición, es decir, entrará si vale xxxx1xxx sin importar los valores de cada x]

De la autonomía usando el panel para recargar ahora mismo ni idea. si saco un rato le pego un vistazo
Citar
#83
Thorontir escribió:Ya he dicho más de una vez que de Arduino yo poco, pero... ¿No puede generar interrupción al recibir trama de datos? Lo digo por lo que dices de que "tienes los pines de interrupciones cubiertos". No se, si comunicas por UART/I2C/Loquesea es raro que eso no te pueda genera interrupción, guardarlo en un buffer, y mostrarlo al salir del menú.


Cuando el bit 3 esté a 1. Piensa que ese código equivale a
Código:
if (prescalar & 00001000) // 8 en binario

[EDIT: Ahora que lo pienso, igual te raya la máscara. Fíjarte que pone & y no &&, es decir, está comparando bit por bit, y mirando si da algo distinto de 0. Al ser un Y, para que de distinto de 0 comparando con 00001000 sólo puede ser si prescalar tiene un 1 en esa posición, es decir, entrará si vale xxxx1xxx sin importar los valores de cada x]

De la autonomía usando el panel para recargar ahora mismo ni idea. si saco un rato le pego un vistazo

Muchas Gracias. El problema es que Arduino, en algunos aspectos esta capado, por ejemplo, si quisiera usar el WTD, tendria que usar un Bootloader diferente al original. He mirado el Data del 328 que monta el nano por encima y seguramente tenga la caracteristica que comentas, pero lo que te digo, al tener un Bootloader no esta disponible.
Citar
#84
Acabo de tirarme a la piscina, para hacer pruebas solidas, he comprado:

http://www.ebay.es/itm/350895968013?ssPa...1497.l2649

Veremos que pasa...

Ahora me pondre a leer sobre WTD, librerias del NRF comunicacion y demas, asique quizas tarde en haber avances, pero llegara el dia en que este proyecto finalice¡¡ jajajaj

Un Saludo¡
Citar
#85
Si vas a usar el watchdog y ello implica quitar el bootloader de Arduino e ir "a pelo" igual no te compensa mirar el watchdog... al menos no para eso. Me explico: lo lógico es que tenga rutinas para despertar al micro por interrupción (Sea por un timer que se queda en marcha aunque duermas la CPU, sea por la UART si llegan datos, etc). El watchdog normalmente es sólo para evitar que el micro se quede frito por algún motivo extraño, aunque obviamente puedes usarlo para lo que quieres, pero reiniciarte cada vez que te tengas que despertar va a consumir más que el proceso "normal" de despertar casi seguro.
Citar
#86
Thorontir escribió:Si vas a usar el watchdog y ello implica quitar el bootloader de Arduino e ir "a pelo" igual no te compensa mirar el watchdog... al menos no para eso. Me explico: lo lógico es que tenga rutinas para despertar al micro por interrupción (Sea por un timer que se queda en marcha aunque duermas la CPU, sea por la UART si llegan datos, etc). El watchdog normalmente es sólo para evitar que el micro se quede frito por algún motivo extraño, aunque obviamente puedes usarlo para lo que quieres, pero reiniciarte cada vez que te tengas que despertar va a consumir más que el proceso "normal" de despertar casi seguro.

Creo que por ahora no usare el WTD, y probare a hacer la comunicacion sin dormir ni los micros ni los NRFs, veremos como va el asunto.

Cuando duermes un AVR, y salta el WTD, reinicia el micro, o vuelve a la linea donde se durmio el micro?

Otro tema, algo no me encaja:

En la funcion para configurar el WTD;

Código:
void setup_watchdog(uint8_t prescalar)
{
  prescalar = min(9,prescalar);
  uint8_t wdtcsr = prescalar & 7;
  if ( prescalar & 8 )
    wdtcsr |= _BV(WDP3);

  MCUSR &= ~_BV(WDRF);
  WDTCSR = _BV(WDCE) | _BV(WDE);
  WDTCSR = _BV(WDCE) | wdtcsr | _BV(WDIE);
}

En la linea 2 de la funcion, tenemos que preescalar es un numero de tamaño BYTE comprendido entre 0-9, por tanto, si aplicamos el operando & con un 7, que en binario seria "00000111", el cuarto BYTE del resultado jamas sera "1", por tanto, jamas entras en el IF. El IF compara prescalar, y si es igual que 8, que seria el patron entra en el IF, es una mascara como bien me comentaste pero opera BIT a BIT. Me siento confuso jajajaja

EDITO: Estoy tonto....que el dato que maneja el IF es prescalar, no wdtcsr...., vamos que prescalar puede ser 8 perfectamente....jajajajajaj
Citar
#87
Triggerr escribió:Cuando duermes un AVR, y salta el WTD, reinicia el micro, o vuelve a la linea donde se durmio el micro?

Si no me equivoco, como te decía, con el watchdog vas a reiniciar el micro, mientras que si lo despiertas por otros medios volverá a donde lo pusiste a dormir. O quizá en los uc de atmel es distinto...

Triggerr escribió:Otro tema, algo no me encaja:

En la funcion para configurar el WTD;

Código:
void setup_watchdog(uint8_t prescalar)
{
  prescalar = min(9,prescalar);
  uint8_t wdtcsr = prescalar & 7;
  if ( prescalar & 8 )
    wdtcsr |= _BV(WDP3);

  MCUSR &= ~_BV(WDRF);
  WDTCSR = _BV(WDCE) | _BV(WDE);
  WDTCSR = _BV(WDCE) | wdtcsr | _BV(WDIE);
}

En la linea 2 de la funcion, tenemos que preescalar es un numero de tamaño BYTE comprendido entre 0-9, por tanto, si aplicamos el operando & con un 7, que en binario seria "00000111", el cuarto BYTE del resultado jamas sera "1", por tanto, jamas entras en el IF. El IF compara prescalar, y si es igual que 8, que seria el patron entra en el IF, es una mascara como bien me comentaste pero opera BIT a BIT. Me siento confuso jajajaja

EDITO: Estoy tonto....que el dato que maneja el IF es prescalar, no wdtcsr...., vamos que prescalar puede ser 8 perfectamente....jajajajajaj

Puedo equivocarme, pero entiendo que lo que hace esa función es:
1) Si prescalar > 9 lo deja en 9, si no, como estaba.
2) wdtcsr = los tres bits menos significativos de prescalar (7 = 00000111)
3) Si prescalar era 8 (Imagino que será algún caso especial) pone a uno mediante la máscara or lo que quiera que valga _BV(WDP3); A partir de ahí, más de lo mismo, imagino que son las cosas distintas del prescalar las que va poniendo a un valor o a otro. Pero es una forma un poco rara/enrevesada, ¿No? Tanto flag sin explicaciones...
Citar
#88
Thorontir escribió:Puedo equivocarme, pero entiendo que lo que hace esa función es:
1) Si prescalar > 9 lo deja en 9, si no, como estaba.
2) wdtcsr = los tres bits menos significativos de prescalar (7 = 00000111)
3) Si prescalar era 8 (Imagino que será algún caso especial) pone a uno mediante la máscara or lo que quiera que valga _BV(WDP3); A partir de ahí, más de lo mismo, imagino que son las cosas distintas del prescalar las que va poniendo a un valor o a otro. Pero es una forma un poco rara/enrevesada, ¿No? Tanto flag sin explicaciones...

Bueno, voy a poner la funcion entera, es para la configuracion de WTD, a mi parecer, me parece muy atravesado pero nose, sera la forma idonea de programarlo....

Código:
// 0=16ms, 1=32ms,2=64ms,3=125ms,4=250ms,5=500ms
// 6=1 sec,7=2 sec, 8=4 sec, 9= 8sec

void setup_watchdog(uint8_t prescalar)
{
  prescalar = min(9,prescalar);
  uint8_t wdtcsr = prescalar & 7;
  if ( prescalar & 8 )
    wdtcsr |= _BV(WDP3);

  MCUSR &= ~_BV(WDRF);
  WDTCSR = _BV(WDCE) | _BV(WDE);
  WDTCSR = _BV(WDCE) | wdtcsr | _BV(WDIE);
}

La cuestion es, que si en el IF solo entra cuando el valor de prescalar es 8, cuando sea 9, no entrara, y es necesario asignar el valor 1 al bit WDP3 ya que necesitamos "1001"

_BV() es una funcion para asignacion de BITS. En principio en la linea de:

Código:
wdtcsr |= _BV(WDP3);

El asignador OR, hace que si hay un 1 en la cadena de BITS de wdtcsr la asignacion a WDP3 sea 1 si no me equivoco.

Pero tambien debiera de asignarlo cuando el valor de prescalar es 9......ya que la mascara anterior, desecha el BIT mas significativo del 9 que seria el 1.
Citar
#89
Para el WTD tienes una librería que hablan muy bien de ella, narcoleptic.h , no sé si la conocías.

P.d: La entrada del modo sleep tiene que esperar, que tengo toda la teoría y los distintos métodos pero en la práctica no me funciona.. xD
Citar
#90
jukillo escribió:Para el WTD tienes una librería que hablan muy bien de ella, narcoleptic.h , no sé si la conocías.

P.d: La entrada del modo sleep tiene que esperar, que tengo toda la teoría y los distintos métodos pero en la práctica no me funciona.. xD

Jukillo, creo que con el bootloader de serie no puedes implementar ni el sleep ni el WTD...., ya que no debe de tener los FUSES configurados para ello imagino. Tengo en el portatil una web donde lo explican, cuando me acuerde lo pongo por aqui.

Echare un ojo a esa libreria de la que me hablas

EDIT: De todas formas, en principio el WTD y el sleep son cosas distintas, quiero decir, en el caso que yo expongo, se emplea el WTD para revivir el Micro despues de un Sleep

Un Saludo¡¡
Citar
#91
Si si, te entiendo. WTD es para interrupciones, y para versiones antiguas hay que actualizar el bootloader. Sin embargo para los modos sleep no he leído nada sobre actualizar bootloader.

La librería narcoleptic te ofrece la función Narcoleptic.delay() para dormir el micro y despertarlo por desbordamiento del WTD.
Citar
#92
jukillo escribió:Si si, te entiendo. WTD es para interrupciones, y para versiones antiguas hay que actualizar el bootloader. Sin embargo para los modos sleep no he leído nada sobre actualizar bootloader.

La librería narcoleptic te ofrece la función Narcoleptic.delay() para dormir el micro y despertarlo por desbordamiento del WTD.

Umm pues puede estar interesante, el tema es que nos tocara cambiar el bootloader si o si, porque por mucha libreria que metamos, si no lo configuras en el bootloader no funcionara. Es una suposicion pero creo que sera asi, esta tarde lo echo un ojo.

Enviado desde mi Nexus 4 mediante Tapatalk
Citar
#93
Mola
Citar
#94
Bueno, creo que ya tengo el tema del IF

Código:
if ( prescalar & 8 )

Al final es como decias al principio Thorontir, solo pasa cuando tenemos un 1 en el cuarto BIT de prescale, es decir, no funciona como un patron, sino mas bien como una mascara.

Ahora todo empieza a cobrar sentido.

Acabo de recibir el DS3231

resim

He buscado una libreria que se adapte a la que ya tenia del otro DS1307, ya que asi me ahorro cambiar demasiado codigo y la he encontrado, ya lo tengo funcionando, veremos si es mas preciso.

Tambien me a llegado el MQ135 sensor de gases, tengo que hacer pruebas sobre el mismo, para ver como funciona.
Citar
#95
Estoy peleandome con la comunicacion inalambrica. El tema seria el siguiente, la estacion exterior esta tomando datos de los sensores constantemente. La estacion interior debiera de enviar un mensaje a la exterior, solicitando actualizacion de datos cada X tiempo, a lo que la estacion exterior, al recibir dicho mensaje, debe de contestar a la estacion interior con la estructura de datos.

La comunicacion funciona correctamente, pero me esta costando implementar esta funcion, la libreria es bastante compleja, y tienes muchas opciones. Otra de la opcion seria usar interrupciones en el exterior, para que al recibir un mensaje, entrar en una funcion que envie los datos, pero tengo que mirarlo mas a fondo.

Espero para finales de esta semana tener la comunicacion ya OK, una vez con la comunicacion funcionando va todo de corrido, ya que es programar cosillas faciles, como maximos, minimos y demas.

El modulo de tiempo, posee salidas para hacer interrupciones para la alarma, pero no me es posible hacerlo de este modo ya que las entradas con interrupciones las tengo ocupadas.

Mañana mas
Citar
#96
Tras toda la tarde luchando para acabar con el tema de la comunicacion, a falta de pruebas creo que tengo algo util¡¡ jajajajajaj

Explico en el video como lo ago. La libreria es la RF24, y consegui una que no me diera problemas con el DHT22, para el cual suprimi el delay(2000), y puse una implementacion con millis() para no tener al micro parado....






Ya queda menos camino por recorrer, si mañana me da tiempo tengo que hacer las funciones para registrar maximos y minimos....

Mañana mas
Citar
#97
Bueno, he estado analizando el comportamiento de los sensores de GASES y LLUVIA, y las conclusiones son las siguientes.

MQ135

EL problema de este sensor, es que para realizar medidas adecuadas, lo optimo es un tiempo de precalentamiento de 24h, y no solo eso, sino que tenemos un consumos de mas de 100mA, consumo al que no puedo hacer frente en la estacion exterior con la bateria y demas.

Por tanto para no obtener nada preciso ni concreto voy a prescindir de este sensor.

SENSOR DE LLUVIA

El sensor de lluvia se basa en una placa con un diseño en zigzag, al variar la resistencia al tocarle el agua actuamos sobre un OAMP y entregamos una salida en caso de detectar liquidos sobre la placa.

El problema de este sensor, no tanto el consumo que son 7 mA, viene en cuanto a la recuperacion del mismo, quiero decir, en caso de llover. La placa se queda un tiempo con las gotas de agua, por tanto seguiriamos detectando que llueve, cosa que realmente tampoco es interesante. A lo sumo podriamos detectar si en algun momento del dia se ha puesto a llover, pero poco mas...., nose realmente si ponerlo o no.

Alguna sugerencias?

Muchas Gracias
Citar
#98
Seguimos tirando para adelante, he tenido unos dias duros jajajaja, vereis, a la hora de enviar los datos el tamaño maximo de PAYLOAD es de 32Bytes, y lo superaba, en concreto mandaba 36, por lo que no entraba todo. Por lo cual he realizado algunas conversiones de los datos, de float a unsigned INT para que entrara todo, y ahora funciona perfecto.

En principio tengo la comunicacion acabada, y tambien todos los menus, a falta de pulir detalles, añadir alguna funcionalidad, y cosillas asi, pero la cosa poco a poco avanza.






He empezado tambien con el diseño de la placa de la estacion interior, porque me acaban sangrando los ojos de programar y programar, y nunca esta de mas cambiar, dejo por aqui un pantallazo:

resim

Me queda de añadir el regulador de 3.3V, algunos modulos, un PIC 12f508 para pilotar el BUZZER de la alarma y demas historias....
Citar
#99
Queda un poco batiburrillo tanto cable por encima de otros no? Para algunas cosas como los conectores queda mejor si pones solo un trozo de cable y le das el mismo nombre que al cable donde tiene que ir conectado. Aunque en el esquema no este unido al tener el mismo identificador hará el mismo efecto cuando diseñes el circuito.

Algo así me refiero:

resim

En cuanto a los sensores de lluvia, si solo quieres medir si llueve o no, quizás podrías investigar sobre los que se basan en el reflejo de la luz (los montados en los coches)

Aunque lo realmente interesante si tienes un sitio para montarlo seria poner un sensor que mida cuanto ha llovido, aunque para eso el Arduino exterior tendría que estar midiendo la lluvia todo el rato y afectaría al consumo :/

http://www.jim-easterbrook.me.uk/weather/rain/
http://www.edcheung.com/automa/rain.htm
giltesa.com Mi blog personal sobre informática, electrónica, Arduino, bricolaje, etc.
Citar
giltesa escribió:Queda un poco batiburrillo tanto cable por encima de otros no? Para algunas cosas como los conectores queda mejor si pones solo un trozo de cable y le das el mismo nombre que al cable donde tiene que ir conectado. Aunque en el esquema no este unido al tener el mismo identificador hará el mismo efecto cuando diseñes el circuito.

Algo así me refiero:

resim

En cuanto a los sensores de lluvia, si solo quieres medir si llueve o no, quizás podrías investigar sobre los que se basan en el reflejo de la luz (los montados en los coches)

Aunque lo realmente interesante si tienes un sitio para montarlo seria poner un sensor que mida cuanto ha llovido, aunque para eso el Arduino exterior tendría que estar midiendo la lluvia todo el rato y afectaría al consumo :/

http://www.jim-easterbrook.me.uk/weather/rain/
http://www.edcheung.com/automa/rain.htm

Quedaria mucho mas apañado sin duda, ese programa es el EAGLE?, nunca me he puesto a hacer diseños grandes y se me va de las manos..., controlo mas de ORCAD, pero me es incomodisimo. Voy a ver que se puede hacer.

El tema de la lluvia, es que en principio yo vivo en un piso, y no puedo poner algo muy grande en la fachada, podria estar bien algun sensor por reflexion de la luz o similar, pero nose hasta que punto afectaria al consumo. Tenemos que tener en cuenta que los sensores que estoy usando, estan muy bien optimizados energeticamente, en cuanto te vas a sensores mas "analogicos" me he dado cuenta que el consumo se me va de las manos....
Citar


Temas similares...
Tema Autor Respuestas Vistas Último mensaje
  Estación meteorológica v2 - giltesa giltesa 68 10,843 18-10-2014, 06:08 PM
Último mensaje: giltesa