I moduli
Nello schema più sotto potete vedere i moduli che ho acquitato che più precisamente si chiamano E32-TTL-100 (433T20DC). Sono quelli a 433MHz basati su chip SX1278 e come vedete a parte il chip che occupa gran parte del modulo, le uniche altre due cose importanti sono il connettore per l’antenna (SMA-K) ed una serie di pin per il controllo del modulo stesso. Vediamo qui sotto uno schema del modulo stesso:
Vediamo il significato dei vari pin:
| Pin | Nome | Utilizzo |
| 1 | M0 | Stato del dispositivo |
| 2 | M1 | Stato del dispositivo |
| 3 | RXD | Ricezione, da collegare al TX di Arduino |
| 4 | TXD | Trasmissione |
| 5 | AUX | Stato di funzionamento del modulo. |
| 6 | VCC | Alimentazione, sia 3.3 che 5V (2.3 – 5.2V) anche se poi nelle note finali è riportato” Please check the power supply source, ensure it is 2.0V~3.6V, voltage higher than 3.6V will damage the module”, che significa “Occhio che sopra i 3.6V il modulo si danneggia”. |
| 7 | GND | Collegare a terra |
Piccola nota sull’alimentazione: quanto vi ho riportato su VCC dipende dal fatto che ci sono differenti modelli con differenti possibili valori di alimentazione per cui dovete fare molta attenzione all’esatto modello che acquitate anche perchè la documentazione non è scritta in maniera impeccabile e in diversi documenti troverete diverse indicazioni, cosa probabilmente legata al fatto che nel tempo si sono aggiunti diversi prodotti e la documentazione non è stata correttamente aggiornata. Il modulo a mia disposizione comunque è un modulo a 3.3V (comunque ho provato ad alimentarlo a 5V per un breve periodo ed è ancora vivo).
Collegamento
Collegare il modulo è molto semplice. Una volta connessi alimentazione (3.3V) ed i pin M0, M1, AUX ed i due pin della UART (porta seriale), siamo già pronti per caricare il nostro sketch di prova. No, non è vero, non è per nulla così scontato e se ve la devo dire tutta ho impiegato diversi giorni prima di ottenere delle risposte dal modulo.
La documentazione ufficiale che vi riporto qui sopra, aggiunge due piccole note, la seconda dice, “per alcune MCU che operano a 5V, potrebbe essere necessario aggiungere un resistore di pull-up di 4-10K per i pin TXD e AUX”. Ok, perfetto, io per le prove ho usato un Arduino DUE che opera a 3.3V per cui questa cosa non dovrebbe interessarmi, comunque sia con Arduino DUE il modulo funziona sia con che senza i resistori di pullup. Ma ulteriori cose che mi ha creato non poca confusione sono alcune diciture che trovate in alcuni datasheet, ad esempio talora anzichè “MCU a 5V” si parla più genericamente di “Arduino”, da altre parti troverete che il resistore può servire anche sul pin RX e per finire la prima volta che ho avuto una risposta dai moduli avevo i resistori montati sulla breadboard facendomi credere che erano necessari anche nel mio caso.
Come vi accennavo un secondo problema è stato il lato software. Purtoppo come spesso accade nei progretti open source come Arduino, il lato negativo è la proliferazione di librerie parallele con funzionalità in parte sovrapponibili, in parte no, che possono rendere ardua la selezione di quella più adatta al nostro scopo. In più gran parte delle librerie sono predisposte per i moduli SPI mentre non supportano i moduli UART come questo o non sono documentate a riguardo. Alla fine sono letteralmente impazzito perchè non ho trovato nulla che funzionasse e non capivo se si trattasse di un problema software, hardware o di entrambi. Alla fine ho cominciato a scrivere una mia libreria personalizzata per cercare di far funzionare questi moduli. La libreria chiaramente effettua per voi tutte le operazioni del caso, ma ci tenevo a sottolineare alcuni aspetti del funzionamento del modulo che ci possono far apprezzare alcune caratteristiche dello stesso.
Sopra dicevo che i pin M0 ed M1 permettono di selezionare la modalità di funzionamento del modulo:
| Modo | M0 | M1 | Spiegazione |
| Normale | 0 | 0 | UART e canale radio pronti per l’utilizzo |
| Wake-Up | 0 | 1 | Come sopra ma nel codice viene inviato del codice che permette di “risvegliare” il modulo ricevente. |
| Power Saving | 1 | 0 |
La UART è disabilitata ed il canale radio è in modalità WON (Wake On Radio) che potremmo tradurre con “risveglio via radio”. In questa modalità il modulo viene appunto risvegliato dalla trasmissione del modulo inviante. La trasmissione non è permessa. |
| Sleep | 1 | 1 | Il modulo non può né trasmettere, né ricevere. In questa modalità è possibile programmare il modulo. |
Il primo modo è quello “normale” e l’ultimo quello “programmazione”. Risultano invece più interessanti i due intermedi che permettono al modulo ricevente di porsi in uno stato di forte risparmio energetico, situazione decisamente interessante per le applicazioni a batteria, mentre sul modulo inviante viene attivata la modalità “WakeUp” che permette di “Risvegliare” il modulo ricevente quando gli vengono inviati i dati. Non approfondiremo ora questo aspetto ma volevo segnalarvelo già in questo primo articolo perchè è uno degli aspetti più importanti nella gestione di sensori remoti che funzionano a batterie.
Il pin AUX serve invece a stabilire lo stato di funzionamento del dispositivo, molto importante nella stesura del codice della libreria ma poco interessante per l’utilizzatore finale.
Configurazione
Come vi accennavo sopra ho avuto non pochi problemi a configurare correttamente il sistema. La stragrande maggioranza della documentazione online è scritta per moduli con interfaccia SPI, mentre per quelli UART la cosa è molto lacunosa. Come fattore confondente ho usato dei NodeMCU con i quali non ho ancora la stessa dimestichezza che ho con Arduino, per cui fra la diversa nomenclatura dei pin, porte seriali più o meno condivise con la porta USB, etc ho avuto diversi problemi. A completare il quadro, le librerie che ho inizialmente provato supportavano quasi tutte i moduli SPI mentre ho fatto non poca fatica a trovare qualcosa di funzionante per i moduli UART e tra quel che ho trovato c’erano errori ed imprecisioni un po’ ovunque. E quindi come sempre è andata a finire che la libreria me la sono scritta da me a partire dai pezzi di codice che ho trovato online e che ho profondamente modificato. Inoltre la documentazione originale purtroppo non risulta molto approfondita ed è divisa in diversi documenti il che crea ancor più confusione. Ad esempio non c’è scritto da nessuna parte che se via UART fate il reset del modulo quest’ultimo oltre ai parametri interni resetta anche la porta seriale con perdita della connessione e non a caso nessuna delle pseudo-librerie che ho trovato in rete prevede questo problema. Voi fate il reset e perdete la connessione UART con il modulo che smette di rispondere. Questo è solo un esempio ma tutti i fattori messi insieme hanno fatto si che ci mettessi una buona settimana per riuscire a creare un prototipo funzionante del sistema. Come intuibile l’indirizzo del modulo ed il canale di trasmissione sono fondamentali perchè i moduli interagiscano fra loro, a tal proposito il canale di comunicazione sarà il medesimo affinchè i moduli si “vedano”, inoltre utilizzeremo l’indirizzo 0x0000 che è un indirizzo di broadcast, ossia se il modulo trasmittente utilizza questo indirizzo, qualsiasi modulo nello stesso canale, ovviamente nel range di ricezione, vedrà la trasmissione in arrivo indipendentemente dall’indirizzo del modulo ricevente.
Alimentazione
Beh, ormai un po’ di esperienza con i moduli di trasmissiuone radio me la sono fatta ed una cosa che li accomuna tutti è legata alla stabilità dell’alimentazione. Tutti questi moduli in fase di trasmissione hanno dei picchi di assorbimento di corrente che possono mettere in crisi tutto il sistema con reset o malfunzionamenti casuali sia a carico del modulo che della mcu (MicroControllerUnit) che lo controlla. Normalmente perciò si utilizzano dei condensatori per supplire a questi picchi di assorbimento, ma in rete a questo punto troverete i consigli più disparati e resterete sempre con la domanda: “qual’è la soluzione adatta al mio caso?”. Il datasheet del modulo dice che l’assorbimento tipico in trasmissione è di 110mA, massimo di 120, ma specifica anche che risulta necessario prevedere un surplus del 30% per garantire un funzionamento stabile a lungo termine, quindi alla fine sono 156mA. Poi però combiate pagina ed il medesimo datasheet vi dice che la fonte di alimentazione deve poter erogare più di 250mA con un ripple massimo di 100mV. Beh diciamocelo, questo è uno dei datasheet più incongruenti che mi sia mai capitato di leggere, si trovano continuamente dati contrastanti per cui risulta difficile capire dove si trovi la verità.
Ora, non pensiate che io abbia la soluzione, ma posso fare delle misurazioni per cercare di capire come procedere nel modo più corretto. Per prima cosa provo il sistema con l’alimentatore da breadboard e vediamo cosa succede:
Bene ottimo, siamo leggermente sotto i 3.3V (linea trateggiata nera), ma l’alimentazione è perfettamente stabile anche durante le fasi di trasmissione. Ora proviamo con Arduino DUE. Il suo regolatore di tensione dovrebbe poter erogare 800mA, quindi più che sufficienti per il nostro scopo e non per niente il sistema funziona correttamente. Ma diamo un occhio più da vicino:
La scala è la medesima di prima, si vede che la tensione di base è pressochè identica a quella precedente, ma nel momento della trasmissione avviene un calo di tensione che si protrae per tutta la trasmissione mal quantificabile in quanto in numerose prove fatte ho registrato valori piuttosto differenti fra una prova e l’altra variabili da circa 150 a 350mV. Successivamente ho provato ad aggiungere dei condensatori da 100uF e da 470uF. Inizialmente mi pareva chiara la riduzione di questa variazione di tensione, ma poi a forza di fare prove mi sono convinto che non vi è nessuna reale evidenza di modificazioni positive sulla stabilità dell’alimentazione. Ho dei dubbi però sul fatto che la scarsa ripetibilità delle misure derivi almeno in parte dai contatti sulla breadboard che come sempre mi hanno dato un sacco di problemi. Infatti durante i miei test ho avuto la riprova pratica che i condensatori sevono. Inizialmente ho usato Arduino DUE come stazione inviante ed un NodeMCU come ricevente, quest’ultimo alimentato con una batteria 18650 ed un regolatore di tensione che mi sono portato in giro con la bicicletta. Un led blu mi indicava la ricezione dei pacchetti dati. Ebbene, la stazione ricevente ha cominciato a funzionare solamente dopo l’aggiunta di un condensatore da 470uF sulla linea di alimentazione, senza non ne voleva sapere.
E la distanza?
Si lo so sarà la prima domanda che vi siete posti. Ma a che distanza sei riuscito a far comunicare questi moduli? Io ho usato una configurazione che possa riprodurre un reale sistema per cui ho tenuto l’antenna trasmittente vicino al pc su cui lavoravo e sono andato in giro con la bici per testare la portata del segnale. Con l’antenna classica a “stilo” da 3dbi e velocità standard di 2.4k, ho raggiunto circa i 120 metri, oltrepassando da parte a parte tre case che sono interposte fra ricevente e trasmittente. Beh, non male se faccio un confronto con la portata del WiFi e dei moduli NRF24L01. Ma ho voluto andare oltre ed ho sostituito entrambe le antenne con altre da 5dbi, sempre a velocità standard. La differenza è notevole in quanto il segnale arriva a circa 450metri di distanza, quasi il quadruplo. E riducendo la velocità al minimo di 300bps? Ho raggiunto i 660 metri circa. Anche se non sono certo i 3Km sbandierati nel datasheet è comunque un ottimo risultato. Ho perciò voluto vedere fino a che punto potevo spremere questi moduli ma siccome era un po’ scomodo andarmente in giro con la bici controllando se il led blu si accendeva o meno, ho deciso di modificare un po’ il progetto. Ho traformato la stazione “sulla bici” da ricevente ad inviante, in questo modo posso valutare la reale possibilità di creare un sensore remoto alimentato a batteria che invia dati ad una stazione centrale. Inoltre ho aggiunto un modulo GPS così invio alla stazione ricevente le coordinate GPS del mio giro in bici così posso poi tracciare comodamente da casa uno schema con tutti i punti cui il segnale è arrivato correttamente a destinazione. Siccome il datasheet specifica che l’antenna dovrebbe stare a 2m da terra, ho deciso di mettere l’antenna della stazione ricevente a circa 3 metri d’altezza, su uno dei supporti del mio impianto fotovoltaico a parete. Com’è andata? Qui sotto potete vedere la mappa (cliccandoci sopra potete accedere a quella riginale online).
Le stelline azzurre sono il primo test effettuato e con mia sorpresa ho coperto tuto il tragitto fatto in bici con una distanza massima dal punto di ricezione di circa 1,2km. Notetere che ci sono degli spazi “vuoti”, ma sono dovuti alla vegetazione che impediva la ricezione del segnale GPS. C’è poi qualche saltuario “salto” che non so se essere dovuto a problemi di trasmissione, al GPS o banalmente al fatto che il prototipo su breadboard era poco affidabile. In rosso invece un secondo test che ho fatto per verificare la massima distanza raggiunibile che è stata di 1.6Km.
Conclusioni
Si lo so che siete impazienti di provare anche voi, ma la libreria non è ancora pronta. Devo ancora mettere un po’ a posto il codice e successivamente devo rispondere ad alcuni quesiti. Ad esempio cosa succede se invio dati da due moduli in contemporanea? Come posso sfruttare i diversi indirizzi attribuibili ai moduli per ottenere il massimo beneficio dalla rete LORA? E poi come li mando in rete? Beh, ovviamente la stazione ricevente dovrà anche essere in grado di inviare i dati in rete, e un protocollo ben sviluppato permetterà di decidere cosa realmente dovrà uscire in rete e cosa invece rimarrà in locale. Insomma, di lavoro ne ho ancora un po’, ma questa volta ho finalmente trovato la tecnologia giusta per il mio sistema domotico, un sistema che mi permette di coprire senza problemi tutta la casa, che dalle prime prove pare affidabile, che non necessita di router e quindi non mi lascia a piedi quando la rete non va. Ora applicherò questo modulo nel circuito che stavo sviluppando per il monitoraggio dell’impianto fotovoltaico.
PS: oggi niente video, vi mostrerò il tutto nelle prossime puntate.