Sensore Sismico Omron D7S

International Italiano Generale
1

Invogliati dall'articolo apparso sul numero di febbraio 2018 di una nota rivista italiana, con gli amici radioamatori della Sezione ARI “Basso Lazio” abbiamo acquistato un sensore D7S nell’ottica di poter fare esperienza con il micro-controllore Arduino e, con il tempo, sostituire un sismografo che attualmente abbiamo in servizio per scopi di monitoraggio e Protezione Civile.

Va premesso che non abbiamo, ne io, ne gli altri amici, una grandissima esperienza di microcontrollori e di Arduino ma certamente la volontà di imparare nuove tecnologie non manca. Quindi, dopo aver assemblato il tutto, come illustrato nell'articolo, abbinando un Arduino Uno al sensore D7S, abbiamo iniziato a fare delle prove con le librerie e con gli esempi scaricati dal sito della rivista; purtroppo però abbiamo riscontrato subito numerose problematiche.

All'atto della compilazione dei vari sketch di esempio ottenevamo una serie di errori, apparentemente, riconducibili alle librerie ma, dopo aver contattato il servizio di assistenza post-vendita del rivenditore di Arduino e del sensore stesso, che ci forniva una copia delle librerie aggiornate (ver.1.1.0), riuscivamo a superare questa prima impasse. Da allora ad oggi, però, nonostante aver cambiato addirittura più computer (sia Windows che MacOS), siamo in una situazione di stallo senza riuscire ad ottenere alcun effetto tangibile.

Nello specifico, la cosa migliore che siamo riusciti ad ottenere, dopo aver tentato di compilare e caricare sull’Arduino tutti gli sketch di esempio a “corredo” dell’articolo, è una segnalazione di warning generalizzata su quasi tutti gli sketch di esempio e che, per completezza di informazione, riporto di seguito riferita nello specifico allo sketch “LastestEarthquakes":

In file included from /Users/utente/Documents/Arduino/libraries/D7S_Arduino_Library-1.1.0/examples/LastestEarthquakes/LastestEarthquakes.ino:22:0:
/Users/utente/Documents/Arduino/libraries/D7S_Arduino_Library-1.1.0/src/D7S.h:53:1: warning: 'typedef' was ignored in this declaration
 };
 ^
/Users/utente/Documents/Arduino/libraries/D7S_Arduino_Library-1.1.0/src/D7S.h:62:1: warning: 'typedef' was ignored in this declaration
 };
 ^
/Users/utente/Documents/Arduino/libraries/D7S_Arduino_Library-1.1.0/src/D7S.h:69:1: warning: 'typedef' was ignored in this declaration
 };
 ^
/Users/utente/Documents/Arduino/libraries/D7S_Arduino_Library-1.1.0/src/D7S.h:75:1: warning: 'typedef' was ignored in this declaration
 };
 ^
/Users/utente/Documents/Arduino/libraries/D7S_Arduino_Library-1.1.0/src/D7S.h:81:1: warning: 'typedef' was ignored in this declaration
 };
 ^
/Users/utente/Documents/Arduino/libraries/D7S_Arduino_Library-1.1.0/src/D7S.h:89:1: warning: 'typedef' was ignored in this declaration
 };
 ^
Lo sketch usa 6054 byte (18%) dello spazio disponibile per i programmi. Il massimo è 32256 byte.
Le variabili globali usano 620 byte (30%) di memoria dinamica, lasciando altri 1428 byte liberi per le variabili locali. Il massimo è 2048 byte.

C'è qualcuno che possa darmi qualche suggerimento su prove da effettuare per risolvere il problema esposto?

Grazie a tutti per l'attenzione ed in particolare a quanti vorranno/potranno darmi indicazioni utili.

Cosmo IWØHP

2

Premetto che non conosco ne il sensore ne la libreria in questione ma in linea generale un messaggio di warning porta comunque alla compilazione del programma e alla possibilità di provarne il funzionamento, molto spesso il warning mostrato in fase di compilazione non impatta nel normale utilizzo della libreria.
Quindi la domanda è: Al netto del warning se provate ad effettuare l'upload del programma su Arduino il programma funziona? Se no cosa non va? Prova a essere il più dettagliato possibile perché "non va nulla" difficilmente da possibilità di un aiuto concreto, ovvero posta il codice utilizzato (quello che da il warning er intendersi meglio), la libreria (o un link ad essa), un link al prodotto acquistato e uno schema del collegamento effettuato (anche a mano su un foglio di carta)

3

Caro fabpolli, hai perfettamente ragione... quando si espone un problema di natura tecnica, molte volte, si tende a sovrastimare la conoscenza dell'argomento da parte degli altri... perdonami, anzi, mi scuso con tutti.

Comunque, una prima risposta ai miei dilemmi da neofita già l'hai data: il fatto che i warning non sempre impattano sul funzionamento del sistema finale; detto ciò, nel nostro caso specifico, verificato lo sketch (con i warning di cui sopra) e caricato sull'Arduino, il funzionamento del sistema costituito dal sensore D7S e dall'Arduino comunque non produce risultati, seppur il sensore, sollecitato con delle vibrazioni, sembrerebbe funzionare dall'accensione dei suoi led.

Per testarne il funzionamento, ci siamo affidati alle librerie (link) reperite, come dicevo precedentemente, sul sito della rivista ed agli sketch di esempio forniti con le librerie stesse; in particolare (visto che il comportamento anomalo è stato riscontrato su tutti gli sketch di esempio) ci siamo focalizzati sul codice che permetterebbe la visualizzazione degli ultimi eventi registrati nella memoria del sensore.

#include <D7S.h>

void setup() {
  // Open serial communications and wait for port to open:
  Serial.begin(9600);
  while (!Serial) {
    ; // wait for serial port to connect. Needed for native USB port only
  }

  //--- STARTING ---
  Serial.print("Starting D7S communications (it may take some time)...");
  //start D7S connection
  D7S.begin();
  //wait until the D7S is ready
  while (!D7S.isReady()) {
    Serial.print(".");
    delay(500);
  }
  Serial.println("STARTED\n");

  //--- LASTEST DATA ---
  Serial.println("--- LASTEST EARTHQUAKES MEASURED ---\n");
  //print the lastest 5 earthquakes registered with all data
  for (int i = 0; i < 5; i++) { //the index must be from 0 to 4 (5 earthquakes total)
  	Serial.print("Earthquake n. ");
  	Serial.println(i+1);

  	//getting the lastest SI at index i
  	Serial.print("\tSI: ");
  	Serial.print(D7S.getLastestSI(i));
  	Serial.println(" [m/s]");

  	//getting the lastest PGA at index i
  	Serial.print("\tPGA (Peak Ground Acceleration): ");
  	Serial.print(D7S.getLastestPGA(i));
  	Serial.println(" [m/s^2]");

  	//getting the temperature at which the earthquake at index i has occured
  	Serial.print("\tTemperature: ");
  	Serial.print(D7S.getLastestTemperature(i));
  	Serial.println(" [°C]\n");
  }
}

void loop() {
	// put your main code here, to run repeatedly:
}

Il risultato ottenuto da questo codice è la visualizzazione sul "Monitor seriale" dell'IDE, della frase Starting D7S communications (it may take some time)... e niente più.

Per meglio descrivere ciò che abbiamo acquistato, il sensore è costituito da una breakout board basata sul sensore D7S prodotto dalla Omron, sensore composto di fatto da un accelerometro a tre assi, dei quali solo due vengono utilizzati durante la rilevazione di un evento sismico e selezionabili, rispetto all'inclinazione del sensore, sia automaticamente che dall'utente.

Di seguito l'immagine dell'assemblaggio effettuato (e controllato più e più volte!)

600×600 53.1 KB

Spero di aver meglio argomentato la problematica con questo ulteriore post... grazie ancora a tutti.

4

Se non ti stampa una serie di . dopo il messaggio allora probabilmente si blocca nella funzione begin(), prova a inserire

Edit:
[s]#ifdef DEBUG[/s]  <--RIGA ERRATA
#define DEBUG

prima della riga

#include <D7S.h>

Nel monitor seriale dovrebbe inserirti un po' di messaggi per tentare di capire dove si blocca e da li tentare di capire qual'è il problema

5

iw0hp:
... un accelerometro a tre assi, dei quali solo due vengono utilizzati durante la rilevazione di un evento sismico...

Scusami se non riguarda direttamente il tuo problema, ma questa cosa mi lascia perplesso ... perche' solo due assi ? ... capisco che per il movimento sussultorio il solo asse Z (se il sensore e' in piano, ma comunque un solo asse) sia sufficente, ma i movimenti ondulatori, propagandosi "su un piano" (semplificando), possono avvenire in qualsiasi direzione, quindi ci si aspetterebbe che se, ad esempio, l'asse Z viene usato per il sussultorio, entrambi gli altri due vengano usati per l'ondulatorio ... o mi sfugge qualcosa ?

Per quanto riguarda invece il problema in se, io non sono un programmatore, piu che altro un tecnico hardware, ma se vi rimane sempre bloccato nel while che attende il "pronto" dal sensore, non e' che e' il sensore ad avere qualcosa ? ... avere provato prima con quattro righe che si limitano a stampare lo stato di quel "D7S.isReady()", giusto per controllare che alla fine il sensore funzioni realmente ? (domanda da hardwarista, lo so, ma vuoi mettere che a volte ci si azzecchi pure noi trafficoni ? :D)

6

Etemenanki:
Scusami se non riguarda direttamente il tuo problema, ma questa cosa mi lascia perplesso ... perche' solo due assi ? ... capisco che per il movimento sussultorio il solo asse Z (se il sensore e' in piano, ma comunque un solo asse) sia sufficente, ma i movimenti ondulatori, propagandosi "su un piano" (semplificando), possono avvenire in qualsiasi direzione, quindi ci si aspetterebbe che se, ad esempio, l'asse Z viene usato per il sussultorio, entrambi gli altri due vengano usati per l'ondulatorio ... o mi sfugge qualcosa ?

Per quanto riguarda invece il problema in se, io non sono un programmatore, piu che altro un tecnico hardware, ma se vi rimane sempre bloccato nel while che attende il "pronto" dal sensore, non e' che e' il sensore ad avere qualcosa ? ... avere provato prima con quattro righe che si limitano a stampare lo stato di quel "D7S.isReady()", giusto per controllare che alla fine il sensore funzioni realmente ? (domanda da hardwarista, lo so, ma vuoi mettere che a volte ci si azzecchi pure noi trafficoni ? :D)

La questione dei tre assi credo sia legata al fatto che il sensore possa essere posizionato come meglio si crede... quindi, necessitandone di soli due assi (forse mi sbaglio) per verificare i movimenti ondulatori e/o sussultori, ecco spiegata la possibilità offerta dall'oggettino in studio.

Riguardo la tua idea di riscrivere qualcosina per capire se il sensore funzioni o meno, beh, è quello che cercheremo di fare anche stando all'idea proposta da fabpolli. Grazie anche a te... :slight_smile:

7

Ho notato ora che con copia incolla ho detto di inserire una riga errata devi mettere

#define DEBUG

e non

#ifdef DEBUG

Nella posizione indicata prima

8

fabpolli:
Ho notato ora che con copia incolla ho detto di inserire una riga errata devi mettere

#define DEBUG

e non

#ifdef DEBUG

Nella posizione indicata prima

Confesso che, da "buon neofita" quale sono, non conoscevo questa funzionalità e stavo già per scriverlo in risposta al tuo precedente post; sai quanto avrei sbattuto la testa senza questa tua ulteriore precisazione?! :astonished:

Sicuramente, non appena rimessomi dall'influenza :confused:, effettuerò delle prove come da te suggerito e posterò i risultati. Adesso devo limitarmi a stare in standby e leggere qua e là sui forum... :wink:

Grazie ancora una volta.

9

Ho dato un occhiata alla file D7S.h ai punti indicati dai warning del compilatore e, ad esempio, alla riga 53:

//d7s state
[color=red]typedef[/color] enum d7s_status {
   NORMAL_MODE = 0x00,
   NORMAL_MODE_NOT_IN_STANBY = 0x01, //earthquake in progress
   INITIAL_INSTALLATION_MODE = 0x02,
   OFFSET_ACQUISITION_MODE = 0x03,
   SELFTEST_MODE = 0x04
};

Non sono un'esperto di C++ ma credo ci sia un errore: o fai un typedef struct oppure un più semplice enum, ma non tutti e due.

Probabilmente l'autore era indeciso tra la prima e la seconda soluzione e ha lasciato entrambe ed il compilatore ha semplicemente ignorato la typedef fornendo un warning.

Ti suggerisco, comunque, di rivolgerti all'autore Alessandro Pasqualini:

alessandro.pasqualini.1105@gmail.com

10

Nel messaggio n. 2 vedo che il loop() è vuoto, quindi non c'è una parte del programma che verrà eseguita ciclicamente!

Comunque sembra che non venga stabilita la comunicazione. Ci sono le resistenze di pull-up sull'I2C?

11

Se quello e' un'esempio, allora nel loop ci deve scrivere la sua parte di programma ... il modulo, se e' quello del disegno, tipo futura, dovrebbe gia avere le resistenze di pull-up, almeno dallo schema elettrico ... :wink:

12

Da quel pochino che ho imparato (ma forse sbaglio) nel loop() non necessariamente dev'esserci qualcosa, ovvero ho eseguito altri sketch di esempio che avevano quella parte di codice vuota perché non necessario eseguire la routine ciclicamente e non davano alcun problema.

Quindi, almeno per questa fase di test, lo sketch di esempio fornito con la breakout board dovrebbe funzionare d'emblée! :wink:

Riguardo le questione elettronica delle resistenze posta da Datman, beh... credo abbia risposto esaustivamente Etemenanki. :wink:

Comunque sia, grazie dell'interessamento e dei contributi.

13

Non necessariamente nel loop deve esserci qualcosa ma, se non c'è, il sensore viene letto solo una volta. Se, per ora, non vuoi avere letture continue, va bene così.

14

iw0hp: (a proposito, VHF ? :wink: :D) come dice Datman, se nel loop non metti qualcosa che legga il sensore ad intervalli e ne stampi lo stato, la lettura la fai una sola volta nel setup, il while di preparazione esce quando il sensore risponde, ma poi il programma non fa ne stampa piu nulla ... :wink:

Prova, giusto per curiosita', a metterci un paio di istruzioni che leggano lo stato delle uscite ogni, diciamo, mezzo secondo, e le stampino, tanto per vedere se funziona quando lo si agita ...

Vero anche che, una volta che esce dal while, dovrebbe comunque stampare tutti i dati almeno una volta ... quindi forse c'e' piu di una cosa che non va ...

15

Datman:
Non necessariamente nel loop deve esserci qualcosa ma, se non c'è, il sensore viene letto solo una volta. Se, per ora, non vuoi avere letture continue, va bene così.

Infatti... va bene così!

Il problema credo vada approfondito altrove... farò, non appena possibile, le prove di debug suggeritemi qualche giorno fa da fabpolli che, al momento, mi sembra la cosa più sensata.

Grazie ancora a tutti per il contributo... ci aggiorniamo fra qualche giorno! Stay tuned! :wink:

Etemenanki:

iw0hp: (a proposito, VHF ? :wink: :D)

Dipende! :stuck_out_tongue: Se vuoi anche altro... VLF, LF, HF, UHF, SHF... :smiley:

16

... allora ti telefono in KA ... :stuck_out_tongue: ... (scherzo :D)

17

Mi son letto la poca documentazione perché questo sensore mi sembrava interessante.
A quanto ho capito non c'è solo l'accelerometro ma anche una MCU programmata che calcola una sorta di magnitudo dell'evento. In oltre sembra che sia programmato in modo da scartare il rumore e non scattare se uno urta il sensore.
Da qui immagino che per ottenere un evento dovrete aspettare un vero terremoto (oppure usare una tavola vibrante!).
Questo perché tale sensore è pensato per eventualmente spegnere apparecchiature in caso di terremoto quindi è programmato in modo da evitare i falsi allarmi.

Il motivo per cui non mi ha più interessato è che non è possibile scaricare la forma d'onda. Me lo ha confermato anche l'autore della libreria.
Forse usa solo due assi per scarsità di RAM.

18

zoomx:
Mi son letto la poca documentazione perché questo sensore mi sembrava interessante.
A quanto ho capito non c'è solo l'accelerometro ma anche una MCU programmata che calcola una sorta di magnitudo dell'evento. In oltre sembra che sia programmato in modo da scartare il rumore e non scattare se uno urta il sensore.
Da qui immagino che per ottenere un evento dovrete aspettare un vero terremoto (oppure usare una tavola vibrante!).
Questo perché tale sensore è pensato per eventualmente spegnere apparecchiature in caso di terremoto quindi è programmato in modo da evitare i falsi allarmi.

Il motivo per cui non mi ha più interessato è che non è possibile scaricare la forma d'onda. Me lo ha confermato anche l'autore della libreria.
Forse usa solo due assi per scarsità di RAM.

Sicuramente, il sensore è fatto per spegnere apparecchiature o impianti al verificarsi di un evento sismico. Te lo confermo...

Come ti confermo che anch'io ho capito non sia possibile scaricare una forma d'onda registrata per un dato evento sismico.

Mi sembra comunque di capire che forse hai esigenze che convergono sulle mie... hai per caso preso in esame altre possibili soluzioni o devices che permettano una semplice realizzazione di sismografo?

19

Dipende cosa vuoi fare.
C'è la strada dell'autocostruzione del sensore con 2 soluzioni classiche e una recente, per me.

Il primo sensore è il classico pendolo orizzontale, stile kit Nuova Elettronica. In rete lo trovi cercando Lehman seismometer. Si tratta di una costruzione compatta equivalente ad un pendolo verticale di decine di metri, molto sensibile ma adatta ai telesismi, cioè i terremoti che provengono da lontano.

Il secondo è un pendolo verticale realizzato con un peso attaccato ad una molla. Questo è il modello da cui puoi partire.

Questo dovrebbe essere più sensibile ai terremoti più vicini.

La novità, almeno per me, è quello realizzato con un tubo ad anello schiacciato pieno parzialmente di acqua e con una strozzatura nel mezzo.
http://www.fesn.org/files/Didattica_Costruzione%20e%20funzionamento%20FMES.pdf
Ne parlano bene e sembra avere buone prestazioni.

Quando c'è da digitalizzare puoi prendere in considerazione altre MCU a 32 bit per il semplice fatto che l'ADC è a 12 bit . La scheda più economica potrebbe essere la Maple Mini o la Blue Pill (ma quest'ultima richiede qualche accessorio). Sono entrambe sotto i 5 euro dalla Cina.
Ci sono digitalizzatori economici a 16 e perfino a 24 bit ma non sono molto veloci. Vanno bene per acquisizioni a 5-10Hz (quindi daccapo i telesismi) ma non arrivano a 100Hz. L'ideale sarebbe sui 200Hz.

Poi c'è la strada dei sensori economici ma già pronti.
Il primo è il classico geofono, da accoppiare ad un amplificatore.
Il secondo è usare un accelerometro MEMS, cioè quelli che stanno dentro un piccolo chip. Esistono accelerometri MEMS dalle prestazioni paragonabili a quelle di un ottimo sensore triassiale moderno ma costano notevolmente. Sto sperimentando vari accelerometri MEMS economici, sia analogici che digitali, tutti presi su Aliexpress.

Come software su PC sto usando jamaseis che, dalla scorsa estate, supporta finalmente 3 canali invece di uno solo come l'oroginale Amaseis nato per essere usato con un pendolo orizzontale. Salva in formato sac che è usato internazionalmente.

Riassumendo. La realizzazione più veloce è quella di un Arduino o altra scheda e un accelerometro, poi quella di un geofono con amplificatore e sempre Arduino. Poi quella di un sesore da costruire come quelli descritti sopra.

Tieni conto che rimaniamo in ambito praticamente didattico perché per avere qualcosa di effettivamente utile ci vuole una rete di sensori, tutti sincronizzati al millesimo di secondo, un sistema di teletrasmissione dei dati, un sistema di acquisizione e una serie di siti dove piazzare i sensori che abbiano poco rumore ambientale. Io, per esempio, sto in città al secondo piano, non è affatto un luogo ideale. Però mi piace giocare.

P.S. Il D7S lo ha preso un mio amico per cui giocherò anche con questo.

20

Salve a tutti,
sono l'autore della libreria per il sensore D7S, vi do due informazioni velocemente.

iw0hp:
Di seguito l'immagine dell'assemblaggio effettuato (e controllato più e più volte!)

600×600 53.1 KB

Spero di aver meglio argomentato la problematica con questo ulteriore post... grazie ancora a tutti.

Questa immagine, sfortunatamente, presenta un piccolo errore nella parte di collegamento nel bus I2C, ovvero SDA e SCL sono stati invertiti. Il collegamento corretto è SDA del D7S su A4 e SCL su A5 (come effettivamente riportato qui Wire - Arduino Reference). Provvederò personalmente ad avvisare Futura Elettronica per evitare che altre persone inciampino su questo problema. I warning li sto indagando, ma penso siano dovuti al compilatore un po' più "strict", in quanto nelle mie macchine non si presentano.

Per quanto riguarda il discorso degli assi, il sensore usa effettivamente due assi perchè misura solamente le onde S (confermato da Omron stessa, la quale paragona i dati del suo sensore ad equivalenti strumenti professionali dal valore di qualche decina di migliaia di dollari). Gli assi che vengono utilizzati possono essere sia impostati "staticamente", nel senso che verranno sempre usati gli stessi, oppure lasciar decidere al sensore quali utilizzare in base alla sua orientazione.

Come già detto, sfortunatamente, non è possibile ottenere i dati "grezzi" registrati dal sensore, ma solamente quelli pre elaborati dallo stesso. Questa è una limitazione dovuta principalmente all'utilizzo per cui è stato pensato, ovvero spegnere un dispositivo (togliendo l'alimentazione) in caso di scosse superiori ad una certa soglia.

Se avete domande al riguardo contattatemi pure.

P.S. Non sono molto pratico di forum, quindi se ho commesso qualche errore fatemelo notare tranquillare e provvedo a correggerlo immediatamente