La tecnologia LoRa – La scheda di sviluppo TTGO LoRa32 – Parte 1 – introduzione

Nel mondo dell’IOT si sente sempre più spesso parlare di LoRa e LoRaWAN. In questo articolo cercherò di spiegare un po’ di cosa si tratta illustrando anche un prodotto molto versatile ed economico per sfruttare questa tecnologia.

Sponsor

Il dispositivo di cui si parla nell’articolo, insieme ad altri componenti, è stato gentilmente offerto da DigitSpace – Negozio online di componenti elettronici e kit ad ottimi prezzi situato in Cina. Pagamento con paypal e spedizioni con corriere espresso.

Digitspace

Cosa è il LoRa

LoRa è l’acronimo di Long Range, Lungo Raggio. Range può anche essere tradotto come spettro ma “lungo spettro” non avrebbe senso (nemmeno in italiano), si sarebbe dovuto dire wide range, ad ogni modo sia i concetti di lungo raggio che di ampio spettro si addicono entrambi, contemporaneamente, a questa tecnologia e vediamo perchè.

Il LoRa è essenzialmente una tecnica di modulazione di trasmissioni a radiofrequenza che è stata inventata nel 2009 da un’azienda francese, la Cycleo, che forniva proprio servizi basati su questa nuova tecnologia. Nel 2012 la Cycleo venne acquistata dalla Semtech che ora detiene la proprietà intellettuale di questa tecnologia.

Il segnale digitale da trasmettere viene modulato utilizzando una codifica che deriva da quella chiamata Chirp Spread Spectrum (CSS). Questo tipo di modulazione è stata inventata negli anni ’40 per i radar (potete leggere questa presentazione che ho trovato molto interessante ed esplicativa) e tra l’altro è stata anche adottata dalla IEEE con lo standard 802.15.4 per le reti LR-WPAN (Low Rate Wireless Personal Area Network): quindi niente di nuovo in realtà.

A differenza delle codifiche di tipo FSK (Frequency Shift Keying) che modulano i segnali digitali con una differente frequenza (un “1” è inviato con una determinata frequenza e uno “0” con un’altra, tanto per capirci), nella modulazione CSS si sfruttano i Chirp ovvero dei salti di frequenza che possono avvenire verso l’alto (si parte da una frequenza bassa per arrivare gradatamente ad una frequenza alta, questo è definito Up-Chirp) o verso il basso (viceversa, Down-Chirp). Ecco, il LoRa basa la sua magia su questa tecnica e codifica i segnali utilizzando i salti di frequenza. Chi è a digiuno di queste cose può vedere questo semplicissimo video che spiega in maniera molto basilare queste cose:

Riguardo al LoRa in particolare è molto utile il documento AN1200.22 LoRa™ Modulation Basics della stessa Semtech che potete trovare un po’ dappertutto su internet (tranne che sul sito della Semtech). Una formula in particolare lega tra loro tutti i parametri che caratterizzano questo tipo di modulazione:

Rb è il bitrate della trasmissione, SF è lo spreading factor e BW è la larghezza di banda. All’aumentare di SF, tenendo la larghezza di banda fissa, diminuisce il bitrate (meno quantità di dati trasmessa nell’unità di tempo) ma la radio ha una sensibilità maggiore per cui il segnale è in grado di viaggiare su distanze più elevate. Il video seguente spiega per bene cosa è lo Spreading Factor ed introduce il concetto di chip che è diverso da quello di chirp:

Le trasmissioni LoRa, utilizzando opportune antenne, riescono a coprire distanze fino a 5km in aree urbane e fino a 15km in campo aperto (linea d’aria) con una notevole resistenza alle interferenze.

Il LoRa è una tecnologia a basso consumo: le potenze di trasmissione sono molto basse per cui i dispositivi sono piccoli, non sono necessarie antenne enormi e i sistemi possono funzionare a batteria per mesi e mesi. In più si inserisce in bande di frequenza libere: le bande ISM (Industrial Scientifical Medical) per cui non è necessario pagare licenze. In particolare le bande più diffuse sono quelle dei 433 MHz (usata un po’ dappertutto), 868 MHz (Europa) e 915 MHz (Nord America e Australia) e altre usate in Asia.

C’è chiaramente il rovescio della medaglia: i bitrate sono molto bassi per cui le trasmissioni sono limitate a dati e non è quindi una tecnologia pensata per trasmissioni audio/video ad esempio. Per tutte queste caratteristiche il LoRa si sta imponendo sempre di più nel campo dell’IOT (Internet Of Things) dal momento che permette di realizzare reti di sensori a basso costo che possono coprire aree molto ampie con bassi consumi consentendo l’utilizzo di batterie e piccoli pannelli fotovoltaici e permettendo quindi di monitorare anche aree disagiate o normalmente irraggiungibili dalla corrente elettrica.

Ad esempio molte scuole italiane hanno partecipato al progetto CanSAT e conosco un professore (ciao Dante!) che ha realizzato con la sua classe un satellite che comunica sulla terra usando un dispositivo LoRa.

LoRa vs LoRaWAN

Nel 2015 la Semtech ha fondato un’associazione senza scopo di lucro, la LoRa Alliance, della quale attualmente fanno parte oltre 500 aziende, tra cui anche Microchip.  Se prima il monopolio di chip basati sul LoRa era solo di Semtech, ora tutti i membri del consorzio possono produrre chip in licenza che sfruttano questa tecnologia. Sebbene i chip della Semtech siano i più diffusi in assoluto, anche Microchip ha nel proprio portfolio dei prodotti LoRa (come l’RN2483 e l’RN2903) così come tantissime altre aziende. In realtà il consorzio è nato per standardizzare e certificare il LoRaWAN e i membri del consorzio producono chip certificati per questo protocollo.

Il LoRa, abbiamo visto, definisce un sistema di comunicazione a livello fisico (PHY) ovvero ci spiega come modulare/demodulare il segnale, ci fornisce le formule per calcolare potenze, frequenze, bitrate ecc.

Il livello superiore (livello applicativo, livello MAC, Media Access Control) : ovvero come possono varie radio coordinarsi tra loro, indirizzarsi, codificare dati ed indirizzi ecc, insomma che lingua parlare, lo possiamo decidere noi: il LoRaWAN è uno dei tanti protocolli che possiamo applicare alle trasmissioni LoRa.

Il LoRa è il livello fisico, che stabilisce frequenze e tecniche di modulazione, mentre il LoRaWAN è il livello MAC che stabilisce il modo in cui i dispositivi della rete possono comunicare tra loro

E’ un protocollo opensource che definisce come comunicano i singoli dispositivi LoRa (end nodes) con i gateways e come questi ultimi facciano da “ponte” tra le trasmissioni LoRa ed altri tipi di trasmissioni come il WiFi o altro.

Esempio di rete LoRaWAN

Potete leggere di più in questa pagina. Il LoRaWAN è solo uno dei tanti protocolli che si inserisce nella fascia più ampia delle LPWAN (Low Power Wireless Area Network) che comprende, cioè. tutte quelle reti fatte per consumare poca corrente e coprire grandi distanze. Nella seguente immagine sono illustrati 3 tipi di reti con i loro pro e contro:

La rete cellulare, ad esempio, ha coperture molto ampie e permette dei datarate altissimi, per contro è una tecnologia implementabile solo dai colossi mentre i “piccoli” devono pagare costi di abbonamento. Tecnologie come il Bluetooth, ZigBee e Wi-Fi sono adatte a luoghi ristretti e sono tecnologie molto ben radicate e conosciute, per contro hanno dei costi  e consumi elevati.

Di protocolli destinati all’IOT ne esistono tantissimi e una lista completa è disponibile qui.

Un concorrente del LoRaWAN, ad esempio, è il Sigfox: quest’ultimo ha molte caratteristiche in comune con il LoRaWAN anche se  a livello fisico viene utilizzata una modulazione differente, ma è un progetto di tipo chiuso, ovvero abbiamo operatori che sostanzialmente noleggiano la rete alla stregua di operatori telefonici. Con Sigfox l’utente finale può progettare un dispositivo che si appoggia alla rete Sigfox pagando un canone mensile.

Un’altra cosa importante che ho mancato di dire è che ogni nodo LoRa è sempre un Transceiver: ovvero è in grado di ricevere ed inviare dati contemporamente. Chiaramente avendo due dispositivi LoRa non è necessario implementare una rete LoRaWAN: possono comunicare tra di loro nel modo in cui vogliamo e uno dei due, può eventualmente fungere da gateway ritrasmettendo  dati su un altro livello.

Dispositivi LoRa in commercio per i Makers

Un ESP32 è il candidato ideale a creare reti LoRaWAN o simili dal momento che di per se ha la possibilità di comunicare via WiFi e via Bluetooth per cui aggiungendo anche un modulo LoRa ad una scheda di sviluppo basata su ESP32 questa può benissimo fungere anche da Gateway: coordinare altri dispositivi LoRa nei paraggi e fare da bridge tra loro e internet o una rete WiFi o via Bluetooth ad altri dispositivi ancora. Attualmente ci sono due marchi che producono una buona fetta delle schede di sviluppo ESP32+LoRa rivolte al mercato dei Makers: la LilyGO e la Heltec Automation.

LilyGO o TTGO?

La maggior parte dei prodotti che si trovano in giro con un ESP32 e un chip LoRa presentano il marchio TTGO e capita di trovare queste schede, con TTGO sulla serigrafia, ma pubblicizzate con i nomi di altre ditte tipo Wemos (dovrebbe essere un’altra azienda ma il loro sito, wemos.cc, ad oggi pare abbandonato) o addirittura compare anche la serigrafia della Heltec Automation. Dal momento che non ci stavo capendo più nulla, nemmeno riguardo ai numeri di versione presenti sulla scheda in mio possesso, ho fatto alcune domande direttamente alla LilyGO per chiedere chiarimenti: TTGO era il vecchio nome del team che ora si chiama LilyGO. LilyGO® è un marchio registrato della Shenzhen Xinyuan Electronic Technology Co.,Ltd ed è un’azienda che produce dispositivi per se e su commissione e realizza PCB. La transizione da un marchio all’altro dovrebbe essere avvenuta intorno al 2018. Quindi è chiaro che non trattandosi prima di un marchio registrato, quelle schede si sono probabilmente diffuse come cloni dell’idea originale e per questioni di marketing vengono ancora commercializzate col marchio TTGO che è sicuramente ben noto.

LilyGo TTGO ESP32-Paxcounter LoRa32 2.1_1.6

Le schede col marchio TTGO sono già molto diffuse: si tratta di un portfolio di dispositivi programmabili rivolti al mondo dei Makers: la maggior parte è basata su ESP32 con a bordo una serie di periferiche, ma LilyGO ha in catalogo anche cloni di Arduino e qualche modulo basato su ESP8266 a marchio TTGO ma, come dicevo, la stragrande maggioranza è tutta costituita da dispositivi con ESP32 ed è probabilmente il pezzo su cui vanno più forte.

Il dispositivo in questione, quello del titolo paragrafo che analizzeremo, ha a bordo un ESP32, un display OLED da 128x64pixel, un modulo caricabatterie per una cella LiPo, un modulo LoRa (Semtech SX1276) e uno slot per schede microSD. Di questo dispositivo sono disponibili 3 varianti in base alla componentistica intorno al modulo LoRa che ne determina la frequenza di funzionamento:  433MHz, 868MHz e 915MHz. In base alla frequenza del modulo, oltre a cambiare la componentistica sul PCB, cambia chiaramente anche la lunghezza dell’antenna fornita in dotazione. Insieme a scheda ed antenna vengono anche forniti gli header maschio eventualmente da saldare sui pad esterni e il connettore maschio JST-PH da utilizzare con una eventuale batteria LiPo (non fornita) per far funzionare il modulo anche in assenza di alimentazione esterna.

TTGO Lora32 modello T3 versione 2.1_1.6 – Viene fornito con cavetto per la batteria munito di connettore JST-PH (pitch 2.00mm), headers e antenna con connettore SMA

La frequenza di 433MHz è quella che forse ha un consenso maggiore un po’ in tutto il mondo, Italia compresa ma anche la maggior parte dell’Europa. La 868MHz va bene in tutta Europa, la 915MHz è consentita negli Stati Uniti, Australia e altri paesi delle Americhe. Per i paesi dell’Asia sono previste altre frequenze ancora (in Cina sono concesse le bande 470-510 e 779-787 ad esempio), sempre raggiungibili dal chip ma per le quali non ho visto che ci sono moduli appositi: scrivo questo perchè alcuni su altri siti indicano come la 433 per l’Asia: assolutamente falso e all’ultimo paragrafo, tra i link, ho messo una pagina in cui sono indicate le frequenze utilizzabili per tutti i paesi del mondo.

Quindi per gli amici Italiani: dovete acquistare il modello da 433MHz o quello da 868MHz.

Versioni

La differenza con l’aggiunta della scritta Paxcounter è che questi, a differenza di moduli venduti senza tale dicitura, hanno precaricato un firmware che ha appunto quel nome: Paxcounter. Quindi sostanzialmente per noi non c’è differenza tra moduli Paxcounter e non perchè tanto ci andremo a caricare su i nostri esperimenti.

Paxcounter è l’abbreviazione di Passenger Counter, si tratta di un progetto open source che sfrutta un ESP32 per contare il numero di persone nei paraggi. Come fa? Semplicemente tenendo conto che ogni persona abbia un cellulare in tasca e quindi abbiano WiFi e/o Bluetooth attivi. Il dispositivo intercetta soltanto il Mac Address dei cellulari discernendo tra questi e riporta il conteggio sul display dei dispositivi WiFi e Bluetooth separatamente.

Non ho idea se questa cosa possa essere legale o meno almeno in Italia ma, anche se un dispositivo del genere per me non costituisce pericolo (non si infiltra nelle trasmissioni per ottenere dati se non il Mac Address), in alcuni paesi pare che sia illegale. Si tratta comunque di un’applicazione che di certo non ha bisogno di un modulo LoRa per poter funzionare, basta una comune scheda basata su ESP32 munita di oled e volendo potrebbe farlo anche un cellulare.

Il fatto che vengano vendute schede con questo firmware precaricato è probabilmente per verificare che il modulo funzioni correttamente e per fare pubblicità al fatto che l’ESP32, a differenza dell’ESP8266, ha anche un modulo bluetooth integrato.

Quando accendete la versione Paxcounter, si presentano varie schermate sul display che si alternano. Tra l’altro deve essere stato caricato un firmware che non tiene conto specificamente di questa scheda dal momento che le scritte sul display si trovano ruotate di 180° rispetto alla posizione dell’antenna, che per me è naturale che sia invece rivolta verso l’alto consentendomi di leggere le scritte.

L’ultima versione del modulo di cui vi voglio parlare è la 2.1_1.6 indicata anche solo come 2.1 e a volte anche come solo 1.6. Proprio per questo, come dicevo sopra, ho contattato la LilyGO direttamente e mi hanno detto che 2.1 è proprio il numero di versione mentre 1.6 è la revisione . Come riconoscere la board dato che non esistono schede su cui appare scritto 2.1? Sulla board appare la scritta T3_V1.6 (T3, ancora, mi dicono sia il modello: se vedete in catalogo, alcuni modelli di schede sono identificate con Tx dove x=numero). Se quindi avete sul PCB la scritta T3_V1.6 vuol dire che si tratta dell’ultimo modello nel momento in cui scrivo questo articolo.

Per me sarebbe stato molto più semplice mettere in mezzo solo il T3, ad esempio, seguito eventualmente da un numero di revisione. Non capisco la necessità di mettere tutti questi numeri e codici che creano solo confusione e non sono congruenti con le serigrafie.

In aggiunta, nonostante tutti questi numeri di versione/revisione, i primi modelli di T3_1.6, o 2.1_1.6 o semplicemente 2.1 che dir si voglia, avevano un bel problema con il modulo caricabatteria, questi modelli pare che non siano più in circolazione (si parla del 2018), ad ogni modo ho approfondito questa questione al paragrafo successivo e non sono stati fatti aggiornamenti al numero di revisione dopo la modifica, quindi altra confusione.

Anatomia del modulo

Chiarita (?) la questione dei nomi/versioni, possiamo passare ad approfondire la parte tecnica. Mi riferirò solo ed esclusivamente alla versione 2.1 alias T3 alias 2.1_1.6 perchè le versioni precedenti (!) hanno delle differenze. A bordo abbiamo la seguente componentistica:

Sulla scheda sono presenti 3 led, tenendo la scheda col display frontale e l’antenna in alto:

  • Il led blu (alto a destra) indica che è il modulo di carica della batteria è in funzione
  • Il led rosso (a sinistra del led blu) indica che è presente la 3.3V (quindi ESP32  il resto sono accesi)
  • Il led verde (in basso a centro-destra) è pilotabile dall’utente (GPIO25)

E’ presente un interruttore a slitta sulla base del modulo che stacca unicamente la tensione VBus presente sulla porta USB dalla linea dei 5V. Alimentando la scheda dalla linea +5V posta sull’header esterno (le due file di contatti), l’interruttore non ha effetto e il modulo resta sempre acceso. Con l’alimentazione da linea +5V, però, e con l’interruttore in posizione OFF, la batteria non viene caricata dato che il modulo Lipo è collegato sulla linea VBus. Non c’è un sistema che rileva la presenza contemporanea di tensione dalla porta USB e dall’header, quindi volendo fare una cosa del genere è necessario tenere l’interruttore in posizione OFF e la batteria eventualmente presente sarà caricata dalla porta USB: è una cosa che non consiglio di fare perchè è facile dimenticarsi l’interruttore su ON o spostarlo accidentalmente e mettere quindi insieme tensione esterna e tensione USB correndo il rischio di friggere qualcosa. Sulla linea VBus è presente un fusibile SMD da 2A.

Schema elettrico della sezione di alimentazione del modulo TTGO LoRa32 2.1_1.6 a meno della sezione 3.3V

Il punto di carica della batteria (uscita BAT del TP4056) è collegato ad un ingresso analogico dell’ESP32 (GPIO35) tramite un partitore 1:2 per cui, con la sola batteria collegata da programma è possibile rilevare batteria scarica ed andare eventualmente in stand-by o dare una segnalazione, con batteria collegata e in carica o senza batteria viene sempre riportata la tensione di carica compresa tra 3.9 e 4.2V.

La batteria è collegata, fissa, tramite un diodo Bs5819 (schottky, 1A), alla linea dei 5V. Sulle versioni precedenti del modulo (che però era sempre marchiato T3_1.6 sulla serigrafia) al posto di questo diodo c’era un fusibile, per cui dopo una mezz’ora di funzionamento con alimentazione esterna e batteria collegata, questa esplodeva perchè gli arrivava direttamente la 5V. Non dovrebbero essere più in circolazione le schede col fusibile ma potete facilmente verificare da voi se avete una scheda che da questo problema o meno:

La versione che non causa problemi alla batteria è quella col DIODO

A bordo ci sono DUE regolatori di tensione a 3.3V (ME6211) da 500mA l’uno, ognuno con la sua circuiteria di gestione e le linee di uscita sono messe insieme. Immagino quindi che dalla linea 3.3V sull’header si possono tranquillamente alimentare altre apparecchiature dato che abbiamo 1A in uscita (fino a che gli vengono forniti in ingresso!). Con l’alimentazione a batteria invece bisogna fare delle considerazioni. 

I regolatori di tensione da 3.3V utilizzati hanno una tensione di dropout di 100mV (se l’assorbimento è 100mA) vuol dire che in ingresso devono avere almeno 3.4V per poter funzionare, al di sotto di questo valore, la tensione passa tal quale, quindi abbiamo comunque meno di 3.4V e va bene così. La batteria, dicevamo, è collegata tramite il diodo BS5819 alla linea dei 5V: questo diodo a 100mA ha una caduta di tensione di circa 350mV, per cui dalla batteria completamente carica (4.2V) arriveranno 3.85V e il regolatore funziona correttamente. Da prove che ho fatto collegando un alimentatore al posto della batteria ho trovato che il sistema funziona correttamente fino a che la batteria fornisce circa 2.9V e quindi sulle logiche arrivano circa 2.6, al di sotto di questa tensione l’unica cosa che funziona, debolmente, è il led rosso sulla linea dei 3.3V. Per stare tranquilli, quindi, possiamo dare la segnalazione di batteria scarica intorno ai 3V o qualcosa in più. Tutte queste considerazioni sono fatte tenendo conto di 100mA di assorbimento sulla linea dei 3.3V. Con un assorbimento maggiore il diodo arriva a scalare 0.6÷0.7V e bisogna fare altre considerazioni.

Con il display OLED sempre acceso e sul modulo in trasmissione ho misurato assorbimenti massimi di 80mA

Il diodo di protezione della batteria è purtroppo in posizione infelice (lo era anche il fusibile dato che l’altezza dei due componenti è uguale) perchè impedisce un collegamento agevole del cavetto per la batteria fornito in dotazione: è necessario utilizzare delle pinzette per poterlo agganciare e molta delicatezza altrimenti rischiate di rompere il connettore sul PCB o far saltare il diodo e dopo esserci riusciti, il connettore va a filo col diodo:

L’ESP32 non ha la schermatura metallica come siamo abituati a vedere sulle molte schede di sviluppo basate su di esso, difatti la scheda non ha certificazioni FCC o altro e in più non ha un’antenna a traccia ma un’antenna metallica saldata sulla scheda:

A sinistra il modulo di cui sto parlando: ha un chip ESP32-PICO D4, non schermato, e un’antenna metallica. A destra c’è un Wemos Lolin32 OLED che ha un modulo Wroom32 che consiste un ESP32 incapsulato con antenna a traccia

Il LED verde ha l’anodo collegato su GPIO25 quindi è possibile accenderlo da programma portando a livello alto dal pin. Sono presenti due connettori per l’antenna LoRa: un connettore SMA per il quale l’antenna viene già fornita  e un più piccolo connettore U.FL che può essere eventualmente essere utilizzato acquistando un cavo con connettore U.FL+SMA per poter montare l’antenna sul corpo di un eventuale contenitore.

Infine un doppio transistor UMH3N montato dal lato del display gestisce la parte di reset via segnale RTS per la programmazione.

Per semplicità riporto di seguito una tabella che indica a quale GPIO (numero di GPIO usabile in Arduino IDE) sono collegati i vari dispositivi onboard anche se ho preparato un file header per Arduino IDE che semplifica la gestione del programma:

UtilizzatorePin UtilizzatoreGPIO ESP32
Chip LoRaSCK5
MISO19
MOSI27
SS18
RESET14
DI026
Display OLEDSDA21
SCL22
MicroSDMOSI15
MISO2
SCK14
CS13
DAT212
DAT14
Led Verdeanodo25
Tensione batteriauscita da partitore 1:235

Prossimamente

Nel prossimo articolo pubblicherò un esempio di comunicazione tra 2 di questi moduli utilizzando tutte le caratteristiche messe a disposizione sulla scheda e più in la un progetto completo che non anticipo.

Vai all’articolo successivo

Links

Se questo articolo ti è piaciuto, condividilo su un social:
Se l'articolo ti è piaciuto o ti è stato utile, potresti dedicare un minuto a leggere questa pagina, dove ho elencato alcune cose che potrebbero farmi contento? Grazie :)