Esperimenti con W5500

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

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

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

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

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

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

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

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

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

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

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

… continua …

Multimetro connesso in MQTT

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

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

Parte prima: l’alimentatore

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

Alimentatore 3.3V con batteria Li-Ion di backup

Alimentatore 3.3V con batteria Li-Ion di backup

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

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

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

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

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

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

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

Parte seconda: il microcontrollore

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

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

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

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

Parte terza: mettere tutto insieme

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

I tre blocchi del circuito connessi tra loro

I tre blocchi del circuito con le necessarie connessioni

E questa è la realizzazione pratica:

Il circuito completo montato su una scheda per prototipi

Il circuito completo montato su una scheda per prototipi

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

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

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

Di seguito, come appare il circuito costruito e collegato:

Il circuito costruito e collegato al connettore ICSP

Il circuito costruito e collegato al connettore ICSP

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

serialspy-schE questa è la realizzazione pratica :

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

Il software e il firmware

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

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

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

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

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

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

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

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

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

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

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

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

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

Flusso di programma

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

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

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

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

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

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

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

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

RAS-WiFi e MasterICS

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

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

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

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

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

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

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

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

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

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

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

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

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

Un altro telecomando TV per smartphone Android

Sì, l’ho fatto ancora. In un mio precedente articolo descrivevo come costruire una interfaccia da collegare al telefonino per poterlo usare come telecomando per il TV. L’applicazione Android permetteva, in quel caso, di controllare un TV di modello Sony Bravia, che utilizza un protocollo a infrarossi di tipo NEC. Ora non ho più quel televisore ed ho un piccolo Telefunken, che però usa un protocollo a infrarossi di tipo RC5, che è completamente diverso. Allora ho scritto una nuova applicazione, mantenendo sempre la stessa interfaccia hardware. E’ da notare che la distanza di funzionamento di questa versione è inferiore alla precedente. Purtroppo, la frequenza generata col sistema descritto nella pagina citata a inizio articolo è sempre di 38.4 KHz che è molto vicina ai 38 KHz “standard” del protocollo NEC, ma purtroppo è un po’ distante dai 36 KHz canonici del protocollo Philips RC5. Comunque, funziona lo stesso, dato che il notch filter del ricevitore non è proprio così stretto in frequenza, ma ha una “campana” ampia a sufficienza per tollerare questo errore in frequenza… Per la corretta temporizzazione delle fasi di “pieno / vuoto” ho utilizzato i pattern che derivano da 11 bytes di valore 0x5B per il “pieno” (burst di frequenza) e 11 bytes di valore 0x00 per il “vuoto” (pausa). Durante la trasmissione di 11 bytes di valore 0x00 si avranno comunque dei “glitches” di 8.68 uS attivi alti, perché questi sono gli “stop bits” della trasmissione che non posso eliminare. Per fortuna, i circuiti di ricezione presenti nei TV hanno una funzione di “filtro” che elimina questi disturbi. I filtri sono indispensabili perché alcuni tipi di illuminazione domestica (specie i tubi al neon) emettono disturbi nello spettro dell’infrarosso con una potenza notevole (provare per credere). Senza una “ripulita” del segnale, i telecomandi sarebbero poco efficienti. Comunque, i prossimi controlli remoti per TV saranno via radio, con i soliti 2.4GHz che ci stanno rendendo le case simili a forni a microonde… 🙂

Perché il tutto funzioni, è necessario che la versione Android sia in grado di gestire le periferiche USB, naturalmente. Nella figura sottostante potete vedere lo screenshot del programma in funzione.

Il programma in funzione: iRemUSB-RC5

Il programma in funzione: iRemUSB-RC5

La App iRemUSB-RC5.apk è scaricabile gratuitamente dalla mia pagina di Google Play.

Switch relays On/Off with WhatsApp messages

I recently installed the famous messaging application “WhatsApp” on my smartphone. After a while, I decided to create a device that can remotely switch two relays On or Off using messages sent through WhatsApp. Obviously, you must have two active accounts (and two smartphones) for remotely control the relays. In this description we call them the transmitter and the receiver. This device needs for a specific circuit (the relays board) and for a special Android application that works together with WhatsApp on receiver smartphone. Let’s start with the description of the circuit (the hardware), then the Android application (the software) will follow.

The hardware

The hardware is based on PIC12F635 microcontroller from Microchip. It’s a small 8 pin device. In the picture you can see the prototype, realized on a 50x70mm proto board. The smd micro has been placed on small adapter (the red one on the left).

The working prototype

The working prototype

The schematic is relatively simple. We have the micro, a DTMF tone decoder (MT8870), a couple of relays and a switching regulator from 12V to 5V. That’s all.

Schematic diagram; click to enlarge

Schematic diagram; click to enlarge

If you want a more readable copy, download the PDF file at this link. Please note the switching regulator module KIS-3R33S. I purchased a lot of (used) modules on ebay, at very low price. The problem is that the module is rated for 3.3V -3A max output, but I need for 5V out, so I modified the module removing a couple of components: one zener diode and one 51K resistor. It’s a very simple operation, please look at the picture:

The switchin regulator and the parts that must be removed.

The switching regulator and the parts that must be removed. (click to enlarge)

This switching regulator is needed only if you want to have an USB output that can recharge the smartphone that you use as receiver. In other cases, you can simply use a 5V linear regulator capable of 100-200 mA output current. A reduced (easy) schematic will be like this: (please, note that also ICSP section has been removed, that means you must program the micro off-board).

A reduced (easy) version of the schematic (click to enlarge)

A reduced (easy) version of the schematic (click to enlarge)

A pdf version of this schematic can be downloaded at this link.

The circuit detects a sequence of four DTMF tones. The first three tones are “the activation key” and are fixed to ‘1’, ‘3’, ‘7’, while the fourth tone is “the command” and can have the values: ‘2’ for R1-ON R2-OFF, ‘5’ for R1-OFF R2-ON, ‘6’ for R1-ON R2-ON and finally ‘8’ for R1-OFF R2-OFF. Once built up, the circuit can be tested with every device capable of playing MP3 files. The test files 1372.mp3, 1375.mp3,1376.mp3 and 1378.mp3 can be downloaded as a zip file from this link. Connect a stereo jack from the circuit to the player and play one at a time the 4 files. The relays will follow the combination presented as DTMF tones.

To make hardware work, you must program the PIC micro with the .hex file that can be downloaded from this link (updated version:150409 – changed red LED behaviour and implemented timeout after valid key received). The Configuration Bits for the PIC12F635 in this application is shown here:

The configuration word for PIC12F635

The configuration word for PIC12F635 (click to enlarge)

Using the ICD2 programmer under MPLAB, you can receive a warning like this:

ICD2 warning (click to enlarge)

ICD2 warning (click to enlarge)

On my prototype the device is correctly programmed if you click the “OK” button.

The software

The WhatsApp (I will use WA abbreviation from now on) protocol is proprietary and I don’t want to hack the received text messages; so… how to decode a command for relays activation ? I have seen on my smartphone there is a folder named WhatsApp/Media/WhatsApp Images. When you receive an image as attachment to a message sent via WA, a copy of that image is saved on this folder. So, my way to control the relays is simply to poll that directory to see if a new IMG file is present, then I load that file in an imagebox of my Android App and analyze the contents in order to decode the relays command; after that the image is renamed (next polling doesn’t find it again). This way to operate is non-intrusive and co-operative with WA application.

The transmitter doesn’t need any additional application; you just need to store the command images on a folder that’s visible for WA when you try to send an image as attachment ( I use the Downloads folder on main storage). The commands are four (all the combinations of two relays) and are small and simple images:

The images that will be used as attachments for sending commands

The images that will be used as attachments for sending commands

The lower part is for the user (human readable), while the upper part will be read by the Android application. Note that the left two bits are the complement of the right two, this is just to have a validity check while analyzing the image. You can download all the files zipped at this link. Finally, when you want to activate a relay on the receiver, simply send from transmitter a WA empty message with one of the previous command images as attachment.

The receiver is a little bit more complicated. You must download, first of all, a special ringtone, that is the “key” to assign the receiver to a specific transmitter. After downloading the ringtone from this link (right button mouse click to download the ringtone if your browser tries to play it directly), you must store the audio file on the receiver smartphone, in a folder that makes it visible under the phone’s ringtones. On my old A5000 smartphone (Android Version 2.2.1) I created a folder on the main storage (/sdcard/) named Media/audio/ringtones, and inside that folder I stored the new ringtone named 137.ogg; after this operation and after rebooting, the file appeared in the list of ringtones. When this new ringtone is in the list, you must assign it to the specific contact (or contacts) in your phonebook that is (are) authorized to play with relays; then you must set WA preferences to play the notification tone using the contact’s ringtone. To test this settings, send a WA message from transmitter to receiver and hear if the played notification tone is the one just assigned. After this, send a WA message from another phone (not authorized) to the receiver and verify that the notification tone is different (or absent).

Now it’s time to load and install the WhatRelay application from my page on Google Play Store. Once installed, at first run, the program asks for the working directory of WA. On my devices (both of them) this folder is on the main storage (/sdcard/) with this path: WhatsApp/Media/WhatsApp Images/ (take care of capital letters and last slash). Insert this path and accept. Please, note that all files IMG-xxxx.jpg already present on such folder will be renamed by the application in .IMG-xxxx.jpg (hidden), one every 5 + 2 seconds. If you want to preserve such files from renaming, move them to a new folder. In any case, every IMG-xxxx.jpg file present will be loaded and analyzed by the program, then renamed in .IMG-xxxx.jpg, so remove all such files before starting the App, or you will see them appear in the imagebox, be analyzed, then renamed at 5 + 2 seconds steps. The application sets the phone to stay always ON. Click the “quit” button to exit the application and restore the normal auto-turn-off time.

First run of WhatRelay App

First run of WhatRelay App

When the default path is set, the application starts, polling every 5 seconds the working directory to look if any IMG-xxxx.jpg file has been received. In the picture below, there is a screenshot of what happens when an IMG file is found. The image is copied in the small box at the right and after 2 seconds the program analyzes the picture to attribute a code. If the code is valid, a DTMF tone is played. In any case (valid image or not) the IMG-xxxx.jpg file will be renamed in .IMG-xxxx.jpg.

Program running: one IMG file has been received

Program running: one IMG file has been received

So, when WA receives a message, plays the notification tone that is the 137.ogg audio file, containing three DTMF tones that are the “key” to enable the circuit, then the WhatRelay App detects a new image, decodes it and plays the fourth DTMF tone (after less than 15 seconds) and the electronic circuits has received the key and the command, so can switch the relays. Job done.

Please, note that this is a release 0.1. This release will be revised many times. Look at this page or on Google Play Store to see if there is something new (and better). A special note regarding the volumes: remember that the circuit connects to the smartphone headphone plug, so put the volumes around 2/3 of the maximum and remove any notification that isn’t needed for the relays control. Do some tests without connecting the circuit, just to hear if all the tones are played with a good audio level. Use the local command buttons for other tests or for manual control of relays.

Circuito di test per display LCD basato su controller NEC µPD7225G

Questo articolo è stato già pubblicato sul mio vecchio sito, che ora non esiste più. Ho notato che ci sono diversi link su Internet che puntano a quel vecchio documento, così ho deciso di metterlo nuovamente on-line sul mio blog. Eccolo di seguito:

Circuitino di test per accendere un display LCD basato sul controller NEC µPD7225G.

Il prototipo montato e funzionante

Il prototipo montato e funzionante

Il microcontrollore utilizzato è un ATmega48 in package DIP.
Lo schema è visibile nella figura sottostante (cliccare l’immagine per una visione ingrandita):

sch131Ho disegnato anche un piccolo circuito stampato per usi generali (vedi sotto) :

cs131comp131Per una stampa precisa, utilizzare il file nel formato PDF che si trova nello zip scaricabile.

Il display utilizzato per il test ha 12 caratteri da 7 segmenti più numerosi segnalatori.
I segmenti sono mappati secondo la tabella sottostante:

disp131mapIl file sorgente in C contiene le routines di gestione del controller e un piccolo programma di prova che accende, uno alla volta, tutti i segmenti del display.
Per chi non ha il compilatore, c’è anche il file HEX già pronto per essere scaricato nel micro.

Il file ef131.zip contiene:

  • cs131.pdf – il disegno del master in PDF stampabile in scala 1:1
  • main.c – il file sorgente in C del programma di test
  • upd7225.hex – il file compilato pronto per essere trasferito sul micro

Activate relays with your smartphone (no BT or WiFi, just sounds)

Old smartphones (Pocket PC, Windows Mobile 5 and 6) can be purchased at very low price, and even if old, are really powerful. In addition, you can write and distribute your own applications / games for free, being not in the slavery of “App Markets” of any sort.

In 2009 summer (August and September), I was in France for a “sabbatic” time. I was in city of Albi, relatively far from the sea and the “usual” way to spend summer time (swimming or walking or looking for funny alternatives). France is fantastic for restaurants, aperitives and wine, so that period was very creative for me. The best “fuel” for brain are good food and wines ; if you add that I was are completely alone and without any job duty, you can understand that such condition was very near to the perfection.
Obviously, a minimal “worklab” was part of my baggage: just few things… a solder iron, soldering wire, some indispensable electronic components, a small netbook PC and my smartphone (Samsung SGH-i600). Note that the smartphones like Android and iPhone wasn’t available in that period and the Windows Mobile (5 or 6) was the “modern” OS (surely less intrusive in your privacy than the ones you’re running today). Some time before this journey, I purchased a software tool called PPL (as alternative to Embedded Visual C) and downloaded a free IDE called FBA Creator (you can find a reference to this software gem under my favourite links). I started to realize applications for WM5 / WM6 in the quiet afternoons time, a little step every day. One of the interesting things produced in this learning time, was a program to turn ON/OFF relays using simply DTMF tones played by the phone (under keyboard control). The main idea was to put the phone on a simple “rover” and then write a small webserver to receive commands by any browser, and produce DTMF tones (related to HTTP GET commands) to activate relays, so left and right motors could move the rover and photos taken after every move could be sent via the Internet to my netbook PC. I realized a video that was posted, initially, on youtube. After monster G (Google) acquired youtube, I decided to remove all my videos, ‘cause I was negatively impressed by the growing power of that company, with all the new terms of use of their services ; shorting it, I removed my pages on google space and the videos from youtube. Recently I reloaded some videos on DailyMotion (hoping that this will not be eaten by monster G). If you want take a look at this video, click the player below here and sorry for my horrible english pronuntiation and also for my tragic english writing (NO google translator help, here).


dtmf_remote di robotop

Now, here is the electric diagram of this device. There are 3 relays, the microcontroller (ATMEL ATtiny2313) , one serial interface for  PC connection and analog circuitry to get sounds (thru microphone) and convert them to digital data, by means of specialized decoder IC.

click to enlarge ; PDF copy is included in the downloadable zip

click to enlarge ; PDF copy is included in the downloadable zip

Using this circuit, you can activate / deactivate 3 relays with the DTMF tones emitted by your smartphone / PocketPC. In the downloadable file ef161.zip you can find:
– schematic.pdf , the electric diagram
– dtmf.hex , the Intel-Hex formatted file to burn the micro
– fuses.txt , the fuses configuration used for microcontroller in this application

If you want to take a look at the C source file, click this link
Someone asked me how to indepently control two motors (running CW and CCW) with 3 relays, so here is a state table:

ABC | motor status (0=relay off,as shown in figure; 1=relay ON)
--- | ---------------------------------------------------------
000 | M1 & M2 stop
001 | M1 stop, M2 run clockwise
010 | M1 run clockwise, M2 stop
011 | M1 & M2 run clockwise
100 | M1 & M2 run counterclockwise
101 | M1 run counterclockwise, M2 stop
110 | M1 stop, M2 run counterclockwise
111 | M1 & M2 stop

and a MAD (manually assisted design) schematic…

twomotorsYou can generate DTMF tones directly with your phone keyboard (setting DTMF as default sound for keys) or can use my own program dtmfremote_cab.zip. This one is supplied as CAB compressed in ZIP with a password. Such strange arrangment comes from limitations of the hoster to uploading of executable files. When you download the file, you have to unzip it (the password is: eficara) and then you have the dtmfremote.cab that can be directly installed on your WM5 or WM6 device. Note that my Samsung WM6 phone has a full qwerty keyboard, but not a touch screen, so all the commands are activated using the cursor keys and the OK button. You can also activate a sequence of pre-recorded commands ; such sequence has to be stored in a file called sequence.txt , that must reside on the same working directory of the executable. You can create / edit such file with the default Notepad. On every text row there are two numbers, comma separated (no spaces, please). First number is the bitmap of the 3 relays, so can be a number from 0 to 7 ; a number greater than 7 indicates the end of the sequence (it will loop again from the first row). The second number is the time to wait after setting the relays, prior to jump to next sequence step. This number is expressed in mS (milliSeconds) and can range from 100 to 9999. Lower numbers can’t work, ‘cause the DTMF tone needs for a minimal time to be correctly decoded by hardware.
I also wrote another program to play DTMF, using the free tool FBA Creator ; this application is called fba_dtmf_cab.zip (as usual, is a zipped CAB with password ; you must unzip it using password eficara and have your fba_dtmf.cab ready to be installed on WM5 or WM6 device). The only difference with the previous program (written in PPL) is that the sequence player isn’t included, but the whole working directory, with sources (LUA language) can be downloaded and modified with the FBA tool. IMPORTANT NOTE: if you download and install “FBA the Creator” on Win7 or newer, please create a shortcut to the executable and set this shortcut to be executed by default as administrator. If you don’t do that and launch the executable without administrator rights, you can experience a recursive pop-up error window, that’s very hard to stop. This is just a little problem in a big, genial software, written by an italian author some years ago (in the times of WinXP). Note that all the IDE sources for FBA are also downloadable from the main site. If you look in the forum, you can find some old post by user robotop ; it’s me…

Here is a short presentation video for the FBA IDE I made some time ago for my friends. It’s in Italian, but may be useful just to take a look at the working environment and how it’s easy and powerful (and free…)


FBA-Video_2011-11-23 di robotop

Finally, here is the full working folder (sources and resources) of the DTMF program written under the FBA environment. After downloading the file FBA_folder_dtmf-remote.zip, you must expand it in a directory ; I suggest a new folder under documents, named FBA with subfolders for this and (may be) your future apps. At this point, if you have the FBA environment installed on your PC, just click the file dtmfrem.fbp to start the IDE and… happy mobile phone programming 🙂

View a short video of this application running in the IDE default emulator…


dtmfrem di robotop

Clock with binary display / Orologio con display in binario

Binary Clock, built with Microchip PIC16F676 (or PIC16F630).
The hours are displayed with 4 LEDs which are (from left to right) 8,4,2,1; so hours are shown from 1 to 12 (no am and pm).
The minutes are displayed with 5 LEDs that are (from left to right) 40,20,10,5,0; in practice, they show in 5 to 5 way and the exact hour (minute 00) turns ON led 0, because I don’t like to have the minutes row completely OFF.
For viewing the time, press shortly the button. Hours and minutes are shown for 3 seconds, then the LEDs are off.
To adjust the time, press and hold down the button until the top row only turns ON and leds begin a binary counting from 1 to 12.
When you reach the desired time, release the button. After a time of 5 seconds, the display automatically shows the minutes and pressing the button, they advance with the binary counting (5 min steps). When you reach the desired minutes, release the button.
Again, after a time of 5 seconds both the led rows turns ON to show hours and minutes (the seconds are cleared automatically), and everything is shut down. The time has been set. The file binwatch.zip contains the wiring diagram in PDF format and the object file (Hex) to program the micro.

The C source was compiled with CC5X Version 3.2I, Copyright (c) B Knudsen Data,Norway 1992-2005 (free edition). If you want to take a look at C source code, click this link.

The prototype: back and front views

This is the PCB diagram (just small image, but a link to PDF 1:1 scale is provided)

For a full size 1:1 PDF, click this link

Note that the circuit uses conductive vias.

Orologio con display binario, realizzato con Microchip PIC16F676 (oppure PIC16F630).
Le ore vengono visualizzate con 4 led che valgono (da sinistra a destra) 8,4,2,1; vengono mostrate quindi le ore da 1 a 12 (niente am e pm). I minuti sono visualizzati con 5 led che valgono (da sinistra a destra) 40,20,10,5,0 . In pratica i minuti vengono mostrati di 5 in 5 e lo scoccare dell’ora (minuti 00) fa accendere il solo led 0, questo perché mi sembra brutto lasciare del tutto spenta la riga dei minuti. Per ottenere la visualizzazione dell’orario, si preme brevemente il pulsantino. Le cifre vengono mostrate per 3 secondi, quindi i led vengono spenti. Per regolare l’ora si tiene premuto a lungo il pulsante fino a quando si accende solo la riga superiore (ore) e i led cominciano un conteggio binario da 1 a 12. Quando si raggiunge l’ora desiderata, si lascia il pulsante.
Trascorso un tempo di 5 secondi, il display mostra automaticamente i minuti e premendo nuovamente il pulsante, questi avanzano con il conteggio binario (si regola, quindi di 5 min in 5 min). Quando si raggiunge il minuto desiderato, lasciare il pulsante. Dopo un tempo di 5 secondi i led si accendono a mostrare ore e minuti (i secondi vengono azzerati automaticamente) e infine tutto si spegne. L’orario è stato regolato.
Il file binwatch.zip contiene lo schema elettrico ed il file oggetto .hex per programmare il micro.

Il codice sorgente in C è stato compilato con CC5X Version 3.2I, Copyright (c) B Knudsen Data,Norway 1992-2005 (free edition). Se desiderate dare un’occhiata al codice sorgente in C dell’applicazione, cliccate questo link.

binwatch_sch

schematic diagram ; click the image to enlarge. A PDF version is included in the downloadable ZIP file

 

Roman numerals clock : orologio LCD con numeri romani

Questo circuito che vi propongo, basato su micro ATtiny2313, realizza un orologio LCD con numeri romani.

Il prototipo del circuito, realizzato su una scheda millefori.

Il prototipo del circuito, realizzato su una scheda millefori (segna le 17:20)

Alla prima accensione mostra una schermata lampeggiante con la scritta “Tempera tempus” per ricordare che si deve effettuare la regolazione.

Le fasi della regolazione dell'ora

Il display in fase di richiesta regolazione (prima riga) e nelle fasi di visualizzazione (ultime due righe). La scritta “et” lampeggia con cadenza 1 secondo.

La regolazione si effettua mediante questa procedura :

1) Premere e tenere premuto il pulsante per circa 3 secondi ; sullo schermo appaiono le ore ; rilasciare il pulsante.
2) Premere nuovamente il pulsante e tenerlo premuto ; le ore avanzano da “I” a “XXIV” ; rilasciare il pulsante sull’ora giusta.
3) Attendere circa 3 secondi ; sullo schermo appaiono i minuti.
4) Premere nuovamente il pulsante e tenerlo premuto ; i minuti avanzeranno da “nulla” a “LIX” ; rilasciare il pulsante sui minuti giusti.

Non essendoci una batteria, l’orologio non mantiene l’ora se va via la corrente. Ogni volta che si stacca l’alimentazione, alla riaccensione verrà visualizzato il messaggio che ricorda di effettuare la regolazione. Nella figura sottostante potete vedere lo schema elettrico. Per una visione più dettagliata, scaricate il PDF dal link indicato nella didascalia.

il file PDF può essere scaricato da questo link

Cliccare l’immagine per ingrandirla ; il file PDF può essere scaricato da questo link

Il display LCD che ho utilizzato, purtroppo, necessita di una tensione negativa su Vo per ottenere il massimo contrasto. Ho usato un pin del micro per generare un’onda quadra e il circuito in basso a sinistra nello schema (transistor, condensatori e diodi) per ottenere tale tensione. In caso di display LCD “normali”, cioè in grado di funzionare bene anche con sole tensioni positive, tale circuito diventa inutile e può essere eliminato.

Nel file ef162.zip scaricabile a questo link sono contenuti :
– schematic.pdf , lo schema elettrico del circuito
– roman.hex , il file HEX per la programmazione del micro
– fuses.txt , il file di testo con la configurazione dei fusibili del micro per questa applicazione.

Se desiderate dare un’occhiata al codice sorgente in C dell’applicazione, cliccate questo link.

RxMet1 – ricevitore per sensore esterno Hygro-Thermo a 433 MHz

Questo circuito permette di ricevere i dati trasmessi da un sensore Oregon Scientific modello THGR228NF (visibile nella figura sottostante) in radiofrequenza a 433 MHz.

sensor-THGR228NFIl circuito è stato pubblicato (a mio nome) sulla rivista CQ Elettronica nel numero di Settembre 2007 (consultare la rivista per maggiori dettagli).

Il microcontrollore utilizzato è un Atmel ATtiny2313 ; lo schema è visibile qui sotto:

Per una visione nitida, scaricare il PDF da questo link

Cliccare l’immagine per ingrandirla ; il file PDF può essere scaricato da questo link

Nella prossima immagine si può vedere il prototipo del circuito con i componenti montati :

rxmeteoIl circuito stampato è visibile nell’immagine qui sotto ; ovviamente, per realizzare un circuito mediante fotoincisione, bisogna stampare l’immagine in scala 1:1 e pertanto è opportuno scaricare il file PDF raggiungibile tramite il link nella didascalia dell’immagine.

stampato

Il file PDF in scala 1:1 può essere scaricato da questo link

Infine, nella prossima immagine si può vedere la disposizione dei componenti sul circuito.

montaggio

Il file contenente l’elenco dei materiali, il codice HEX da scrivere sul micro ed i batch files per settare il clock esterno e per effettuare la programmazione dell’ATtiny2313 (tramite il programma freeware SP12), può essere scaricato da questo link. Se desiderate dare un’occhiata al codice sorgente in C dell’applicazione, cliccate questo link.

I dati in uscita dal circuito sono “grezzi”, cioè rappresentano in Ascii l’insieme di bits ricevuti dal sensore, raggruppati in notazione esadecimale. Nella figura sottostante, i dati ricevuti dal sensore sono mostrati nel riquadro a sfondo verde (quello in alto, per i daltonici..) mentre la “traduzione” in temperatura e umidità sono nel riquadro a sfondo blu (quello in basso).

Screenshot del programma su PC per la visualizzazione dei dati

Screenshot del programma su PC per la visualizzazione dei dati

Ho realizzato il programma in VB6 ; chi fosse interessato può scaricare il file d’installazione da questo link. Ricordo che il programma è offerto gratuitamente a scopo di test e non ha alcuna clausola di garanzia e nessuna assunzione di responsabilità da parte mia per eventuali danni o malfunzionamenti.

Il “cuore” di questo programma è una DLL (libreria) scritta da me per decodificare il protocollo di trasmissione del sensore. Chi volesse scrivere un proprio programma per visualizzare i dati forniti dal sensore, potrà usare liberamente tale DLL scaricandola da questo link e inserendola nel proprio programma. Di seguito, un esempio di come utilizzare la DLL in un programma VB6 per decodificare la stringa di dati “grezzi” ricevuti dal sensore in valori leggibili di temperatura e umidità:

// declare the convert function
Private Declare Function RawConvert Lib "meteo.dll" (ByVal text As String) As String

// use the function
//  rxraw contains the full ascii string received from RxMet1
//  rxd contains the decoded Temperature and Hygro
dim rxd as string
dim rxraw as string

    rxd = RawConvert(rxraw)

Nota: questo materiale fu già pubblicato su un mio vecchio sito (ora cancellato) e venne citato da “Hack-a-day” nel settembre del 2007.