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…

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.

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 !

ESP8266 Modify default SSID without a compiler

This program has been written in FreeBasic with the IDE FireFly 3.50 ; both tools are free, easy to use and very “light”.  The compiled executable doesn’t need for installation, it’s ready to run. Just download the zipped file ssid_mod.zip and expand it in a working directory (ie. \downloads\esp8266) and there will be the ssid_mod.exe ready to run.
In order to expand the .zip you must supply a password that is: eficara. Be sure that the downloaded file is the original one by checking its MD5 with a tool like HashTab that’s available for free.
The MD5 hash for the zipped file must be: FB94DDF8B155A0511C13A60FE585642D. If it’s different, do not expand the zip, ‘cause it isn’t the original one. Look at the screenshot of the program just executed:

SSIDmod_ssHow it works

Prior to write this software, I tried to modify the original firmware binary file ESP_8266_BIN0.92.bin with a hex-editor, looking for the string “ESP_” that was the prefix of the default SSID. I found the string at address 0x82C4. Well, it was simple. I stored a new SSID string at the same address, with the care to not overcome the memory area reserved for such data. I then saved the new binary file and tried to re-flash my ESP-01 module, but the programmer failed at a certain block. Ok, the simplest solution did not work. The reason was that the binary file isn’t a “true binary”, but is a collection of binary data, instructions, addresses that are used by the programmer software to communicate with the ESP-01 bootloader (when in flash mode). Looking on the internet I discovered an important information: all the blocks in this “no-binary .bin file” are followed by a checksum. The checksum is very simple: it’s just the xor of all the bytes in the block. Then I decided to write this program that simply creates a string with the same checksum of the original one. This is possible due to the easy implementation of the checksum by means of xor ;.if it was done with a real CRC, this programming approach couldn’t have been used.

The string in the original .bin file is “ESP_%02X%02X%02X” that seems to be a constant data or a variable initialization data. This will probably be used in C statement like: printf(“ESP_%02X%02X%02X”, x,y,z) that means send the ascii “ESP_” followed by three bytes of data in HEX format, 2 characters each, capital letters, to the standard output. In our case, the default SSID of the module may be(for example): ESP_9A0FE9 where 9A, 0F and E9 are the three least significative bytes of the MAC address of the WiFi chip. The C compiler saves all the initialization data in a memory area called “data segment” and the linker creates a fixed map of all that areas. So, if we modify some data without overcoming the assigned space, we can change any initialization string. Note that C strings are “null-terminated”, that means that after the ascii characters there is a /0 (0x00). This makes very simple to change the default SSID of the module, in our case. The important thing is that the ‘Replacement String’ must be at least 2 bytes shorter than the one we want to change. This is because we want to change the data in that memory space without changing the full block checksum. This can be obtained in a very easy way. It’s better to explain with an example: suppose that we want to change an initialization string with the contents “ABCDEF” ; the checksum for all the characters will be 0x07 (0x41 xor 0x42 xor 0x43 xor 0x44 xor 0x45 xor 0x46). Now, lets change it in “TEST” ; such string has checksum 0x16 (0x54 xor 0x45 xor 0x53 xor 0x54) , so we simply add after TEST a null-terminator (0x00) and the value that makes the checksum equal to the one of the old string. In this case it’s 0x11 (0x11 xor 0x16 = 0x07). At the end, the ESP C program, when accessing that data, will find a variable at the default address with the contents : 0x54 0x45 0x53 0x54 0x00 (and this is the end of string, for the program) followed by 0x11. The C program will ignore the 0x11 (it’s after the null-termination), but the .bin file will result correct because “ABCDEF” has exactly the same checksum as “TEST” followed by 0x00 and 0x11. That’s all.

Why the original string is 16 characters long (ESP_%02X%02X%02X) and we can only use a max 10 characters SSID ? It could be 14 max (16 of original size, minus 2 for the checksum adjustment), but in this C program only 10 characters are used, even if you write a 14 characters field. I still haven’t a compiler and toolchain for the ESP8266, nor the C sources to look inside, but, for now, I reached my target that is to change the default SSID of the module without using a compiler and a toolchain. 🙂

update: 2016/04/20

I tried the SSID change on a newer version of the firmware (ai-thinker-0.9.5.2-9600.bin), changing the ‘Search String’ to AI-THINKER_%02X%02X%02X, and modifying the wanted SSID, but at the end of re-flashing, the ESP-01 module still presented the old SSID AI-THINKER_A0C76D 🙁 The reason is simple: there is another point in the firmware where the string is saved in plain form. So I changed again the ‘Search String’ as you can see in the picture below and all was OK. Note that in this case, you can use an SSID up to 15 characters long.

new-version_ssReflashing the ESP-01 module

I used a tool called esp8266_flasher.exe to re-flash the ESP-01 module after the default SSID change; here is a screenshot of the operation. Note that the program ends with a failure trying to exit the “flash mode”, but it’s normal, ‘cause my hardware has a physical jumper to enter / leave such operating mode.

flash-downloader-ssThe original firmware, together with the programming tool, was found googling the internet for ESP8266_flasher_V00170901_00_Cloud Update Ready. The original binary file used in my experiments is the one named: ESP_8266_BIN0.92.bin

After resetting the module, the state of the WiFi networks visible from my computer was the one in the picture below. As you can see, I joined my ESP-01 module with SSID named WiFicara01, that was substituted to the one in the original flash rom binary file.

wifi-connected-ss

Software di test per ESP8266

Se qualcuno ha costruito il circuito che ho proposto nel mio precedente articolo sul fantastico IC ESP8266, potrà trovare utile un software di test in ambiente Windows per effettuare qualche prova. So che ci sono in giro applicazioni di tutti i tipi con la stessa funzione, ma di solito preferisco scrivere io stesso i miei programmi perché così ci metto dentro esattamente quello che mi serve, niente di più e niente di meno. Qui sotto si può vedere uno “screenshot” del programma in funzione:

tool_esp8266_ssIl programma è stato scritto in FreeBasic con l’IDE FireFly 3.50; questo ambiente di sviluppo è gratuito, facile da usare, “leggero” ed efficace.  Il programma è un eseguibile puro, non ha bisogno di installazione; una volta scaricato il file zippato Tool_ESP8266.zip si dovrà solo scompattare l’eseguibile in una directory di lavoro (ad es. \downloads\esp8266) e lì ci sara l’EXE pronto all’uso. Per scompattare il file verrà richiesta una password ; questa è eficara. Per verificare che il file zippato sia quello originale, mi raccomando di verificarne il contenuto calcolando l’hash (io uso il programma HashTab V5.10) e controllando che l’ MD5 sia: FC97A53A0465FCA6CD8CA471E2B2623E. Se è diverso, non scompattate il file, non è quello originale.

Caratteristiche del programma

Il programma comunica, attraverso una porta seriale, con il modulo ESP8266. In alto a destra nella schermata dell’applicazione ci sono i campi da riempire per settare la comunicazione seriale. Il numero della COM port potrà essere verificato vedendo, tra le risorse hardware del computer, quale indirizzo è stato assegnato dal sistema al convertitore USB-Seriale che avremo inserito in una delle porte USB del nostro computer. La velocità (speed) è solitamente di 115200 BPS, ma in alcuni moduli ESP molto vecchi (il primo lo comprai più di due anni fa) la comunicazione potrebbe essere inizialmente a 9600 BPS. Per verificare che tutto sia OK, basta inserire il numero della COM port e la velocità e cliccare il pulsante “open”. Se tutto è OK, allora la scritta sul pulsante si trasformerà in “close” e la porta di comunicazione sarà attivata; in caso contrario, si potrà leggere nella finestra dei messaggi la ragione per la quale la comunicazione non è possibile. In pratica, si può ricevere un errore per impossibilità di aprire la porta seriale (ad esempio. se avete sbagliato numero di porta COM) oppure per una velocità errata. In questo caso, riprovate inserendo altre velocità tra quelle standard: 4800, 9600, 19200, 38400, 57600, 115200 o superiori se la vostra interfaccia USB-Seriale le supporta..

Una volta aperta la comunicazione, abbiamo a disposizione alcuni comandi pre-caricati nelle 9 righe di comando. Il contenuto delle righe di comando, ovviamente, può essere modificato secondo le proprie necessità. Notate che a destra di ogni comando AT c’è un commento, iniziato da una doppia barra // ; tutto ciò che scriverete dopo la doppia barra (e la doppia barra stessa) non verrà inviato sulla porta seriale. A destra di ogni riga di comando c’è un pulsante di invio il cui uso è abbastanza intuitivo: invia sulla porta seriale il comando AT contenuto nella riga. Sulla finestra dei messaggi si vedrà il messaggio inviato e la conseguente risposta del modulo ESP collegato. I comandi pre-confezionati, così come li vedete appena aperto il programma, consentono di effettuare tutte le operazioni necessarie per attivare un server TCP sulla porta 80. Nella foto della schermata del programma, vedete l’effetto di un browser che cerca di accedere ad una pagina html del nostro ESP. Ovviamente, il browser rimane “impallato” per mancanza di risposte fino a quando non inviamo il comando sulla riga 9, che chiude la connessione TCP (oppure al timeout in attesa di risposta).

Se modifichiamo i comandi, inserendo al posto di quelli “di default”, quelli che riteniamo utili alla nostra sperimentazione, potremo poi salvarli (tutti insieme) usando il pulsante “save” in alto a destra nel riquadro -disk- ; analogamente, potremo ricaricare una combinazione di comandi salvata usando il pulsante “load”. Bisogna tenere presente che se il programma eseguibile è stato salvato in una directory che richiede i privilegi di amministratore, per salvare un file bisognerà lanciare il programma con i privilegi richiesti, quindi “esegui come amministratore”. Se si è utilizzata una directory con i diritti di scrittura da parte dell’utente, non ci sarà problema.

Per il momento è tutto. Buona sperimentazione !

Nota: a questo link è possibile trovare una nuova versione del programma con alcune importanti migliorie.

Spread your meteo sensor data over the internet

I published on the Italian Magazine for Electronics “CQ Elettronica” (issue N.485 September 2007) an article about my project based on Atmel ATtiny2313 microcontroller that converts the RF data stream (OOK modulation at 433 MHz) received from Oregon Scientific meteo sensor model THGR228NF (look at this link for more details).  This device was also revised by Hack-a-day in September 2007.

Recently, I created an Android App to display the received data on a tablet or a smartphone, using an USB-Serial interface to connect the receiver to the device. You can find the App on my page on Google Play Store and more informations at this link.

After the first version, I created a new one that uses a PIR sensor (Passive InfraRed) to swap the screen from a flip-clock to the meteo data screen when a person passes near the box. This is the prototype:

App in funzione su tablet 800x480 scala=1

Prototype running on 800 x 480 display 6.5″ Phablet

Well, after that I had the idea to publish my webcam on the Internet, superimposing over the picture (taken every 20 minutes) the meteo data received from the Oregon Scientific meteo sensor. This will enhance the picture with useful meteo data. Here is an example of what you can see clicking my webcam link :

webpic

click to reload actual view

As you can see, at the bottom of the image there are two information lines. Such lines are created by a PHP script that I stored on the server. The first line is the date and time of the picture, while the second is the date and time of the meteo informations (sent every 10 minutes), together with the temperature and humidity at the specific time.

The picture sent by the webcam hasn’t any information, being the camera a very simple device (look below how simple is..)

very home made webcam (click to enlarge)

very home made webcam (click to enlarge)

The bridge from the meteo receiver to the second line of picture is a new App written for an old 7″ tablet, running Android 2.2. This App does what the previous did, but every 10 minutes sends an HTTP GET request to a specific PHP script that I saved on the server. This GET request is formatted with a simple crypting and contains the temperature and humidity read from the sensor. The PHP script on the server receives the meteo data and creates a file with such infos. When the user clicks the link of my webcam, the PHP script loads the picture received from the webcam and the meteo data received from the tablet and creates on-the-fly the image you receive on your browser. Obviously, the tablet running the App connects to the Internet thru the home modem / router that acts as a WiFi hotspot.

I haven’t published this App on Google Play ‘cause I decided to use, as communication port, the internal ttyS0 of the tablet. Such communication port was present in almost all the first models of tablets, but was used by the system for the “console” service. I modified the init.rc file of my rooted tablet (running Uberoid image) in order to disable the console service on that port, so I connected my RX-Met1 receiver directly to ttyS0 without any USB-Serial interface. This approach is too “specialistic” and therefore isn’t idoneous to the Play Store distribution. I just added a small video to show how I arranged the old tablet in a box with the receiver and the PIR sensor… (Dailymotion video)


MeteoRx22 di robotop

This way of sending sensor data over the Internet can be easily achieved with new low-cost modules, like ESP8266 that gives you the power of WiFi at very low price, with extreme easy of use.

IP Query – utility di rete per Android

L'icona dell'applicazione

L’icona dell’applicazione

Sempre più spesso gli smartphone vengono usati per connessioni Internet, non solo per la navigazione del Web o per la messaggistica istantanea, ma anche per il controllo a distanza di apparecchi collegati in rete. Ho così deciso di scrivere una piccola App che svolge due compiti : verificare se è possibile connettersi ad una certa “porta” su uno specifico IP e se si riceve risposta ad un “ping” inviato verso un IP. Nello screenshot sottostante si vede che la porta 80 (http) dell’IP 192.168.1.1 (il modem / router di casa) è raggiungibile.

Screenshot dell'App a seguito del comando Test

Screenshot dell’App a seguito del comando Test

In alto, sullo schermo, si nota l’IP locale dello smartphone, che essendo collegato in WiFI ha avuto dal server DHCP l’IP 192.168.1.9 . La porta 80 è raggiungibile perché il modem / router ha un’interfaccia di programmazione attraverso un browser web, quindi via HTTP.

Il comando di Ping invia un pacchetto ICMP e verifica che l’IP impostato sia raggiungibile. Alcuni server bloccano il servizio di risposta al ping per ragioni di sicurezza, ma nella maggior parte dei casi è possibile vedere se un IP è attivo ed operante.

Sia il comando Test che il Ping inviano una singola richiesta. Se si riceve come risposta un “no”, è opportuno eseguire di nuovo la prova per tre o quattro volte, per essere sicuri.

L’applicazione è disponibile gratuitamente su Google Play Store.

Terne Pitagoriche

pitagoraIl signore nell’immagine, che giustamente pensa di essere “troppo” forte, è Pitagora. Avendo una mente incline alla matematica, arrivò a calcolare che il quadrato costruito sull’ipotenusa è pari alla somma dei quadrati costruiti sui cateti (nel caso di un triangolo rettangolo, ovviamente). So che i Babilonesi arrivarono alla stessa conclusione diverso tempo prima, usando un metodo quasi “grafico”, e noi ringraziamo tutte queste menti brillanti e applichiamo la regola lasciataci in dono per fare i nostri calcoli.

Normalmente conosciamo i due cateti e dobbiamo trovare l’ipotenusa, oppure conosciamo l’ipotenusa e un cateto e dobbiamo trovare l’altro, ma recentemento ho aggiunto alla mia calcolatrice Android (scaricabile da Google Play Store, vedi link)  un tasto che compie un’azione diversa: possiamo inserire un valore per l’ipotenusa e la calcolatrice ci restituirà tutti i possibili valori dei cateti. Questa funzione è particolarmente utile a chi prepara gli esercizi per gli studenti, infatti con un semplice click si possono creare le cosiddette “Terne Pitagoriche”.

Prima di scrivere l’applicazione per Android, ho provato l’algoritmo sul PC, usando il solito FreeBasic. Ecco la schermata relativa ai risultati avendo dato in ingresso un valore di ipotenusa pari a 17.00 :

terne_ss

cliccare l’immagine per ingrandire

La precisione dei numeri è compresa nella regione delle due cifre decimali ; questo vuol dire che sia l’ipotenusa, sia i cateti sono numeri “precisi”, cioè sono terne esatte con al massimo due cifre decimali. Naturalmente, anche se nella schermata si vede A= 2.60 e B= 16.80, vale anche la soluzione A= 16.80 e B= 2.60 ; le simmetrie non vengono stampate dal programma per non dare un’inutile ripetizione.

Chi volesse provare il programma sul proprio PC, potrà scaricare l’eseguibile zippato a questo link ; per decomprimerlo occorre fornire la password che è: eficara . Per verificare che il file scaricato sia l’originale e non sia stato manipolato da biechi individui, potete controllare l’hash MD5 che deve essere: B09D351E99FB13C4E45993F0D56A12C9 .

Nota: ho inserito questa funzione anche nella mia calcolatrice Android (gratuita).