August 2014 - RMAP - lists.cs.unibo.it (DISI)

[meteo] Ultrasonic Anemometer
by Paolo Patruno 05 Jan '17

05 Jan '17

Un mio collega ha recuperato un paio di articoli molto affascinati sulla misura del vento: http://www.technik.dhbw-ravensburg.de/~lau/ultrasonic-anemometer.html http://hackaday.com/2013/08/21/ultrasonic-anemometer-for-an-absurdly-accura… La cosa mi pare molto interessante ... C'è qualcuno che si vuole cimentare ?

2 1

[meteo] Protezione Esterna sensori
by Mirco Bergamini 01 Apr '15

01 Apr '15

Questa potrebbe essere una prima versione di protezione completa: L'inclinazione degli schermi è di 23° la sede per il braccio di supporto 30 x 30 Gli schermi sono modulabili , differenti dal coperchio che è anch'esso uguale agli altri con in più la chiusura. Per unificare il componente si potrebbe sostituire la chiusura con un tappo oppure si potrebbe prevedere una zona per il taglio della chiusura da farsi per tutti gli schermi tranne l'ultimo in alto. Se qualcuno di Bologna ha già una stampante 3d vi passo i file stl Ciao. -Mirco

5 12

[meteo] Varie I2C modulo attuatore e microduino
by Mario Mazzullo 29 Aug '14

29 Aug '14

Sempre di passaggio da bologna per daniele e paolo I segnali dell'I2C e i conseguenti salti di tensione non sono solo quelli relativi alla abilitazione o disabilitazione della linea di trasmissione per cui se si collega a 3,3 si risolvono le questioni di differenza di segnale... il tutto è un pochino più complesso .... http://www.robotware.it/lezioni-online/livelli-logici.html# stando alle specifiche del protocollo http://www.robotware.it/lezioni-online/trasferimento-dati-con-il-protocollo…<http://www.robotware.it/lezioni-online/livelli-logici.html#> nel bus I2C su sdk e scl ci vanno solo due resistenza di pullup collegate all'alimentazione (3,3 V va benissimo) questo garantisce la sicurezza dei collegamenti per il trasferimento dati. Se però capita di utilizzare una breadboard, come ad esempio alcuni rtc alimentati a 5 volt e con resitenze di pullup onboard (vedi modulo adafruit) collegate ai 5 volt il tutto crea problemi e malfunzionamenti. Quindi per l'I2C, se non si vogliono utilizzare i traslatori di livello sulle linee sdk e scl, bisogna essere certi che ci siano solo due resistenze collegate all'alimentazione che ripeto va benissimo se a 3,3 volt ma questo implica il controllo delle breadboard e dei relativi datasheet degli altri sensori per essere certi che non vi siano altre resistenze di pullup collegate ad altra alimentazione ed in parallelo con le precedenti: ripeto le resistenze devono essere solo due per gli n device i2c che si collegheranno. Per questo motivo avevo suggerito l'idea dei traslatori di livello da ingobare sulla basetta speimentale. Questo tipo di connessione lo avevo già implementato per uno shield in cui inglobavo diversi sensori I2C da 3,3 volt risolvendo i problemi dei differenti livelli di tensione di alimentazione in modo abbastanza semplice. Inoltre come avete avuto modo di constatare i 3,3 volt sono utilizzati anche dai moduli rf in modo piuttosto intenso per quanto attiene l'assorbimento di corrente e la conseguente stabilizzazione delle tensioni quindi più roba si mette sui 3,3 volt e più potente deve essere l'erogazione di corrente su questa alimentazione. daniele se per la breadboard sperimentale, se devi portare fuori dei pin sulla scheda sperimentale per utilizzare gli attuatori suggeriti da paolo, potrebbe valere la pena di mettere in linea i pin del mega che consentono il montaggio degli shield Arduino in questo modo si potrebbe utilizzare il progetto dell'attuatatore a cui abbiamo lavorato realizzando in proprio lo shield con 8 relays che può essere impiegato per gli esperimenti di domotica che paolo suggerisce di fare e che al momento potrebbero essere gestiti facilmente con il prototipo disponibile. Comunque per info e dettagli sulla sua realizzazione si può consultare il link http://www.robotware.it/progetti/progetto-modulo-attuatore.html i pin utilizzabili in questo caso vanno dal 4 all'11 per un totale di otto relays tutti alimentati a 5 volt. Concludendo ho fatto alcune prove con i microduino ed il modulo nrf ed hoconstatato che cambia la configurazione dei pin SPI di controllo del modulo rf sono ioltre riuscito a far trasmettere dei dati. Al prossimo passaggio da Bologna Mario ________________________________ Da: dcast78(a)gmail.com [dcast78(a)gmail.com] Inviato: mercoledì 6 agosto 2014 19.21 A: meteo(a)liste.raspibo.org Oggetto: Re: [meteo] rmap installation party Ciao stavo apportando alcune modifiche allo schema elettrico dello shield per rmap e mi sono imbattuto in queste considerazioni: http://www.element14.com/community/thread/19665/l/is-level-shifting-really-… Mi sembra sensato considerare che I2c sia un bus open collector quindi la tensione positiva al bus la diamo noi (con le resistenze di pullup) non arduino o i sensori perchè chi trasmette sul bus in pratica usa un transistor per abbassare il valore della linea. http://www.robotware.it/images/articoli/2014/1722014_Tutorial_I2C/Body_Sche… Perciò credo che invece che collegare le resistenze di pullup come avevo fatto prima a 5V, ora le collegherò a 3.3V anche se poi non le ho saldate sulla basetta perchè attualmente usaimo quelle del sensore TMP102. Cosa ne pensate? Il giorno 08 luglio 2014 16:40, Mario Mazzullo <mario.mazzullo(a)unibo.it<mailto:mario.mazzullo@unibo.it>> ha scritto: Ciao Quando sarà disponibile una immagine della sd card con fedora da montare su raspberry, quella attuale on-line si scarica con diffcicoltà (tempi biblici), la posso mettere in linea sul server qui da me e renderla disponibile per il download in FTP ad un gruppo di utenti ben definito. Vi chiedo info sulle limitazioni nell'utilizzo di debian per r-map mqtt, python, i2c, graphite sembra funzionino e credo anche ino. Il porting per quali file o pacchetti deve essere fatto ? potrei provarci Per quanto concerne i sensori I2C le specifiche in merito ad indirizzi e modalità di funzionamento si trovano e sono ben documentati su sparkfun oltre che sui datasheet dei singoli sensori. esistono vari tipi di sensori I2c montati su breadboard alcuni hanno on board il convertitore di tensione da 5 Vcc a 3,3 e questa è per la linea di alimentazione. Le linee SCL e SDA necessitano inoltre, se sulla breadboard del sensore non vi sono sistemi di traslazione dei livelli di tensione, di essere pilotate o interfacciate solo con linee a 3,3 volt se le specifiche di funzionamento del sensore sono tali. Se sulle due linee SDA e SCL (o SCK) sono collegati più sensori I2C alcuni funzionanti a 3,3 ed altri a 5, come ad esempio nel caso di alcuni moduli RTC, i livelli di tensione sul bus I2C sono comandati dal sensore che ha le due resistenze di pull-up collegate all'alimentazione. Il sensore collegato con le due resistenze all'alimentazione dei 3,3 o 5 volt che sia determina il livello di tensione su tutto il bus I2C. Quindi in caso di più sensori I2C è necessario che UNO SOLO DI QUESTI SIA COLLEGATO AI 3,3 VOLT CON DUE RESISTENZE DI PULL-UP da 4,7 K Ohm, tutti gli altri dovranno avere dette linee prive di queste resistenze altrimenti si verificano malfunzionamentio e nel caso di sensori funzionanti a 5 Volt si forza la tensione del bus a 5 volt bruciando il tutto come accaduto a paolo un altro metodo per salvaguardare i sensori da 3,3, è quello di collegare in serie alle line e SDA e SCL due resistenze da 10 KOhm in modo da limitare gli assorbimenti anche n caso di collegamento ai 5 volt. su Robotware trovate due articolini che potrebbero essere di una qualche utilità (uno su I2C e uno più grezzo sui traslatori di livello) http://www.robotware.it/lezioni-online/trasferimento-dati-con-il-protocollo… http://www.robotware.it/lezioni-online/level-shifter-converter.html# infine sarebbe buona cosa prevedere sull breadboard sperimentale anche lo spazio per dei traslatori di livello, sparkfuna ne commercializza alcuni in modo da essere sicuri che anche alimentando a 5 volte le tensioni su SDA e SCL saranno sempre quelli corretti. Per la board a forza di discutere come vedete vengono fuori sempre nuove questioni non considerate in precedenza quindi cerchioamo di approfondire i vari aspetti poi per la realizzazione si vedrà come cosa e a chi rivolgerci per la realizzaizone dello stampato. Non comprendo bene questa affermazione di Paolo ... rimane il fatto che utilizzare tutte board di prototipizzazione assemblate con bread board o rmap shild puo abbassare il gradino di accesso piuttosto di una board specifica per una applicazione . l'idea dello shield dedicato non era altro che l'ingegnerizzazione della breadboard rmap fatta per rendere le cose più funzionali e non uno shield per una specifica applicazione , anzi l'idea era di valutare levarie necessità e modalità di funzionamento per creare qualcosa di valido. Per quanto attiene poi la produzione di una qualche ditta interessata la questione dei costi è ingestibile a livello professionale per una borad 10x6 si arriva a cifre notevoli e a livello amatoriale bisogna valutare come dicevo prima tutti gli aspetti progettuali altrimenti un prototipo serve lo spazio di un mattino perchè poi va ampliato per il giorno dopo. A presto e grazie delle info Mario Il giorno mar, 08/07/2014 alle 14.05 +0200, dcast78(a)gmail.com<mailto:dcast78@gmail.com> ha scritto: > Ciao, > dopo la serata di giovedì ieri sera mi sono messo a cercare di mettere > in funzione la mia stazione. Grande ! > Ho comprato una nuova sd, dato che quella che avevo portato giovedì > riciclata non ne voleva sapere di partire ed ora il raspberry parte > con fedora. in realtà il metodo della clonatura delle SD è grezzissimo come minimo bisognerebbe ridurre l'immagine a meno di 8G e riattivare il resizefs del firstboot; cosa più seria sarebbe ricreare un vera immagine di installazione oppure un how to passo passo o uno script di "personalizzazione" ... > Il sensore collegato direttamente a raspberry funziona anche se > rispetto a quello del file station.py ha un altro indirizzo, cioè 0x48 > invece che 0x40 (da verificare se dipende da come l'ho collegato io) > comunque ho aggiornato il wiki facendo riferimento ad un'altra pagina > su come trovare sensori i2c. il tmp102 ha un pin addr che a seconda di dove viene collegato imposta l'indirizzo i2c per trovare cosa è connesso al bus i2c su raspberry bisogna dare il comando: i2cdetect -y 1 i privilegi per poter fare questo sono già impostati e l'utente rmap è abilitato per trovare i sensori i2c su arduino invece si puo usare il progetto ino che trovate in /home/rmap/svn/r-map-code/trunk/arduino/ino/i2cscanner ino build -m mega2560 ino upload -m mega2560 ino serial > Ho aggiornato le coordinate ed ho visto che i dati vengono pubblicati. bene! > Ho lanciato graphite mi va in ascolto su http://127.0.0.1:8000/ e non > ho trovato come metterlo in ascolto per accedere dall'esterno percio' > dato che ero collegato da esterno questa parte non sono riuscito a > provarla. graphite dovrebbe partire in automatico senza necessità di eseguire nulla; bisogna invece eseguire mqtt2graphite graphite è composto da due pezzi a backend (Carbon) storage application the Graphite webapp ad ascoltare su http://127.0.0.1:8000/ è carbon che memorizza i dati e ha un file di configurazione per modificare questo default Graphite webapp è eseguita da apache come wsgi ed è quindi apache a servire a tutti i grafici prodotti ed è raggiungibile tramite http alla porta 80 standard > Per il fronte Arduino mega sono un pó più indietro > > Ho finito di saldare la scheda, dato che l'aveva saldata Mario senza > lo schema mancavano un paio di componenti e un paio di ponticelli che > ho saldato io. > Ho verificato che la scheda si accenda, ho messo in funzione > l'alimentazione via poe entrando dal convertitore dc/dc. > > Il pulsante di reset non funzionava percio' ho fatto un check > hardware, c'era una pista che aveva un problema comunque risolto > ripassandola con stagno. > > Ho notato sullo schema che ho collegato sul bus i2c l'alimentazione > dei sensori a 5 volts, ma il sensore tmp102 va al assimo a 3.3 volts > quindi per ora non ho collegato niente in attesa di vedere se va > tutto. ecco, io avevo collegato tmp102 a 3.3 su raspberry e 5V su arduino. ecco perchè ne ho bruciato uno, mentre l'altro ha resistito ... > Ho aggiornato il repository su raspberry ricompilato e caricato > trovare come si faceva e' stata un po' un'avventura ma ce l'ho fatta, cd /home/rmap/svn/r-map-code/trunk svn up cd arduino/ino/rmap ino clean ln -sf src/rmap_master.h src/rmap_config.h ino build -m mega2560 ino upload -m mega2560 ino serial > ho provato la configurazione ed ho visto che non andava quindi ho > provato i reset con il pin 8 e qui le cose sono andate un po' meglio > anche se credo non abbia finito, questo passaggio lo rifaro' un po' > meglio. attenzione che si rifiuta di configurare un sensore se questo non è realmente collegato alla board e quindi la configurazione si ferma Ricordate (impossibile perchè non ve lo ho detto ;) ) che in logrpc.txt trovate il trace della comunicazione seriale che vi può aiutare nel debug > Del modulo satellite ho solo provato che la parte core funzionasse ed > ho collegato il sensore, ma non e' ancora programmata. ln -sf src/rmap_satellite.h src/rmap_config.h ino build -m 644pa16m ino upload -m 644pa16m ino serial > Non ho ricevuto la mail con l'how to dal ragazzo che aveva preso > appunti, quindi mi manca qualche info che mi sono perso mentre > saldavo. anche io non ho ricevuto nulla > > Questo e' tutto per il momento sui test. > > Aggiungo qualche considerazione: > > per il pin di reset io ridurrei gli spazi al massimo usando un jumper > invece che un pulsante fisico, tanto i reset dovrebbero essere pochi > oppure si puo' poi collegare un pulsante esterno con due ponticelli > dupont. stessa cosa bisognerebbe fare per il pin 8 > > Metterei anche un ponticello per scegliere a quale tensione alimentare > i sensori (vedi sopra). > > Mancano alcuni pin per pilotare eventuali attuatori come richiesto da > Paolo e Luigi. > > Prima di pensare di fare una scheda vorrei che tutti i test fossero > completati con successo perche' come avete visto finche' non si mette > mano alle cose si fa fatica a valutare. > > La mia preoccupazione sugli ingombri delle schede ha trovato parziale > riscontro sul fatto che il modulo rtc va un po' in sovrapposizione con > la scheda di rete, ora ho risolto cambiando il tipo di connettore, ma > va migliorata perche' almeno all'apparenza non e' molto stabile. > > > Io cercando chi poteva produrre le schede avevo trovato questi > http://www.pcb-pool.com/ppit/index.html > > > Non so se siano meglio o peggio di altri, sicuramente la nostra scheda > costera' piu' del necessario perche' incastriamo sulla board delle > altre schede, e dato che i prezzi variano in base alla superficie > probabilmente sprechiamo qualche euro. siamo in fase di prototipo e io me ne fregherei > Fare una scheda master con i componenti invece che con le schede > sarebbe probabilmente piu' economico ma un po' piu' complicato > (escluderei comunque la scheda radio), non escludo che sia fattibile, > vediamo. io lo vedrei come fase due, quando le cose si saranno stabilizzate e lo potrebbe fare una ditta intenzionata a commercializzare ? rimane il fatto che utilizzare tutte board di prototipizzazione assemblate con bread board o rmap shild puo abbassare il gradino di accesso piuttosto di una board specifica per una applicazione ... Io sono quindi dell'idea di rimanere per ora nella logica di prototipo con board di protopizzazione generiche e diffuse; poi si vedrà ... ciao Paolo -- Saluti Daniele

3 8

[meteo] database Arkimet, DB-all.e e carbon
by Paolo Patruno 28 Aug '14

28 Aug '14

Sul server sono installati i database per l'achiviazione di tutta la rete RMAP, ma non sono ancora alimentati quindi per ora solo una anteprima: Database DB-all.e con (in teoria) gli ultimi dati in tempo reale http://rmapv.bisognodipace.org/borinud/ selezionate come data 2013/10 e avrete come punto solo la mia stazione con i dati dell'anno scorso ... (eh si è già un anno che ci lavoriamo) clikkate sul puntino per un grafico. Non funziona se siete dietro a un proxy e un firewall cattivo. Database Arkimet con tutti i dati storici. http://rmapv.bisognodipace.org/arkiweb/ qui bisogna avere un minimo di idee chiare per sapere cosa si vuole (ma tanto e quasi vuoto ...) Database carbon con tutte le metriche rmap e non pubblicate su broker MQTT http://graphite.rmapv.bisognodipace.org/ Qui si puo' graficare tutto quanto viene pubblicato sul MQTT (mosquitto) in quanto è attivo il gateway MQTT2graphite; si può pubblicare anche con la get http come da mail precedente. Questa è una visualizzazione per qualsiasi misurazione come ad esempio il carico della cpu del server: http://graphite.rmapv.bisognodipace.org/dashboard/cpu Bhe questo per incominciare a mettere insieme i pezzi del puzzle rmap che non sono pochi ... Paolo

1 0

[meteo] amqp e rabbitmq
by Paolo Patruno 28 Aug '14

28 Aug '14

Come certamente sapete per il trasferimento dei messaggi al nostro server centrale utilizzeremo il protocollo amqp http://en.wikipedia.org/wiki/Advanced_Message_Queuing_Protocol Il software che utilizzeremo sarà rabbitmq Qui i concetti base: https://www.rabbitmq.com/tutorials/amqp-concepts.html https://www.rabbitmq.com/getstarted.html ho configurato raspberry e server aggiungendo i plugin per l'amministrazione web e Shovel Praticamente i report che saranno composti sul raspberry verranno immessi in un "exchange" di rabbit che lo distribuirà a un paio di code per l'archiviazione locale e a una coda rmap per l'upload al server. Sul server verranno ricevuti i messaggi da un "exchange" e inviati a un paio di code per l'archiziazione sull'archivio condiviso. Per gestire l'upload su server utilizzo il plugin Shovel; qui le sue principali caratteristiche: https://www.rabbitmq.com/shovel.htm Ho messo le configurazioni in svn nella dir rabbitmq mentre nella dir python ci sono python/amqp_producer.py e python/amqp_consumer.py come esempi per inviare e ricevere messaggi con amqp. Pare funzionare bene al contrario di un anno fa quando avevo avuto problemi con Shovel. Ora bisogna "connettere gli spinotti" e provare ad alimentare i database. Paolo

1 0

[meteo] server mqtt
by Paolo Patruno 28 Aug '14

28 Aug '14

Inizio a pubblicizzare i primi servizi esposti dal server rmap messo a disposizione da ARPA Veneto. rmapv.bisognodipace.org (ho usato temporaneamente un mio dominio per comodità, tanto di bisognodipace direi che ce ne sia ancora) dovrebbe essere funzionante il broker mqtt e la sua semplice interfaccia http. E' attivo l'access control list quindi accesso anonimo: è possibile leggere tutti i topic è possibile scrivere in tutto l'albero /test/ user rmap con password rmap : può scrivere nel path /rmap interfaccia web a: http://rmapv.bisognodipace.org/http2mqtt/?topic=/test&payload=prova esempio di sottoscrizione e pubblicazione: mosquitto_sub -v -t \# -h rmapv.bisognodipace.org pubblicazione anonima: mosquitto_pub -h rmapv.bisognodipace.org -t /test -m ciao pubblicazione con autenticazione: mosquitto_pub -h rmapv.bisognodipace.org -u rmap -P rmap -t /rmap/test -m ciao Gli altri servizi (arkiweb, borinud, graphite) sono già attivi, ma non sono alimentati. Chi volesse contribure interagendo con rabbitmq (protocollo AMQP) in particolare con il plugin shovel http://www.rabbitmq.com/shovel.html batta un colpo. Paolo

1 1

[meteo] Avanzamento lavori sulla mia stazione
by dcast78＠gmail.com 28 Aug '14

28 Aug '14

Ciao a tutti, dopo aver ricevuto i suggerimenti di Paolo e Mario mi sono rimesso al lavoro per mettere in funzione la mia stazione che non ne voleva sapere di andare, mi si bloccava in modo anomalo come segnalato da Paolo quando abbiamo fatto i test assieme. Ho saldato i condensatori sulla scheda nfr2401+ ma senza risultati, poi a forza di fare prove sembrava che la situazione stesse degenerando in quanto in fase di verifica della corretta scrittura dell skecth su arduino cominciavo ad avere timeout. Mi sono chiesto se la causa potesse essere il funduino e volevo togliermi ogni dubbio percio' ho riassemblato il tutto su breadboard come avevamo fatto con Paolo, e li ho avuto conferma to che il materiale era sano perche' ha inizato a funzionare regolarmente la lettura dei sensori e la pubblicazione su mosqitto. A questo punto tanto per capire ho provato a simulare la situazione anomala che mi si verificava sulla scheda autoprodotta, la situazione si verifica se si stacca un filo collegato alla porta spi sia della scheda di rete che del trasmettitore radio. A questo punto mi sono messo in ricerca guasti sulla scheda. Per velocizzare la cosa e per avere uno strumento che possa essere utile anche in futuro ho fatto uno skecth banale che attiva uno per uno i pin di arduino in modo che collegando il tester o anche un semplice led si possa verificare se tutte le saldature sono buone. Ed infatti ho trovato una saldatura fredda che non faceva contatto sul trasmettitore radio. Sistemata quella saldatura il modulo master ha iniziato a funzionare. Ho avuto qualche altro piccolo contrattempo, ma lo possiamo considerare trascurabile, Mi rimane qualcosa che non va credo con il watchdog perche' se faccio un reboot di raspberry che non fornisce connettivita' al modulo master poi devo andare a disalimentarlo per farlo ripartire. Attualmente mi sembra che su graphite i dati non vengano collezionati, ma la cosa penso sia un problema minore, cioe' se apro graphite sul browser non vedo i dati della stazione, e se non ricordo male li vedevo passare anche lanciando mqtt2graphite. Ora le ferie sono alle porte, penso che cerchero' di fissare su una todo list quello che serva per produrre un'altra scheda, la scheda che sto' usando ha qualche problema che ho corretto con ponticelli saldati piu' qualche problema fisico di spazi e di saldature poco agevoli come dimostrato sopra. In piu' lo sviluppo sw di Paolo richiede un paio di cose. -- Saluti * Daniele *

3 6

[meteo] Re: Benvenuto nella lista meteo
by Paolo Patruno 25 Aug '14

25 Aug '14

Ciao Giuseppe, ti rispondo con grande ritardo, ma la mail che hai utilizzato non è la mail della lista ma quella di amministrazione della lista. Ho dato una occhiata alla presentazione ed è chiaro che dovremo confrontarci/incontrarci per approfondire i nostri evidenti obiettivi comuni. Il progetto r-map ha come prima scadenza importante la maker faire a Roma agli inizi di ottobre http://www.makerfairerome.eu/its/ Ricominciano anche gli incontri del non corso a partire dal 9 settembre alle 20:30 al makerspace in via Canonica 18 a Casalecchio dove ovviamente sei invitato. Se non puoi venire sentiamoci e concordiamo per un altro momento. Paolo Il giorno lun, 11/08/2014 alle 01.05 +0200, Giuseppe De Marco ha scritto: > Ciao a tutti, > > questo progetto è molto interessante, > anche dalle mie parti abbiamo condotto alcune esperienze in ambito > embedded-meteo e abbiamo deciso di realizzare un laboratorio dove > coinvolgerci insieme a studenti ed appasionati. Questa è una > presentazione abbastanza recente: > > http://diaticloud.unical.it/statics/Presentazioni/embedded.29luglio2014/#/ > > Speriamo di coinvolgerci :) > Giuseppe > > 2014-08-11 0:50 GMT+02:00 <meteo-request(a)liste.raspibo.org>: > > Benvenuto nella lista meteo(a)liste.raspibo.org > > Il tuo indirizzo di iscrizione è demarcog83(a)gmail.com > > > > > > Mailinglist del gruppo Rete di Monitoraggio Ambientale Partecipativo > > > > La pagina ufficiale è: > > http://www.raspibo.org/wiki/index.php?title=Gruppo_Meteo > > > > Il sito di RaspiBO è: > > http://www.raspibo.org > > > > > > > > > > > > The list homepage: http://liste.raspibo.org/wws/info/meteo > > General informations about mailing lists: http://liste.raspibo.org/wws/help/introduction > >

1 0

[meteo] pulsante di poweroff su raspberry
by Paolo Patruno 22 Aug '14

22 Aug '14

Riprendendo il progetto fatto l'anno scorso https://sourceforge.net/p/raspdbusgpiopy/wiki/Home/ ho aggiunto il pulsante di poweroff a raspberry perchè mi pare una cosa stupida dover avere un pc e fare un ssh per spegnerlo, oltre a non utilizzare il lavoro fatto. Per attivare il pulsante bisogna: aggiugere il file dbusgpio.conf in /etc/dbus-1/system.d/ come riportato sotto attivare l'interfaccia GPIO DBUS: dbusgpiod restart eseguire python /home/rmap/svn/raspdbusgpiopy/applications/poweroff.py che dice al raspberry di spegnersi quando il pin 12 del connettore , pin 18 della GPIO http://pi.gadgetoid.com/pinout/pin12_gpio18 viene collegato a massa. Il prossimo passo sarà quello di far partire questi servizi automaticamente al boot e mettervi a disposizione questo software nella prossima immagine per l'SD del raspberry Paolo dbusgpio.conf <!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN" "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd"> <busconfig> <policy user="root">  <allow own="org.gpio.myboard.Pins"/> <allow send_destination="org.gpio.myboard.Pins"/> </policy> <policy context="default"> <allow own="org.gpio.myboard.Pins"/> <allow send_destination="org.gpio.myboard.Pins"/> </policy> </busconfig>

1 0

[meteo] problemi con modulo nRF24L01+
by Paolo Patruno 21 Aug '14

21 Aug '14

Quando ci simo incontrati con Daniele, fatto funzionare a dovere il raspberry e la sensoristica a lui collegata abbiamo avuto grandi problemi con il modulo master. Dopo ore non ne siamo usciti e tutto pareva rotto e inutilizzabile. Abbiamo iniziato a sezionare il problema e ci siamo fermati a notte fonda su un problema nei test relativi ai moduli radio. Abbiamo passato molto tempo a giocare a "trova le differenze" per cercare di capire perché la mia board di test funzionava e quelle sia fatte con la breadboard o con la board di connessione di Daniele non andavano. Prima di tutto abbiamo rilevato che la scheda di rete funziona molto meglio se alimentata a 5V e non a 3.3V. Ma solo oggi ho potuto verificare che, come consigliato in tutti i forum, bisogna assolutamente aggiungere un condensatore al modulo RF. Nella mia board di test il condensatore era stato messo per comodità sulla breadboard, ma il cavo di collegamento non è più di 10 cm. Usando un cavo più lungo, ed è comunque sempre consigliabile, ho dovuto aggiungere un condensatore elettrolitico da 470uF direttamente sul connettore del modulo RF. Questo serve per eliminare il rumore sull'alimentazione dovuto ai consumi impulsivi del modulo RF. Così le cose funzionano molto meglio, rimane che senza condensatore la board "stalla" e ne il pulsante di reset, ne il watchdog sono in grado di rifar partire il tutto. Questa non è una cosa buona e giusta e bisogna indagare meglio le cause di questo smalvino, magari con un oscilloscopio con memoria ... io dispongo solo di un vecchio unahom degli anni 70 ... Paolo

2 4