Després d'uns quants mesos funcionant, el datalogger v1.0, descrit en el projecte ha funcionat molt bé, sense cap incidència rellevant, però ha exigit tenir sempre l'ordinador engegat. Quan per algun motiu ha marxat el corrent l'ordinador s'ha reiniciat però no sempre el port sèrie ha connectat amb l'Arduino, perdent la informació del sensor durant aquest període. Per tant vaig decidir pensar un datalogger més robust, seguint les idees que ja vaig apuntar a jardiNet.

Resumint una mica aquestes són les noves prestacions del datalogger:

  • Arduino Mega 2560.

    Només dues consideracions: l'Arduino Uno té només 32KB de memòria i el Mega 256, amb totes les prestacions a incorporar caldria un bon programador i a mi encara em falta una mica per encabir-ho tot el 32KB, tot i això la versió final del codi ocupa uns 36KB, o sigui que no estaria gaire lluny d'encabir-ho en un Uno, si no fos que al tenir només un port sèrie ens limita la connectivitat. El Mega en té 4 i això ha estat definitiu per la versatilitat: alimento el conjunt pel connector USB associat al port sèrie 0 i utilitzo el port sèrie 3 per la connexió amb l'ordinador. Penseu a més que el port sèrie també l'utilitza el XBee.

  • Afegir un sistema de fitxers.

    Cal doncs algun shield amb una tarja SD i que a més pugui suportar un XBee. N'he provat un parell: 'Arduino Wireless SD Shield' i 'Adafruit Assembled Data Logging shield for Arduino' però al final vaig decidir utilitzar el component d'Adafruit perquè incorpora connectors pels pins SCL i SDA de l'Arduino Mega que necessitarem per la pantalla (Arduino pinout 1.0), que l'altre no té, i requereix soldar un parell de fils.

    Dir també que hi ha avantatges en l'ús del shield d'Arduino: es pot fer servir una versió actuatlizada de la llibreria sdfat, en comptes de la SD incorporada a l'entorn de desenvolupament. Sembla una tonteria però la llibreria SD estàndard no suporta renombrar fitxers i he hagut de fer una rutina per copiar i esborrar, una mica cutre la veritat. Finalment l'Arduino shield té un interruptor que permet seleccionar la connectivitat del port sèrie 0 de l'Arduino, el qual és molt útil al provar codi, doncs no cal treure el Xbee cada vegada que volem pujar codi, bé al final acabes posant el XBee en un protoboard amb un interruptor...

  • Afegir un rellotge (Real Time Clock).

    Cal que l'Arduino pugui generar el temps en que reb cada mostra. Fins ara ho feia el Mac al rebre el paquet sèrie des de l'Arduino, però si volem un datalogger autònom ha de ser capaç de generar el seu propi temps. Per tant he mirat quins RTC es poden afegir fàcilment al Mega: Pel Arduino Wireless SD shield he provat sense problemes un RTC independent com el Adafruit 264, però com que he utilitzat shield d'Adafruit que ja porta incorporat el RTC simplifico el problema. D'altra banda si feu servir un RTC d'Adafruit caldrà utilitzar la llibreria RTClib a l'entorn de desenvolupament de l'Arduino. Finalment, pel shield d'Adafruit cal instal·lar una versió modificada de la llibreria SD. Ambdues les trobareu a learn.adafruit.com

  • Substituir l'aplicació arduinoToSQLite.

    Finalment he canviat el codi Objective-C de l'arduintoToSQLite per un script python. En resum he canviat 1.500 línies de codi més altres recursos com el disseny de l'interfície d'usuari (no tot el codi és meu doncs vaig començar amb codi d'exemple) per un script de 150 línies. Python és molt potent a l'hora de processar dades i interpretar-ne el format. Tot i això cal dir que he substituït una interfície gràfica molt robusta per un fitxer de configuració, però també funciona !!

  • Afegir una pantalla amb teclat.

    Potser és un luxe afegit, perquè realment no hi ha cap funcionalitat que no és pugui fer sense la pantalla, però un cop instal·lada i funcionant ajuda molt, en el diagnòstic del datalogger, per actualitzar l'hora del rellotge, o per veure la darrera lectura del sensor. Al final he escollit l' Adafruit RGB LCD Shield 16x2. Però el procés de muntatge l'he variat una mica seguint el post del fòrum d'Adafruit per poder gestionar les interrupcions del teclat des de l'Arduino. Només cal soldar un cable al display (pin 20 del MCP23017) i modificar les llibreries que proporciona Adafruit per aquest display.

  • Més ports sèrie.

    Com ja he dit abans el Mega té 4 ports sèrie i el nou datalogger en necessita 2. L'Arduino Uno en te un només però cal dir que quan el XBee rep dades i les envia a l'Arduino, el port sèrie 0 segueix connectat al convertidor USB-to-serial, per tant es pot enviar a l'ordinador el que es va rebent del sensor, però desafortunadament això impedeix que l'Arduino es pugui programar. Ara estic fent servir el port 0 per alimentar la bèstia i per rebre dades des del XBee i he afegit un USB-to-serial al port 3, Adafruit FTDI friend, per a la connectivitat amb l'ordinador.

Tot i que la funcionalitat del datalogger ja està descrita a jardiNet v1.0 descriuré breument les prestacions i la seva implementació.

El nou datalogger está format per les següents peces: Arduino Mega 2560, que suporta la resta d'escuts. A sobre hi té connectat l'escut 'Adafruit Data Logging shield for Arduino (1141)' i a dalt tenim el display 'RGB LCD Shield Kit w/ 16x2 Character Display (714)' també d'Adafruit. El 'Adafruit FTDI Friend (284)' està cablejat directament al Mega:




Ja sabeu que la programació de l'Arduino utilitza el port sèrie 0 i això genera un conflicte amb el XBee que també l'utilitza, doncs si tenim connectat el XBee no podem programar l'Arduino i cal extreure'l de l'escut per fer-ho. Això no és gens eficient i es corre el risc d'acabar espatllant algun pin dels components, per tant vaig muntar el XBee sobre un 'SparkFun XBee Explorer (WRL-09132)' i vaig cablejar un interruptor del pin DOUT del XBee cap al shield, com mostra la foto. Ara per programar l'Arduino només cal accionar l'interruptor, més senzill i sense risc d'espatllar res:




Durant les proves i la programació, vaig utilitzar un XBee directament muntat sobre un XBee Explorer, programat de tal manera que ens envia una mostra de les entrades analògiques cada minut, bàsicament soroll, es clar, però efectiu. Finalment amb el XBee instal·lat al shield, l'aspecte del datalogger és més o menys això:




Les següents taules resumeixen totes les connexions realitzades en els diferents shields amb l'Arduino Mega:

Arduino Mega 2560 pin Adafruit Data Logging shield for Arduino (1141)
3.3V 1 Vcc XBee
GND 10 GND XBee
0 RX 2 DOUT, TX XBee
1 TX 3 DIN, RX XBee
10 CS (SS) pin as OUTPUT in Arduino
11 SPI
12 SPI
13 SPI
Arduino Mega 2560 pin Adafruit 264 (FTDI Friend, serial to USB)
14 TX3 RX1
15 RX3 TX1
GND (costat pin 53) GND
31 Vcc
Arduino Mega 2560 pin Adafruit 714 (RGB LCD shield 16x2)
3 INTA (MCP23017)
20 SDA (posició Arduino UNO) SDA
21 SCL (posició Arduino UNO) SCL

El flux de les dades es processa de forma una mica diferent que la versió 1.0. Ara el propi datalogger realitza la conversió dels valors llegits a les entrades analògiques del XBee a milivolts, d'aquesta forma és completament transparent en el flux de dades (abans la conversió es realitzava a l'hora de guardar les dades a sqlite). A la base de dades es guarden doncs els valors en mVolts proporcionats pel sensor i és finalment el servei web, codi python, que llegeix la base de dades i aplica la fórmula per convertir aquests mVolts en VWC%, o sigui que el valor final s'obté just en el moment de consultar les dades via web.

Només comentar que prefereixo fer el darrer càlcul a la pàgina web i guardar les lectures del sensor en mVolts a la base de dades, doncs ara utilitzo la fòrmula estàndard del fabricant, però també es recomana que per a millor precisió es pot obtenir una nova fórmula mitjançant la calibració del sensor, llavors només hauria de canviar el codi del servei per ajustar-ho, sense haver de convertir les dades enlloc.




El més important a destacar és la substitució del codi Objective-C per codi python que és independent de plataforma. La versió que hi ha a MacOS X 10.8.5 és python v2.7.2 i és la que he fet servir en totes les proves. Cal dir que a python cal afegir-hi el mòdul serial, que es pot trobar a pySerial

El codi a l'Arduino ha canviat substancialment, si bé el nucli de codi que gestiona el XBee no ha canviat gaire. El codi s'ha embolicat molt a l'haver de gestionar el teclat del display, doncs si bé l'Arduino pot gestionar interrupcions i el display és capaç de generar-ne a l'utilitzar les tecles, l'Arduino no disposa d'una arquitectura multi-thread i per tant tot el codi acaba barrejat i és poc entenidor, però funciona !!

El codi ara sempre emmagatzema les dades del sensor a la tarja SD i si per algun motiu no hi ha connexió amb l'ordinador llavors aquestes dades s'etiqueten amb el prefix 'PENDENT:'. D'aquesta forma quan l'Arduino detecta que s'ha restablert la connexió amb l'ordinador, es rellegeix el fitxer de dades i s'envien a l'ordinador. El fitxer es còpia a un subdirectori a la tarja SD i es genera un nou fitxer.

El següent diagrama descriu a grans trets com funciona el codi de l'Arduino:




La funció handshake() s'executa dins el loop() i serveix per a gestionar la connexió amb l'ordinador, així l'Arduino sap si ha d'enviar la informació a la base de dades o només l'ha de emmagatzemar a la tarja SD. Hi ha d'haver un compromís entre la freqüència d'execució del handshake() i el temps del loop() que es destina a la recepció de packets XBee. Si s'executa massa de forma freqüent correm el perill de perdre mostres del sensor. En la versió actual el handshake() s'executa cada 5 minuts i la major part de les iteracions per tant es destinen a l'execució de la funció xbee.readPacket(XBEE_TIMEOUT) que ens permet rebre les dades del sensor i processar-les.

Finalment només comentar que el codi del web service, que ja estava en python, no ha canviat.

Adjunto tot el codi que estic utilitzant: jardiNet_v2.0.zip. Si el voleu fer servir feu-ho lliurement però si el milloreu us agrairïa que m'ho enviessiu, a veure si ho puc aprofitar.

El LCD display té diferents botons que permeten una gestió bastant rudimentària de l'Arduino tot i que ha calgut modificar una mica el circuit d'Adafruit així com la llibreria proporcionada per tal de suportar les interrupcions del teclat al codi de l'Arduino. La següent taula descriu la funcionalitat de cada tecla:




Tecla Descripció
Select mode premeu successivament per escollir mode: Set date & time, Save time, XBee mode
Up Set date & time: incrementa
Down XBee mode: hora actual (no suporta DST), Set date & time: decrementa
<-- (Left) XBee mode: darrera lectura sensor, Set date & time: mou cursor
--> (Right) XBee mode: estat tarja SD i connexió ordinador, Set date & time: mou cursor
Reset Reinicia l'Arduino
Brightness Ajusta la brillantor de la pantalla, cal un tornavís

Notes:

  • XBee mode: l'Arduino està esperant lectures del sensor via XBee i les envia a la tarja SD i a l'ordinador si està connectat. Si no està connectat es guarden a la tarja SD i es volcaran de cop quan la connexió amb l'ordinador s'activi. És el mode per defecte i les tecles Down, Left, Right mostren informació del sistema.
  • Select mode: funcions bàsiques d'ajust del rellotge incorporat, alerta, en aquest mode s'ignoren les lectures del XBee. Set date & time, permet ajustar l'hora a l'Arduino, per defecte apareix el valor del darrer upload del codi a l'Arduino. Save time grava la nova hora a l'Arduino. Set time demana confirmació i cal prémer el botó esquerra (<--), també cal fer-ho per tornar al mode XBee.

El projecte 1.0 ja és història i el 2.0 ha canviat només el datalogger, però ara estic pensant en el 3.0. Us passo la carta als reis doncs això no s'acaba mai!!

  • Pendent des de la versió 1.0:

    M'agradaria integrar tots els components del sensor en un únic circuit. L'Adafruit 390 és un circuit molt versàtil per a molts projectes però per aquest en concret m'agradaria modificar-lo per donar 3,3Volts a la sortida, sense haver de regular-la i a més disposar dels sockets per integrar el XBee directament i ja posats a demanar deixar espai lliure per poder integrar-hi altres components com els sensors. Els esquemes i plànols del circuit estan disponibles al github i són el millor punt de partida però desconec les implicacions legals d'aprofitar-ho. A veure si animo algú !!

  • Més autonomia per a l'Arduino i evitar la dependència del servidor…

    El datalogger 2.0 ha suposat un gran avanç en aquest punt però encara necessitem un ordinador per guardar les dades i servir-les per internet, sobretot si volem les dades en temps real. Per tant un datalogger 3.0 ha de ser completament independent, sense necessitat de passar res a un ordinador. Estic valorant l'utilització d'Arduinos híbrids con el Arduino Yún o el Arduino Tre, que son Arduinos amb un processador capaç d'executar versions de Linux, amb suficient memòria RAM (64MB el Yún i 512MB el Tre), i amb Ethernet/SD incorporat. La part servidora de l'Arduino/Linux ha de poder executar SQLite per a guardar-hi les dades del sensor i el servidor web Cherrypy. El Yún està disponible a dia d'avui però pel Tre s'haurà d'esperar a principis del 2014, així em donaré un descans...

  • Obrir l'aixeta

    Finalment, acabar el projecte amb una estació actuadora per obrir l'aixeta remotament quan les condicions de sequedat ho necessitin i regar l'hort. Amb les mateixes prestacions d'autonomia que té el circuit sensor. Posat's a demanar suposo que afegiré alguna pàgina a la web per regar des d'internet o des del datalogger mateix. Aquí entrarem en un camp nou, doncs caldrà proveïr el maslestorres.cat amb algun nivell de seguretat addicional.