Archivi tag: elettronica

Esp8266 – No WiFi Connection

Dopo l’allagamento della mia stazione meteo, ho deciso di riprogettare tutto il sistema. Ho quindi realizzato un circuito stampato in modo da abbandonare per sempre la realizzazione filata su mille-fori. Il PCB lo ho disegnato con Eagle e realizzato presso Millennium Dataware, come sempre. Ho dovuto correggere qualche piccolo errore derivante dalla poca attenzione e massima fretta nello sbroglio delle piste, ma tutto ha funzionato bene. Almeno dal punto di vista elettrico.

Nel momento in cui sono andato a ricaricare il firmware sulla scheda mi aspettavo un funzionamento “alla prima botta”. Invece il dispositivo si è bloccato nella fase di connessione all’access point, restituendo codice di errore “6” da WiFi.Status(). In pratica: nessuna connessione. Malgrado questo io sul’AP ero in grado di vedere il modulo come “autorizzato” o connesso. Per sbrigliare meglio questa matassa ho deciso di utilizzare un AP realizzato con una RouterBoard Mikrotik, in modo da potere approfittare delle funzionalità di logging.

Il codice che gestisce la connessione verso l’AP è il seguente:

Serial.println("");
Serial.println("WIFI INIT");
Serial.println("");
WiFi.macAddress(MAC_array);
for (int i = 0; i < sizeof(MAC_array); ++i){
sprintf(MAC_char,"%s%02x:",MAC_char,MAC_array[i]);
}
Serial.print("Unit Mac Address is: ");
Serial.println(MAC_char);
Serial.println("");
Serial.print("Connecting to ");

Serial.println(ssid);

// IP,DNS,GATEWAY,SUBNET
WiFi.mode(WIFI_STA);
WiFi.begin(ssid, password); //Gestione della connessione ad un AP
WiFi.softAP(ssidSA, passwordSA, 1, 1); //Gestione del SoftAP e hidden SSID
WiFi.setOutputPower(0); // Impostazione della potenza di uscita

while (WiFi.status() != WL_CONNECTED) {
Serial.println(WiFi.status());
delay(1000);
Serial.print(".");
}

Serial.println("");
Serial.println("WiFi connected");
Serial.println("IP address: ");
Serial.println(WiFi.localIP());

Cercando una possibile soluzione in rete mi sono imbattuto in questo post, in cui si legge:

WL_CONNECTED is only returned if the wifi interface has connected an has IP address
in DHCP mode this means you got the IP form the DHCP server. in Static mode you have set the IP yourself.

Detto fatto: ho configurato la mia MikroTik per lavorare come dhcp server e per effettuare il NAT della rete WiFi verso la rete di casa e… funziona!

Nota bene, in caso l’assegnazione dell’IP sia statica, il codice deve essere modificato in questo modo:

IPAddress host(192,168,**,**); //used for socket,mysql,mqtt 
IPAddress ip_wifi(192,168,**,**);
IPAddress dns_wifi(192,168,**,**);
IPAddress gw_wifi(192,168,**,**);
IPAddress subnet_wifi(255,255,**,**);

void setup() {
  Serial.println("");
  Serial.println("WIFI INIT");
  Serial.println("");
  //WiFi Management
  Serial.print("Connecting to ");
  Serial.println(ssid);
   
   WiFi.mode(WIFI_STA);
   WiFi.config(ip_wifi,dns_wifi,gw_wifi,subnet_wifi);  
   WiFi.begin(ssid, password);     
   WiFi.softAP(ssidSA, passwordSA, 1, 1); 
   WiFi.setOutputPower(0);        
   
  while (WiFi.status() != WL_CONNECTED) {
    delay(1000);
    Serial.print(".");
  }

 

CubieBoard: Monitoraggio presenza tensione

Nella nuova dimora accade, ogni tanto, che la fornitura di energia elettrica risulti un po’ ballerina. Ci sono stati dei casi di black-out molto prolungato che hanno messo a dura prova i miei UPS, portando le battarie all’esaurimento e creando qualche attimo di panico con il NAS.

Per questo ho deciso di implementare un sistema di monitoraggio della tensione di rete, che fosse in grado di:

  • rilevare l’assenza della tensione di rete;
  • comunicare via mail l’evento;
  • inviare mail periodiche in caso di perdurare del balck-out;
  • spegnere in modo graceful NAS.

La cosa è stata più facile sulla carta che non da vero, come sempre. In effetti ho dovuto lottare con le I/O della Cubieboard (come ho descritto in questo articollo).

CubieBoard. GPIO e che fatica!

Il rilevatore di tensione lo ho realizzato implementando uno schema che ho trovato in rete. Si tratta di utilizzare un piccolo trasformatore di tensione 220V -> 5V e di connetterlo ad un GPIO della Cubieboard attraverso un regolatore di tensione a 3.3V. Il trasformatore sarà collegato ad una presa di energia elettrica non servita da UPS. Al momento del black-out, la tensione in uscita dal trasformatore passa a 0 e lo stato logico del piedino di I/O della Cubieboard è 0. Lo schema è semplice ed efficace, solo che occorre mettere in conto che il trasformatore, consuma (pochissimo ma….).

IMG_20160417_105230

A questo punto ho quindi un sistema hardware che è in grado di creare un evento su un PIN della Cubieboard in caso di Black-Out. Il software è stato scritto in “bash” (strano vero?) . Lo script viene eseguito ogni minuto dal crontab e verifica lo stato del piedino di monitor. In caso sia a livello logico alto non succede nulla, in caso sia a livello 0 inizia una complessa routine per la gestione degli alert e degli eventi. Il funzionamento dello script si basa su alcuni files che vengono creati in /tmp/ e che contengono flag o timestamp per tenere traccia di quello che sta succedendo. Forse non è il modo migliore di programmare, ma questo è ciò che riesco a fare.

Una volta approntato il software è necessario configurare alcuni aspetti del sistema operativo, per fare in modo che le mail vengano inviate utilizzando Gmail. Per questo mi sono avvalso di una guida reperibile a QUESTO indirizzo.

Visto che avevo le mani  sulla tastiera, mi sono anche divertito a configurare l’applicazione Telegram sulla piattaforma Cubieboard. In effetti lo step due dello sviluppo del sistema sarà quello di abilitare anche il controllo bidirezionale del sistema via Telegram (per adesso è solo una idea, il tempo per lo sviluppo del codice e delle idee è sempre pochissimo).

Per quanto riguarda la programmazione in bash, il web è pieno di tutorial base o avanzati, basta sapere cercare un po’ su Google.

Per lo spegnimento del QNAP l’unica strada percorribile è quella di effettuare login sul sistema utilizzando SSH e dare il comando “halt”. Il comando poweroff non è altrettanto efficace e rischia di lasciare alcune parti del sistema attive. Per effettuare il login con il protocollo ssh sul NAS occorre utilizzare i certificati, in modo che non siano richieste le credenziali di autenticazione. Una guida alla configurazione si trova QUI.

Il codice è scaricabile dalla sezione DOWNLOAD del sito, nella sezione “Software”.

 

CubieBoard. GPIO e che fatica!

Per realizzare un progettino di cui parlerò tra qualche tempo, mi sono imbattuto nella necessità di lavorare con il GPIO della Cubieboard2. Alcune considerazioni:

  • la documentazione è pessima, questo riguarda tutto il progetto. Quindi, nessuna nuova!
  • Le GPIO sono a passo 2mm davvero scomode.

La mia CB monta un sistema operativo Debian 8.3 MainLine, come descritto QUI. Pertanto

The Allwinner-specific script.bin isn’t needed anymore.

L’accesso alla GPIO si effettua direttametne da SYSFS, solo che occorre “pescare” il PIN giusto. Per fare questo innanzitutto si individua il PIN FISICO sul quale vogliamo operare: io ho scelto il pin 17 del connettore U15 (ponendo la scheda con la alimentazione in basso, è il connettore sulla destra). Il PIN17 si chiama CSI1-D6. Guardando su questo schematico (è per la CB con A10 ma non cambia molto a quanto pare), si scopre che questo PIN fa capo al segnale PG10 del System On Chip. Pertanto si può applicare la formuletta trovata qui, per capire come referenziare correttamente il PIN: G-> 7a lettera dell’alfabeto

(numero_lettera_alfabeto – 1) * 32+(numero_pin) —> (7-1)*32+10=202

Per abilitare il PIN occorre digitare:

/bin/echo 202 > /sys/class/gpio/export
/bin/echo in > /sys/class/gpio/gpio202/direction

In qeusto modo, con il comando cat si può ricavare il valore del PIN:

root@cubieboard:~# cat /sys/class/gpio/gpio202/value
1
root@cubieboard:~#

Semplice vero? No. Ho impiegato DUE ore a capire questa cosa.

Maledetti!

Eagle, creare una board da una jpg!

Qualche tempo addietro un amico mi ha riportato la esigenza di riprodurre dei vecchi stampati utilizzati per un progetto datato. Di questi è presento solo qualche fotocopia dei layout originali, nassuno schematico. Mi sono attivato per vedere se si riuscisse a creare qualche cosa con Eagle, partendo da una scansione del foglio con il layout.

Il primo step è quello di scansire l’immagine, sperando che sia stata stampata in scala 1:1. Nell’eseguire la scansione annotare da una parte il valore del DPI utilizzato e eseguire lo scan in bianco e nero, a due colori. L’immagine deve essere salvata come BMP e ritagliata in modo da includere solo la parte di interesse.

Fatto questo è possibile importare l’immagine in una board Eagle, utilizzando File->Import->Bitmap.

eagle_blog_01

Prima dell’importazione Eagle chiede quali siano, tra i tanti rilevati, i colori da prendere in considerazione. Selezionare il bianco ed il nero.

eagle_blog_02

Fatto questo si apre una finestra nella quale dobbiamo mettere il fattore di scala. Se l’immagine scansita era stata stampata 1:1 e sappiamo la risoluzione di scansione è meglio affidarsi al DPI.

eagle_blog_03

Se ci sono dubbi sulla effettiva scala usata nella stampa dell’originale occorre procedere per… tentativi. In un caso ho proceduto in questo modo:

  • identificare un componente dello stampato con un footprint noto (TO92, DIP16);
  • importare la scansione impostando il DPI pari a quello della acquisizione;
  • confrontare il footprint noto con quello della libreria;
  • se non coincidono alla perfezione, cambiare DPI e reimportare l’immagine.
  • procedere fino a che il match non è perfetto.

Una volta che abbiamo l’immagine è necessario creare i fori di montaggio e le piste. Come primo passo si posizionano i fori.

eagle_blog_04

Quindi si collegano tra loro con il “signal” e poi si effettua un manual-routing dei segnali.

eagle_blog_05

Le zone più ampie possono essere coperte da poligoni, avendo l’accortezza di deselezionare il thermal e impostare isolate al minimo (non a zero).

eagle_blog_06

Dopo qualche ora di lavoro (svariate), il risultato è dignitoso.

eagle_blog_07

Buon lavoro. Sono sicuro che quando farete un progetto, la prima cosa che salverete sarà lo schematico!

 

 

Estate, tempo di…

Potrei anche chiudere qui la frase: Estate=tempo.

Negli ultimi giorni ho avuto finalmente il tempo di giocare un po’ con una cella di Peltier. Avevo acquistato il componente in inverno, in modo da preparare un minifrigo per l’estate. Il tempo è tiranno e solo negli ultimi due giorni ci ho messo le mani.

Premessa. Da qualche tempo utilizzo, per bere, una borraccia in alluminio della Scout Tech, in modo da non avere sempre tra i piedi le bottiglie di plastica. L’idea che mi è venuta è questa: se appoggio la borraccia sulla cella di Peltier, riesco a mantenere l’acqua fresca durante tutto il periodo lavorativo.

Mi sono messo all’opera, con una cella da 60W (se ricordo bene). L’ho installata su un dissipatore e ho dato tensione.

IMG_20150715_142457 IMG_20150715_142551

Il lato freddo è correttamente freddo ma quello caldo arde! Sono quindi nati tre giorni di prove alla ricerca del dissipatore migliore (recuperato poi in un armadio di ciarpame), dell’alimentare migliore (ex-pc del 2003) e di qualche ventola per raffreddare il dissipatore (ex alimentatore).

IMG_20150714_083141 IMG_20150714_152617

IMG_20150715_142503 IMG_20150715_142519

Ne è nato un “accrocco” davvero inguardabile ma perfettamente funzionante. Adesso voglio però migliorare alcuni aspetti: Dissipatore più grade, alimentatore migliore e cella più potente. il tutto spendendo il giusto (20 euro).

Buon divertimento!

Raspberry PI e i2c

Per acquisire dei dati meteo, ho realizzato una piccola schedina figlia che si basa sue due sensori: SHT21 della Sensirion e MPL3115 della Freescale.

Nell’interfacciamento del primo sensore non ci sono state particolari difficoltà, anche per il fatto che il codice è piuttosto diffuso e ben funzionante, sia in pyhton che in c.

Qualche grattacapo in più è arrivato dal dispositivo Freescale. In effetti il sisitema riconosce il dispositivo ma non riesce ad accedere ai dati. Pertanto anche se il comando i2cdetect -y 1 consente di visualizzare correttamente il dispositivo, una successiva lettura dei dati fallisce. Leggendo il datasheet è possibile notare come lo scambio dati richieda una condizione di “repeated start” per l’accesso al bus I2C. Peccato che questo non sia supportato dalla corrente implementazione del Kernel su Raspberry Pi:

As part of guaranteeing reliability, mostly in a multi-master setup, SMBus requires the use of I2C’s repeated starts for read operations. The I2C master driver for Linux on the Raspberry Pi does not support this

Fantastico. Fortunatamente Jovian Jackowski ha sviluppato un hack per questo problema. informazioni possono essere reperite qui e qui. Il codice per il dispositivo mpl3115 lo si può trovare qui e restituisce questo output:
root@raspbeacon:~/weather/mpl3115# ./mpl3115_comma
WhoAmI:c4
Status Register: 0
---- PRESSURE FUNCTION ----
Press RT: M:62 C:39 L:30
Press Integer Complete: 188e4 100580
Complete: 1005.00
Final Value 1005.75
---- END PRESSURE ----
---- TEMPERATURE FUNCTION ----
Temp RT: M:15 L:70
Temp Decimal Integer Part: 21
Tcomplete 21.4375
---- END TEMPERATURE ----
---- ALTITUDE FUNCTION ----
Alt RT: M:0 C:3f L:80
alt  Integer Complete: 3f 63
Complete: 63.00
Final Value 63.50
---- END ALTITUDE ----
1005.75,63.50,21.44

A presto!