Localizzatore GPS con SMS

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

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

La struttura hardware

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

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

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

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

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

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

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

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

La struttura del software

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

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

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

Costruzione ed utilizzo

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

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

1_wrFlash.bat per la programmazione della memoria Flash:

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

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

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

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

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

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

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

Il file che contiene il firmware del micro è localizer.hex, che contiene il codice compilato dall’indirizzo 0x0000 a 0x096F. Rimane quindi molto spazio per eventuali aggiornamenti e migliorie.

Una volta programmato il micro, si potrà accendere il dispositivo. Nello schema potete vedere un connettore di uscita denominato USB SERIAL. A che serve ? E’ uno strumento di debug. Dato che il modulo GPS occupa solo il pin di ingresso della UART del micro, ho pensato di usare quello di uscita come pin di debug. Su questo pin, infatti, viene inviata tutta una serie di messaggi di testo, con protocollo 9600,N,8,1. Quando il modulo GPS determina una nuova posizione valida, i dati “filtrati” vengono inviati sull’uscita di debug e così sono visibili su un terminale seriale connesso alla porta. Oltre a questo, anche le comunicazioni con il modulo GPS vengono replicate su questa porta, permettendo così di analizzare tutta la comunicazione tra il micro e i due moduli. E’ una “feature” molto importante e molto utile per capire cosa c’è che non va (se c’è qualcosa che non va).

Ora portiamo il circuito funzionante all’aperto e facciamo un giro per almeno 5 minuti, cercando di spostarci in modo da avere diverse localizzazioni in memoria. Se siamo pigri, mettiamo il circuito sul terrazzo e lasciamolo lì fermo… Dopo 5 o sei minuti, con uno dei telefoni il cui numero è abilitato in Eeprom, facciamo una chiamata al numero della SIM contenuta nel localizzatore. Facciamo fare uno o due squilli e poi chiudiamo. Il localizzatore invierà immediatamente uno SMS di risposta con i dati memorizzati (ci può essere un ritardo nella ricezione del messaggio se l’operatore è “intasato”). Riceveremo quindi un messaggio di questo tipo (ho pixellato alcune cifre per la privacy -la mia-) :

Vediamo in prima posizione la locazione attuale, l’ultima rilevata dal GPS al momento della chiamata. Nelle successive righe ci sono le ultime 5 posizioni memorizzate, in base ad un temporizzatore che agisce ogni 60 localizzazioni valide (record $GPGGA del protocollo NMEA).

Le coordinate ricevute dal modulo sono in formato ggxx.xxxxxN(S) per la latitudine e gggxx.xxxxxE(W) per la longitudine. Purtroppo, se proviamo ad inserire i dati esattamente così come li riceviamo su un programma tipo Maps, non otterremo risultati. Dobbiamo quindi fare un paio di semplici operazioni.

Supponiamo di avere ricevuto questo messaggio: 3804.373568N01538.944818E; le prime cifre (fino a N) sono la latitudine e le ultime (fino a E) sono la longitudine. Per convertire questo formato in uno accettabile per Maps, dobbiamo agire così: latitudine 3804.373568N dove 38 sono i gradi; ora dividiamo 04.373568 per 60 e otteniamo 0,0728928; in totale, la latitudine risultante sarà: 38.0728928. Ripetiamo la stessa operazione per la longitudine: 01538.944818E dove 015 sono i gradi; ora dividiamo 38.944818 per 60 e otteniamo  0,6490803; in totale, la longitudine è 15.6490803. Ora possiamo andare su Maps ed inserire nella barra di ricerca questi numeri: 38.0728928, 15.6490803 ed otterremo la mappa della località indicata. Notare, nel formato, che come separatore per i decimali viene usato il “punto”, mentre per dividere i due campi lat – lon viene usata la “virgola”. Per convenzione, la latitudine è indicata per prima e la longitudine per seconda. Nel nostro esempio abbiamo usato latitudine Nord (N) e longitudine Est (E). Se usiamo il programma in altre parti del mondo, potremmo ricevere dal GPS coordinate S (Sud) e W (West). In questi casi, dovremo inserire un segno “meno” prima della latitudine o della longitudine. In breve, N è “più” (si può omettere) ed S è “meno”, così come E è “più” e W è “meno”.

Infine, qui sotto, dopo la clausola di non assunzione di responsabilità, trovate il link al file Localizer-v1.zip liberamente scaricabile, che contiene la prima release del firmware. L’applicazione è stata provata in condizioni “normali” e funziona perfettamente, ma se scoprirò errori nascosti, farò le opportune correzioni e pubblicherò l’aggiornamento.

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

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

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

M590 – modulo GSM/GPRS – Esperimenti

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

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

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

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

block-diag-ss

Lo schema a blocchi dell’hardware di test

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

charger

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

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

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

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

Il kit montato; lato connettore sim

Il kit montato; lato connettore sim

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

Il kit montato; lato modulo M590

Il kit montato; lato modulo M590

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

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

Lo screenshot del programma in funzione

Lo screenshot del programma in funzione

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

SMS ricevuto !

SMS ricevuto !

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

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

Buona sperimentazione !