Barografo elettronico fai da te

[Andomast]

------------------
nell'idea di un sistema modulare di cui sopra ho pensato che forse un'uscita in protocollo NMEA (le 'sentenze' sono gia' definite) possa essere ancora meglio dell'USB poiche' garantirebbe una piu' ampia compatibilita' (un adattatore RS232/USB se servisse costa quattro soldi).
------------------

Concordo pienamente, anzi, visto che siamo ancora in fase di brainstorming, propongo di aggiungere un modulino GPS così da poter avere il time stamp, la velocità e l'heading oltre a LAT/LON.
La connessione al PC verrà fatta con porta seriale (ed eventuale adattatore USB<->RS232. Chiaramente l'aggiunta di un modulo USB ( seriale) farà si che la comunicazione fra il circuito e il PC avvenga in una singola direzione (dal circuito al pc e non il viceversa)

[Edolo]

Vi amo!!

[IanSolo]

-----
propongo di aggiungere un modulino GPS così da poter avere il time stamp, la velocità e l'heading oltre a LAT/LON.
-----
O.K. ma come disse il Barbiere di Siviglia 'uno alla volta per carita'' : con quale cominciamo ?

Fatto e collaudato uno si passa al secondo e cosi' via, propongo la sequenza:
- Barometro (e' quello di cui qui si e' parlato per primo e penso abbia la precedenza)
- Igrometro + Termometro (da esterno)
- GPS (salvo verifica che gia' non ne esistano belli che fatti a cui serva solo il connettore opportuno)
- ... ?
- Display intelligente (lo ho messo per ultimo visto che un PC a bordo lo hanno in tanti)

Suscettibile di varianti, ovviamente.

Scordavo un particolare: ho il programmatore di PIC (e di altri processori) ma non ho il sistema di sviluppo, mi pare di capire che tu Andomast sia in grado di fare cio' che porta al file per la programmazione, e' corretto ?
Se e' cosi' potremmo dividere il lavoro fra sviluppo della parte fisica dell'hardware e il software di comunicazione dal lato modulo (dal lato PC non ci sono problemi). Ovviamente in parallelo lo sviluppo dell'idea.

[Andomast]

Ciao,
Ecco uno prima release dello schema (rigorosamente UNCONTROLLED!) che prevede l'uso del sensore di pressione e di due sensori di temperatua.
Il display è un 4X20 così da poter creare un istogramma con 10 colonne per vedere il trend della pressione nelle ultime dieci ore.
creando 6 caratteri 'particolari' si possono discriminare per ogni colonna 24 incrementi di pressione. Se poniamo 920mB come mina pressione da graficare e ad ogni incremento facciamo corrispondere un incremento di 5 mB, il display sarà in grado di visualizzare l'intervallo 920mB-:-1040 mB che va bene per capire se si è in una zona di bassa o altra pressione....
So perfettamente di non essere stato chiaro, appena ho un po' di tempo faccio qualche simulazione così da mostrare cosa appare sul display.

Questo contenuto non e' visualizzabile da te Ospite. Se vuoi vederlo, REGISTRATI QUI .

[IanSolo]

Sei gia' piuttosto avanti !
Io ipotizzavo qualcosa che, di base, sia senza display e si appoggi ad un micro molto meno evoluto in modo da avere un costo bassissimo per ciascun modulo 'sensore' e, a parte con il display, vi sia la logica per l'eventuale presentazione locale.
Ora sono lontano da casa e non posso ragionarci piu´a fondo, al mio ritorno ci pensero' meglio.

[Andomast]

Ho verificato in rete presso un paio di distributori il costo del Pic16F876, in buona sostanza siamo intorno ai 5 euro.
Se consideriamo le caratteristiche di questo micro penso che li valga tutti.
In questa fase preferisco prevedere a priori l'uso di un display così da assegnare gli I/O alle funzioni principali, chiaramente gli I/O non utilizzati 'a tempo zero' potranno essere impiegati successivamente per altre funzioni (i.e. allarmi, pulsanti....).
A proposito di allarmi, credo che sia necessario assegnare ad un I/O la gestione di un cicalino! Aggiorno lo schema (che fra le altre cose ha già subito un paio di correzioni) e lo condivido

[IanSolo]

Se il prezzo e' quello va bene ed e´comodo avere qualche I/O in piu'.
Penso che possa essere meglio utilizzare un LM135 (http://www.ti.com/lit/ds/symlink/lm135.pdf) in TO92 come sensore di temperatura poiche´, essendo in Kelvin, consente la misura di temperature anche negative che in molte regioni sono frequenti in inverno.
Anche per i sensori di temperatura userei un amplificatore con offset per portare nel range dell'A/D la gamma da -15 a +45 gradi centigradi, il sensore di umidita' relativa non necessita di alcun adattamento avendo uscita fra 0,5 e 4,5V circa.
O.K. per l'uscita verso un cicalino ma la sua funzione andra' pensata molto bene per definire per quale parametro e quale variazione si dovra' attivare.

[danielef]

Citazione:Andomast ha scritto:
Ciao,
Se poniamo 920mB come mina pressione da graficare e ad ogni incremento facciamo corrispondere un incremento di 5 mB, il display sarà in grado di visualizzare l'intervallo 920mB-:-1040 mB che va bene per capire se si è in una zona di bassa o altra pressione....
So perfettamente di non essere stato chiaro, appena ho un po' di tempo faccio qualche simulazione così da mostrare cosa appare sul display.

Sei stato chiarissimo ma io proporrei un range di pressione tra 980 e 1028 mb in modo da avere una risoluzione di 2 mb perché in complesso il 90% delle volte sarà più utile. Andrà fuori scala ogni tanto ma in quei rari casi... forse meglio non trovarsi in barca!
Alternativa anche migliore ma richiede un po' più di programmazione e memoria: plottaggio sul display a barre della sola fluttuazione attorno alla media calcolata sulle ultime N ore (12 o 24) - una cosiddetta 'media corrente'. In quel caso la risoluzione del display a 24 livelli può essere portata a 0.5 mb/step (molto utile!) ma sarebbe opportuno avere un altro display numerico a 5 cifre che desse in parallelo la pressione assoluta istantanea.

Come si dice: la fame vien mangiando!

Daniele

[IanSolo]

----
Come si dice: la fame vien mangiando!
----
Proprio per questo ho proposto la soluzione modulare con elementi 'sensori' indipendenti dal 'presentatore', si arriva prima ad una soluzione utilizzabile senza fare 'indigestione' gia' all'antipasto e si ha il vantaggio di poter avere piu' versioni che si differenziano solo per il modo di presentare i dati e chi ha gia' strumenti in grado di leggere le sentenze NMEA relative agli strumenti meteo: $WIMDA - Pressione Barometrica in Bars, $WIMDA - Temperatura dell'aria in Celsius, $WIMDA - Umidita' Relativa %, ecc., puo' fare a meno del modulo con display. Nel momento in cui si operera' sulla presentazione vale in ogni caso la pena di tenere conto della propsta perche' ragionevole.

Andomast,
a proposito di sentenze NMEA e' opportuno che l'uscita NMEA sia bilanciata ovvero che sia prevista una seconda linea come quella gia' inserita nello schema che fornisca lo stesso dato pero' negato (linea NMEA-OUT low), questo per ragioni di totale compatibilita' con tutta la strumentazione che usa quel tipo di protocollo.

[S8S8]

...vi seguo con interesse oltre che grande ammirazione.
...sarebbe interessante un allarme con soglia impostabile sull'andamento della pressione aumento o discesa che sia in un tempo impostabile....sul mio Vion prima che smettesse di funzionare usciva il disegnino della barca sbandata se veniva rilevata in un ora una variazione di 3 mb ...credo che per complicarvi il progetto visto le competenze ci voglia ben altro e perciò non mi resta che auguraVi una Buona e Continua Collaborazione...la mia era solo una idea.

[Edolo]

Cavoli ragazzi!! Che ammirazione!!! Non si fa in tempo a dare il LA che si è già arrivati a due ottave sopra!
IanSolo... mi dovrai spiegare un par di cose

[Andomast]

---------------
e' opportuno che l'uscita NMEA sia bilanciata
---------------
Beccato! E' vero, hai ragione NMEA è bilaciato anche se non ho mai avuto problemi aleggere dati bilanciati con linea sbilaciata e transistor di inversione. Comunqe, per essere 100% compliant con lo standard, useremo un ST485 (integrato a 8 piedini) che provvede a generare un segnale bilanciato. Il pic16f876 ha la UASART hardware, e quindi non è possibile utilizzare due I/O per geerare il segnale bilanciato a meno di non fare una routine di emulazione della UART che ruberebbe memoria e tempo.
Concordo pienamente sull'utilizzo degli LM135 così da avere anche valori negativi di temperatura in passato ho provato ad usare degli LM35 con delle masse fittizie sperando di andare 'sotto zero' ma non ho mai ottenuto risultati soddisfacenti; una possibile soluzione di backup e rappresentata dagli LM35C (mai trovati!) che nascono appunto per qusto scopo.

[IanSolo]

Edolo,
anche tre ...

Andomast,
il sistema delle masse fittizie con gli LM35 funziona ma non e' perfettamente ripetitivo perche' gli si mescola la corrente di fuga del dispositivo che non e' sempre uguale, per renderla trascurabile si dovrebbe farlo lavorare con carico piu' forte ma questo lo fa un po' riscaldare e si perde linearita' e taratura... e' come un gatto che rincorre la sua coda, alla fine e' meglio il 135.

[BornFree]

IMHO sarebbe utile poter spegnere il solo display con un pulsantino quando non serve per risparmiare un po' di energia

Complimenti cmq per il progetto

[Andomast]

--------------
sarebbe utile poter spegnere il solo display con un pulsantino quando non serve per risparmiare un po' di energia
--------------

Il display non consuma quasi nulla, forse intendi la retroilluminazione che ha un consumo di circa 50mA. In questo caso basta mettere un interrutorino a levetta in serie all'anodo della retroilluminazione.

Inutile dire che se si vuole utilizzare il PC come interfaccia grafica basta non montare il display.
Qui di seguito un piccolo aggiornamento dello schema.

Questo contenuto non e' visualizzabile da te Ospite. Se vuoi vederlo, REGISTRATI QUI .

[IanSolo]

Visto che la soluzione scelta si basa su di un micro abbastanza potente che di base permette vari tipi di interfacciamento potrebbe essere una semplificazione circuitale utilizzare dei sensori I2C che non avrebbero bisogno di amplificatori e di tarature.
Intendo sensori di questo tipo:
http://www.adafruit.com/products/1603
https://www.sparkfun.com/products/10239
https://www.sparkfun.com/products/9418
https://www.sparkfun.com/products/12064

Questo ha fatto una cosa simile alla nostra un po' di tempo fa:
http://www.edaboard.com/thread230720.html
(sito originale in Polacco : http://www.elektroda.pl/rtvforum/topic2115892.html)

[Andomast]

In effetti già da qualche giorno meditavo la stessa cosa. Il costo dei sensori intelligenti non è di gran lunga superiore a quello dei sensori standard e non avere tarature può solo incoraggiare altri ADV ad intraprendere questo progetto.
Anche il firmware verrebbe 'snellito' permettendo così l'uso di un micro più piccolo come il PIC16F628 oppure il PIC16F648 se ci fosse bisogno di più memoria.

[IanSolo]

Infatti, alla fine fra diversa superfice PCS, necessita' di operazionali con frattaglie (e tempo, che in oggetti amatoriali non costa ma ci vuole lo stesso), le due soluzioni diventano praticamente equivalenti.
Nell'uscita NMEA penso che possa essere una buona idea avere un 'sensing' sul bus per potersi parallelare ad un bus esistente e accodare l'uscita allo 'stream' di dati di eventuali altri 'talkers' che si rileva sul bus (o dopo un opportuno 'timeot' se non c'e' segnale), questo perche' non vale la pena per tre sole sentenze di fare un vero multiplexer ma va tenuto conto della necessita' di aggiungere i dati ai dati di altri strumenti e del possibile conflitto nella comunicazione.

[Andomast]

Il vantaggio di usare i sensori con uscita I2C è che tutti i sensori possono essere collegati sullo stesso bus formato da due I/O (pin del micro).
Qui di seguito un possibile schema che fa uso, come già accennato, di un micro più piccolo (18 pin). Spero quanto prima di realizzare un PCB per il debug del firmware. Chiaramente per evitare l'indigestione giustamente prevista da IanSolo si potrebbe inizaire con il solo sensore di pressione per poi estendere 'il polpo' con altri tentacoli dai quali attingere le info di pressione umidità e chissà cos'altro.


Questo contenuto non e' visualizzabile da te Ospite. Se vuoi vederlo, REGISTRATI QUI .

[IanSolo]

Perfetto ! Mi piace, direi completo.
Ora raccolgo il protocollo delle 'sentenze' NMEA da inviare e poi decidiamo quali siano da implementare.