Your HotSpot is a presence detector

note: USB connector used only to power the circuit

I never connect my devices to “free wifi” hotspots. I’ve seen what a (bad) hacker can do, using one laptop, a battery powered Raspberry PI board and a collection of software tools. He can spy (almost) any smartphone that is connected to the same “free wifi” hotspot.

For this reason, I always use my own LTE 4G connection and my smartphone is always enabled to share such internet connection with my other devices (one laptop, another smartphone and some other) using an access filter based on MAC address of every device. This is more secure than use “free wifi” hotspots and I suggest to everyone the same approach. However, this isn’t the subject of my post.

Having my own hotspot, with the SSID choosen by myself, I can use the smartphone for a lot of nice services. In this article I will describe one of them.

The presence blinker

I’m currently living in a B&B, ‘cause I’m far from home, due to a contract job. When I am in my room, I don’t make too much noise. I just read or write documents; the TV is turned off and also the music is off. So, it happens that other hosts of the B&B, when going out, lock the main door with the key! This makes me a bit claustrophobic! To avoid this unfair situation, I decided to build a flashing light that will be visible from the low side of my room’s door, just to warn the other hosts that I am in my room

I thought about a passive IR sensor, but such devices work only if there is a movement in the room, and I don’t move so often. Also microwave sensors based on Doppler effect work in the same way; they activate the output when there is a movement. Finally, I decided to use my smartphone as a presence detector… I built a small device based on the well known ESP-01 module. This device has an ATtiny2313 microcontroller and a blue led (high luminosity) that blinks when I am in the room (with my smartphone). When my smartphone goes out (with me) the led stops blinking…

The working principle is very simple. The microcontroller sends AT commands to the ESP-01 to get the list of active hotspots in the area. One of such hotspots is my smartphone, so the SSID string is taken and compared with the one programmed in the internal flash memory. If the two strings match, the led blinks; otherwise the led remains off. So simple…

Note that no connection is active between the module and the smartphone; there is only a periodic check of the visible hotspots. This timed check happens every six seconds and the led lights for 250 mS each time (if your SSID is found).

Note that the SSID of your smartphone must be programmed in the flash memory of the microcontroller (the default is “myHotspot_15car”) so I added an application for PC that modifies the original .hex file to change the default SSID to the one that you like. The max number of characters allowed for your SSID is 15. This limit comes from the low amount of ram memory available on the ATtiny2313 microcontroller (just 128 bytes). Remember that you can choose your SSID in the smartphone using the appropriate menu, so write down one that has max 15 characters and the job is done. Another limit imposed by low ram resources (lack of buffers for serial communication), is that you must program the ESP-01 module to use a 9600 BPS communication speed. There is an AT version created with such default speed on this website:

http://wiki.aprbrother.com/wiki/Firmware_For_ESP8266

go there and look for ai-thinker-0.9.5.2-9600.bin. You can also modify (in a permanent way) the current communication speed of your ESP-01 module using AT commands. There are two, that works depending upon the version of firmware installed. Try both of them; the first that gives answer “OK” is the right one ūüôā

For additional information and tools, take a look at my previous articles here:
http://ficara.altervista.org/?p=3041
http://ficara.altervista.org/?p=3158

You could also look at another my article, that was the “starting point” for this project. There you can find a downloadable executable and the relative source program in FreeBasic. It can be useful to better understand how it works. The link is:
http://ficara.altervista.org/?p=3711

Someone can say: “Hey, I can program the same SSID on my smartphone and fool your device so it thinks that you’re in the room, while you aren’t” ! Then I can answer: “so, I will add to my firmware a check of the WPA2 password of my hotspot, that’s invisible to you” ! Such password check option opens the road to many applications where your smartphone will be the key to unlock your car, your door, to turn on lights at home and every thing you want, simply having it near to you. No buttons to click, no Apps to run, just the “native” HotSpot feature active. It’s easy !

In the downloadable file you can find the .hex file that must be programmed in the microcontroller and the .exe that allows you to insert your SSID in the flash memory, prior to program the micro ! The firmware is very small (less than 1 Kb) and has been written in pure C without any special library.

The schematic of the device is simple. Here below there is a picture of it. You can also download it in PDF format for a better view (click this link).

Disclaimer of Liability.
The program or software described, freely downloadable from the site, has to be considered a free “demo” and therefore the author Emilio P.G. Ficara will not provide any support nor will be responsible for any problem, damage, or consequence that may occur during download or execution of the application.

By clicking this link to download the file, you implicitly declare that you have read and understood the non-assumption clause and to accept it.

Always check the MD5 checksum for the files you download! In this case, it must be FC211B2DCBF05C7874489AC32C7D9641 . If it is different, the file is corrupted or is not the original one, so do not unpack it and throw it away! If it is all right, you can unzip it (use the 7Z program with the password: eficara).

You can also run the executable on a USB memory stick as it does not need installation, being a pure executable.

Have fun !!!

Problemi (risolti) su FW AT con GPIO per moduli ESP8266

Nell’articolo precedente ho descritto un utilizzo inusuale per i soliti modulini ESP8266. Per poter utilizzare il comando AT+CWLAPOPT (quello che consente di utilizzare delle opzioni quando si chiede la lista degli Access Points) ho dovuto aggiornare il firmware del modulino ESP-01 che ho utilizzato. Tutto ok. Poi, per√≤, ho tentato di aggiornare il modulino con la versione firmware contenuta nel file ESP8266_NONOS_SDK-2.1.0.zip (il FW AT che consente di utilizzare il GPIO del modulo) ed ho trovato delle difficolt√†. Una volta programmato con tale versione, il modulino si resettava di continuo. Dopo un po’ di indagini e prove con vari file di boot presi da versioni precedenti (boot 1.2 ; boot 1.6; boot 1.7 e altri), mi sono un po’ stufato ed ho preso con un editor esadecimale la zona di memoria dedicata al boot (a partire dall’indirizzo 0x00000) da un firmware sicuramente funzionante (una versione vecchia, distribuita con un file .bin unico) e da quella ho ricavato un nuovo file boot.bin “tutto mio” o quasi ūüôā Usando questo “frankenstein” ho finalmente programmato con successo l’ultima release del firmware. Ora i comandi relativi al GPIO vengono accettati ed eseguiti.

Ho deciso di pubblicare qui il piccolo file myboot.zip per coloro i quali si trovassero ad affrontare lo stesso problema.

Tengo a precisare che si tratta di una soluzione “per hobbisti” ! Non mi assumo responsabilit√† per malfunzionamenti o difetti ! Si tratta di un esperimento e come tale va trattato !

Nota: il file myboot.bin è zippato con password. Usate il programma 7Z con la password eficara per estrarlo.

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 con il programma 7Z 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 !

AT-commands tool

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 (vedi sotto) 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 con il programma 7Z 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 (vedi sotto). 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 !

Aggiornamento – 15 Ott 2017
– modificato controllo numero porta seriale
– aggiunto editBox multilinea con relativo pulsante send per comporre messaggi lunghi
Aggiornamento – 23 Lug 2016
– modificato il segnalatore di 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 ATool-3.zip è disponibile a questo link.
Il checksum MD5 è: ABC804479C35C15CCB4D68320E6E9E41

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 zip con il programma 7Z 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), 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.

Interfacciare il modulo ESP-01 con una porta USB

Ho di recente realizzato un progetto basato sul dispositivo ESP8266. Quando ho cominciato a lavorare sul dispositivo, ho acquistato un modulino ESP-01 su un “noto negozio on-line” e poi, per fare le prime prove, ho pensato di collegare il modulino ad una porta USB del notebook, in modo da scrivere qualche programma di test. Ho quindi realizzato questo circuitino di prova:

Il circuito montato

Il circuito montato

Questo circuito √® costituito da tre blocchi, due dei quali sono l’interfaccia USB-TTL e l’ESP-01, mentre il terzo elemento √® autocostruito. Ecco i tre blocchi:

I tre moduli del circuito

I tre moduli del circuito

A sinistra vediamo il circuitino autocostruito, al centro l’interfaccia USB-TTL e a destra il modulo WiFi ESP8266. Il circuito autocostruito √® montato molto “alla svelta” come si evince dalle foto (fronte e retro):

il circuito autocostruito, fronte e retro

il circuito autocostruito, fronte e retro

Lo schema del circuito è questo (disegnato a mano, spero sia comprensibile) :

Schema elettrico del circuito e del collegamento dei moduli

Schema elettrico del circuito e del collegamento dei moduli

Nota: nel mio prototipo non c’√® pi√Ļ spazio nemmeno per uno spillo, ma se ve ne costruite uno un po’ meno “compatto”, aggiungete una resistenza da 1K in serie al pulsante di reset dal lato Gnd, cos√¨ pure sul jumper “re-flash”, sempre verso Gnd. Questo servir√† a proteggere i segnali di I/O qualora nel modulo ESP-01 sia stata caricata una versione di firmware diversa da quella “base”, magari con i pin GPIO16 o GPIO0 non impostati come ingressi.

Sul modulo USB-TTL che ho usato io, ci sono solo 4 pin, che sono Vout, Txd, Rxd e Gnd, ma ci sono altri moduli che hanno pi√Ļ collegamenti. Quelli che servono, sono Gnd, Txd, Rxd e un quarto pin che porta la V_Usb, cio√® il 5V preso dalla porta USB. Sul mio modulo c’√® un jumper per scegliere se portare sul pin di uscita la tensione di 5V dalla presa USB oppure la 3.3V ricavata da un regolatore interno del chip. La tensione di 3.3V andrebbe bene, ma la corrente fornita dal regolatore interno √® insufficiente, cos√¨ useremo la 5V e creeremo la 3.3V con un regolatore LM1117-3.3, che √® in grado di fornire al modulo ESP-01 i 3.3V e la corrente necessaria per funzionare. Il ponticello chiamato: “re-flash jumper” serve per fare l’update / upgrade del firmware contenuto nel modulo ESP-01, mentre il pulsante di reset serve… a resettare il modulo WiFi.