Localizzatore GPS con SMS

Aggiornato il 24 Apr 2017
Ho deciso di progettare e costruire un semplice localizzatore GPS dopo un viaggio in macchina. Quando, dopo centinaia di Km di strada, sono arrivato a destinazione, ho parcheggiato l’auto ed ho citofonato alle persone che ero andato a trovare. Ho detto: “Posso lasciare qui la macchina ?” e mi è stato risposto: “Sì, c’è la telecamera”. Bene, avevamo punti di vista diversi sul lasciare lì la macchina! Io intendevo: “dà fastidio se la lascio qui ?” e loro: “lasciala pure lì, che se tentano di fregartela lo vediamo dalla telecamera”… Così ho deciso di realizzare questo localizzatore, da nascondere nell’auto quando vado fuori. La mia automobile non è “preziosa”, ma andare in auto e tornare in treno è… scocciante!

Inizialmente avevo pensato di realizzare la cosa usando un vecchio smartphone, creando una App in grado di fare ciò che mi serviva; poi, invece, ho deciso di usare un paio di modulini comprati su Internet. Ho sempre scritto volentieri le mie App, che poi ho pubblicato in forma gratuita su Google Play, ma recentemente ne ho dovute cancellare un paio perché mi è arrivato l’avviso di pubblicare una pagina di “privacy policy” a causa dell’uso della telecamera interna del telefono. Ora, l’uso della telecamera era assolutamente “pulito”, non carpivo dati sensibili dell’utente (non me ne può fregare di meno), ma la “dura lex” impone di scrivere una pagina in linguaggio “da legali” per avvisare l’utente che scarica l’App dal Market. Allora, dato il mio odio profondo per la burocrazia e per le cose inutili, ho deciso di rimuovere le App coinvolte e di non scriverne altre che richiedano di seguire la vigente normativa europea. In un tempo in cui tutti pubblicano ogni cosa della loro vita, VOLONTARIAMENTE, sui “Social”, le leggi europee sulla privacy mi sembrano delle autentiche fesserie. Purtroppo, però, le multe per inadempienza sono molto, molto salate e quindi io smetto di pubblicare App gratuite e stop.

La struttura hardware

Il localizzatore è molto semplice; usa un modulo GPS con uscita seriale che si compra su Internet a meno di 8 Euro e un modulo GSM M-590 in kit che ho pagato addirittura meno di 3 Euro!  I moduli sono collegati ad un microcontrollore Atmel ATmega48V che gestisce tutte le operazioni necessarie con un apposito firmware che ho scritto in C. Per quanto riguarda il modulo GSM, consiglio di leggere questo mio articolo che lo descrive in modo approfondito. Attenzione: il modulo GSM dovrà essere inizializzato preventivamente (vedi articolo citato, comando: AT+IPR=2400^M^J) per forzare la velocità della porta seriale. Questo è necessario in quanto il micro ATmega48V ha una sola UART e questa è usata per il modulo GPS con protocollo 9600,N,8,1. Ho dovuto quindi implementare una seconda seriale da software e prudentemente ho usato una velocità bassa (2400 BPS) per il GSM.

Se volete ulteriori notizie sul modulo GPS GY-NEO6 MV2, questo è il link da cui si può scaricare il datasheet. Nella figura sottostante potete vedere un esempio dell’output seriale, catturato con il programma di terminale seriale RealTerm impostato a 9600,N,8,1. Le righe evidenziate in giallo sono quelle che vengono usate dal firmware per determinare la posizione (latitude-longitude) attuale.

Il modulo GPS può essere utilizzato senza alcuna modifica hardware. La cosa veramente importante è di non superare mai il limite di 3.6V per l’alimentazione.

Il modulo GSM M-590, invece, arriva in kit (scatola di montaggio) e deve essere costruito. Il montaggio non è complicato, anche se si tratta di componenti smd. La parte difficile è saldare i led, che… tendono a rompersi! Quelli forniti con il kit sono molto, molto delicati. Consiglio di comprarne altri in package 0805 e usare molta pazienza e accuratezza nella saldatura. E’ imperativo l’uso di un buon saldatore. Lo schema del modulino è riportato nella figura sottostante.

Le zone evidenziate indicano le modifiche da fare. Il diodo D2 non sarà montato. Al suo posto si metterà un ponticello. La resistenza R4 da 4.7 KOhm sarà montata sui pin del connettore (vedi figura sotto), così come i condensatori C2 da 100nF e C3 da 22 pF. Il condensatore C1 non sarà montato. In pratica, il modulo sarà collegato al circuito a microcontrollore con 4 fili: Vgsm, GND, GSM_RX e GSM_TX.

Vediamo infine lo schema del circuito a microcontrollore. Come anticipato, si basa sul micro Atmel ATmega48V che ha 4KB di Flash, 256 Bytes di EEprom e 512 Bytes di Ram.

Se volete leggere lo schema con maggior chiarezza, scaricate il PDF da questo link. Nello schema è prevista l’alimentazione tramite una batteria ricaricabile Li-ion da 3.7V. L’assorbimento del circuito può andare da 50 a 250mA, con brevi picchi di 2A in funzione delle varie fasi operative dei moduli GPS e GSM. La durata della batteria, quindi, dipende dalla sua capacità. Una cella Li-ion a piena carica ha una tensione di 4.2V e scende a 3.7V quando la carica residua è circa del 10%. La tensione ideale per l’alimentazione del circuito è di 3.9V ; funziona anche con qualcosa di meno, ma il rischio è che il modulo GSM non riesca più ad inviare gli SMS. Notate che alcune batterie Li-ion di formato AA mostrano in etichetta una capacità molto elevata, ma spesso questa indica che la cella stessa può dare quella corrente, superiore alla nominale, per un periodo limitato di tempo. In pratica, in alcune applicazioni (in genere dove c’è un motorino elettrico) è necessario avere un corrente alta per un periodo di tempo breve e allora, queste batterie sono idonee allo scopo. Per un consumo “leggero” e continuativo, invece, bisogna guardare alla capacità reale della batteria. Un metodo infallibile per misurare questa capacità è quello di mettere in carica la batteria con una sorgente di cui si conosca l’erogazione di corrente. Facciamo un esempio: se io ho un caricabatterie settato per dare una corrente max di 300mA e la batteria si ricarica completamente in 4 ore, potrò dire con una certa sicurezza che è una cella da 1200mA (anche se c’è scritto sopra “4800mA”).

Se invece vogliamo alimentare il circuito a 12V, possiamo usare un regolatore lineare o uno switching. Nella figura sotto potete osservare lo schema di un regolatore lineare (super collaudato) in grado di fornire 3.9V stabilizzati. Sul regolatore andrà montato un piccolo dissipatore.

La struttura del software

Il software è scritto in linguaggio C ed è strutturato in due tasks indipendenti: 1) il gestore del modulo GPS e 2) il gestore del modulo GSM. I due tasks sono non-bloccanti e un watchdog si occupa di resettare il micro qualora uno di essi dovesse restare bloccato per più di 2 secondi.

Il task GPS si occupa di rilevare la posizione Lat – Lon quando il modulo la invia da seriale. Viene utilizzato il record NMEA di tipo $GPGGA, che viene generato quando il ricevitore ha “agganciato” un numero sufficiente di satelliti. I dati vengono salvati in un array di bytes in Ram che sarà poi utilizzato come testo dello SMS inviato a seguito di una richiesta. Il buffer è organizzato in modo da contenere la posizione corrente e 5 posizioni precedenti, prese a distanza di 60 campionamenti validi ognuna. In questo modo, se il ricevitore non vede più il cielo, in memoria restano almeno le ultime 5 posizioni valide prima della perdita della visuale. Questa memoria non viene azzerata al reset del micro (l’array è definito con la clausola __no_init), ma viene solo formattata in modo adeguato. Al primo reset (al power-on) la Ram ha dati casuali e quindi la routine di inizializzazione sostituisce con degli “spazi” ogni carattere fuori range. Se il reset è a caldo, quindi con il circuito già alimentato, i dati contenuti nel buffer saranno probabilmente validi e quindi l’inizializzazione non apporterà correzioni.

Il task GSM si occupa di verificare se ci sono chiamate dai numeri abilitati e in caso ci siano, si occupa di inviare un SMS con il testo elaborato dal task GPS, con le coordinate del dispositivo. La prima operazione dopo il reset è quella di aspettare la stringa “+PBREADY” dal modulo. Questa stringa ci conferma che il modulo è attivo e registrato sulla rete dell’operatore. La SIM deve essere preparata in modo da non richiedere un PIN per l’attivazione. E’ inoltre opportuno disabilitare ogni servizio non necessario (segreteria, messaggi automatici, ecc). Una volta ricevuta la conferma di registrazione, il software invia al modulo il comando “AT+CLIP=1” che avvia il servizio di identificazione del chiamante. In pratica, quando si riceve una chiamata, oltre alla classica stringa “RING” si riceve un altro messaggio “AT+CLIP:” seguito dal numero di telefono del chiamante. Il numero ricevuto è comparato con i due numeri abilitati (memorizzati in EEPROM, vedremo poi come) e se il confronto è positivo il messaggio SMS viene inviato al chiamante quando questo chiude la chiamata (nota: il dispositivo non “risponde” alla chiamata, non ci sono costi addebitati sul telefono che chiama). La chiusura della chiamata viene recepita con il messaggio “NO CARRIER”. Il task invia l’SMS e attende la conferma dell’avvenuto invio e quindi riprende il suo ciclo con la fase di attesa di chiamate. Se invece qualcosa va storto, il task esegue un reset del modulo GSM togliendo brutalmente alimentazione al modulo stesso, tramite un pin di uscita del microcontrollore che è collegato ad uno switch elettronico realizzato con due mosfet P-N (vedi schema). Questa soluzione può sembrare eccessiva e costosa, ma il datasheet del costruttore del modulo M-590 consiglia, in casi in cui non si riesca a ripristinare il modulo con il comando software, di togliere alimentazione… e così ho deciso di tagliar corto e di usare questa soluzione comunque, senza perdere tempo con il comando software. Ovviamente, dopo questa operazione di riavvio del modulo, il task GSM riparte dallo stato iniziale, attendendo il messaggio “+PBREADY” prima di ogni altra operazione.

Costruzione ed utilizzo

Come si vede dalla foto del dispositivo in testa all’articolo, non c’è un circuito stampato per il microcontrollore, ma il tutto è assemblato su di una scheda “millefori” per prototipi. Data la semplicità del circuito e data la natura “sperimentale” del progetto, ho deciso per questa soluzione. I componenti sono pochi e chiunque abbia una certa pratica di costruzioni elettroniche può riuscire a realizzare il localizzatore, con un po’ di pazienza. Naturalmente, non è il progetto ideale per chi è alle prime armi e non ha la padronanza del saldatore e un po’ di pratica con i prototipi elettronici.

Una volta costruito il circuito, si dovrà programmare il microcontrollore. Per la programmazione del microcontrollore io utilizzo il programma AvrDude, disponibile a questo link. Troverete, nel file zip di questo progetto, tre files batch che servono a programmare, rispettivamente, la memoria Flash, la EEPROM e i FUSES (fusibili) con la configurazione necessaria per questa applicazione. I files batch prevedono che il programma AvrDude sia installato e raggiungibile con il percorso impostato. Modificate i files batch secondo le vostre esigenze, adattandoli per il percorso dell’applicazione e per il modello di programmatore usato.

1_wrFlash.bat per la programmazione della memoria Flash:

avrdude -P com14 -p m48 -c stk500 -e -U flash:w:localizer.hex
pause

2_wrEeprom.bat per la programmazione della memoria EEPROM:
avrdude -P com14 -p m48 -c stk500 -U eeprom:w:earom-wr.bin
pause

3_wrFuses.bat per la programmazione dei FUSES:
avrdude -P com14 -p m48 -c stk500 -U hfuse:w:0xC5:m -U lfuse:w:0xFC:m
pause

Come si vede dal contenuto dei files batch, il programmatore che uso è di modello stk500 ed è collegato sulla porta com14. Le operazioni di programmazione saranno eseguite nell’ordine: 1) scrittura della memoria Flash, 2) scrittura della memoria Eeprom, 3) scrittura dei Fuses.

Per rendere il dispositivo in grado di funzionare, dobbiamo modificare il file earom-wr.bin per inserire i due numeri di telefono che saranno autorizzati a comandare l’invio del messaggio SMS da parte del dispositivo. Vediamo un esempio di tale file aperto con l’applicazione FrHed, scaricabile a questo link.

Evidenziati in giallo ci sono i due numeri. Quelli nell’immagine non sono numeri “veri”, servono solo per far capire dove e come scrivere quelli “reali”. Con FrHed è possibile modificare i valori sia in ASCII, spostando il cursore di editing sulla finestra a destra, sia in Hexadecimal, spostandolo a sinistra. Il numero programmato dovrà essere preceduto dal prefisso internazionale, perché così viene ricevuto dal modulo GSM (vedi esempio sotto).

In pratica, se usiamo un telefono con SIM italiana, il numero inizierà con 39. E’ fondamentale chiudere il numero con il valore Hex 00, che viene usato come terminatore di stringa dal liguaggio C. Nell’immagine di esempio i due numeri programmati sono: 39 333 1234567 e 39 339 7654321; modificateli secondo le vostre esigenze e quindi salvate il file aggiornato. Ora sarà possibile scrivere i numeri nella EEPROM del microcontroller eseguendo il file batch WrEarom.bat.

…continua…

Telepatometro

Mi sono un po’ stufato delle compagnie telefoniche e delle loro “variazioni di contratto unilaterali”, che significa che se vuoi continuare a usare il telefono devi tacere e accettare le nuove condizioni. Perché mai dobbiamo continuare a usare questi collegamenti “primitivi” per contattare una persona (o un dispositivo) a distanza ? Perché non usare la TELEPATIA ? Ah, forse voi pensate di non essere telepati. Beh, non tutti lo sono. Non fatevene un cruccio. Però, forse lo siete e non lo sapete ! Allora vi serve un dispositivo per misurare le vostre capacità di telepate, come “trasmettitore” o come “ricevitore” o in entrambi i ruoli.

E’ da tanto che penso a come sarebbe bello un mondo pieno di telepati, dove ci si possono scambiare idee senza parlare, senza ipocrisie, senza menzogne. Lo so, sarebbe la fine per una certa classe politica e soprattutto per le compagnie telefoniche. E allora che aspettiamo ? Per dimostrarvi che è da un po’ che ci penso, vi invito a visitare questo link, dove potrete scaricare una copia in PDF della rivista “Electronics Projects” del Gennaio 1990. Sfogliate la rivista fino a pag. 25 e lì troverete un mio articolo che ha come titolo “Il telepatometro” !

Quella volta, come strumento per misurare le capacità telepatiche, avevo fatto un circuito con un micro 6804 (Motorola). Ho ancora il prototipo :

Oggi vi presento una versione più moderna 🙂 ma il concetto rimane lo stesso. Qui sotto vedete una schermata della App per Android :

Ho messo qui l’immagine in orizzontale, per fare un raffronto con il “vecchio modello”, ma in effetti l’App supporta solo l’orientamento verticale (portrait).

Come funziona ?

Lo schermo del telefono è separato in due da una riga gialla. In alto c’è il lato del “ricevitore”, con cinque pulsanti ognuno dei quali ha un simbolo Zener, della serie usata anche da persone che effettuano esperimenti seri in questo settore. In basso c’è la parte del “trasmettitore”, con un display a due cifre, un pulsante di “exit” e un altro per avviare e controllare l’andamento della prova.

Facciamo un giro: due persone si mettono sedute a un tavolo, una di fronte all’altra, con il telefono in mezzo. Al centro del telefono (sulla riga gialla) si piazza uno schermo (può essere un pezzo di carta, oppure la mano di uno dei giocatori) in modo che il “ricevitore” non possa vedere cosa c’è dal lato del “trasmettitore”. Il “trasmettitore” preme il pulsante a destra (quello con le due frecce tonde) e nello spazio centrale appare (in modo casuale) uno dei 5 simboli Zener: cerchio, quadrato, croce, stella, onde. Il “trasmettitore” si mette a pensare intensamente al simbolo visualizzato e il “ricevitore”, se è telepatico, sicuramente visualizzerà nella sua mente tale simbolo, quindi premerà il tasto corrispondente dalla sua parte. A questo punto il “trasmettitore” premerà di nuovo il pulsante a destra per estrarre un nuovo simbolo. La cosa andrà avanti per 20 volte (ho verificato che con più prove mi viene mal di testa) e alla fine ci sarà il conteggio dei risultati indovinati dal “ricevitore”. Tale valore sarà visualizzato sul display, che in tale occasione sarà lampeggiante. Per ripartire con un nuovo test (magari scambiando il “trasmettitore” e il “ricevitore”) si premerà di nuovo il solito pulsante a destra, oppure “exit” per terminare.

Probabilità

Avendo 5 simboli, la probabilità di indovinare quello giusto è del 20% (una su cinque) e quindi, ripetendo la prova per 20 volte, tipicamente avremo un totale di “carte indovinate” pari a 4. Possiamo verificare questa cosa facendo premere al “ricevitore” sempre lo stesso pulsante (lo stesso simbolo) per tutti e 20 i tentativi. Il valore ottenuto non si discosterà molto da 4. Allora, come facciamo a vedere se c’è telepatia ? Se due persone riescono ad ottenere un valore che si discosta MOLTO da quello previsto, tipo 8, 10 o più, potremo affermare che c’è qualcosa di “strano” (se non abbiamo imbrogliato) . Conviene fare questo “gioco” con molti amici, provando diverse combinazioni di “trasmettitori” e “ricevitori”. Va benissimo fare queste prove al tavolo di un Pub, ripetendo l’esperimento dopo uno o più boccali di birra ! L’importante è che chi poi dovrà guidare resti sobrio, anche se sfortunatamente non dovesse risultare telepatico !

Trovate l’App sulla mia pagina di Google Play, è gratuita.

Ecco un esempio di uno schermo di protezione realizzato con un pezzo di carta e due stuzzicadenti, in meno di un minuto. In questo modo si sta più comodi e nessuno “sbircia”. E’ facile realizzarlo (pure meglio) anche con materiale che trovate al Pub. Sarà un ulteriore divertimento…

w5500 – relè controllato da Internet

aggiornato il 19 Mar 2017 – finito!
Correva l’anno 1997. In Ottobre decisi di fare un contratto con il locale provider di Internet. Nella mia cittadina di 19mila abitanti (allora), il provider (l’unico) aveva 3 (dico tre) modem, e quindi il massimo numero di connessioni contemporanee era… tre. E bastavano ! Sì, a qualsiasi ora si riusciva a trovare un modem libero. Si pagavano sia l’abbonamento al provider, sia la telefonata. Eravamo in pochi, davvero.

Durante le prime navigazioni, finii sul sito di una università in Australia. Il sito aveva tre telecamere (B/N) che inquadravano un piano di lavoro a tre assi X,Y, Z con un braccio che poteva essere comandato via web (a linea di comando) per muoversi e afferrare dei pezzi (costruzioni per bambini) per costruire qualcosa. Ne rimasi affascinato e mi meravigliai di cosa si potesse fare così, da una parte all’altra del mondo. Fu una rivelazione e decisi che mi sarei messo a studiare come fare anch’io qualcosa del genere. Ammiravo quelle persone che erano così competenti da aver realizzato questa cosa fantastica, mentre io non sapevo ancora niente di Internet e dei vari protocolli coinvolti. Mi misi quindi a studiare e dopo qualche mese, nella primavera del 1998, realizzai il mio primo “rover” controllato via Internet tramite un web browser (c’era Internet Explorer 3 e prima bisognava lanciare lo stack TCP con Trumpet). Il mio rover aveva a bordo una telecamera B/N del Game Boy, collegata ad un microcontrollore Mitsubishi (ora Renesas) M16C che aveva ben 20KB di RAM interna ! L’immagine, da 128×128 pixel, veniva inviata dal rover al PC (su cui girava il mio piccolo web server elementare) tramite un modulino RTX a 866 MHz. Funzionava ! Era primitivo, goffo, lento, rispondeva con una decina di secondi di ritardo, ma funzionava !

My first Rover, built in 1998, controllable via a standard browser on the Internet.

Oggi abbiamo una situazione leggermente diversa. Si parla sempre di IoT e io pensavo che fosse “Internet of Thieves” perché come clicchi il bottone sbagliato ti svuotano la carta di credito. Invece NO, pare che tutti i dispositivi di casa vogliano davvero collegarsi a Internet, per darvi una vita migliore (???).

Bene, a prescindere dalle considerazioni filosofiche, abbiamo molte diverse possibilità per controllare un relè in casa tramite Internet. Ci sono apparecchi professionali o anche da hobbisti che fanno già questa cosa ; se non avete tempo da perdere, compratevi uno di questi dispositivi già pronti e via…

Per comandare un relè da remoto, dobbiamo creare una connessione Internet tra il ricevitore (il dispositivo con il relè) e il trasmettitore (un PC o un Tablet o uno Smartphone). Possiamo creare una connessione Server-Client HTTP, ma dovremo fare un abbonamento ad un servizio tipo dyndns, per avere un “nome” con un IP “statico” a cui collegarci. Dovremo inoltre programmare il nostro modem / router in modo che vada ogni tanto ad aggiornare il servizio dyndns. Inoltre, sarà necessario aprire una “porta” che lasci passare, sul firewall incorporato nel modem / router, il traffico “in-going” verso il server.

Se non vogliamo fare tutto questo, potremmo creare un dispositivo che si comporta da MQTT subscriber, cioè mettere un client MQTT sul nostro dispositivo ed utilizzare un “broker” pubblico per fare la connessione. Però i broker pubblici e gratuiti non sono garantiti per funzionare sempre e poi dovremo comunque usare un client MQTT anche sul dispositivo di comando (PC, Tablet, Smartphone) per modificare lo stato del nostro relè. Il vantaggio di questa soluzione è che non dobbiamo eseguire alcun settaggio sul modem / router e l’attivazione / disattivazione del relè è praticamente immediata dopo aver azionato il comando “Publish” su PC / Tablet / Smartphone.

Poi, c’è la soluzione che ho deciso di adottare per questo esperimento. Non dovremo aprire porte sul router o fare un abbonamento a dyndns, ma ci serve un nostro sito web personale, in grado di eseguire scripts PHP.

I siti web gratuiti sono molto diffusi. Questo articolo che state leggendo è pubblicato su un hosting gratuito. Se andate su: https://it.altervista.org/ potete farvi un sito gratis, con un ottimo servizio e molti tools. Nella descrizione di questo esperimento, però, farò riferimento ad un altro web hosting gratuito che è: http://www.freewebhostingarea.com/ . Cercate on-line la soluzione che più vi aggrada. L’unica cosa importante è che ci sia la possibilità di far girare scripts PHP. Quindi, il prerequisito per andare avanti è quello di avere lo spazio web. Preso lo spazio, ci dobbiamo mettere dentro un po’ di cose. Useremo un client FTP per accedere ai nostri files, con le credenziali che ci saranno fornite dal web hosting. Di solito, come client FTP, io uso WinSCP (sotto Windows) e quindi gli esempi che seguiranno si basano su questo tool.

Sì, ma come funziona ?

Il funzionamento è veramente semplice. Il nostro relè-box, con il chip w5500, andrà ogni 3 minuti a caricare dal nostro sito un file che si chiama cmd.htm ; il contenuto (minimale) di questo file è una semplice stringa di testo che può essere #On oppure #Off. In funzione di questo valore, il relè si accenderà o si spegnerà. Più facile di così…

Dato che il nostro relè-box va a fare il “polling” ogni 3 minuti, avremo un certo tempo di latenza, cioè, nel caso peggiore, dovremo aspettare 3 minuti perché il nostro comando ON o OFF venga recepito e quindi il relè assuma lo stato desiderato. Questo è uno dei limiti del sistema, ma per un’applicazione generica, tipo quella di accendere le luci di casa per scoraggiare i ladri, è accettabile.

Ora, chi è che modifica il file cmd.htm in modo da far cambiare stato al relè ? Ci pensa uno script PHP che risiede sul nostro sito. Con un qualsiasi browser, su un qualsiasi dispositivo connesso ad Internet, inseriamo l’indirizzo del nostro sito e navighiamo. Facciamo un esempio:  abbiamo creato il nostro sito come ilmiosito.eu5.org ed abbiamo salvato sulla root tutti i files necessari (li trovate più avanti). Ora, avviamo il browser sul nostro dispositivo e scriviamo nella barra degli indirizzi : http://ilmiosito.eu5.org/remote e diamo l’invio. Ci troveremo su una pagina di accesso protetta da password.

A sinistra vediamo la schermata di accesso. Dovremo inserire il nostro nome utente e password, così come sono stati salvati sul file .htpasswd . Una volta inserite le credenziali ci troveremo con la schermata a destra. Toccando l’icona #On vedremo il menù di selezione con le due opzioni possibili:

Selezioniamo, ad esempio, #Off e quindi premiamo “invio”. Se tutto è a posto, il file cmd.htm sarà modificato e vedremo la schermata a destra che ci conferma che non ci sono stati errori. Vediamo quindi la struttura del nostro sito web :

Non c’è molta roba… Abbiamo una sottocartella chiamata “remote” e due files. La pagina web index.htm è semplicemente quella principale del sito “in costruzione”, mentre cmd.htm è quella che sarà richiamata dal nostro relè-box per sapere quale stato deve assumere il relè. A seconda del web hosting utilizzato, potremmo avere un errore di scrittura quando cerchiamo di modificare lo stato del relè. Ciò è dovuto ai permessi di scrittura del file cmd.htm sul server. Per modificare tali permessi, usando WinSCP, basta cliccare sul file cmd.htm (nella cartella remota) con il tasto destro del mouse e poi su properties, come nell’immagine (a seconda del server, sarà 644, 664 o 666) :

I files che ci permettono di fare l’accesso con password sono due: .htaccess e .htpasswd. Il primo informa il server sul fatto che la directory dove esso stesso è contenuto ha l’accesso limitato. Il suo formato sarà questo:

E’ importante dare il percorso completo (path) giusto per il file .htpasswd, quello che contiene la lista di utenti / passwords autorizzati all’accesso. Se il percorso non è corretto, riceveremo un errore dal server, tipicamente il #500. La riga evidenziata di giallo andrà modificata con il percorso completo del vostro sito, naturalmente. Per l’editing di tutti i files di testo, io uso il programma Geany, che è gratuito e fondamentale anche per programmare in diversi linguaggi.

Il secondo file, quello chiamato .htpasswd, contiene, come detto, username e password per i vari utenti abilitati, uno per linea. Nella figura sotto vediamo il file di default che ha l’utente: user e la password: password (che fantasia !)

La password non è “in chiaro”. Per creare le password con la cifratura standard, possiamo usare vari tools presenti su internet. Ne ho uno anche io sul mio sito a questo link : http://robotop.eu5.org/php/pswmaker.php. Inserendo user e password e cliccando Encrypt si otterrà la linea da inserire, con copia-incolla, nel proprio file .htpasswd.

Il file index.php nella cartella remote è quello che fornisce la pagina di accesso, con la lista #On / #Off e il pulsante Invio. La destinazione del form è lo script PHP chiamato write.php, che si occupa di modificare il file cmd.htm sulla cartella principale. E’ tutto qui. Se ogni cosa è stata fatta bene, potremo testare il corretto funzionamento del sito e osservare se puntando con il browser sul file cmd.htm leggiamo #On o #Off in seguito alle nostre operazioni. Se tutto è OK, possiamo passare all’elettronica e alla scatoletta relè-box con il w5500.

I files per realizzare il sito web “minimalistico” sono in uno zip scaricabile dal link che trovate qui sotto.

Clausola di non assunzione di responsabilità:
Il programma o software descritto, liberamente prelevabile dal sito, è da considerarsi una “demo” gratuita e pertanto l’autore Emilio P.G. Ficara non fornirà alcun supporto, né si assumerà alcuna responsabilità per ogni eventuale problema, danno o conseguenza che dovesse presentarsi nel download o nell’esecuzione dell’applicazione.
Cliccando questo link per effettuare il download del file ilmiosito.zip implicitamente dichiarate di aver letto e capito la clausola di non assunzione di responsabilità e di accettarla.

Verificate sempre il checksum MD5 dei files che scaricate ! In questo caso deve essere: 7C5D035C9EDE39827ED747E5DBCE5895 ; se è diverso, il file è corrotto o non è quello originale, quindi non scompattatelo e buttatelo via ! Se invece è tutto ok, potete scompattarlo (è richiesta una password che è: eficara).

Hardware e firmware

Veniamo ora al circuito e al firmware di quello che da ora in poi chiameremo, per brevità, RBox (Relay Box). Dallo schema si nota che è del tutto simile a quello presentato nel precedente articolo Esperimenti con W5500 con la sola aggiunta del relè e di un diodo di protezione.

Per una visione più dettagliata, è possibile scaricare il file in formato PDF da questo link. Qui sotto c’è una foto del prototipo modificato con il relè. Ho usato un relè a 5V con una bobina da 167 Ohm, preso da un vecchio circuito telefonico.

Come nei precedenti esperimenti con il chip W5500, sarà possibile personalizzare il firmware mediante un programma su PC (Windows) che modifica il file HEX usato per programmare il microcontrollore ATmega88. Rispetto a prima, sono stati aggiunti dei nuovi parametri, come si vede dalla figura:

Il microcontrollore usato è un ATmega88, ma se si eliminasse la sezione di firmware che fa da debug / monitor (sulla seriale), si potrebbe tranquillamente utilizzare un ATmega48, con la metà di memoria Flash e Ram ; per quanto riguarda la EEprom, questa non è usata affatto. Per l’utilizzo del programma di personalizzazione, rimando a quanto scritto nel precedente articolo (Esperimenti con W5500). A parte i campi in più, il funzionamento è identico.

Il flusso di programma

Il programma è molto semplice. Vediamolo nelle sue fasi successive :

:: al reset il micro legge i parametri dalla memoria flash e li scrive nel chip W5500 e nei buffers di Ram che saranno utilizzati nei comandi successivi, quindi avvia la procedura principale, programmando il primo evento temporizzato dopo 5 secondi. Durante tutti i tempi di attesa, il led lampeggia con cadenza di circa un secondo..

:: appena il contatore del tempo arriva al valore impostato per l’evento temporizzato, parte la prima fase di connessione ad Internet, che consiste nell’interrogazione del server DNS il cui IP è stato impostato nei parametri programmabili. Di default questo IP è 8.8.8.8 che è il DNS server di Google. Viene quindi aperto un socket UDP sulla porta 53 e viene inviata la richiesta con la URL del nostro sito web, quella impostata nei parametri programmabili. Se tutto va bene, riceviamo l’IP del web server e questo viene salvato in un buffer in Ram che costituisce l’indirizzo IP di destinazione per le operazioni successive. Se invece ci sono problemi, il programma riparte dalla fase iniziale.

:: una volta ottenuto l’IP del nostro web server, il programma inizia una connessione HTTP GET a tale indirizzo IP, usando nello header (come Host:) l’URL del server e come PATH la restante parte dell’indirizzo. Ad esempio, l’URL sarà ilmiosito.eu5.org e come PATH ci sarà /cmd.htm. La porta di destinazione sarà ovviamente la 80, dato che facciamo una connessione a un server web. Se tutto va bene, riceveremo un pacchetto di dati che contiene la pagina web a cui abbiamo fatto riferimento ; verrà quindi analizzato il testo tra i tag <html> e </html> per vedere se c’è il comando #On oppure #Off. Se tutto va bene, il relè sara impostato di conseguenza ; se invece ci sono errori, il ciclo comincerà di nuovo. In caso di esito positivo, tutto il ciclo sarà riavviato, ma con il tempo del prossimo evento settato a 3 minuti. Nel frattempo, il led continuerà a lampeggiare.

Durante tutte le fasi, sulla porta seriale (con protocollo 9600,N,8,1), viene prodotto il log delle operazioni eseguite. Collegando alla porta di debug una interfaccia USB-TTL e avviando un programma di terminale seriale (se volete, ce n’è uno di mia creazione nel file di download), sarà possibile effettuare un efficiente debug ed eventualmente intervenire per modificare alcuni valori.

I comandi da seriale sono aumentati, rispetto alla versione precedente (Esperimenti con W5500). I nuovi comandi sono:

: : (trattino) ferma l’applicazione che effettua automaticamente la richiesta DNS e l’HTTP GET e quindi il sistema rimane in attesa di comandi da seriale.

: 1 : (cifra 1) accende il relè

: 0 : (cifra 0) spegne il relè

Download

Tutti i files necessari per programmare il microcontrollore sono contenuti in uno zip che potete scaricare liberamente. Il contenuto della cartella è questo:

Analizziamo i vari files:

1_wrFlash.bat è un file batch per lanciare l’applicazione avrdude per programmare la memoria Flash del micro. Le impostazioni per il mio programmatore sono: porta=Com14 e tipo=STK500. Modificate i valori per le vostre esigenze.

2_wrFuses è il batch per programmare i “fuses” del micro.

com3-9600.bat è il batch per avviare il terminale seriale miterm sulla Com3 a 9600 BPS. Modificatelo per le vostre impostazioni.

miterm.exe è l’eseguibile che fa da terminale seriale. L’ho scritto in FreeBasic e gira anche su una chiavetta USB, non serve installazione.

rbox.hex è il file originale in formato intel-hex che viene usato come base di partenza dal programma di personalizzazione.

rbox-mf.hex è il file in formato intel-hex che è stato modificato tramite il programma di personalizzazione. Sarà utilizzato per programmare il microcontrollore.

RBoxprog.exe è l’applicazione per Windows che consente di modificare i parametri del firmware per personalizzarlo secondo le proprie esigenze. Anche questo l’ho scritto in FreeBasic e gira anche su una chiavetta USB, senza installazione.

Clausola di non assunzione di responsabilità:
Il programma o software descritto, liberamente prelevabile dal sito, è da considerarsi una “demo” gratuita e pertanto l’autore Emilio P.G. Ficara non fornirà alcun supporto, né si assumerà alcuna responsabilità per ogni eventuale problema, danno o conseguenza che dovesse presentarsi nel download o nell’esecuzione dell’applicazione.
Cliccando questo link per effettuare il download del file implicitamente dichiarate di aver letto e capito la clausola di non assunzione di responsabilità e di accettarla.

Verificate sempre il checksum MD5 del file scaricato ! Questo deve essere: 632CA2A7244552F141384D70A6975971 ; se è diverso, il file è corrotto o non è quello originale. In questo caso, non scompattatelo e buttatelo via !
Se invece è tutto ok, potete scompattarlo (è richiesta una password che è: eficara).

Considerazioni finali

Alcune cose importanti da considerare : il dispositivo è “sicuro” ? NO! E’ possibile intercettare i dati (user e password) quando date il comando sul sito web, dato che non si effettua una connessione sicura HTTPS. Inoltre, ci sono altri metodi per dirottare le richieste DNS in modo da andare a prendere la pagina web cmd.htm da un’altra parte (un sito fittizio). Questo è un esperimento, un esercizio e perciò la sicurezza è limitata. Tenete presente, però, che anche i sistemi “professionali” hanno le loro vulnerabilità. Ricordate che anche i server dei BIG dell’informatica vengono attaccati con successo dagli hackers “cattivi”, così come i siti istituzionali di potenti Nazioni. Un vecchio detto dell’informatica afferma: “un computer sicuro è un computer con la spina staccata, chiuso in una cassaforte di cui si sono perse le chiavi“. E’ la pura verità. Un altro detto che fa parte della mia filosofia di vita (e di progettazione) è “non usare un cannone per sparare alle zanzare” e quindi usate gli strumenti adeguati in funzione dello scopo da raggiungere. Se avete in casa gioielli per 5mila euro, non comprate un impianto antifurto da 50mila euro, tanto per intenderci. In questo caso, per accendere e spegnere da remoto le luci di casa, mentre siamo fuori per il week-end, il circuito proposto va più che bene. Ricordate che la migliore sicurezza si ottiene con… la segretezza! Non fate pubblicità ai vostri controlli remoti, non parlatene con gli amici al bar, non date username e password ad altri, non usate il WiFi pubblico per inviare informazioni personali e… forse sarete al sicuro!

Il sistema descritto in questo esperimento può essere usato, naturalmente, anche per conoscere da remoto lo stato di uno switch, la temperatura di un ambiente o qualsiasi altro valore. Se continuerò a fare esperimenti, pubblicherò un nuovo articolo a questo proposito. Al momento, penso di non farlo perché sto dedicando tutte le mie energie alla ricerca di un nuovo lavoro. E’ complicato, sia in Italia che all’estero. Incrocio le dita…

Esperimenti con W5500

aggiornato il 7 Mar 2017- Finito !
Dopo aver progettato alcuni dispositivi con i modulini WiFi basati sul componente ESP8266, ho deciso di passare in modalità “wired”, perché mi hanno fatto notare che molte persone spengono la sezione WiFi del modem / router quando non serve loro per “navigare” e quindi gli eventuali dispositivi di domotica basati su wireless diventano inutilizzabili !

A questo punto, ho deciso di realizzare una versione dei miei dispositivi anche su wired LAN e ho quindi cercato un componente adatto. Ci sono diverse opzioni, ma dopo alcune considerazioni su costi e reperibilità ho deciso di puntare sul chip W5500.

Il sito del produttore mette a disposizione una vasta e accurata documentazione, sia per l’hardware che per il software. Ci sono librerie software aggiornate e molti esempi relativi alla gestione dei vari protocolli, ma (come sempre) io ho deciso di studiare il datasheet del componente e scrivere i miei programmi di test a partire da zero.

Per cominciare a fare delle prove pratiche, ho comprato on-line un modulino che ospita il componente, con il minimo essenziale di hardware per la connessione al microcontrollore esterno e alla rete LAN.

A destra il modulo collegato con un flat-cable al micro; a sinistra il dettaglio del pinout

Purtroppo, non ho potuto riutilizzare nulla del software scritto per i moduli ESP-01, ESP-07 eccetera, perché il W5500 ha un’architettura e una modalità di pilotaggio completamente diversi. Intanto, dal punto di vista hardware, la connessione avviene tramite SPI (quindi una seriale sincrona) e non tramite UART ; poi, lo stack TCP embedded richiede una programmazione a un livello più basso, una gestione dei “socket” un po’ più complessa.

Per questa prima parte dell’esperimento ho riciclato una mia vecchia scheda, basata sul microcontrollore Atmel ATmega88, che avevo realizzato in passato per pilotare il noto ENC28J60 della Microchip. Dato che anche quel chip si pilotava tramite SPI, ho rimosso l’integrato (che era in versione DIP e montato su zoccolo) e ho collegato i vari segnali della seriale sincrona al connettore del modulino W5500. Ho così potuto riutilizzare anche la parte di software che gestiva la comunicazione SPI. Il circuito di prova si presenta così :

Il primo prototipo: scheda con micro ATmega88, modulo W5500 e interfaccia USB-TTL per il debug del programma.

Lo schema elettrico della scheda a microcontrollore, modificato e semplificato dalla versione originale con il chip ENC28J60, è questo:

Per una visione più dettagliata, è possibile prelevare il file in formato PDF da questo link.

Come si vede dalla nota sullo schema, al momento attuale le linee di I/O del micro che non sono state utilizzate sono “floating”, in attesa di definire un hardware aggiuntivo, ma a progetto finito ogni linea non usata deve essere opportunamente collegata ad un riferimento. Tipicamente, dato che il micro al reset pone tutto l’I/O in condizioni di Input (alta impedenza), è possibile collegare tra loro tutti i pin inutilizzati ed usare una resistenza sola per collegarli tutti a GND. Ovviamente, nella fase di inizializzazione delle linee di I/O del firmware, bisogna tenere conto di questa soluzione circuitale.

Breve descrizione del componente

L’integrato mette a disposizione del progettista un completo stack TCP, con 8 sockets indipendenti e un’area di memoria RAM dedicata. Il controllo del funzionamento avviene scrivendo o leggendo alcuni registri e aree di memoria tramite interfaccia seriale sincrona SPI. I blocchi di memoria sono tre:

Common Register Block, dove troviamo i registri di controllo
Socket Register Block, dove troviamo i registri relativi agli 8 Sockets
Memory, dove troviamo i buffers di lettura / scrittura degli 8 Sockets

La seriale SPI può essere usata in modo da leggere / scrivere una quantità fissa (1,2,4 bytes – FDM) o variabile (n Bytes – VDM) di dati. Per utilizzare quest’ultima modalità, è necessario pilotare la linea /CS (Chip Select) per informare il chip dell’inizio e fine di uno stream di dati. Nel mio progetto ho usato esclusivamente questa modalità. Uno stream di scrittura / lettura è costituito da tre fasi: Address Phase, Control Phase, Data Phase.

Nella Address Phase vengono inviati 2 bytes che costituiscono l’indirizzo di offset rispetto all’origine del blocco di memoria selezionato ; nella Control Phase viene inviato un singolo byte che indica il blocco di memoria che si vuole selezionare, il modo RD / WR e la modalità FDM / VDM ;   infine, nella Data Phase vengono scritti o letti i dati (quindi, in caso di modo VDM questa fase ha un numero variabile di bytes).

Per poter effettuare una qualsiasi operazione è necessario inizializzare alcuni registri principali. Al reset il chip assegna dei valori di default ; molti di questi non avranno bisogno di essere modificati, perché sono i più adatti ad un funzionamento normale. Per esempio, i registri che determinano la quantità di memoria RAM assegnata agli 8 sockets vengono inizializzati con il valore di 2K Bytes. Così facendo, avremo lo spazio di memoria uniformemente distribuito tra gli 8 sockets, per un totale di 16K Bytes in scrittura e altrettanti in lettura. Naturalmente lo spazio di memoria può essere distribuito in modo differente, purché si rispetti la quantità massima di RAM disponibile che è, appunto, di 16K Bytes per i buffers di TX e 16K Bytes per quelli di RX.

L’accendiamo ? Sì, l’accendiamo !

Bene, il circuito c’è, partiamo con il primo step: colleghiamo il nostro dispositivo alla LAN e proviamo a vedere se risponde al “ping”. Come al solito, non ho utilizzato “librerie precotte”, ma ho scritto il programma a partire dallo studio di ciò che mi serve, riflettendo bene sul minimo indispensabile per raggiungere lo scopo. Non mi piace l’approccio che (purtroppo) ha preso piede negli ultimi anni, cioè quello di fare strutture di software immense e poi definirle “scalabili”. Questo “scalabile” spesso significa che se a me serve solo una minima parte, devo prendere un grosso blocco e poi togliere quello che è in eccesso. Nella mia lunga esperienza ho potuto appurare che si fa molto prima a scrivere da zero l’essenziale che non a togliere il 90% dell’inutile ; è come costruire una  tazzina da caffè partendo da un blocco di marmo di due metri di lato, con grande fatica di scalpello e martello. Io, preferisco usare una “stampante 3D” e creare ciò che mi serve usando solo il materiale necessario.

Il nostro dispositivo si collega ad una rete LAN, tipicamente fornita dal modem / router che ci connette al provider. Teniamo presente che il chip w5500 non ha protocolli già pronti, ma ci mette a disposizione alcuni sockets TCP / UDP e poi… il protocollo lo dobbiamo scrivere noi ! Dunque, non c’è un DHCP pronto all’uso e quindi programmeremo nei registri interni del chip un IP statico, che sarà quello che poi proveremo a “pingare”. Un altro importantissimo dato da scrivere nei registri è l’indirizzo fisico del nostro dispositivo, comunemente chiamato MAC address. Il MAC address è costituito da 6 bytes; i primi tre identificano il produttore dell’hardware ed i secondi tre sono a discrezione del produttore, che li codifica nel modo che più gli aggrada, mantenendo però l’univocità della terzina. Particolarmente importante è il primo byte della prima terzina e in particolare, di questo, il secondo bit meno significativo. Questo bit, infatti, determina se il MAC address è OUI (Organizationally Unique Identifier) oppure se è “locally administered”. In pratica, se il primo byte del MAC è xxxxxx1x, il dispositivo non appartiene ad una delle industrie registrate come produttori, ma è amministrato localmente. L’ultimo bit (il meno significativo) del primo byte determina se la connessione è multicast o unicast. Noi useremo solo unicast e quindi questo bit sarà sempre a zero.

Un trucco per creare un indirizzo fisico OUI, che ho visto usare nei tablets cinesi “very cheap” di prima generazione (nel 2011), è quello di utilizzare come MAC del tablet quello del router a cui ci si collega, modificando l’ultimo byte di +1 o -1. Ingegnoso, ma non si dovrebbe fare ! Se volete sapere qual è il MAC del vostro router e usare lo stesso trucco, potete usare il comando ARP da finestra DOS di Windows.

Questo comando chiede al sistema di restituire il MAC address (attraverso il protocollo ARP) del dispositivo che ha IP 192.168.1.1 (tipicamente il router di casa). Gli altri due dati essenziali da programmare nei registri del W5500 saranno l’IP del Gateway (il nostro modem / router) e la Network Mask. Tutti questi dati risiedono nella memoria flash del micro ATmega88, allocati in modo statico con questa assegnazione:

Come si vede in figura, alla locazione 0x0EC0 troviamo 64 bytes di memoria flash riservati ai dati per la personalizzazione del dispositivo. Si noti che c’è un solo byte definito nel sorgente in ‘C‘ ! Questo serve unicamente a far generare dal compilatore una linea nel file di uscita raslan.hex con il riferimento all’indirizzo 0x0EC0. Poi, sarà un’applicazione su PC ad aggiungere al file .hex i dati personalizzati. Ecco come si presenta la schermata iniziale di tale applicazione:

Nella finestra in alto a destra potremo scrivere, un dato per riga, i valori corretti per personalizzare il nostro dispositivo in funzione della rete a cui dovremo collegarlo. Il programma, quando si clicca il pulsante [ Modify HEX file ], genera un nuovo file chiamato raslan-mf.hex che contiene, nell’area flash dedicata, i parametri personalizzati. A questo punto potremo usare tale file per effettuare la programmazione del microcontrollore.

In questa prima versione di programma, il micro invia su porta seriale (9600, N,8,1) i parametri letti dalla propria memoria flash. Dopo aver trasmesso ogni messaggio,  il micro scrive i medesimi dati nei relativi registri del w5500 e quindi resta in attesa di comandi da seriale o di richieste ICMP Ping.

Come si vede nel listato, la prima operazione che viene effettuata sui registri è la lettura della versione del chip. Il w5500 risponde con il valore 04. Questa lettura è utile anche per verificare che le routines di lettura/scrittura tramite SPI siano efficaci. Di seguito, troviamo la scrittura dei vari parametri di cui abbiamo parlato.

Colleghiamo ora un convertitore USB-Seriale al circuito e lanciamo un programma di terminale seriale. Nel file zip messo a disposizione per il download troverete anche un mio piccolo programma di terminale, che potrete utilizzare per visualizzare l’output del micro e per inviare comandi. In questa primissima release del software, l’unico comando accettato da seriale è il carattere ‘+’ che provoca un reset da watchdog del micro, facendo quindi ripetere la procedura di inizializzazione. Ecco cosa leggiamo sulla finestra del terminale:

A questo punto vedremo il led rosso del circuito mandare un piccolo lampeggio ogni 3 secondi, segno che tutto gira regolarmente. Dall’immagine precedente vediamo che il Device IP è settato a 192.168.0.123 e quindi proviamo a fare un ping da un computer collegato sulla stessa sottorete. Il risultato sarà questo:

BENE ! Il circuito risponde al Ping ! Il primo passo è fatto ! I registri sono stati inizializzati correttamente. Possiamo ora, per prova, lanciare di nuovo il programma w5500prog.exe per modificare i parametri e riprogrammare il micro con un altro Device IP. Quindi, possiamo provare a “pingare” il nuovo IP e vedere se ci risponde (lo farà).

Nota importante: quando si programma la memoria flash del micro, si devono anche settare i “fuses” secondo questa configurazione: Hfuse: 0xCD Lfuse: 0xFC Efuse: 0xF9.

Nel file w5500-v1.zip messo a disposizione per il download troverete questi elementi:
miterm.exe – il terminale seriale
raslan.hex – il file hex di base, senza parametri
raslan-mf.hex – il file hex con i parametri, da usare per programmare il micro
w5500prog.exe – l’applicazione per modificare i parametri

La prova del Socket

Finita questa primissima prova, cominciamo la seconda e ultima parte dell’esperimento: la prova di un “socket” TCP. Per dare un po’ di flessibilità al programma, ho aggiunto una serie di comandi che possono essere inviati da porta seriale. Il primo di questi permette di inserire un IP al quale ci si vuole collegare. Da seriale scriveremo ” i ” e comparirà un ” ? “, quindi scriveremo l’ IP che ci interessa. Dato che ancora non abbiamo programmato un client DNS sul micro, useremo un terminale cmd di Windows e il comando nslookup per ottenere l’ IP del server a cui collegarci. Ecco un esempio:

Con questo nslookup chiediamo al server DNS 8.8.8.8 (quello di Google) l’attuale IP del sito robotop.eu5.org, che è un mio sito di test ospitato su uno spazio web gratuito.

Un altro comando da seriale permette di settare la Porta a cui ci si vuole collegare. Sul terminale seriale scriveremo ” p ” e verrà mostrato il carattere ” ? ” e quindi inseriremo il numero della Porta, in questo caso 80 perché vogliamo collegarci a un server web che ci restituirà una pagina HTML.

Vediamo ora il comando che ci permette di selezionare il percorso della pagina a cui vogliamo accedere, sul sito di cui abbiamo ottenuto l’ IP . Sul terminale seriale scriveremo ” s ” e riceveremo il solito ” ? ” e a questo punto scriveremo il percorso, ad esempio: /php/ipget.php. La lunghezza massima accettata per la stringa, come in tutti gli altri comandi, è di 31 caratteri.

Ora abbiamo il comando per inserire l’URL del sito. Scriveremo da terminale seriale ” u ” e ci verrà mostrato il solito ” ? ” ; a questo punto, inseriremo la stringa, per esempio robotop.eu5.org. Qualcuno si chiederà perché inseriamo l’URL del sito, dato che ne abbiamo già ricavato l’IP con nslookup. La ragione è che lo stesso host contiene molti siti (è un hosting gratuito) e quindi nella richiesta GET HTTP che faremo, dovremo aggiungere il campo “Host: ” che specificherà a quale sito vogliamo accedere, sul server che gira a quell’indirizzo IP.

L’ultimo comando che possiamo dare da seriale è: ” g “. Questo comando avvia una richiesta GET HTTP con i parametri impostati da seriale e quelli programmati nella flash. I dati ricevuti (se la richiesta va a buon fine) sono limitati a 255 bytes. Gli eventuali dati in eccesso vengono troncati.

Vediamo un esempio sul terminale seriale:

Ho utilizzato il comando ctrl-r del terminale seriale per registrare tutta la procedura, a partire dal reset del circuito effettuato inviando il carattere ” + “. Eccolo di seguito:

> Boot
> Chip version: 04
> Device MAC: 02-00-00-00-00-01
> Device IP: 192.168.0.100
> Gateway IP: 192.168.0.1
> Network Mask: 255.255.255.0

> i ? 5.9.82.16 err: editing not allowed !
> i ? 5.9.82.18
> Destination IP: 5.9.82.18
> p ? 80
> Destination PORT: 80
> s ? /php/ipget.php
> Server's path: /php/ipget.php
> u ? robotop.eu5.org
> Server's URL: robotop.eu5.org
> g
# socket open; src port:1326
# socket initialized OK
# connect socket to server...
# [3] status=15
# socket connected
# sending data...
# data received on socket - bytes:00AD
HTTP/1.1 200 OK
Date: Tue, 07 Mar 2017 16:33:20 GMT
Server: Apache
X-Powered-By: PHP/5.4.17
Content-Length: 11
Connection: close
Content-Type: text/html

5.170.76.79
# closing socket...
# closed
>

Ecco cosa abbiamo fatto: ci siamo connessi a http://robotop.eu5.org/php/ipget.php ed abbiamo ricevuto una risposta. La risposta è… il nostro IP pubblico, quello con il quale il nostro router viene visto dalla rete. Il contenuto del file ipget.php è veramente minimale.. eccolo qui: <?php echo $_SERVER[REMOTE_ADDR]; ?> .

L’esperimento è concluso. Nel nuovo file w5500-v2.zip troverete i programmi aggiornati.

Nel prossimo articolo descriverò un’applicazione pratica di quanto sperimentato fin qui. Sarà un relè che potremo accendere / spegnere via Internet, usando come comando remoto un qualsiasi dispositivo mobile provvisto di connessione ad internet (con il browser di serie). Non dovremo abilitare particolari porte sul modem / router e potremo usare anche un router 3G/4G (come quello che sto usando adesso) che non ha un IP pubblico (fa parte di una sottorete del provider). Noi riusciremo ugualmente a comandare il nostro relè (con qualche minuto di latenza), grazie a un paio di scripts PHP che scriveremo su un hosting gratuito qualsiasi, dopo aver fatto la nostra registrazione.

Provare per credere ! Arrivederci…

Clausola di non assunzione di responsabilità:
Il programma o software descritto, liberamente prelevabile dal sito, è da considerarsi una “demo” gratuita e pertanto l’autore Emilio P.G. Ficara non fornirà alcun supporto, né si assumerà alcuna responsabilità per ogni eventuale problema, danno o conseguenza che dovesse presentarsi nel download o nell’esecuzione dell’applicazione.
Cliccando questo link per effettuare il download del file implicitamente dichiarate di aver letto e capito la clausola di non assunzione di responsabilità e di accettarla.

Verificate il checksum MD5 del file w5500-v2.zip scaricato ! Questo deve essere: E71F4C2707932F8A2EBCC8C5815D109B ; se è diverso, il file è corrotto o non è quello originale. In questo caso, non scompattatelo e buttatelo via ! Se invece è tutto ok, potete scompattarlo (è richiesta una password che è: eficara). Potete usare i programmi anche su una chiavetta di memoria USB, in quanto non hanno bisogno di installazione, essendo eseguibili puri.

Multimetro connesso in MQTT

In questo articolo descrivo come il mio multimetro DT-4000ZC pubblica su Internet le misure effettuate, utilizzando un microcontrollore Atmel e un modulo WiFi ESP-01 (basato sul chip ESP8266) ed il protocollo MQTT. Per comprendere meglio le fasi di questo progetto, vi invito a leggere i vari articoli pubblicati precedentemente che sono gli “studi preliminari” per arrivare a questo risultato.

MQTT Client tester per modulo ESP-01
http://ficara.altervista.org/?p=3326
DT-4000ZC logger per Android
http://ficara.altervista.org/?p=3208
Interfacciare il modulo ESP-01 con una porta USB
http://ficara.altervista.org/?p=3041
Single 3.7V Li-ion cell battery back-up for Raspberry Pi
http://ficara.altervista.org/?p=2736

Parte prima: l’alimentatore

Il modulino WiFi ESP-01 funziona a 3.3V, quindi tutto il circuito utilizzerà questa tensione. Ho pensato di usare un alimentatore tipico da carica batterie per telefonini, con uscita a 5V e un regolatore lineare per i 3.3V, ma ho deciso anche di aggiungere una batteria da 3.7V Li-ion di formato AA come backup di alimentazione in caso di mancanza rete. Il circuito è simile a quello già mostrato nell’articolo Single 3.7V Li-ion cell battery back-up for Raspberry Pi, ma in questo caso invece di avere uno step-up in uscita, abbiamo uno step-down (anche se non switching, ma lineare). Di sotto vedete la foto del circuito appena costruito e collaudato.

Alimentatore 3.3V con batteria Li-Ion di backup

Alimentatore 3.3V con batteria Li-Ion di backup

Lo schema è vergognosamente disegnato a mano, perché non credo che metterò “in produzione” questo dispositivo. Eccolo qui (solo la parte di alimentazione) :

lo schema MAD (Manually Aided Design) della sezione di alimentazione

Lo schema MAD (Manually Aided Design) della sezione di alimentazione

Ho utilizzato un modulino carica batterie Li-Ion acquistato su internet (1 Euro, spedizione inclusa…ma come fanno ?) basato sul chip TP4056. Ho modificato la resistenza che stabilisce la corrente di carica, portandola a 5KOhm (due da 10K in parallelo). Nella foto sottostante si vede il punto da modificare.

0501set-resistorLa ragione di questa modifica è che l’alimentatore esterno a 5V deve “reggere” sia la corrente di ricarica della batteria, sia la corrente di funzionamento del resto del circuito. Considerando che tanti alimentatori “very cheap” hanno una corrente di uscita max di 500-750mA, mi è sembrata una scelta razionale. Notate che sullo schema ho aggiunto anche una morsettiera a 2 poli per dare i 5V anche con un alimentatore diverso, senza uscita su connettore Mini-USB. Se alimentate il circuito attraverso questo morsetto, STATE BEN ATTENTI a non superare i 6 Volts ; sul datasheet del TP4056 c’è scritto che la Vin massima è di 8 Volts, ma io sarei prudente, onde evitare “fumate”, scintille e bruciature miste.

Il regolatore low-drop con uscita a 3.3V è di tipo LM3940 ; il link al datasheet è questo: www.ti.com/lit/ds/symlink/lm3940.pdf . Dalle caratteristiche tecniche si vede che con 5V d’ingresso non c’è problema, stabilizza a 3.3V fino ad 1A (a noi serve MOLTO meno). Il problema è quando manca la tensione di rete e invece dei 5V ci si ritrova con i 4.2V che vengono dalla cella Li-Ion a piena carica. Con questa differenza tra Vin e Vout, la stabilizzazione decade un po’, ma per correnti basse (150-200 mA) si dovrebbe restare nel range operativo di tutto il resto del circuito, modulino WiFi e microcontrollore compresi. Eventualmente, per fare le cose a regola d’arte, si può scegliere un altro regolatore che sia very-low-drop e quindi in grado di stabilizzare l’uscita anche con una Vin più bassa oppure, meglio ancora, usare un regolatore step-down switching che prolungherà anche il tempo operativo del circuito quando alimentato a batteria. Se usate un altro tipo di regolatore lineare, fate attenzione al pinout ! Molti regolatori low drop con lo stesso package hanno una disposizione diversa dei pin ! Controllate bene e modificate lo schema di conseguenza. Per quanto riguarda la tensione, teniamo presente che la cella Li-Ion scenderà a 3.7V (la tensione nominale) solo quando la carica residua sarà ormai solo del 10%. Ricaricate la batteria quando si scarica e tenete presente che le celle Li-Ion non devono scendere mai sotto la tensione di 2.75 V circa, pena la perdita della capacità di ricaricarsi (diventano da buttare). Le celle con protezione interna hanno già un circuito che evita questo rischio.

Infine passiamo al mosfet che fa da switch tra l’alimentazione esterna e la cella Li-Ion. Io ho usato un PMV48XP che avevo tra i miei campioni (il datasheet è qui), ma dato che questo ha un package smd SOT-23 (bello piccolo), è un po’ difficile da saldare su una scheda prototipo come quella mostrata in figura. Chi non ha un’esperienza più che buona nella saldatura, farà bene a cercare un altro componente dalle stesse caratteristiche elettriche, ma con un package più “umano”. Comunque, la funzione di questo switch è di mandare al regolatore la 5V presente sul connettore fino a quando c’è. Appena viene a mancare, invece, è la cella Li-Ion a diventare la sorgente di alimentazione. Il mosfet aperto permette al circuito di ricarica di non “vedere” tutto il carico che c’è dietro (regolatore, modulino wifi, microcontrollore) e di eseguire quindi il normale ciclo di carica con le soglie prefissate. Vi invito, per maggiori dettagli a leggere l’articolo Single 3.7V Li-ion cell battery back-up for Raspberry Pi menzionato in precedenza.

Parte seconda: il microcontrollore

Per il micro, ho “riciclato” un vecchio circuito realizzato nel 2011 per collegare degli economici tablet Android “Made in China” ad un bus RS485 per il controllo di unità di potenza in dispositivi biomedicali. A quei tempi i tablet avevano di serie, internamente, la porta seriale TTYS0 con livelli a 3.3V e bastava modificare la Flash di sistema per poterla utilizzare con i propri programmi. Il circuito comprende un micro ATmega48V e un integrato  SP3072E come interfaccia RS485. Il micro dispone di 4KB di Flash, 512Bytes di Ram e 256 Bytes di EEprom. Queste risorse, sebbene limitate, bastano per realizzare il programma.

img_20161119_181150Purtroppo il micro ha solo una UART asincrona, mentre a me ne servono due: la prima per leggere i dati provenienti dal multimetro e la seconda per pilotare il modulino ESP-01 con i comandi AT. La UART “hardware” l’ho usata per il pilotaggio del modulo ESP-01 a 9600 BPS. Per fortuna, il multimetro comunica con un baud rate “basso” (2400 BPS) e così la seconda UART l’ho realizzata in software. Il multimetro non invia i dati “in chiaro”, come caratteri ASCII, ma come una bitmap dei segmenti accesi sul display LCD. Se qualcuno è interessato a come vengono codificati i dati seriali, il protocollo è descritto in un articolo a questo link (paragrafo: Fortune_Semiconductor_FS9721_LP3).

Questo è lo schema della scheda a microcontrollore. L’interfaccia RS485 verrà utilizzata in modo “creativo” per leggere i dati seriali dal multimetro (la resistenza segnata in rosso è stata cambiata proprio per questo scopo). E’ possibile semplificare il circuito ed ottenere lo stesso risultato, ma avendo una scheda già funzionante, ho deciso di usarla senza troppe modifiche.

microcontrollerPer una visione dello schema più nitida e dettagliata, è possibile scaricare il file in formato PDF da questo link: rs485-andro-micro.

Parte terza: mettere tutto insieme

Nello schema seguente (sempre disegnato a mano) potete vedere i vari blocchi (alimentatore, microcontrollore e modulo wifi) interconnessi tra loro.

I tre blocchi del circuito connessi tra loro

I tre blocchi del circuito con le necessarie connessioni

E questa è la realizzazione pratica:

Il circuito completo montato su una scheda per prototipi

Il circuito completo montato su una scheda per prototipi

Per fare un po’ di debug del software, ho aggiunto un altro circuitino che si collega al connettore ICSP (di programmazione) che rimane libero una volta trasferito il firmware nel micro. Il circuito ha due led (uno giallo e uno rosso) e due pulsanti. Uno di questi è per resettare il microcontrollore e l’altro è un generico input per eseguire routines di test. Il circuito è nella figura sottostante:

Il circuitino di debug che si collega al connettore ICSP (schema)

Il circuitino di debug che si collega al connettore ICSP (schema)

Di seguito, come appare il circuito costruito e collegato:

Il circuito costruito e collegato al connettore ICSP

Il circuito costruito e collegato al connettore ICSP

Un altro utilissimo strumento di debug può essere costruito in brevissimo tempo. Si tratta di una “spia” per il traffico dei dati seriali tra il microcontrollore e il modulino WiFi. In generale, si può utilizzare in tutte quelle comunicazioni seriali half-duplex basate su domanda / risposta. Lo schema è il seguente (i diodi devono essere Schottky, low drop)

serialspy-schE questa è la realizzazione pratica :

serialspy-picCon questo piccolo strumento, insieme ad un programma di terminale seriale, si riesce a intercettare tutta la comunicazione tra il micro e l’ESP-01 ed è facile scoprire gli errori. Come programma di terminale seriale, se non lo scrivo personalmente, mi affido all’ottimo RealTerm .

Il software e il firmware

La sezione software è divisa in due parti : una è il firmware per il microcontrollore e l’altra è un’applicazione per PC (Windows) che permette di programmare i numerosi parametri necessari per personalizzare la connessione al broker MQTT e quella al router WiFi. Normalmente, i dati di personalizzazione vengono salvati nella EEprom del micro, ma dopo centinaia di progetti fatti con i micro Atmel ho potuto verificare che c’è una certa “debolezza” di questa zona di memoria e in ambienti elettricamente rumorosi o in presenza di circuiti non realizzati “a regola d’arte” è possibile ritrovarsi con dei dati corrotti in memoria. Normalmente, nei prodotti commerciali che realizzo, utilizzo una doppia copia dei dati in EEprom, ognuna delle quali ha un CRC relativo ai dati memorizzati. Ad ogni reset del micro e anche in base ad un timer di verifica integrità, il firmware si occupa di verificare entrambe le copie dei dati in EEprom e se ne trova una corrotta, usa l’altra per ripristinare i dati. Se entrambe le copie hanno un CRC errato, allora il firmware segnala un errore su una delle periferiche disponibili (led, display, cicalino, uscita seriale, eccetera). Questa procedura, ovviamente, richiede una certa quantità di codice e allora, in questo particolare caso in cui ho a disposizione solo 4K di Flash per l’intero firmware, ho deciso di usare un approccio differente : i parametri vengono salvati nella memoria programma (Flash), ma NON sono contenuti nel file sorgente in C, bensì vengono “aggiunti” al file di uscita .hex grazie all’applicazione su PC. Questo permette ad un utente di crearsi un proprio file .hex personalizzato ed utilizzarlo per programmare il microcontrollore. La memoria Flash nei microcontrollori Atmel, per la mia esperienza personale, è “sicura”, cioè non mi è mai capitato, in tanti dispositivi costruiti e attualmente presenti sul mercato, di riscontrare una corruzione dei dati programmati.

Nel sorgente in C, l’area di flash destinata ai parametri programmabili è definita semplicemente così :

mqtt-fw1In pratica, viene creata una costante flashdata che nel sorgente è di soli 2 bytes, ma che servirà solo a creare un riferimento per l’applicativo su PC per aggiungere tutti i dati necessari. L’area è allocata all’indirizzo 0x0F00, quindi all’inizio dell’ultimo blocco da 256 bytes della memoria flash. I dati vengono salvati con uno “header” che contiene l’indirizzo (relativo) di partenza di un messaggio e la sua lunghezza. In pratica, uno header di 2 bytes per ognuno dei messaggi (parametri) disponibili. Ecco un esempio di accesso ai dati:

mqtt-fw2Il sorgente in C così compilato, non contiene quindi alcun parametro / messaggio. Infatti, se andiamo a vedere il file .hex risultante dalla compilazione, troveremo questa situazione:

mqtt-fw3Per chi non conosce lo standard dei file intel-hex, il record alla linea 130 indica esattamente all’indirizzo di Flash 0x0F00 i due bytes {0xFF, 0xFF} definiti come ‘flashdata’ nel sorgente in C e sarà proprio questa “chiave” ad essere utilizzata dall’applicativo su PC per inserire tutti i parametri programmati dall’utente. In sostanza, la riga 130 sarà eliminata e al suo posto saranno inserite 16 righe (nel caso di 256 bytes) con i dati “veri”. Naturalmente, il numero di riga 130 è relativo ad una versione iniziale del firmware. Nella versione definitiva troverete gli stessi dati, ma su un numero di riga successivo. Un esempio (incompleto) della sostituzione operata dal programma MQTTprog.exe su PC è visualizzato nell’immagine sottostante:

mqtt-fw4In pratica, quando programmeremo il microcontrollore attraverso l’apposito connettore, useremo come file di origine questo .hex modificato e poi il firmware andrà a “pescare” i vari messaggi (da 0 a 7) usando questo “indirizzamento indiretto”.

Ed ecco la prima versione del software per PC e del firmware per il microcontrollore. Si noti che quest’ultimo non fa uso di “librerie” per il protocollo MQTT ed è realizzato in linguaggio C a partire dallo studio delle specifiche del  protocollo stesso. Nella cartella zippata si trovano: l’eseguibile per Windows MQTTprog.exe, il file intel-hex mqttclient.hex e un file di testo con la lista dei possibili errori e delle abbreviazioni usate per il multimetro, nominato docs.txt. Il file zip si chiama multimqtt-v5.zip e può essere scompattato usando  la password: eficara. L’occupazione di memoria flash per questa versione è la seguente: programma=0x0000..0x0BE3 ; parametri=0x0F00..0x0FFF.

Per verificare l’integrità del file zippato, controllate che Il codice MD5 del file sia: 0AECDF122EB1B5A1700F9FADE625B438. Se lo MD5 è diverso da quello indicato, non scompattate il file perché non è quello originale oppure è corrotto o scaricato parzialmente.

Clausola di non assunzione di responsabilità:
Il programma o software descritto, liberamente prelevabile dal sito, è da considerarsi una “demo” gratuita e pertanto l’autore Emilio P.G. Ficara non fornirà alcun supporto, né si assumerà alcuna responsabilità per ogni eventuale problema, danno o conseguenza che dovesse presentarsi nel download o nell’esecuzione dell’applicazione.
Cliccando questo link per effettuare il download del file multimqtt-v5.zip implicitamente dichiaro di aver letto e capito la clausola di non assunzione di responsabilità e di accettarla.

La prima operazione da fare per creare un file .hex personalizzato per le nostre esigenze è di avviare il programma MQTTprog.exe. Ci troveremo davanti una schermata fatta così:

mqttprog-ssIl riquadro in alto a sinistra contiene una descrizione del significato di ogni parametro; nel riquadro a destra (editabile) inseriremo i nostri parametri personalizzati, uno per riga.

Io non ho il “telefono fisso” e quindi non ho l’ADSL, ma uso il mio cellulare per fare da hot-spot e per collegarmi ad Internet. Come potete vedere dalla prima riga dei parametri, lo SSID del mio hot-spot è  warmyGun e la password è m2mqtt55. Ovviamente, voi potrete modificare questi dati per accedere al vostro hot-spot personale. I pulsanti Read Param file e Write Param file servono, rispettivamente, a leggere da disco una configurazione pre-salvata e a scrivere su disco la configurazione correntemente mostrata sullo schermo. Il pulsante Modify HEX file serve invece per produrre un nuovo file hex personalizzato partendo dalla base di quello “standard” mqttclient.hex. Il file di uscita prodotto si chiama sempre mqttclient-mf.hex ed è questo che dovrà essere utilizzato per programmare il microcontrollore. Potete copiare la cartella scompattata anche su una chiavetta di memoria usb, perché l’eseguibile non richiede installazione. In ogni caso, copiate la cartella su una directory o un disco con i permessi di scrittura.

Per la programmazione dei microcontrollori Atmel, in generale, io uso il noto programma Avrdude, scaricabile presso il sito: www.nongnu.org/avrdude. La configurazione per i “fuses” del microcontrollore ATmega48V in questo caso è: Hfuse=0xCD Lfuse=0xFC. C’è da tenere presente che alcuni registri interni del micro ATmega48 (o ATmega48V) non sono esattamente identici a quelli dell’ ATmega48P o ATmega48AP. E’ quindi possibile che un circuito che utilizzi uno di questi micro possa presentare qualche problema. Appena avrò il tempo di realizzare un circuito “commerciale”, userò un micro di ultima generazione e compilerò il sorgente in C per una completa compatibilità.

Flusso di programma

Al reset, il led giallo lampeggia 3 volte e poi rimane spento per un paio di secondi, quindi ricomincia a lampeggiare velocemente mentre i vari comandi AT vengono inviati dal micro al modulo WiFi ESP-01 (v0.9.5.2 AT Firmware.bin – 9600 BPS). Le varie fasi successive del programma sono:

1) connessione al router (hot-spot) WiFi
2) attraverso la connessione wifi stabilita, apertura socket TCP su IP:Port del broker
3) invio al broker del comando mqtt CONNECT ; al parametro programmabile ClientId viene aggiunto automaticamente un numero random da 10 a 73, in modo da mantenere una parte fissa e una variabile ad ogni nuova accensione / reset del circuito.
4) attesa dal broker per la risposta CONNACK ; il led rosso si accende in modo fisso.

5) attesa 40 secondi con il led giallo che lampeggia lentamente
6) si spegne il led rosso e viene inviato un comando mqtt PINGREQ
7) attesa dal broker per la risposta PINGRESP ; si riaccende il led rosso fisso

Le fasi da 5 a 7 si ripetono per 2 volte e poi :

8) attesa 40 secondi con il led giallo che lampeggia lentamente
9) si spegne il led rosso e viene inviato un comando mqtt PUBLISH con flag di retain = 1 e QoS = 1. Nel campo Topic verrà inviato il corrispondente paramentro programmato, il Packet Identifier partirà dal valore 0x0101 (incrementato dopo la risposta) e infine nel Payload verrà inviata l’ultima lettura del multimetro, in ASCII, con un limite di 28 caratteri.
10) attesa dal broker per la risposta mqtt PUBACK ; se il Packet Identifier corrisponde a quello inviato, ne viene modificato il valore per la prossima trasmissione.

A questo punto la procedura riprende dalla fase 5. Teoricamente, potremmo spegnere il nostro dispositivo in qualsiasi momento, lasciando che il broker chiuda la connessione per esaurimento del tempo di Keep-Alive (60 secondi, in questa versione), ma per fare le cose in modo “educato”, ho aggiunto anche il comando mqtt DISCONNECT che chiude la connessione in modo canonico. Questo comando può essere attivato premendo il pulsantino TST (TeST, vedi schema) durante le fasi 5 o 8 (attesa 40 secondi). Se il comando viene accettato dal broker, si avrà una immediata disconnessione del socket TCP e i due led rosso e giallo cominceranno a lampeggiare velocemente, alternativamente. Il micro resterà in questa fase finché non toglieremo l’alimentazione o premeremo il pulsantino RST (ReSeT, vedi schema).

Se una delle fasi termina con un errore,  il led rosso farà da “monitor”, indicandoci il numero dell’errore. I vari codici di errore sono contenuti nel file docs.txt ; un lampeggio lungo indica 5 e un lampeggio corto 1. Per esempio, se il codice d’errore fosse 7, avremmo un lampeggio lungo e due brevi. Dopo la visualizzazione dell’errore il micro eseguirà un reset da watchdog e tutto ricomincerà dall’inizio, con i tre lampeggi del led giallo e così via.

Bene, il programma è completo ! Si tratta di una prima versione e forse farò aggiunte o correzioni ; nel caso, pubblicherò le variazioni in un nuovo articolo. That’s all, folks !

MQTT Client tester per modulo ESP-01

L'icona del programma e l'interfaccia USB di prova

L’icona del programma e l’interfaccia USB di prova

Sto per realizzare un nuovo progetto per trasmettere i dati di un multimetro via Internet. Inizialmente avevo pensato di creare un mio piccolo server e qualche script in PHP per gestire i dati in arrivo e smistarli verso gli utenti interessati alla lettura dei dati da remoto. Poi, invece, ho dato un’occhiata al protocollo MQTT ed ho visto che è molto semplice da implementare, almeno per quanto riguarda la parte Client. Ho per prima cosa visitato il “sito ufficiale” a questo link: http://mqtt.org/documentation e da lì ho scaricato il PDF con tutte le specifiche del protocollo: http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.pdf . Ho studiato tanti protocolli e letto tante specifiche e devo dire che sono stato piacevolmente impressionato dalla chiarezza e dalla sinteticità di questo documento.

Mi sono messo quindi al lavoro per sviluppare la mia versione di Client senza usare alcuna “libreria” già pronta. Il perché di questo approccio risiede nel fatto che dovrò “far entrare” tutto il software su di un piccolo microcontrollore e perciò voglio essere in grado di implementare nel firmware solo le cose strettamente necessarie. In secondo luogo, scrivere da zero un protocollo significa capirlo profondamente e questo è sempre un bel vantaggio, in prospettiva !

La fase preparatoria ha incluso la messa in opera di un “broker” MQTT (in pratica, il Server). Ho utilizzato un programma open-source ben collaudato che si chiama “mosquitto”. Ho trovato il sito ufficiale “An Open Source MQTT v3.1 Broker” a questo link: https://mosquitto.org/ . Per l’installazione ho usato un computer con Debian 7 e tramite il caricatore di pacchetti “apt-get install” ho caricato tutto il necessario. La personalizzazione è piuttosto semplice e richiede solo una lettura accurata delle istruzioni fornite e reperibili in rete.

Per chi volesse fare delle prove senza installare il broker, c’è la possibilità di collegarsi ad alcuni brokers “free”. Ce ne sono parecchi in rete. Ne cito uno: Host: broker.hivemq.com Port: 1883 , ma cercando su Internet se ne trovano anche altri. Non so quale consigliare, perché personalmente ho scelto di usare il mio.

Infine, mi sono messo a scrivere il software del Client. Come al solito, prima di preparare il firmware in C per il microcontrollore, ho fatto un “tester” sul computer usando il caro, potente e gratuito Freebasic, con il supporto del FireFly per la gestione grafica su Windows. Come hardware ho usato la mia interfaccia USB per il modulino WiFi ESP-01, che ho descritto in un mio precedente articolo “Interfacciare il modulo ESP-01 con una porta USB” a questo link: http://ficara.altervista.org/?p=3041 .

Questa è l’immagine del programma in funzione:

Il programma in funzione, collegato al broker.

Il programma in funzione, collegato al broker.

All’avvio, il programma apre un selettore di files per poter scegliere un file di parametri. In tale file sono contenuti tutti i dati necessari per effettuare il collegamento. Il file di default: MQTT-defaults.txt ha inizialmente questo contenuto:

il file di parametri all'origine; dovrà essere personalizzato dall'utente

il file di parametri all’origine; dovrà essere personalizzato dall’utente

Analizziamo i vari parametri e personalizziamo il file per le nostre esigenze.
Ogni linea contiene un dato ed è composta da due campi; il primo che termina con il carattere ‘:‘ è il nome del parametro e non deve essere modificato; il secondo è il valore che vogliamo attribuire a quel parametro. Vediamoli uno alla volta:

wifi-ssid: qui dobbiamo inserire lo SSID del modem / router WiFi al quale ci vogliamo collegare con il modulo ESP-01 per accedere a Internet, tipicamente qualcosa come “Alice-12345678”.

wifi-pasw: qui dobbiamo mettere la password che usiamo per rendere sicura la nostra connessione WiFi, ad esempio: “123LaMiaPasswordDIFFICILE”

E con questo abbiamo fornito al programma i dati necessari per eseguire l’accesso a Internet. Il mio modulo ESP-01 è un po’ vecchio ed ha la memoria flash da 512KB ; ho caricato al suo interno la versione di firmware per comandi AT di nome: v0.9.5.2 AT Firmware.bin (508 KB), nella versione con baud rate “nativo” di 9600 BPS. Per come è scritta l’applicazione di test, non ci dovrebbero essere problemi anche con altre versioni di firmware AT, modificando opportunamente la velocità della porta seriale. Consiglio, in ogni caso, di forzare il baud rate a 9600 sul modulo e lasciarlo così, perché è più che sufficiente per lo scopo.

Veniamo ora agli altri dati da fornire, quelli relativi al protocollo MQTT.

mqtt-broker: qui inseriamo il nome o l’IP del broker a cui vogliamo collegarci. Se usiamo un nostro broker installato su un PC della rete locale, scriveremo l’IP di quel particolare PC, per esempio: 192.168.1.200 ; se invece vogliamo usare un broker esterno, scriveremo il suo IP (se lo conosciamo) o il nome, ad esempio: broker.hivemq.com

mqtt-port: qui inseriremo la porta di comunicazione usata dal broker. L’impostazione standard per la porta TCP è la 1883 per la connessione normale o la 8883 per connessione SSL. In questo tester non viene usata la connessione SSL perché il dispositivo a microcontrollore che seguirà, non prevede questo grado di sicurezza.

mqtt-user: qui inseriremo il nostro username che verrà inviato al broker nel momento in cui effettueremo una operazione di CONNECT. Se usiamo un nostro broker e abbiamo inserito un elenco di nomi abilitati, la connessione sarà possibile solo se lo username (con la relativa password) verrà riconosciuto. Usando il broker “free” citato precedentemente, potremo usare un nome qualsiasi. Attenzione ai caratteri ! In questa mia versione di prova, è previsto che i caratteri siano solo maiuscole, minuscole e numeri. Inserendo strani simboli, si riceverà un errore o non si riuscirà ad effettuare il CONNECT.

mqtt-pasw: qui inseriremo la nostra password, che sarà inviata insieme allo username. Anche per questo testo, vale la limitazione dei caratteri descritta per lo username. Trattandosi di una connessione non SSL, qualcuno potrebbe “sniffare” i vostri dati usando un analizzatore di protocollo (es: wireshark) con la propria scheda di rete WiFi settata in modo “promiscuo”; ma ricordiamoci che stiamo solo facendo esperimenti ! Non siamo nei servizi segreti…

mqtt-clid: qui inseriremo il “Client Identifier” che è un nome che serve al broker per tenere traccia della nostra connessione. Il nome che inseriremo (sempre con le solite limitazioni) verrà elongato dal programma con 4 caratteri aggiuntivi, che saranno la rappresentazione esadecimale di un numero random da 0 a 0x7FFF. Quindi, se usiamo per esempio: MioTester, al momento di un comando CONNECT verrà inviato un Client Identifier tipo: MioTester6F3C. Questo permette di avere un nome con una parte fissa e un suffisso variabile per le nostre connessioni.

mqtt-keep: qui inseriremo il numero di secondi per i quali il broker deve tenere attiva la connessione anche se il Client non invia nulla. Un valore tipico potrebbe essere 60. Se entro i sessanta secondi il broker non riceverà un comando dal client, chiuderà la connessione. In tal caso, dovremo dare di nuovo il comando di CONNECT per poter effettuare qualsiasi altra operazione.

Ecco come potrebbe risultare il file modificato con i valori indicati:

Un esempio di configurazione.

Un esempio di configurazione.

Iniziamo il nostro esperimento !

Per prima cosa, naturalmente, colleghiamo l’interfaccia USB:ESP-01 ad una porta USB del nostro computer. Prendiamo nota del numero di COM PORT che viene assegnato. Io, di solito vado nelle impostazioni delle periferiche, seleziono la porta COM assegnata e la “forzo” (con le impostazioni avanzate) a diventare la COM3. Ho questa abitudine fin dai tempi in cui nei notebook “di pregio” esistevano due porte COM standard, la COM1 e la COM2. Ora, se abbiamo il firmware del modulo ESP-01 con il baud rate fissato a 9600 BPS, possiamo eseguire la prima operazione, che consiste appunto nell’aprire la porta COM mediante il pulsante OPEN. Se tutto è andato bene, sulla finestra dei messaggi apparirà la scritta: #: Open ; se invece c’è qualche errore, vedremo la scritta: #: Error opening COMx. In questo caso, è possibile che ci sia qualche errore nelle impostazioni delle porta. Quindi, ricontrollare tutto e riprovare…

Se volete modificare il baud rate del modulino WiFi, vi consiglio di usare un mio programmino che trovate su questo sito, col nome: AT-commands tool al seguente link: http://ficara.altervista.org/?p=3158. La lista dei comandi AT per l’ESP8266 si trova con una facile ricerca su Internet, in formato PDF. Sulla mia versione del modulino ESP-01, il comando per modificare il baud rate (stabilmente) è: AT+CIOBAUD=9600^M^J ; naturalmente, questo comando deve essere inviato al modulino con il baud rate che è attualmente in uso. Quindi: se il modulino è fissato a 115200 BPS noi ci connettiamo a quella velocità, diamo il comando e poi chiudiamo la porta seriale, resettiamo il modulo e riapriamo la seriale, stavolta settata a 9600 BPS.

Ora, se la porta COM è aperta, eseguiamo il primo passo, che è quello di connettersi alla rete WiFi. Lo facciamo cliccando il pulsante  WiFi Connect. Se i dati che abbiamo inserito nel file di parametri sono tutti giusti, vedremo sulla finestra una serie di messaggi e dopo una decina di secondi apparirà in fondo allo schermo la scritta: #: Ok, WiFi connected! Bene, la nostra connessione a Internet è stabilita.

wificonn-partIniziamo ora ad usare i comandi MQTT.

Faccio innanzitutto una premessa: in questa versione di prova non vengono gestiti alcuni comandi ed altri sono utilizzati con delle limitazioni. Questo programma, infatti, è nato per fare delle prove in vista della realizzazione di un firmware per un piccolo microcontrollore, con risorse hardware molto limitate.

Consiglio caldamente la lettura della documentazione del protocollo MQTT, che è disponibile sul sito principale http://mqtt.org e su tanti altri siti (anche in italiano) che danno spiegazioni in linea generale o anche approfondita, di come funziona il sistema. Data la gran quantità di pubblicazioni sull’argomento, mi è sembrato inutile ripetere le stesse cose anche in questo mio articolo. Mi limiterò, quindi, ai soli casi in cui ho imposto delle limitazioni alle possibilità offerte dal protocollo, con l’obiettivo di mantenere “minimalista” la struttura del software.

La prima e più importante limitazione è che la lunghezza massima dei comandi è di 127 bytes, più 2 bytes di Fixed Header. Questa vale per ognuno dei comandi implementati nel software di test.

Il primo comando da dare è il CONNECT, quindi clicchiamo il pulsante MQTT Connect. Con questo comando instauriamo un collegamento con il broker. Vengono inviati il Client Identifier, lo username e la password (quelli inseriti nel file dei parametri) e il flag di Clean Session attivo. Se il comando viene ricevuto correttamente dal broker, questo ci spedirà una risposta di CONNACK, che indica che siamo connessi e che è stata creata una nuova sessione per noi. Vedremo la risposta apparire nella finestra dei messaggi. Se la risposta non c’è, verifichiamo che non ci siano errori nei dati impostati sul file dei parametri (indirizzo del broker, porta di comunicazione) ed eventualmente, ripetiamo tutte le procedure dopo aver corretto gli errori.

connack-partCome si vede dai pulsanti presenti sulla finestra del programma, mancano alcuni comandi che invece fanno parte del protocollo. I controlli “mancanti” sono: PUBREC, PUBREL e PUBCOMP, perché sono legati alla assured delivery (consegna assicurata) disponibile tra le possibilità del QoS (Quality of Service).

Nel protocollo MQTT il QoS ha tre possibili opzioni:
0 – at most once (al massimo una volta) che significa che qualche messaggio può essere perso ed è adatto per applicazioni tipo quella di un sensore che manda continuamente il proprio stato e quindi anche se un pacchetto “si perde” non è un dramma.
1 – at least once (almeno una volta) che significa che il messaggio arriva sicuramente almeno una volta, ma che è possibile che ne arrivino anche dei duplicati.
2 – exactly once (esattamente una volta) che significa che il messaggio arriverà sicuramente solo una volta, senza duplicati.

Nel mio programma, sul comando PUBLISH, attivato dal pulsante MQTT Publish, uso l’opzione 1 – at least once. Quando si riceve un messaggio PUBLISH dal broker (sempre con QoS = 1), bisogna “rispondere” con un PUBACK, cliccando il pulsante MQTT Puback, altrimenti il broker continuerà a tentare di inviarci lo stesso messaggio, attivando il flag DUP che sta appunto a indicare che si tratta di un messaggio ripetuto.

Proviamo, una volta ricevuta la conferma di connessione dal broker con il messaggio di CONNACK, ad inviare un comando di PINGREQ. Clicchiamo quindi il pulsante MQTT Ping e vedremo comparire sulla finestra dei messaggi prima l’invio del comando e poi la risposta del broker: PINGRESP, che ci conferma che il comando è stato accettato. Il ping può essere convenientemente utilizzato per mantenere attiva la comunicazione anche quando non si inviano altri comandi. Per esempio, se inviamo i dati di un multimetro che sta misurando la tensione di una batteria, useremo un PUBLISH quando c’è una variazione importante della misura da comunicare ai vari subscribers, ma per tenere attiva la comunicazione manderemo dei PINGREQ a intervalli di durata inferiore a quella che abbiamo definito nel parametro mqtt-keep:.

pingresp-partOra proviamo il comando DISCONNECT, cliccando il pulsante MQTT Disconnect. Sulla finestra dei messaggi vedremo l’invio del comando, ma non ci sarà alcuna risposta da parte del broker. Vedremo, invece, un messaggio dal modulo ESP-01 che ci conferma che il socket #0, che avevamo aperto al CONNECT, è stato chiuso. Ciò ci conferma che il broker ha terminato la sessione chiudendo la connessione TCP.

disconnect-partNotiamo, tra i vari pulsanti, un TCP Close, che normalmente non dovrebbe essere usato. La sua funzione è quella di chiudere il socket #0 nel caso si verificasse un blocco di qualsiasi genere nella comunicazione TCP. E’ stato utile nella fase di messa a punto del protocollo (sperimentando, si fanno errori !) e allora ho deciso di lasciarlo, anche se probabilmente non servirà. E’ da notare che interrompendo con questo pulsante una connessione in atto, sul broker la “stranezza” verrà riportata sul log come errore. Se avete installato il vostro broker mosquitto, potete andare a vedere il file di log e lì troverete la segnalazione di un Client (il vostro) che ha chiuso inaspettatamente la connessione.

Adesso passiamo al comando SUBSCRIBE, attivato dal pulsante MQTT Subscribe. Come possiamo vedere nell’immagine sottostante, i dati coinvolti in questa operazione sono il Topic filter e il Packet Identifier. Da notare, nel Topic Filter, il carattere ‘#‘ che viene definito wildcard e che in pratica si comporta come il .* quando chiediamo l’elenco dei files in una directory. Facciamo un esempio pratico: se ho due dispositivi che pubblicano (PUBLISH) dei dati, uno con il Topic multimeter/home e l’altro con multimeter/roulotte , facendo una sottoscrizione (SUBSCRIBE) con il Topic filter multimeter/# dirò al broker di inviarmi tutti gli eventi che arrivano sia dal dispositivo che pubblica su multimeter/home, sia da quello che lo fa su multimeter/roulotte.
Il broker, una volta ricevuta la nostra richiesta, ci risponde con un messaggio di SUBACK, per confermare di aver ricevuto ed accettato il comando. Vedremo questa risposta sulla solita finestra dei messaggi.

un esempio di SUBSCRIBE

un esempio di SUBSCRIBE

La finestra dei messaggi dopo aver inviato il comando SUBSCRIBE

La finestra dei messaggi dopo aver inviato il comando SUBSCRIBE

L’operazione opposta a quella appena vista è quella di UNSUBSCRIBE. Con questo comando, attivato dal pulsante MQTT Unsubscribe, si chiede al broker di cancellare la nostra sottoscrizione a uno o più “publisher”. Nonostante il comando permetta di inviare anche più Topic Filters successivi, in questa versione ne viene inviato sempre e soltanto uno. E’ da ricordare che il campo non può essere vuoto, perché questo verrebbe considerato come violazione del protocollo. I campi coinvolti nell’invio del comando sono quelli indicati nella figura sottostante. Il broker risponderà con un messaggio UNSUBACK per avvisarci di aver recepito il comando e smetterà di mandarci messaggi del publisher che abbiamo cancellato. Nell’immagine sottostante vediamo un esempio in cui chiediamo di non essere più iscritti ai messaggi pubblicati da multimeter/home. Alcuni messaggi che erano già in coda, verranno comunque trasmessi, ma dopo non ne riceveremo più. La risposta UNSUBACK apparirà, come di consueto, nella finestra dei messaggi.

Un esempio di UNSUBSCRIBE

Un esempio di UNSUBSCRIBE

La finestra dei messaggi dopo l'invio del comando UNSUBSCRIBE

La finestra dei messaggi dopo l’invio del comando UNSUBSCRIBE

Per concludere, diamo un comando di PUBLISH, tramite il pulsante MQTT Publish. Dando questo comando, trasmettiamo un messaggio al broker e questo si preoccuperà di reinviarlo a tutti i subcribers che sono iscritti al Topic in questione. Nel comando di PUBLISH non è possibile usare caratteri wildcard. Quando il comando è inviato con QoS = 1 (Il nostro caso), è obbligatorio inviare anche il Packet Identifier, che invece non è necessario in caso di QoS = 0. Una volta ricevuto il messaggio, il broker ci risponderà con un PUBACK per confermare di averlo ricevuto. Se in precedenza avevamo dato un comando di SUBSCRIBE per lo stesso Topic, dopo qualche istante riceveremo dal broker lo stesso dato che abbiamo inviato, in quanto facciamo parte di coloro i quali sono destinatari di questi eventi di publish. E’ da notare che il messaggio di PUBLISH inviato dal broker contiene uno specifico Packet Identifier. Durante la ricezione, questo dato viene mostrato nella finestra dei messaggi e inoltre viene copiato nel TextBox riservato a questo scopo, in modo che quando cliccheremo il pulsante MQTT Puback, il nostro PUBACK avrà lo stesso Packet Identifier del messaggio ricevuto e quindi il broker smetterà di reinviarcelo. Nella figura sottostante potete vedere i campi utilizzati nell’invio del messaggio.

Un esempio di PUBLISH

Un esempio di PUBLISH

La finestra dei messaggi dopo aver inviato il comando PUBLISH

La finestra dei messaggi dopo aver inviato il comando PUBLISH

Se avevamo fatto un SUBSCRIBE a multimeter/# o a multimeter/home, riceveremo anche noi il messaggio appena pubblicato, come si legge nelle ultime righe della finestra dei messaggi. A questo punto daremo il comando di PUBACK tramite il pulsante MQTT Puback e vedremo questo risultato:

Dopo aver ricevuto un PUBLISH dal beroker, inviamo un PUBACK per conferma (se IoS è diverso da zero)

Dopo aver ricevuto un PUBLISH dal broker, invieremo un PUBACK per conferma (se Q0S = 1)

Questo è tutto. Spero che il programma e l’articolo possano essere di aiuto a chi volesse cimentarsi nella sperimentazione di questo protocollo.
Buon lavoro !

Clausola di non assunzione di responsabilità:

Il programma o software descritto, liberamente prelevabile dal sito, è da considerarsi una “demo” gratuita e pertanto l’autore Emilio P.G. Ficara non fornirà alcun supporto, né si assumerà alcuna responsabilità per ogni eventuale problema, danno o conseguenza che dovesse presentarsi nel download o nell’esecuzione dell’applicazione.

Cliccando questo link per effettuare il download del file MQTT8266_161111.zip implicitamente dichiaro di aver letto e capito la clausola di non assunzione di responsabilità e di accettarla.

Verificate il checksum MD5 del file MQTT8266_161111.zip scaricato ! Questo deve essere: 6451A7F02C4821C0A14D774D8DE9B623 ; se è diverso, il file è corrotto o non è quello originale. In questo caso, non scompattatelo e buttatelo via !

Se invece è tutto ok, potete scompattarlo (è richiesta una password che è: eficara) e troverete l’eseguibile e il file dei parametri da personalizzare. Potete usare il programma anche su una chiavetta di memoria USB, in quanto non ha bisogno di installazione, essendo un eseguibile puro.

Ultima modifica 2016,Nov,11 : lasciando vuoti i parametri mqtt-user: e / o mqtt-pasw: nel file delle impostazioni, l’operazione di CONNECT avverrà in modo anonimo (Connection Flags = 0x02), quindi nel pacchetto inviato al broker non compariranno i campi username e password. Ovviamente, il broker deve concedere questo tipo di accesso, altrimenti si riceverà un errore o comunque non sarà possibile effettuare alcuna operazione.

RAS-WiFi e MasterICS

Nel “lontano” 2013 sviluppai, insieme agli amici della Cem Srl, un dispositivo in grado di collegare delle centrali di allarme di modello Advisor Master © e Advisor Advanced © (UTC Fire & Security) ad Internet, mediante un circuito supplementare collegato al normale “bus” delle periferiche di questi dispositivi. Tutto funzionò bene e la prima installazione presso un cliente fu eseguita nell’Agosto 2014. Il dispositivo è in attesa di brevetto come estensione d’utilizzo delle summenzionate centrali.

La versione iniziale del progetto si basava su un circuito di interfaccia con il “bus” della centrale più un’altra scheda “Linux embedded”. I primi esperimenti furono condotti su una scheda Alix, basata su un processore X86, ma successivamente utilizzai una Raspberry PI, con architettura ARM, per ragioni esclusivamente legate al costo. Oggi ci sono delle alternative molto, molto interessanti. Così, ho riscritto l’intero progetto ed ho realizzato questa nuova scheda:

La single-board che permette di gestire la centrale con uno smartphone via internet

La single-board che permette di gestire la centrale con uno smartphone via internet

E’ una piccola meraviglia. Pochi centimetri quadrati ed ho potuto eliminare completamente la scheda “Linux Embedded” e concentrare sul microcontrollore Atmel tutto il lavoro di “bridging” necessario per il controllo remoto. Per la connessione a Internet ho utilizzato un modulo WiFi molto popolare e con un costo contenuto. Uno dei vantaggi di questa nuova versione, oltre a quello economico, è che per rendere operativo l’impianto non si deve più passare attraverso un server dedicato. Basta fare un abbonamento (anche gratuito, ma è meglio a pagamento) presso uno dei servizi tipo DynDns o simili, che rendono “statico” l’IP della vostra connessione ad Internet.

Ovviamente, anche l’applicazione per lo smartphone è cambiata. La precedente Master2Net rimane su Google Play per gli utenti del sistema “maggiore”, ma la nuova App MasterICS è pronta ed è già disponibile per gli utenti su un link privato della Cem Srl. A breve (dopo una serie consistente di collaudi) l’App sarà pubblicata anche su Google Play, disponibile per download gratuito.

La schermata principale dell’App è identica a quella del modello maggiore, come si vede dalla figura sottostante;

L'App per Android. Lo stato mostrato è quello in attesa di connessione.

L’App per Android. Lo stato mostrato è quello in attesa di connessione.

La variazione principale è nell’impostazione dei parametri di connessione. Nella versione precedente, si dovevano inserire i dati relativi al server del produttore (Cem Srl), mentre ora si deve inserire il nome fornito dal servizio DynDns (o simili), la porta di connessione e l’ID della scheda, che viene fornito al momento dell’acquisto. Ecco un esempio:

A sinistra, la lista degli indirizzi web, a destra quella delle schede con la porta di utilizzo e l'ID scheda

A sinistra, la lista degli indirizzi web, a destra quella delle schede con la porta di utilizzo e l’ID scheda

La scheda è in produzione pilota. Per ulteriori informazioni, rivolgersi alla Cem Srl.

DT-4000ZC logger per Android

Aggiornato: 10 Lug 2016
Ho realizzato, qualche tempo fa, un programma in ambiente Windows per collegare al PC un multimetro digitale di tipo DT-4000ZC. Questo multimetro (economico) ha una uscita seriale, ma non invia -come si potrebbe pensare- una serie di caratteri alfanumerici che contengono le informazioni sulla misura in atto, bensì una specie di “bitmap” di tutti i segmenti del display. Quindi, il programma deve “ricostruire” il dato misurato partendo da questi elementi.

Ulteriori spiegazioni si possono trovare nei miei precedenti articoli a questi links:
http://ficara.altervista.org/?p=1581
http://ficara.altervista.org/?p=1602
Il secondo link è stato citato anche dal sito Hack-a-Day:
http://hackaday.com/2013/08/26/logging-two-multimeters-at-nearly-the-same-time/

Ora mi trovo a dover effettuare una registrazione dell’andamento della tensione su una linea di un impianto di allarme e non voglio lasciare il mio notebook utilizzato come logger nel sito dove si trova l’allarme. Ho pensato quindi di riscrivere l’applicazione per Android e farla girare su un vecchio (economicissimo) tablet Android “Made in China” che possiedo.

L’applicazione è estremamente semplice :

La scermata principale

La schermata principale

Abbiamo un riquadro dove compare il contenuto del display LCD e due pulsanti che provocano l’avvio e l’arresto della registrazione. I dati vengono trasmessi dal multimetro secondo un proprio timing, di circa 2 invii al secondo. Se la registrazione è attiva (se il “led” rosso è acceso) ogni dato arrivato viene salvato in un file di log, altrimenti viene solo mostrato sul display. (9 Lug 2016) Ho aggiunto un box per impostare il numero di letture da ignorare, per ridurre le dimensioni del file di log in caso di misure che variano con molta lentezza nel tempo. Facciamo un esempio : quando si avvia la registrazione (log) vengono salvate 3 letture e quindi il programma controlla se l’utente ha settato un numero di campioni da saltare. Diciamo di aver deciso di saltare 27 letture ; il programma NON salverà su disco le successive 27 letture. Finite le letture da saltare, lo strumento registrerà di nuovo tre campioni e quindi il processo ricomincerà. Dato che ci sono approssimativamente 2 letture al secondo, scegliendo un numero di letture da saltare pari a 117, avremo un log di 3 letture ogni 60 secondi.

Ho inoltre fissato anche un limite alla lunghezza del file di log. Quando il contatore delle letture salvate raggiunge 86400, la registrazione si interrompe automaticamente.

Possiamo distinguere la fase di esclusione delle letture dal colore del box che contiene il numero di letture salvate ; se è grigio, ciò che arriva dal multimetro non viene salvato sul log, se invece è verde, la lettura viene salvata e il numero si incrementa.

Ho scelto di salvare tre letture per volta perché il protocollo dei dati inviati dal multimetro non prevede un checksum, quindi se ci fosse un errore nel trasferimento, con tre letture è possibile scartare l’errore facendo la scelta delle “due su tre” buone. Poi, se sono sbagliate più letture consecutive, allora è richiesto l’intervento del vostro Santo Protettore. Comunque, facendo un cavetto dati piuttosto corto (entro un metro), è difficile che ci siano errori…

Registrazione - la casella con il num. di campioni è grigia perché si stanno saltando delle letture

Registrazione – la casella con il numero di campioni salvati è grigia perché si stanno saltando delle letture

Registrazione - la casella con il num. di campioni è verde perché si letture vengono salvate sul log

Registrazione – la casella con il numero di campioni è verde perché le letture vengono salvate sul log

Il file di log viene inizializzato al momento in cui premiamo il pulsante start (quello col cerchio rosso) e gli viene dato il nome log_data_ora.txt (es: log_160706_101820.txt per un log avviato il 6 Luglio 2016 alle ore 10:18:20). Il file viene salvato sulla directory propria del programma, quindi, in questo caso, lo troveremo in Android/data/robotop.DT4Klogger/files/.

Ogni “linea” del file di log contiene l’ora e le informazioni lette dal multimetro. Per esempio:

17:35:44 DC Auto [2.200] V
17:35:44 DC Auto [2.201] V
17:35:45 DC Auto [2.201] V
17:35:56 DC Auto [2.206] V
17:35:57 DC Auto [2.206] V
17:35:57 DC Auto [2.207] V

Per aprire un file di log copiato dal tablet su un PC Windows, usate un text-editor tipo Genie o altri compatibili con la modalità Android (Linux) di terminare le linee di testo con il solo carattere LF (Line Feed, 0x0A), anziché CRLF (Carriage Return & Line Feed – 0x0D 0x0A) come usa Windows.

Quando l’applicazione viene avviata la prima volta, compare una richiesta di autorizzazione all’uso dell’interfaccia USB :

Richiesta di autorizzazione ad usare l'interfaccia USB

Richiesta di autorizzazione ad usare l’interfaccia USB

Diamo quindi l’autorizzazione per proseguire (si dovrà nuovamente toccare l’icona del programma per effettuare l’avvio). Se ci sono problemi con la seriale USB, si riceverà un messaggio di errore :

Oops ! Errore sulla seriale USB

Oops ! Errore sulla seriale USB

Come interfaccia USB ho utilizzato una di quelle schedine USB-TTL che sono comunissime nei negozi on-line e che costano un paio di Euro dai venditori cinesi. La mia utilizza il chip Prolific PL2303 ed è riconosciuta tranquillamente da Android.

Nota: alcuni tablet non riconoscono l’interfaccia USB-TTL se questa è collegata “a caldo”, cioè col tablet già acceso. Se si riceve l’errore “Impossibile usare porta COM”, provare a spegnere completamente il tablet e quindi riaccenderlo con l’interfaccia già collegata.

L’interfaccia USB, però, non basta per collegarsi al multimetro, che ha una presa Jack stereo come connettore d’uscita. Bisogna costruire un minuscolo adattatore. Questo è lo schema :

Lo schemino dell'adattatore

Lo schemino dell’adattatore

Io l’ho costruito direttamente su una striscetta di contatti con 3 pin, senza usare un CS. Ho poi collegato i tre pin all’interfaccia USB con i soliti cavetti Dupont. Il risultato è questo :

Scheda USB-TTL e circuitino adattatore per multimetro

Scheda USB-TTL e circuitino adattatore per multimetro

Aggiornamento 19 Nov 2016:

Ho comprato di recente su un “noto negozio on-line” una interfaccia USB-RS485 e così ho notato che potevo creare una interfaccia più semplice della precedente per collegare il multimetro al computer. L’interfaccia che vedete nella foto sottostante è basata su un chip FTDI e quindi dovrebbe essere “vista” tranquillamente dal dispositivo Android. La mia prova l’ho fatta su un PC con Windows e su un tablet Android ed ha funzionato in entrambi i casi.

L'interfaccia USB-RS485 con le connessioni effettuate senza saldatore.

L’interfaccia USB-RS485 con le connessioni effettuate senza saldatore. I fili neri sono quelli del connettore Jack che va sul multimetro.

Lo schema elettrico corrispondente è questo:

Lo schema elettrico

Lo schema elettrico

Il bello di questa interfaccia è che può essere realizzata senza saldatore, basta un giravite e un po’ di pazienza per intrecciare i fili di rame. Notate che il +5V è stato preso da un “jumper” inserito sul circuito, intrecciando sul ponticello un filo di rame isolato, come si vede in figura. Tempo di assembleaggio: meno di un minuto, se avete un cavetto con il connettore jack già pronto. Nella foto sotto, potete vedere il dispositivo in funzione.

Il multimetro collegato al tablet con l'interfaccia descritta.

Il multimetro collegato al tablet con l’interfaccia descritta.

L’applicazione DT4Klogger.apk può essere scaricata gratuitamente dalla mia pagina Google Play a questo link :
https://play.google.com/store/apps/developer?id=Emilio+P.G.+Ficara

L'icona dell'App

L’icona dell’App

(10 Lug 2016) Note per la versione corrente dell’App gratuita :
1) l’App può essere usata solo su dispositivi che siano in grado di supportare USB OTG e di rilevare correttamente l’interfaccia USB-TTL collegata.
2) l’App attualmente supporta solo l’orientamento verticale. Se si ruota il tablet (o smartphone) l’applicazione viene chiusa.
3) l’App si chiude quando viene mandata in sospensione tramite il pulsante home o se si riceve una chiamata o un avviso.
4) l’App mantiene il dispositivo acceso, quindi il consumo della batteria può essere consistente.

M590 – modulo GSM/GPRS – Esperimenti

Sto realizzando un circuito di controllo di un server tramite SMS e, come al solito, prima di mettermi a scrivere il programma in C per il microcontrollore, faccio dei test con un hardware “minimalista” collegato al notebook. Per scrivere i programmi di test in ambiente Windows, uso spesso il FreeBasic con il supporto dell’IDE FireFly (vedi Links utili); entrambi i programmi sono freeware ed hanno potenzialità notevoli.

Dato che costruirò pochi esemplari di questo circuito di controllo, ho cercato un modulo GSM/GPRS che fosse facile da saldare su un PCB realizzato da me. Per questi progettini non sofisticati, sviluppo da solo il disegno del PCB e poi invio il file Gerber ad una ditta cinese scoperta su “un noto negozio on-line” e quindi ricevo i miei bellissimi circuiti stampati, con tanto di “verde” e di serigrafia, in meno di due settimane, ad un prezzo conveniente. La qualità, per chi avesse dei dubbi, è decisamente buona.

Tra i moduli “facili da saldare” ed economici ho trovato lo M590 della Neoway. Le piazzole di saldatura sono col passo 2.54mm e la documentazione si trova facilmente su Internet, sia quella relativa all’hardware elettronico, sia quella relativa ai vari comandi AT implementati nel software. Un ulteriore punto a favore di questa scelta è che sul “noto negozio on-line” si trovano dei “kit” di montaggio che comprendono il modulo stesso, un PCB e i vari materiali accessori. Ovviamente, tutti (o quasi) i componenti del kit sono in SMD, quindi difficoltosi da saldare per un principiante, ma io ho cominciato a 12 anni ed ora ne ho 60, quindi…

Quindi ho comprato tre di questi kit, da tre venditori diversi (diversificare, diversificare) ed ho atteso pazientemente. Appena è arrivato il primo “kit” mi sono messo all’opera. Per prima cosa ho letto approfonditamente il documento PDF trovato on-line dal titolo: Neoway M590 Hardware Design Manual V1.1.pdf e vi ho trovato molti consigli utili a sviluppare un circuito “come si deve”. Ho allora abbozzato uno schema a blocchi di come avrei realizzato il mio hardware di test.

block-diag-ss

Lo schema a blocchi dell’hardware di test

La cosa su cui più insiste il manuale dell’hardware è l’alimentazione del modulo. Quindi ho deciso che nel circuito di prova avrei usato una batteria ricaricabile al litio, una cella da 3.7V di formato AA (14500, la classica stilo). Il vantaggio di usare una batteria così è che questa è in grado di fornire senza problemi i picchi da 2A che il modulo richiede durante la trasmissione. Una batteria al litio “decente” è in grado di fornire una corrente di 5C, dove C è la capacità nominale, quindi con una cella da 1200mA posso chiedere spunti di 6A e così per l’alimentazione sono a posto. Per ricaricare la batteria, quando questa si scarica, ho costruito un piccolo circuito utilizzando un modulino che si trova on-line “a due lire” ed ho modificato la resistenza di programmazione per avere una corrente di ricarica di 350mA circa.

charger

Il carica-batteria per una cella da 3.7V tipo AA (14500)

Sistemata la sezione di alimentazione, ho visto che il manuale parlava di come uscire da situazioni di blocco software del modulo. Una parte della procedura si può tentare da comandi AT, ma in casi di emergenza, il costruttore consiglia di togliere alimentazione al modulo e ripartire da zero. Allora ho deciso di costruire uno switch controllabile da una linea del convertitore USB-TTL che userò come porta seriale dal PC al modulo. Ho usato un doppio mosfet P-N in single chip, anch’esso comprato on-line. Regge tranquillamente la corrente richiesta e viene attivato o disattivato dalla linea DTR che è controllabile tramite il mio software. Se non si necessita di tale “sofisticazione”, basta usare uno switch “a mano”.

Lo schema elettrico dello switch ON/OFF per l’alimentazione del modulo

Ora, l’ultima cosa rimasta è l’interfaccia seriale. Il convertitore USB-TTL che ho usato (sì, anche questo comprato on-line) è basato sul chip CP2102 ed ha, oltre ai soliti TXd e RXd anche i vari segnali di controllo, tra i quali le uscite DTR e RTS. L’uscita DTR l’ho usata per lo switch, mentre la RTS è inutilizzata, però nel programma di controllo (vedi sotto) c’è un checkbox per controllarne lo stato via software. Il modulo ha tutto il proprio I/O alimentato a 2.85V e il manuale avvisa chiaramente che superando i 3.3V si rompe. Oltre a questo, dallo schema interno si vede che i diodi di protezione portano un eventuale positivo presente su un pin fino in cima alla catena di alimentazione, mantenendo il modulo “parzialmente alimentato” anche in mancanza di Vbat, in una condizione in cui potrebbe “resettarsi male”. Per questa ragione ho usato il circuito consigliato (diodo e resistenza di pull-up verso VccIO) per la linea di ricezione dati. Infatti, se si spegne il modulo, la linea di TX del convertitore USB-TTL continua ad “iniettare” 3.3V sull’uscita. Se avessi solo messo una resistenza, questa tensione sarebbe entrata nel modulo andando ad alimentare (parzialmente) il circuito. Così, invece, il diodo non la lascia passare. Ho usato un BAT43, uno Schottky, perché a 2mA ha un drop di circa 300mV, abbastanza basso. La linea VccIO del modulo tira fuori 2.85V, ma con una corrente max di 3mA. La pull-up di 4K7 è abbondantemente “a specifiche”. L’unica cosa un po’ critica, in questa configurazione, è che i fronti di salita del segnale seriale sono un po’ lenti, dato che dipendono dalla capacità del pin di input e dalla resistenza di pull-up. Il modulo “nasce” con una velocità di trasmissione di 115200 BPS, che significa che ogni bit è “largo” circa 8.7 microsecondi ; un fronte di salita lento potrebbe, randomicamente, provocare un errore nei dati. La soluzione è quella di fornire al modulo il comando per abbassare questa velocità e salvare la nuova impostazione nella configurazione interna. Io uso quasi sempre i 19200 BPS, perché per applicazioni tipo SMS vanno più che bene e le possibilità di errori dovuti a fronti lenti si riducono enormemente.
Per la parte di trasmissione del modulo, ho messo come interfaccia solo una resistenza di protezione da 470 Ohm. E’ da notare che il convertitore USB-TTL che ho usato ha una strana serigrafia: il pin dove c’è scritto TXD non è quello di trasmissione, ma quello di ricezione ! Lo stesso vale per il pin RXD. In pratica, l’allegro ingegnere che ha progettato il circuito ha inteso dire: “questo Pin lo devi collegare a TXD” e non: “questo Pin è TXD”. Una filosofia strana, ma si sa come son fatti gli ingegneri… Fate attenzione, quindi, a non scambiare i Pin, altrimenti non funzionerà. Comunque, un piccolo dispositivo facile-facile per testare il pin di uscita (TXD) è composto da un led rosso e una resistenza da 470 Ohm in serie. Mettete il catodo del led sul pin da testare (TXD) e la resistenza su 3.3V. Con un programma di terminale (o con il mio presente più sotto) inviate un comando; se il led si illumina, il pin TXD è l’uscita, altrimenti provate spostando il catodo del Led sul pin RXD. Quello che fa illuminare il led è il segnale di uscita.
Ora, veniamo al kit. Ho montato il circuito stampato che è arrivato insieme al modulo M590, ma ho apportato qualche modifica, come in figura:

Il kit montato; lato connettore sim

Il kit montato; lato connettore sim

Sullo stampato sono evidenziate le piccole modifiche: ho innanzitutto saldato tra i pin Vbat e Gnd due condensatori (SMD), uno da 100nF e l’altro da 22pF. Servono per filtrare un po’ i disturbi ad alta frequenza sull’alimentazione. Ho poi saldato una resistenza da 4K7 tra il pin RXD (7) e VccIO (6). Questa è la resistenza di pull-up a cui si collegherà l’anodo del diodo BAT34. Il diodo l’ho montato sull’altro circuito (a sinistra) dove ci sono anche lo “switch” e il convertitore USB-TTL. Ho infine cambiato i led, usandone due in package 1206 (uno rosso e uno verde) ed ho cambiato le relative resistenze. Per il led rosso ho usato una resistenza da 1K e per il verde una da 470 Ohm. Con un biadesivo ho poi fissato il portapile per la batteria da 3.7V, in modo da tenere tutto vicino. Il circuito millefori dove c’è il resto del circuito è collegato tramite i soliti cavetti tipo Dupont. Dall’altra parte del CS c’è il modulo M590 e il connettore con i vari segnali. Ho eliminato il condensatore elettrolitico da 470uF e al posto del diodo ho messo un ponticello. In questo modo, il circuito funzionerà con la tensione di batteria.

Il kit montato; lato modulo M590

Il kit montato; lato modulo M590

E’ da notare che le celle ricaricabili al litio da 3.7V, una volta a piena carica forniscono una tensione di 4.2V e arrivano a 3.7V solo quando è rimasta una carica residua di circa il 10%. Una batteria non deve MAI scendere sotto i 2.85V, pena la perdita della proprietà di ricaricarsi. In ogni caso, alimentando il modulo con la batteria, vi accorgerete subito di quando questa si sta scaricando, perché dalla seriale comincerete a ricevere, ogni 3/4 secondi, il prompt MODEM:STARTUP, che indica che c’è stato un reset automatico. Quando la tensione scende sotto i 3.3V, c’è il reset automatico; poi il modulo prova a ripartire e appena va in trasmissione la tensione cade perché c’è un alto assorbimento e così si resetta tutto e ricomincia. Quando arrivate a questa situazione, prendetevi una pausa, mettete la batteria a ricaricare e andate a fare una passeggiata.

Arriviamo, infine, al programma di test. Questo è praticamente uguale a quello presentato per le prove del modulo WiFi ESP-01 (vedi http://ficara.altervista.org/?p=3158), ma ha pre-registrati altri comandi utili per il modulo M590, più i controlli per le linee DTR e RTS. Questi controlli, ovviamente, funzionano solo quando la porta COM è stata aperta con il comando Open. I moduli M590 comprati on-line, si vede chiaramente, sono dissaldati da uno stampato. Io credo che qualcuno abbia comprato uno stock di vecchie schede (migliaia di vecchie schede) ed abbia smontato i modulini, poi abbia fatto fare dei PCB “base” trovando così il modo di vendere la “roba vecchia” sul mercato (vastissimo, ormai) degli appassionati. Però, siccome il modulo è stato dissaldato (i miei tre, sebbene di diversi fornitori, sono tutti così) non è detto che risponda ai comandi con il settaggio “di default” a 115200 BPS. Nel mio caso, il primo che ho provato era “settato” a 38400 BPS. Io, nel mio programma, ho fissato come default 19200 BPS, perché ho già spiegato che è quello che uso più spesso. In ogni caso, fate diverse prove con velocità standard e aspettate di leggere sulla finestra dei messaggi il fatidico: MODEM:STARTUP. Ecco la schermata del programma in funzione:

Lo screenshot del programma in funzione

Lo screenshot del programma in funzione

Nell’esempio mostrato, usando i primi 4 comandi di fila, si è inviato uno SMS. Eccolo come è apparso, immediatamente, sul telefono a cui era destinato:

SMS ricevuto !

SMS ricevuto !

Il programma AT-M590 è un eseguibile puro, non ha bisogno di installazione. Per le istruzioni leggere l’articolo precedente (http://ficara.altervista.org/?p=3158), è tutto uguale. I checkbox DTR e RTS, una volta cliccati (con la COM PORT aperta) provocano il cambio di stato delle relative linee, e sulla finestra dei messaggi compare lo stato logico della linea (3.3V o Gnd). Il file zippato può essere scaricato da questo link. Per scompattare lo zip verrà richiesta una password; questa è: eficara.

Una volta scaricato il file, prima di scompattarlo, verificate che il suo hash MD5 sia: 978903344C7E65C33963E8F9983EE0A1 (vedi Links utili: Hashtab). Questo vi darà la certezza di aver scaricato il file originale, senza errori.

Buona sperimentazione !

AT-commands tool

Aggiornamento – 23 Lug 2016:
– modificato segnalatore inizio commento da // a ;; (per comandi includenti http:// ecc.)
– migliorata fase apertura/chiusura porta seriale
– eliminato invio automatico “AT” e attesa ricezione “OK” all’apertura porta COM
Il nuovo file eseguibile zippato è disponibile a questo link..
La password per scompattare lo zip è: eficara.
Il checksum MD5 è: F98FA8CBBD03F3D9A4E2C222306A111E

Ho deciso di modificare il programma scritto per fare delle prove con il modulo ESP-01, già descritto in un precedente post, perché mi sono trovato ad utilizzare dei modulini low-cost GSM-GPRS per l’invio di SMS. Entrambi i moduli M590 e SIM800 hanno, come di consueto, una serie di comandi AT, così come l’ESP8266. Ho quindi fatto delle aggiunte che dovrebbero rendere lo strumento più comodo ed efficace. Qui sotto potete vedere uno screenshot del programma in funzione.

Atool-ssPer prima cosa ho modificato il nome del programma, cambiandolo da Tool_ESP8266 a ATool, anche perché ho visto che di programmi chiamati “Tool_ESP8266” ce ne sono in giro davvero tanti ! Poi, ho fatto le seguenti modifiche e aggiunte:

Variazioni e aggiunte:

  • modificata default speed da 115200 a 9600 BPS
  • Aggiunti al file save / load anche i valori di COM e SPEED. Il comando load chiude anche la porta seriale, se era aperta; si dovrà quindi eseguire di nuovo un “open”.
  • Aggiunte altre 3 linee di comando, così passano da 9 a 12
  • Modificato il funzionamento dei “send”. Non mandano più un CR-LF a fine stringa
  • Aggiunta possibilità di costruire caratteri di controllo tramite il segno ^. Il carattere successivo a ^ viene calcolato con & 0x1F, permettendo quindi di inserire nella riga programmata vari tipi di caratteri di controllo. Per esempio, ^M verrà trasmesso come 0x0D (CR) e ^J come 0x0A (LF). Con questo sistema si potrà decidere come terminare le stringhe da inviare sulla seriale ed inserire altri caratteri di controllo necessari, ad esempio, nella trasmissione di SMS.
  • Aggiunto un box che indica la lunghezza della stringa nella riga che si sta modificando. La lunghezza non tiene conto dell’eventuale commento // e conta i caratteri di controllo (ad es. ^M) come un singolo byte. Questo è molto utile quando ci sono dei comandi in cui va inserita la lunghezza del pacchetto da trasmettere.
  • Modificato il funzionamento della finestra dei messaggi per la visualizzazione di messaggi da parte del dispositivo collegato anche se la stringa in arrivo non è terminata da CR o LF.

Il programma è stato scritto in FreeBasic, con l’IDE Firefly for FreeBasic. Entrambi i programmi sono disponibili gratuitamente presso i rispettivi siti (vedi colonna a destra della pagina Home, Links utili). Nell’immagine del programma in funzione è possibile vedere come si è ricevuto il testo di una pagina internet, inviando (dopo aver effettuato le fasi preliminari) i comandi AT-CIPSTART= e successivamente AT+CIPSEND= e quindi la stringa GET / . Il file scaricabile liberamente ATool.zip contiene l’eseguibile puro, non c’è bisogno di installazione. Scompattate lo zip in una directory (ad esempio: /downloads/tools) e potrete utilizzarlo immediatamente. Per scompattare lo zip serve una password che è: eficara. Per eseguire il comando “save” è necessario disporre dei permessi di scrittura nella cartella dove risiede l’eseguibile. Se avete scompattato l’eseguibile in una cartella in cui l’utente ha i diritti di scrittura, non c’è problema, altrimenti dovrete eseguire il programma come amministratore. Prima di scompattare lo zip, però, verificatene l’hash MD5: C1BC15FF6CF4A0E77B7661A08DCAD1F0. Se non corrisponde, non scompattate il file, potrebbe essere corrotto o non essere quello originale. Per il calcolo dell’hash MD5 io uso il programma freeware HashTab che può essere scaricato dal sito del produttore (vedi Links utili) e si integra nella Shell di Windows. In pratica, dopo averlo installato, quando cliccherete col destro su un file, tra le “proprietà” ci sarà anche lo strumento per calcolare l’Hash. Questo programma è molto comodo anche per verificare che i files copiati su supporti rimovibili siano esattamente uguali a quelli di origine. Vedrete così quanti errori ci possono essere nelle copie eseguite su memorie di massa USB di basso costo !

Per il momento è tutto. Buona sperimentazione !