Installazione del sensore fisso per il Quake Catcher Network
Indice
1. Premessa
2. Reperire il JW in Europa
3. Assemblaggio
4. Test e caratterizzazione degli assi
5. Posizionamento
6. Configurazione e requisiti per il funzionamento del software
7. Rete fissa e rete mobile
8. Conclusioni e riassunto dei requisiti
Notizie suggerimenti e trucchi
1. Premessa
Questa è una piccola relazione sull'installazione di un sensore sismico per il QCN, rivolta principalmente agli amici di BOINC.italy. Per ulteriori informazioni su cosa sia il QCN rimando al loro sito, invece riguardo all'utilità di una rete di sensori alternativa a sensibili e precisi sismografi professionali, consiglio la lettura di questo articolo di Franco Foresta Martin sul Corriere della Sera, i frettolosi possono passare direttamente all'ultimo paragrafo.
Il sensore JoyWarrior 24F8 (in breve JW) è un accelerometro a tre assi, per porta USB. Attualmente è l'unico ufficialmente supportato dal QCN per la propria rete “desktop” che nelle intenzioni dei gestori del progetto lavorerà in parallelo ad una rete “mobile” basata sugli accelerometri contenuti in alcuni modelli di PC portatili.
2. Reperire il JW in Europa ^
Attualmente e possibile acquistare un kit JW in Europa dal sito:
http://www.codemercs.com/index.php?id=134&L=1
Il costo il costo del kit per QCN (per l'ultima, più sensibile versione del sensore, il 24F14) con IVA e spese di spedizione per l'Italia, è di circa 60 euro, che si riduce di circa 20 euro con l'acquisto di 10 pezzi. Mentre il kit del vecchio 24F8 è ancora disponibile qui al costo di circa 50 euro.
La scatola del kit per il QCN contiene:
- la schedina del sensore
- un cavo USB
- un box plastico in due pezzi su misura per la schedina
- un foglietto di istruzioni tedesco/inglese
3. Assemblaggio ^
Assemblare il sensore è relativamente semplice, basta aver un poco di pratica con il saldatore e rispettare l'ordine dei fili sulla scheda e il verso in cui va inserita nel box plastico.
Il collegamento dei fili alla scheda deve seguire il seguente ordine:
- +5V = rosso
- D- = bianco
- D+ = verde
- Gnd = nero
La schedina va inserita nel box con il lato componenti verso l'alto e il lato delle saldature dalla parte opposta dell'ingresso del cavo USB.
Il secondo pezzo del box va poi incastrato nel primo allargandolo leggermente con delicatezza visto che non sembra molto robusto, seguendo le guide e premendo per chiudere.
4. Test e caratterizzazione degli assi ^
Collegando il sensore alla porta USB, windows XP riconosce automaticamente una nuova periferica, e lo possiamo controllare da “Risorse del computer => (mouse dx) proprietà => (tab) Hardware => Gestione periferiche”. Nell'elenco sotto “Human Interface Device (HID)” dovrà essere presente una nuova voce “Controller gioco compatibile HID”, un altro joystick quindi.
Da “Pannello di controllo => Periferiche di gioco” dovremmo vedere una nuova voce Joystick in stato OK, selezionando le proprietà e il tab “test” devono essere presenti 3 assi, nessun pulsante, e muovendo il sensore dovremmo vedere muoversi i relativi controlli dell'applicazione di test.
Un test simile può essere eseguito dalla GUI del QCN, un programma didattico interattivo chiamato QCN Live che riporta le letture sui tre assi in formato grafico. Con questo ci possiamo divertire a sollecitare il sensore in vari modi per vedere quali sono quelli che causano le attivazioni (trigger) rappresentate graficamente da linee verticali, che, durante l'attività del client BOINC comporteranno l'upload al server QCN di un'intervallo dei dati registrati intorno all'istante in questione.
Sempre con il programma QCN Live è consigliabile verificare l'orientamento e il verso degli assi del sensore, poichè questo andrà posizionato in direzione nord-sud come illustrato in questo messaggio nel forum del QCN, dato che le specifiche del sensore potrebbero cambiare e quindi anche la disposizione degli assi rispetto al sensore mostrato sul forum.
Spostando il sensore avanti e indietro una sola volta, lungo uno dei lati del box, dovremmo ottenere due impulsi di segno opposto (come quelli evidenziati nel rettangolo rosso in figura), su uno solo degli assi, avremmo in questo modo identificato sia l'asse che il suo verso. Se il primo impulso è positivo e il secondo negativo allora l'asse è a crescere nella direzione del primo spostamento e viceversa.
5. Posizionamento ^
Il sensore, secondo quanto consigliato dai gestori del progetto, andrebbe incollato nel posto più vicino alle fondamenta della casa, per evitare che eventi come lo sbattere di porte o finestre provochino troppe false attivazioni. Quindi non sulla scrivania ma almeno sul pavimento e in posto al riparo da possibili urti di scope o lucidatrici, l’ideale sarebbe proteggerlo dentro un contenitore fissato al muro, cosa che farò quando avrò un poco di tempo, per ora mi affido a un “warning casaligno” diramato periodicamente ;-)
Il suo sito attuale è a 10 metri (secondo piano) sopra le fondamenta di un condominio realizzato in cemento armato, su una strada secondaria in quasi totale assenza di traffico pesante. La precedente posizione a diretto contatto con le fondamenta di un edificio su una strada principale con continuo passaggio di TIR e altro traffico pesante, alla fine non ha rivelato grosse differenze. In entrambi i casi rilevo in media una decina di attivazioni giornaliere (controllabili direttamente sulla pagina di report del mio host) con la colonna Magnitude intorno a 0.20 anche se spesso capitano dei giorni di "silenzio" totale e in rari casi (2 in un mese) degli "abbagli" con trigger di magnitude 4, apparentemente con collegati ad alcun avento fisico.
Dal test sugli assi, il mio sensore è risultato identico a quello mostrato sul forum del QCN e quindi è stato posizionato con il cavo USB uscente in direzione nord dalla parte bassa del box. Nel mio caso (figura a lato) ho usato del normale attaccatutto ripulendo per bene le superfici da incollare e aiutandomi con il bordo della bussola per mantenere la direzione giusta. Controllando inoltre che il cavo USB con fosse in trazione e che a colla essicata il sensore non inizi a spostarsi o a ruotare (attenzione ai pavimenti con la cera). Per un orientamento preciso controllate anche che nelle vicinanze non vi siano oggetti metallici, evidenti o nascosti, che possano far ruotare l'ago magnetico della bussola dalla sua posizione abituale. Ad esempio, al di sotto di un pavimento galleggiante conviene posizionarsi al centro della piastrella per rimane il più equidistante possibile dalle barre metalliche di sostegno.
6. Configurazione e requisiti per il funzionamento del software ^
Perchè il client QCN possa funzionare correttamente dobbiamo verificare i seguenti requisiti:
- PC con CPU > 2 Ghz e una porta USB libera.
È possibile (leggi sotto) usare anche PC più lenti, modificando la priorità del client QCN manualmente da task manager o automaticamente (in vari modi). Naturalmente è preferibile utilizzare un PC che sia acceso 24 ore su 24 per aver maggiori probabilità di registrare un evento.
- Programma BOINC installato.
La versione consigliata è la 6.4 poiché sui PC con più di una CPU virtule (core o HT), che utilizzano versioni precedenti, viene lanciato erroneamente un numero di client maggiore di quello corretto che, vista la natura del programma, è 1. Tuttavia se già BOINC è messo in condizioni (configurazione o tipo di CPU) di lanciare un solo client “elaborativo”, non avrà problemi e lancerà anche un solo client QCN, quindi sarà possibile usare anche una versione 5.x di BOINC.
- Collegamento diretto a internet.
Il collegamento, come previsto da BOINC può essere diretto oppure via proxy se ad esempio siete connessi a una LAN, tuttavia in questo caso è bene controllare che non sia bloccata da qualche firewall la porta 23 UDP poiché una delle funzioni essenziali per il funzionamento del client QCN è la sincronizzazione temporale degli eventi tramite un client NTP. Nota si parla di sincronizzazione degli eventi e non dell'orologio del PC, infatti il client NTP utilizzato dal QCN non è “invasivo” e si limita a calcolare la differenza tra il clock del PC e quello del server NTP di stanford.
Una volta completata l'installazione fisica del sensore e il collegamento ad un PC adeguato, si potrà fare l'attach del progetto QCN Alpha Test al seguente link:
http://qcn.stanford.edu/qcnalpha/
Se tutti i requisiti precedenti sono stati rispettati, in parallelo ai client BOINC tradizionali partirà l'elaborazione di una WU un poco atipica per la piattaforma BOINC. Il suo stato sarà “Running” su BOINC 5.x e “Running non-CPU intensive” su 6.x, e il processo del client (qcnX.XX_windows_intelx86.exe) da task manager non dovrà in condizioni normali utilizzare più del 1% della CPU. Una WU dura esattamente 24 ore ed equivale all'ascolto del sensore per un giorno intero, per un utilizzo tipico del processore di circa 5 minuti di CPU Time complessivo.
L'attività del proprio host ha una sua pagina di report con un storico delle attivazioni nelle ultime 24 ore. In blu sono visibili delle attivazioni periodiche di controllo (i cosiddetti trigger di ping che hanno una cadenza di 30 minuti) mentre le righe bianche corrispondono a attivazioni reali, nel 99% dei casi dovute ad eventi di microsismicità locale o forse a rumore interno del sensore e quindi tipicamente di bassa intensità. Anche se, come dicevo sopra, mi è capitato (nel corso dell'ultimo mese) di vedere due eventi di magnitudo 4 non associabili a nulla in particolare.
Se l'NTP client riesce a comunicare correttamente con il server del progetto, le colonne “Sync Time” e “Sync Offset” saranno popolate, in caso contrario saranno vuote e quindi occorrerà verificare il firewall altrimenti invieremo i nostri eventi senza sincronizzazione temporale e il tutto sarà completamente inutile!
Ultimo passo essenziale è aggiungere il riferimento geografico: sempre dalla pagina del proprio host (dopo aver fatto il logon) dal link alla voce "Computer Locations" si accede alla pagina di edit dell'host location. Di default sono attive le coordinate riferite al domicilio del nostro ISP probabilmente tratto dall'IP "esterno" del nostro PC che tuttavia è assolutamente da cambiare dato che con questo metodo può facilmente accadere di ritrovarsi addirittura nella città sbagliata. Con questo sistema basato su Google Maps si può riportare in modo molto preciso la posizione del nostro sensore, in particolare ho potuto anche trovare il tetto del mio condominio e dare la posizione della "colonna" dove si trova il mio studio. Tuttavia le coordinate del nostro PC per i visitatori poi vengono riportate sul sito in modo approssimato così da traslare casualmente (da qualche centinaio di metri a qualche km) la posizione pubblica e garantire la privacy degli utenti.
Come annunciato nel forum del QCN una modifica del form di input delle coordinate permette anche di inserire l'elevazione sul suolo del sensore (leggere l'aggiornamento nelle news a fine pagina).
7. Rete fissa e rete mobile ^
Come dicevo all'inizio esiste anche una rete basata sugli accelerometri contenuti nei PC portatili. Questa dovrebbe inizialmente disporre di più nodi grazie alla facilità di mettere a disposizione l'accelerometro del proprio portatile semplicemente facendo l'attach del progetto. Tuttavia la mancanza di specifiche degli accelerometri interni dei portatili rende attualmente difficile partecipare alla rete, a dispetto di un'operazione di attach conclusa con successo, poi il client non funziona. Solo pochi modelli di portatili sono supportati (IBM-Lenovo ThinkPad e Mac) e spesso neanche quelli funzionano bene. Inoltre credo che una rete “mobile” potrebbe essere meno affidabile per vari motivi:
- l'operatività è limitata ai periodi in cui il portatile è attivo e non viene toccata la tastiera, tuttavia questa configurazione è manuale, quindi è possibile che utenti possano, non avendo configurato correttamente il profilo, inviare eventi (trigger) dovuti al semplice uso del PC
- un portatile attivo inoltre non si troverà quasi mai in corrispondenza delle fondamenta dell'edificio in cui si trova, quindi potrà dare un numero maggiore di trigger dovuti a vibrazioni della struttura innescati dallo sbattere di porte e finestre, colpi alla scrivania ecc.
- l'aggiornamento della posizione geografica del portatile è manuale e a carico dell'utente, quindi è maggiormente probabile che non tutti i nodi siano continuamente aggiornati alla loro posizione reale
- a differenza del JW il sensore del portatile non avrà quasi mai gli assi orientati rispetto al nord geografico
8. Conclusioni e riassunto dei requisiti ^
In conclusione prima di imbarcasi in queste prove bisogna verificare di poter soddisfare tutti i requisiti tecnichi sopra elencati e tener in conto che se si vuol provare, lo deve fare con il fine unico del test di progetto e non quello di produrre dati utili, a scanso di equivoci e inutili delusioni.
Ecco in breve riassunti i requisiti più o meno obbligatori per poter partecipare al test in modo utile:
- test preventivo del programma QCN Live; anche in assenza del sensore il programma deve funzionare pur senza mostrare dati, se il programma non parte a causa di un errore di sistema, probabilmente su quel PC non funzionerà neanche il client QCN per BOINC
- sito con ridotta sismicità locale, il più vicino possibile al suolo, se siete su un soppalco in ferro dentro una fonderia, o al 14-esimo piano, forse meglio rinunciare, per evitare di inviare un numero eccessivo di false attivazioni
- PC con CPU > 2 GHz preferibilmente sempre acceso
- BOINC installato in versione 6.x per CPU multicore,
5.x per CPU a core singolo e non HT
- accesso a internet continuo, con firewall sbloccato sulla porta dell'NTP client (23 UDP)
- sul forum consigliano di tenere sotto gruppo di continuità sia il PC che l'NT per l'accesso alla rete, perchè in corrispondenza di una scossa di particolare magnitudo solitamente si verifica un blackout; basterebbe un'autonomia di pochi secondi perchè l'invio dei dati del trigger avviene subito dopo la scossa
Come avevo accennato è possibile partecipare anche con CPU più lente di 2 GHz: potete seguire i test che sto facendo dal mio Celeron M 1.3GHz su forum del QCN qui e qui o contattarmi direttamente per qualsiasi dubbio.
Ultima nota, il RAC calcolato dal progetto è sbagliato, infatti siccome ogni WU di 24 ore fornisce 50 crediti, dovrebbe essere esattamente di 50, invece dopo qualche settimana di elaborazione inizia a crescere a 500 e oltre.
[ Torna all'inizio ]
[ Torna alla home ]
Notizie, suggerimenti e trucchi
Errori tipici nel report delle WU e loro significato
Per controllare che il nostro mini sismografo funzioni correttamente, la via più semplice è la lettura dei log che vengono pubblicati sul sito al termine dei uno slot di 24 ore di attività. Ad esempio, questo link http://qcn.stanford.edu/qcnalpha/result.php?resultid=314431 punta ad un result di una WU (work unit) di 24 ore in cui si trovano dei tipici messaggi di errore. Vediamo il segnificato dei due più frequenti:
Timing error encountered t0check=1240876445.400692 t0active=1240876446.626625 diff=-1.245933 timeadj=0 sample_size=2, dt=0.020000, resetting...
qcn_util::ResetCounter(4) - Incrementing iNumReset to 1 at 1240876446.626625
Questo messaggio indica che vi è stato un reset dovuto ad un problema, probabilmente di "lentezza" del PC, in conseguenza del quale il client QCN non è riuscito a garantire il "timing" di 50 letture al secondo sul sensore. Errori sporadici di questo tipo non sono preoccupanti, probabilmente sono dovuti a processi ad alta priorità (es. antivirus) che rallentano il PC per qualche istante. Se però l'errore persiste e avvengono più di 1000 reset entro la durata di una WU allora la WU stessa viene abortita e fino alle 24 successive il sensore rimarrà inattivo. A questo link trovate un esempio di report di questa situazione. In questo caso il problema è un processore troppo lento (un Duron 800MHz), la soluzione in genere è alzare la priorità del client QCN.
Sempre al link iniziale troviamo un altro tipo di errore:
Time synchronization failed local time = 1240931400.314125, will retry in 3 minutes - elapsed time = 163.140625
Se il messaggio è occasionale non c'è da preoccuparsi, vuol dire che che l'NTP client che serve per sincronizzare temporalmente gli eventi registrati dal sensore, ha fallito la connessione con il server. Se invece l'errore è continuo allo bisogna verificare che la porta UDP 23 non sia bloccata da un firewall locale o dal proxy, oppure (leggi sotto) di non utilizzare windows 2000.
Uscita dallo stato di ALPHA test [21-apr-2009]
Il progetto QCN non viene più considerato allo status di "ALPHA test" anche se l'indirizzo web rimarrà lo stesso per non avere problemi con il database utenti in relazione ai detach/attach.
Tuttavia dopo pochi giorni nel log del BOINC Manager si poteva leggere un messaggio di questo tipo:
4/27/2009 10:22:08 PM Quake-Catcher Network You used the wrong URL for this project
4/27/2009 10:22:08 PM Quake-Catcher Network The correct URL is http://qcn.stanford.edu/sensor/
4/27/2009 10:22:08 PM Quake-Catcher Network Using the wrong URL can cause problems in some cases.
4/27/2009 10:22:08 PM Quake-Catcher Network When convenient, detach this project, then reattach to http://qcn.stanford.edu/sensor/
Seguendo le istruzioni, e facendo il detach/attach al nuovo link apparentemente non sembra cambiato nulla, anzi usando lo stesso nome ha ereditato automaticamente tutti i vecchi dati: results, crediti e anche la lista dei vecchi host non più utilizzati. Nota: il passaggio al nuovo link sembra essere stato chiesto solo agli host dotati del sensore fisso JW.
La nuova applicazione richiede BOINC 6.2 [22-apr-2009]
Con il rilascio della versione 4.76 dell'applicazione QCN (che viene scaricata in automatico da BOINC) per continuare a tenere attivo il proprio sensore sarà necessario aggiornare BOINC almeno alla release 6.2, questo per una modifica concordata con gli sviluppatori di BOINC che consente di far girare l'applicazione QCN ad una priorità leggermente più alta delle applicazioni di altri progetti che, al contrario di quella QCN, generalmente utilizzano la CPU al 100% e sono per questo impostate alla priorità più bassa. Ora il client QCN su windows girerà di default alla priorità appena successiva "infNormale" (belowNormal). Ciò al fine di ridurre al minino gli errori di reset del sensore descritti sopra.
Ho notato che tuttavia su PC estremamente lenti (es. il mio Celeron M 1.3Mhz) questo accorgimento non basta ad annullare del tutto il problema, motivo per cui ho scritto uno script che attende la partenza dell'applicazione QCN e gli cambia la priorità al volo. Sempre sul mio PC ho verificato che per portare a zero i reset del sensore bisogna impostare la priorità "SupNormale" (AboveNormal). Se anche voi volete fare questo tuning fine dell'applicazione potete mandarvi un'email e vi invierò lo script con le relative istruzioni.
Altezza sul suolo del sensore [giu-2009]
Come annunciato dai gestori del progetto ora è possibile inserire oltre alle coordinate geografiche anche l'altezza rispetto al suolo del sensore. Se quindi nella pagina del vostro host la colonna "Elevation" (dopo la longitudine) non è popolata, dovrete riaprire il form di input delle coordinate e inserirla scegliendo anche alla voce "Level Type" il tipo di dato (altezza sul mare o sul suolo) o l'unita di misura:
- Floor (+/- above/below surface) [piano dell'edificio (+/- sopra/sotto la superficie)]
- Meters (+/- above/below surface) [metri]
- Feet (+/- above/below surface) [piedi]
- Elevation - meters above sea level [altezza sul mare in metri]
- Elevation - feet above sea level [altezza sul mare in piedi]
Come leggere i dati generati dal proprio sensore
I file con i dati dei trigger vengono conservati sul PC (credo per un tempo indefinito) in questo path:
C:\Documents and Settings\All Users\Dati applicazioni\BOINC\projects\qcn.stanford.edu_sensor\triggers
che può cambiare leggermente a seconda dell'utente per cui è stato installato BOINC, e della nazionalizzazione di windows.
Ogni file .zip è un evento di trigger contenente i dati del sensore in 4 file .sac che sono facilmente visualizzabili con questo programma free:
http://alomax.free.fr/seisgram/SeisGram2K.html
Si possono inoltre generare dati in modo continuo con il programma QCN-live citato nella relazione. Questo può salvare ogni 10 minuti dei file .sac zippati con la lettura temporalmente completa del sensore. L'applicativo QCN/BOINC può girare in parallelo al QCN-live, entrambi leggeranno in parallelo i dati di accelerazione sui tre assi del JW. Dall'utilizzo del QCN-live su PC lenti in condizione di lettura "parallela", mi aspetto un peggioramento del problema dei reset del sensore.
[ Torna all'inizio ]
[ Torna alla home ]