Ardu-Aquarium Controller v. 3.3.1

riciweb:
Ciao Testato
Con OneWire si può pilotare anche il display?

ho visto farlo sia via shift register che con ulteriore micro dedicato. considera che pur sempre un altro chip devi usare, anche con i2c useresti un chip intermedio tra il bus ed il display. E' anche vero pero' che esistono display COG che sono direttamente I2C (vedi mia firma), non ne ho visti invece direttamente OneWire per ora.
Ma ripeto, se la tua idea e' usare un display standard a cui aggiungere un chip allora i componenti da usare restano numericamente uguali. Io pero' non l'ho mai fatto, sarebbe interessante approfondire, se decidete di andare verso questa strada fo qualche prova anche io
http://mbed.org/cookbook/1-wire-shifting-2x16-LCD

PaoloP:
Usa il "CaneDaGuardia". :wink:

--> http://www.logicaprogrammabile.it/arduino-resettare-automaticamente-la-scheda-utilizzando-il-watchdog-timer/

Grazie Paolo,
ho letto, mi piace e sicuramente se ne terrà conto.

Etemenanki:
...
Il sistema a ridondanza comporta semplicemente l'usare sensori doppi, ed eseguire la lettura sui vari cicli integrando i valori e discriminando quelli "illogici" ... ad esempio, se hai 2 sonde di temperatura in 2 punti diversi, ogni volta che le leggi, confronti le 2 letture ... se lo carto e' entro una tolleranza programmata (mettiamo 1 grado, per fare un'esempio", fai la media dei valori e la usi come lettura, se lo scarto inizia ad essere maggiore della tolleranza (ad esempio, una delle sonde va in corto e ti restituisce 0 gradi, o simile), oltre ad accendere un'allarme, escludi la lettura della sonda che risulta illogica.

Il sistema migliore sarebbe avere almeno 3 sonde, in questo modo avresti la (quasi) certezza di individuare con precisione quella guasta ... esempio, con 2 sonde, se una ti da 27 ed una 31, non c'e' modo sicuro per discriminare quale delle due e' imprecisa, specie se entrambe continuano a dare dati coerenti (entrambe salgono o scendono insieme ... se invece una si bloccasse e l'altra continuasse a variare, sarebbe possibile discriminare quella bloccata, che non cambia piu nel lungo periodo) ... con 3 sonde, il problema non si pone cosi difficile, se una da 27, l'altra 28, e la terza 34, e' chiaramente quella che si scosta di piu da escludere dal ciclo delle medie di lettura :wink: ... oltretutto non costano cosi care, e sarebbe fattibile abbastanza facilmente, per impermeabilizzarli basta un po di resina per barche bicomponente :wink:
A livello personale escluderei qualsiasi bus tipo "onewire", e concettualmente anche l'I2C, mettendo forse piu cavi, ma non rischiando blocchi generali dovuti alla frittura di un singolo sensore o interfaccia ... personalmente per trasferire dati analogici preferirei i current-loop, anche se poi ci si deve creare una scheda di conversione da corrente a tensione per poterli leggere, perche' quello standard e' stato realizzato per uso industriale ed e' abbastanza affidabile, anche se richiede almeno un doppino per ogni sensore (ma ripeto, e' una preferenza personale)

Già ora usiamo due sonde, di cui mediamo le letture e le confrontiamo affinche si rimanga all'interno di un certo range di temperatura (+/- 1,5°attualmente) con allarme sia visivo che sonoro, quello che non viene fatto perché non ci avevo proprio pensato è verificare quale sonda va in palla ed escluderla... un to do sicuramente.

lesto:
mi piace l'idea dei 3 sensori

A livello personale escluderei qualsiasi bus tipo "onewire", e concettualmente anche l'I2C, mettendo forse piu cavi, ma non rischiando blocchi generali dovuti alla frittura di un singolo sensore o interfaccia

questo avviene perchè sono state sviluppate male le libreire (bloccanti e senza gestione degli errori), non a caso tempo fa modificai la Wire per essere non bloccante, e quindi supportare errori sulla linea/hotplug unplug di sensori, ovviamente se previsti lato software, altrimenti sono ignorati

anche l'idea della current-loop, che ammetto di non conoscere (non capisco perchè tu parli di segnali analogici, ho cercato qualcosa ma si parla di segnali digitali, in particaolre seriali), mi pace, se dimostra di essere a prova di disturbi anche su un metro di cavo volante.
il grosso vantaggio dell'analogico è che ogni sensore sarebbe su un pin separato, e quindi se si rompe inserendo una corrente "pazza" non serve escluderlo (se invece un sensore inizia a mandare segnali a caso sul bus i2c o one-wire, bisogna disaccoppiare i sensori riattivandli uno a uno fino ad individuare la causa..)
mettere più atmega in parallelo è semplice in tutti i casi (digitali o analogici), forse nei digitali una seriale è meglio perchè è più facile "sniffare" i dati in entrambe le direzioni ache se l'arduino non è il master del bus, e quindi verificare che l'output dell'atmega in master sia corretto e allineato con quello calcolato anche dagli arduiono dormienti... :grin:

Etemenanki:
Piu che alle librerie, mi riferisco a guasti fisici ai sensori ... ad esempio, in un bus in cui tutti i segnali sono in parallelo, se una delle uscite va a massa, crea problemi a tutto quello che c'e' connesso in parallelo a quell'uscita ...
Il current loop si puo usare per trasferire valori analogici (un'uscita che varia proporzionalmente da 4mA, equivalente a zero volt di uscita, a 20mA, equivalente a fondo scala), sia digitali (modulando l'uscita come una linea seriale a due fili, solo che e' in corrente invece che in tensione) sia addirittura entrambi insieme (il protocollo HART usa la sovrapposizione di due toni FSK sulla corrente del dato analogico per trasmettere contemporaneamente un valore analogico ed uno stream digitale sullo stesso doppino) ... la robustezza della trasmissione e' garantita dal fatto che il sistema e' un'anello chiuso in cui scorrono sempre da 4 a 20 mA, indipendentemente dalla lunghezza del cavo, o dai contatti osidati (fino ad un certo punto, ovviamente :P) ... potresti avere un doppino da un metro o da 100 metri, se l'interfaccia e' fatta come si deve, sempre da 4 a 20 mA ci passano :wink: ... poi ci sono anche sistemi multipunto in cui ogni sensore ha un codice e comunica in digitale, ma non ne conosco lo standard ... ed il vantaggio e' che se ad esempio un'uscita va in corto, il sistema si autoregola per riportare i corretti valori di corrente ed al massimo e' quel sensore che non ti va piu (ed a quel punto arduino potrebbe segnalare un'allarme del tipo "sensore "X" non funzionante), ma il resto continua a funzionare.
Ovvio che se il filo si stacca e l'anello si apre non funziona piu nulla, ma quello lo fa con qualsiasi altra configurazione :stuck_out_tongue: ... a meno di non usare degli splitter, ma costano uno sproposito :fearful:

Mi piace leggervi e di fatto poi passo le giornate a googlare cercando, con scarso successo devo ammettere :blush:, di capirvi, il fatto è che così si stravolge la filosofia di tutto il progetto che poi rispecchia anche la mia attuale conoscenza di questo mondo...
Vorrei che tutto rimanesse molto easy, continuo a pensare che la vera sfida sia riuscire con Arduino UNO a fare tanto con poco e nel modo più semplice possibile...
Più avanti col tempo ci sarà sicuramente spazio per creare "Ardu-Acquarium Controller ++" ovvero più sofisticati con interfacce più avanzate e periferiche più performanti, ho in testa anche io così tante idee che non stò neanche a scrivere, ma così ho paura che non si arrivi o non si riesca a concludere.
Ho bisogno di aiuto, ma voi andate troppo avanti e troppo veloci "gna posso fa'..." oltre tutto, non so nemmeno se con arduino si possono fare tutte le cose che scrivete senza mandarlo in palla, è pur sempre un atmega328 bho... scrivo di cose che non conosco bene scusatemi :smiley:

Testato:
ho visto farlo sia via shift register che con ulteriore micro dedicato. considera che pur sempre un altro chip devi usare, anche con i2c useresti un chip intermedio tra il bus ed il display. E' anche vero pero' che esistono display COG che sono direttamente I2C (vedi mia firma), non ne ho visti invece direttamente OneWire per ora.
Ma ripeto, se la tua idea e' usare un display standard a cui aggiungere un chip allora i componenti da usare restano numericamente uguali. Io pero' non l'ho mai fatto, sarebbe interessante approfondire, se decidete di andare verso questa strada fo qualche prova anche io
http://mbed.org/cookbook/1-wire-shifting-2x16-LCD

Te lo chiedevo, perché si sta discutendo se fare tutto I2C o tutto One-Wire, è chiaro che serve un'altro chip in ogni caso, ma non sapevo se fosse una strada già percorsa da qualcuno, però grazie del tuo interessamento.

Ciao e grazie a tutti.

Riccardo

riciweb:
...il fatto è che così si stravolge la filosofia di tutto il progetto ...

Be', stravolgere i progetti altrui e' uno dei pochi, piccoli divertimenti che questa vita oppressiva e noiosa qualche rara volta ci consente ... non vorrai mica essere cosi crudele e senza cuore da negarci anche queste rare, piccole soddisfazioni, vero ? ... ]:smiley:

(scherzo, ovviamente :stuck_out_tongue: XD XD XD)

Non sia mai che io tolga divertimento e sollazzo a chicchessia :astonished: :astonished: :astonished:
Piuttosto ti ringrazio per avermi spinto a conoscere ed imparare (fai finta di crederci ti prego :blush:) nuove metodologie!!!
Rimane il fatto che alla fine faccio cmq. come mi pare ]:smiley: ]:smiley: ]:smiley:

Byeee!!!

Riccardo

Ok, fingero' di crederci (ma solo per farti un piacere :stuck_out_tongue: :D)

riciweb:
Rimane il fatto che alla fine faccio cmq. come mi pare ]:smiley: ]:smiley: ]:smiley:

E ci mancherebbe pure il contrario :wink: XD

oddio mi avete fattoscompisciare :grin:

Arrieccomi!!!

allora, a casa avevo ho un DS18B20 waterproof (che poi ho scoperto essere il sensore che usate), e l'ho usato senza la libreria dallas, ma solo quella OneWire. Allego il codice, magari vi a risparmiare qualche prezioso byte in flash: funziona in modalità parassita, ovvero GND e VCC collegati a GND, e il cavo dati sul pin 9 + pull-up di 4,7K (io uso 2 in serie da 2.2K, quindi 4.4K, senza problemi), dovrebbe funzionare con qualsiasi risoluzione, ma lascia quella di default (12bit), che permette una lettura ogni 750ms al massimo.

Notare che si tratta di una versione rivista di quella per il ds18S20 (notare la S) che è presente sul playground

#include <OneWire.h>

/* DS18B20 Temperature chip i/o */

OneWire  ds(9);  // on pin 9
#define MAX_DS1820_SENSORS 2
byte addr[MAX_DS1820_SENSORS][8];
void setup(void) 
{
  Serial.begin(9600);
  delay(1000);

  Serial.println("DS18B20 Test");

  for (int i=0;i<MAX_DS1820_SENSORS;i++){
    if (!ds.search(addr[i])) 
    {
      Serial.println("No more addresses.");
      ds.reset_search();
      delay(250);
      return;
    }
  }

}
int HighByte, LowByte, TReading, SignBit, Tc_100, Whole, Fract;
char buf[20];

void loop(void) 
{
  byte i, sensor;
  byte present = 0;
  byte data[9];

  for (sensor=0;sensor<MAX_DS1820_SENSORS;sensor++)
  {
    if ( OneWire::crc8( addr[sensor], 7) != addr[sensor][7]) 
    {
      Serial.println("CRC is not valid");
      return;
    }

    if ( addr[sensor][0] != 0x28) 
    {
      Serial.print("Device is not a DS18B20: ");
      Serial.println(addr[sensor][0], HEX);
      return;
    }

    ds.reset();
    ds.select(addr[sensor]);
    ds.write(0x44,1);         // start conversion, with parasite power on at the end

    delay(1000);     // maybe 750ms is enough, maybe not
    // we might do a ds.depower() here, but the reset will take care of it.

    present = ds.reset();
    ds.select(addr[sensor]);    
    ds.write(0xBE);         // Read Scratchpad

    for ( i = 0; i < 9; i++) 
    {           // we need 9 bytes
      data[i] = ds.read();
    }

    LowByte = data[0];
    HighByte = data[1];
    TReading = (HighByte << 8) + LowByte;

    Serial.print("Temperaura: ");
    Serial.println(TReading/16.0);    
    
    Serial.print("Configuration: ");
    Serial.println(data[4], BIN);
  }
}

Grazie Lesto,
appena ho un minuto ci gioco un pò.

Riccardo

lesto ho fatto una prova per capire se ne vale la pena, il tuo sketch occupa 6KB, usando invece la libreria dallas, ed in modalita' async (che visto parliamo di un blocco di quasi un secondo ritengo sia utile in ogni contesto), occupa solo 1KB in piu', oltre ad avere uno sketch pulito e semplice

per lo sketch il problema non è la pulizia, essendo facilemente riscrivibile in classe/funzioni separate. Nota che il mio codice può leggere MAX_DS1820_SENSORS sensori, non so se è bloccante (credo di sì)

il tuo non e' bloccante perche' togliendo il delay lo sketch continua (logicamente resti su errore 85, ma quello e' un altro discorso)

non so, le read nel for non sono bloccanti? o esiste qualcosa tipo timeout? in tal caso non ho gestito il fatto di accorgermi del valore ritornato inatteso (che immagino sia il codice 85 che nomini). E quindi a mio parere il mio codice non è adatto. Tra l'altr oora qul codice è in parallelo con una sonda K (da calibrare), ed oggi volevo iniziare a salvare i valori su SD.. peccatto che non ho transistor NON sd e nessin diodo tranne gli zener... mannaggia a me.

no, nel for non ci sono blocchi, perche' e' rnomale sia cosi'
e'il ds.reade (0x44) che e' bloccante se non si usa la funzione Async, quindi il +85C a te appare perche' non aspetti i 750ms necessari per la lettura (res 12bit)
Eliminando il delay infatti fai ripartire a palla, non essendo appunto bloccante il codice, il comando 0x44

Come procede il progetto?

Io non lo so perché non.lo sto facendo, però sto lavorando ad un progetto do motivo e mi ero intromesso visto che uso alcuni sensori uguali. Sul 18b20 ti posso confermare che la cosa migliore è usare l ultima versione Dallas in modalità async, per un solo K in più hai un lavoro funzionante e testato da tempo

Ciao a tutti,
anche io sto preparando una centralina di gestione per l'acquario. Ho seguito una strada un po' diversa ed infatti non ho usato gpio expander ma degli shift register anche per pilotare il display LCD. Ho praticamente sfruttato tutte le risorse hardware dell' Atmega e mi manca solo lo sbroglio del pcb XD. Ho già preparato la scheda relè anche se è pronta una revisione... ho modificato le piste lato 220Volt (le ho fatte più grandi) e ho deciso di usare almeno una presa sul normalmente chiuso dei relè dove collegare la pompa.
Infatti in acquario il sistema di filtrazione è l'unica cosa in funzione 24h/24 7gg./7. Lavorando col NC eviterò spegnimenti anche quando la centralina dovesse per qualche motivo impallarsi o andare giù. Nel mio acquario fare innescare la pompa è abbastanza fastidioso e se sono fuori casa potrebbe essere un vero problema.
Volevo aggregarmi comunque al progetto perché alcune esperienze saranno comuni come la necessità di leggere i valori chimici dell'acqua (vedi ph). Volevo infatti chiedervi :

  1. Avrei intenzione di usare questa scheda http://www.robot-italy.com/it/1130-ph-orp-adapter.html col relativo elettrodo. Qualcuno ha avuto modo di provarla?
  2. Come dicevo prima ho esaurito tutte le risorse Hw dell'atmega, la ram ormai è poca e faccio ormai fatica ad implementare altre funzioni... avrei intenzione, per un futuro aggiornamento, usare due ATmega uno da dedicare al Display, tastiera, temperatura stanza, buzzer, e l'altro alle funzioni di gestione dell'acquario. Sono indeciso se utilizzare I2C o una seriale software (dimenticavo la mia centralina usa la seriale per collegarsi con Xbee al PC). Cosa mi consigliate? E chiaro che usare Gpio expander non risolvono il problema di risorse come RAM e Flash.

Grazie in Anticipo a tutti

Passa alla MEGA.

Il problema è come fare la versione stand-alone?

lexip:
Il problema è come fare la versione stand-alone?

Ciò non toglie che tu non la possa usare 8)
Che funzioni hai gA implementato nel tuo progetto?

Ciao Riccardo

lexip:
Il problema è come fare la versione stand-alone?

non e' obbligatorio farla, invece di fare uno standalone fai una shield