Radiocomando Long-Range: il trasmettitore palmare LoRa

Trasmettitore palmare da abbinare allo shield LoRa per Arduino per realizzare comandi via radio long-range.

Tra le tecnologie per la trasmissione via radio a grande distanza ma con basso consumo energetico, una su cui abbiamo focalizzato la nostra attenzione è quella chiamata LoRa (Long Range) proposta dalla Semtech con un prodotto basato su di essa.

In questo articolo, oltre a descrivere il trasmettitore per radiocomando LoRa, richiamiamo un po’ di concetti della trasmissione “Spread Spectrum” ed in particolare della tecnica LoRa.

Infatti il trasmettitore che abbiamo realizzato, meglio descritto dallo schema elettrico, è pensato per integrarsi con lo shield LoRa per Arduino e utilizza le stesse caratteristiche di trasmissione; lo shield diventa l’unità ricevente.

LoRa (Long Range) è una tecnologia candidata alla realizzazione dell’IoT (Internet of Things, ossia Internet delle cose), laddove link radio esistenti come WiFi e Bluetooth risultano inadeguati.

Infatti per portare la comunicazione di dati a livello di mini/micro apparati a bassissimo consumo (per esempio autoalimentati con batterie o pannelli solari) è necessario utilizzare tecniche di trasmissioni radio diverse dal WiFi (che consuma molto) o dal Bluetooth (che ha una portata ridotta).

Le soluzioni long-range ad oggi proposte sono due:
• Ultra Narrow Band (UNB), ovvero trasmissione su banda strettissima in cui si può concentrare la piccola potenza del trasmettitore (SigFox);
• Wide Band con lo Spread Spectrum, ossia trasmissione dove l’informazione è sparpagliata su un’ampia banda di frequenze mediante appositi algoritmi; così i dati possono essere ricostruiti anche se il segnale è bassissimo e addirittura sotto la soglia del rumore. Proposta LoRa.

In ambedue i casi il prezzo da pagare è la bassa velocità di trasmissione (qualche centinaio di bps ovvero decine di byte per secondo). Ma questa limitazione non ha molta importanza, visto che di norma per le applicazioni IoT come i sensori intelligenti occorre lo scambio di pochi dati periodici tra gli apparati periferici ed un centro di raccolta ed instradamento su rete Internet.

Quello che importa è che si possano contattare numerosi mini/micro apparati periferici sparpagliati su qualche chilometro di raggio; e che questi apparati siano a bassissimo consumo.

Schema elettrico del trasmettitore LoRa

Spread Spectrum e LoRa

 

Distribuire il segnale dati su una banda larga della portante si può fare in due modi:
a) facendo saltare una portante su diversi canali adiacenti con un algoritmo prestabilito; cioè attuando il cosiddetto Frequency Hopping (FH);
b) facendo corrispondere ad ogni bit dei dati una stringa di molti bit modulanti in base ad uno schema prestabilito (per esempio pseudo-random); il ricevitore poi ricostruirà i singoli bit applicando il processo inverso.

È possibile applicare contemporaneamente le due tecniche, come è possibile farlo anche in LoRa. Ma in realtà LoRa utilizza sostanzialmente la tecnica descritta al punto b.

Questa tecnica può essere implementata con una sovra-modulazione digitale, come nel caso della DSSS (Direct Sequence Spread Spectrum), oppure con altri metodi come quelli utilizzati in LoRa.

Per semplificare l’hardware soprattutto in ricezione, LoRa non utilizza la DSSS ma una sequenza di “chirp”; ovvero una oscillazione la cui frequenza varia linearmente nel tempo (Fig. 2).

 

Questo permette di sincronizzare più semplicemente il ricevitore con il trasmettitore, al contrario di quanto è nella DSSS, che necessita invece di timer precisi.

I byte di dati vengono suddivisi in nibble (4 bit) a cui sono aggiunti 1 o 2 o 3 o 4 bit per il controllo di parità. Il parametro che definisce la robustezza della trasmissione è CR, che infatti può avere valore da 1 a 4.

Per cui se CR=4, vuol dire che la lunghezza dei dati del payload (dati da trasmettere) viene raddoppiata ma la sicurezza di integrità è molto alta. Nell’unità di tempo, dal modulatore, vengono prodotti tanti chip (unità di modulazione) quanti sono gli Hertz della larghezza di banda (BW) (dato di progetto di LoRa). Quindi il rateo dei chip è proprio Rc=BW. Ma su ogni chip possono essere modulati 2SF valori (simboli), dove SF è il parametro che definisce lo “spread factor” che può avere valori da 6 a 12.

Quindi il rateo dei simboli è Rs=Rc/2SF. Poiché 2SF valori sono rappresentati da SF bit, possiamo dire che il rateo dei bit (bps) è Rb=SF * Rs. Ma non abbiamo considerato la maggiorazione dei bit dovuta alla ridondanza per il controllo di parità definito dal parametro CR. Questo produce un surplus pari alla frazione (4+CR)/4 dei bit da trasmettere. Quindi, in definitiva il rateo della trasmissione come bit per secondo (bps) è legato ai parametri BW, SF e CR dalla seguente formula:

 

Quindi la frequenza di bit al secondo è direttamente proporzionale alla BW ed in relazione inversa allo SF (Rb ∝ 1/2(SF-1)).

Oltre al rateo bps c’è da considerare la sensibilità della ricezione che invece è in relazione diretta con SF mentre invece cala all’aumentare della BW.

Quindi la massima sensibilità si ottiene con il massimo SF e la minima BW. Ma in questo caso si ha anche un bps troppo basso, per cui è il caso di trovare un compromesso utilizzando una BW più grande per aumentare il bit rate, soprattutto se ci sono dei vincoli di velocità di trasmissione da rispettare.

In Tabella 1 sono calcolati i valori bps per le diverse BW e i diversi SF nell’ipotesi di utilizzare la massima ridondanza (CR=4). Mentre in Tabella 2 sono mostrate le sensibilità di ricezione stimate.

In sostanza i valori dei parametri più utili nelle situazioni tipiche sono: SF = 11/12 e BW = da 4 a 9. Corrispondenti a valori da 46 bps con -144 dBm di sensibilità a 1.343 bps con -129 dBm di sensibilità.

Nel caso di bit-rate piuttosto bassi (<1.000 bps) , è necessario aggiornare un registro del modulo abilitando il flag che ottimizza la ricezione lenta.

Si tratta del bit 3 del registro 0x26 (che va posto ad 1); può essere fatto utilizzando la funzione di libreria “SX.setLoraLowDataRateOptimize (boolean on)”; ma questo viene fatto automaticamente dalla libreria all’inizializzazione.

 

 

 

Il radiocomando LoRa

In questo post ci concentreremo sull’utilizzo nell’ambito del protocollo LoRa. Per LoRa è stato studiato, da parte della “LoRa Alliance”, anche un complesso protocollo di rete chiamato LoRaWAN.

L’associazione si assume anche il compito di certificare i prodotti compatibili con questo protocollo.

Poiché le caratteristiche di LoRaWAN sono complesse e non si sposano bene con una attività hobbistica o anche semi artigianale, si è pensato di fornire una libreria per l’uso del modulo radio e per l’implementazione di una comunicazione LoRa bidirezionale e multi-punto.

Si è lasciato così all’utente il compito di costruire la propria rete secondo le sue necessità, senza le rigidità legate ad un protocollo industriale certificato.

Con la libreria è possibile gestire facilmente due stazioni che si parlano, oppure un centro di raccolta e una moltitudine di sensori sparsi, o altri tipi di strutture di rete più complicate. La libreria è stata aggiornata (versione 1.2) aggiungendo qualche ulteriore funzione (vedere il file ReleaseNote).

La libreria può essere utilizzata con funzioni base senza nessun indirizzamento, spedendo via etere un payload giusto per verificare la copertura. Un esempio lo troviamo negli sketch “LoRaTxEcho” e “LoRaRxEcho” presenti negli esempi allegati. In questo caso vediamo le funzioni fondamentali:
• inclusione della libreria #include <LoRa.h>
• istanza della classe LORA LR;
• inizializzazione LR.begin();
• setting dei parametri principali LR.setConfig(SF,BW,CR); //tipicamente 12,7,4;
• spedisce messaggio LR.sendMess(tbuffer);
• si pone in ricezione LR.receiveMessMode();
• riceve messaggio (loop n volte) if (LR.dataRead(rbuffer,maxlength) >0 ) break;

Ma la libreria è organizzata con funzioni più sofisticate così da definire ed utilizzare indirizzi di apparati. In particolare è possibile definire un indirizzo di un apparato nell’ambito di una rete identificata da un indirizzo complessivo. Ovvero è possibile utilizzare un indirizzamento del tipo:

Indirizzo di rete – Indirizzo locale (di device)

La dimensione di indirizzamento della rete è legata alla dimensione dell’indirizzamento locale. Infatti l’indirizzo complessivo definito dalla libreria è sempre basato su 16 bit (unsigned integer per Arduino). Per cui se per esempio si decide di avere uno spazio indirizzabile di 28 =256 device, per la rete rimangono 2(16-8=16)=256 possibili valori.

In realtà la dimensione dell’indirizzo locale è minore di una unità, perché l’indirizzo 0 identifica una trasmissione broadcast (cioè a tutti i locali). Per definire questa suddivisione si utilizza la funzione:

LR.defDevRange(cod);

dove “cod” è uguale all’esponente di 2; per esempio 3 per il range 1-7.

La funzione ritorna il numero massimo di indirizzo di rete per un eventuale controllo.
Ecco alcuni esempi:
Codice 3 : Indirizzo locale 1-7
indirizzi di rete da 0 a 8191;
Codice 4 : Indirizzo locale 1-15
indirizzi di rete da 0 a 4095;
Codice 5 : Indirizzo locale 1-31
indirizzi di rete da 0 a 2047;
Codice 6 : Indirizzo locale 1-63
indirizzi di rete da 0 a 1023;
Codice 7 : Indirizzo locale 1-127  indirizzi di rete da 0 a 511;
Codice 13 : Indirizzo locale 1-8191
indirizzi di rete da 0 a 7.

A questo punto non rimane che decidere l’indirizzo della rete che deve essere compreso entro il limite stabilito dalla precedente suddivisione.
Questo può essere fatto dalla funzione:

LR.defNetAddress(addr);

Ritorna errore se “addr” non è dentro i limiti.

Poiché le portate radio sono consistenti è necessario proteggere le informazioni; non a caso il protocollo LoRaWAN prevede una crittografia AES128.

Anche la libreria da noi proposta implementa una crittografia AES (ma AES256).

È quindi necessario stabilire una identica chiave tra gli apparati.
Questo può essere fatto tramite la stessa funzione di inizializzazione, passandogli un intero come chiave:

LR.begin(key);

Poiché la chiave AES è formata da 32 Byte, in realtà il numero “key” serve come “seme” per inizializzare il generatore di numeri random; la funzione stessa si occupa poi di generare la chiave di 32 Byte. In questo modo è possibile scambiare un semplice numero come chiave di comunicazione.

Ciò si mantiene vero solo nel caso che si usi il compilatore di Arduino per tutti i device. Infatti a partire dal “seme” la routine del compilatore produrrà la stessa sequenza pseudo-randomica in tutti i device Arduino.

Le funzioni principali da utilizzare in una rete LoRa proprietaria possono allora essere elencate così:
• inclusione della libreria:
#include <LoRa.h>
• istanza della classe:
LORA LR;
• inizializzazione:
LR.begin(key);
• setting dei parametri principali:
LR.setConfig(SF,BW,CR);
//tipicamente 12,7,4
• definisce il range di ind. locale:
LR.defDevRange(cod);
• definisce l’indirizzo di rete:
LR.defNetAddress(address);
• spedisce il messaggio:
LR.sendNetMess(destinatario locale, mittente locale, mess, lung);
• si pone in ricezione:
LR.receiveMessMode();
• riceve messaggio
(loop n volte):
if (LR.receiveNetMess(dest. locale,mitt. locale, buffer, maxlung)>0) break;
• estrae e decodifica il testo:
LR.getMessage();
• estrae e dec. l’indirizzo mittente:
LR.getSender();

La funzione di ricezione torna 0 se non sono arrivati messaggi o non sono arrivati messaggi inviati al destinatario. Inoltre ritorna -1 se il messaggio non è stato spedito dal mittente indicato. Se nel messaggio il destinatario ha valore 0 il messaggio è sempre accettato (broadcasting). Se il parametro mittente della funzione ha valore 0, vengono accettati i messaggi a prescindere dal mittente.

Negli esempi inclusi nella libreria potete trovare due sketch “LoraTxAddressing” e “LoraRxAddressing” che realizzano un server che dialoga con diversi moduli periferici.
Tenete comunque presente che la gestione diretta dei registri dello SX1278 può sempre essere fatta dalle funzioni base della classe SX della libreria.

Il telecomando LoRa e la libreria per Arduino

Come vedremo in dettaglio più avanti, il telecomando usa lo stesso modulo LoRa degli shield. Quindi le stesse funzioni si applicano allo sketch che agisce sul telecomando.

Il quale telecomando contiene un Arduino compatibile come processore e velocità di clock con la versione “LilyPad con USB”. Il telecomando, però, invia un messaggio sempre uguale alla pressione del tasto. Ne risulta una trasmissione sempre identica (anche se criptata).

Chiunque, se dotato di opportuna apparecchiatura, potrebbe registrare e ripetere la trasmissione senza bisogno di decodificarla. È il problema di tutti i telecomandi attuatori.

Problema che si cerca di risolvere, per esempio, rendendo la trasmissione sempre diversa con la tecnica del “rolling code”. Per risolvere questo problema nella libreria è stato predisposto un “marker”, ovvero un byte con valore casuale. Il marker di un messaggio ricevuto, può essere letto e confrontato con gli ultimi marker arrivati. Nel caso fosse presente in questa lista, il messaggio sarebbe rigettato come sospetto.

La grandezza della lista sarà decisa a piacere. Non troppo lunga per non avere troppe probabilità di trovare un marker già utilizzato.

Né troppo corta per avere un controllo su un sufficiente numero di trasmissioni già effettuate. Come vedremo più avanti, il telecomando si accende ogni qual volta viene pigiato il pulsante di comando.

In questa situazione non possiamo usare il generatore random di Arduino che sarebbe inizializzato ogni volta allo stesso valore.

Per avere un valore random ad ogni accensione, dobbiamo ricorrere al rumore elettronico. Infatti possiamo leggere il valore di una o più porte analogiche di Arduino, non utilizzate e lasciate ad alta impedenza. Questo valore può essere usato come “seme” per inizializzare il generatore random (o meglio pseudo-random).

Per leggere il marker si usa la funzione:

LR.getMarker();

Si tenga presente che il messaggio risulta crittografato nel suo complesso, eccetto il destinatario. Quindi, anche a causa della modalità operativa della crittografia AES, il contenuto, compreso il marker, si trova distribuito come rumore su tutta la lunghezza del messaggio, rendendo la sicurezza molto efficace.

Test di portata radio

In rete sono diffusi dati di portata radio, alcuni un po’ esagerati ed altri più realistici.

Molto dipende dal terreno, più o meno edificato, o più o meno accidentato, o dalla posizione e dalla bontà dell’antenna.
In ogni caso si tratta realisticamente di alcuni chilometri in città e di una o più decine in campo aperto.

In ogni caso i dati fanno riferimento alle condizioni LoRaWAN dove le trasmissioni avvengono a 868 MHz. Abbiamo, allora, voluto fare qualche misura effettiva per riportare qualche dato reale con il nostro modulo a 433 MHz e con antenna a ¼ d’onda.

Le misure sono state effettuate con lo shield LoRa per Arduino che ha l’antenna su connettore SMA. Per il telecomando, che ha l’antenna a filo interna, ovviamente le portate sono inferiori. In ogni caso non ha problemi a superare quattro solai e raggiungere un parcheggio interrato.

Tornando allo shield con antennina, abbiamo effettuato due serie di prove: una con il trasmettitore collocato all’interno dell’abitazione ed una con il trasmettitore posizionato all’esterno, sulla terrazza condominiale.

I dati di trasmissione sono i seguenti: SF=12, BW=5, potenza 10 dBm e 20 dBm. L’altro shield ricevitore era all’interno di una automobile.
Come si può vedere dalla Fig. 3, con lo shield all’interno della abitazione la portata è asimmetrica perché la portata maggiore è in direzione della finestra dietro la quale si trova il trasmettitore. In ogni caso si raggiungono portate dell’ordine del chilometro.

 

Nella Fig.4, la portata risulta non solo simmetrica ma anche molto maggiore, attestandosi su alcuni chilometri.

Queste prove sono state effettuate, come detto, utilizzando una antennina da ¼ di onda; potendo contare su un’antenna più efficiente, per esempio a lunghezza intera da 70 cm, e ponendola in posizione alta e libera, si presuppone che si possano raggiungere alcuni chilometri in città e alcune decine in aperta campagna. Le misure riportate vanno intese come approssimative anche se pur sempre reali.

Il telecomando LoRa

Il telecomando LoRa comprende sia il microprocessore Arduino che il modulo radio.

Il tutto è stato miniaturizzato per essere inseribile nel “case” di un classico telecomando tascabile/portachiavi.

A causa delle dimensioni e per uniformare le tensioni (infatti lo SX1278 funziona a 3,3 V), è stato scelto il processore Atmega32u4 con quarzo a 8 MHz, lo stesso della scheda LilyPad con USB. Il quarzo da 8 MHz al posto di quello a 16 MHz di Arduino standard, è necessario a causa dell’alimentazione ridotta a 3,3V. In ogni caso, poiché è la stessa configurazione di LilyPad con USB, è possibile (e necessario) selezionare questa piattaforma dall’elenco dell’IDE di programmazione.

Ovviamente, come sapranno già gli affezionati programmatori di Arduino, la programmazione ha sempre le stesse caratteristiche di quella destinata ad “Arduino Uno”, in quanto è l’IDE che si preoccupa di tenere conto della diversa velocità di clock in fase di compilazione. Per la programmazione è stata prevista sul telecomando una presa micro USB.
In Fig. 5 è descritto lo schema a blocchi.

Come si può notare, il trasmettitore viene alimentato dalla pressione del pulsante di comando; questo significa che il processore deve essere veloce nell’intervenire sull’interruttore elettronico, in modo da mantenere l’alimentazione al rilascio del pulsante. Infatti questa è la prima cosa che fa, senza problemi visti i tempi di intervento umano che hanno durate di alcune decine di millisecondi.

Il processore utilizza il pin D6 per portare a massa il gate del POWERMOS Q1 (a canale P) tramite il transistor T1.

Il transistor T1 agisce in parallelo al pulsante e quindi mantiene in conduzione il POWERMOS Q1 anche quando il pulsante viene rilasciato.

Una volta che ha provveduto a mantenere l’alimentazione, il processore inizializza il modulo radio con le caratteristiche LoRa definite dallo sketch e con l’indirizzo di rete e quelli locali. Inoltre inizializza il generatore di numeri pseudo-random, del compilatore C di Arduino, con un paio di valori letti dai pin analogici non utilizzati (A0 e A1) e moltiplicati fra loro. In questo modo utilizza un rumore elettronico variabile ad ogni accensione.

Quest’attività è necessaria per produrre un marker casuale del messaggio. A questo punto spedisce il messaggio con il pattern stabilito ed attende la risposta. Quando riceve una risposta positiva, segnala l’avvenuta esecuzione con un codice bip convenuto, tramite il cicalino.

Altrimenti dopo una certa attesa (qualche secondo), oppure dopo aver ricevuto una risposta negativa segnala con un diverso codice di bip. Quindi si spegne, ovvero pone basso il pin D6. Nel Listato 1 è mostrato lo sketch preparato come esempio per il telecomando LoRa.

 

In questo modo il processore ed il modulo radio sono alimentati solo per pochi secondi (con un consumo medio di circa 20 mA durante l’attività). Una semplice batteria del tipo A23 può quindi farlo funzionare per parecchio tempo.

Il server che riceve e gestisce il comando può essere implementato come riportato nello sketch di esempio presente nella libreria. Sostanzialmente non deve far altro che mettersi in ascolto della trasmissione da parte del telecomando, verificare il pattern concordato e verificare che il marker non sia presente nella lista di quelli già arrivati.

Nel caso sia un duplicato, scarta il messaggio e risponde negativamente. Nel caso, invece, sia originale, lo inserisce in una posizione casuale della lista e manda la conferma dopo aver eseguito l’azione. L’inserimento del marker nella lista in una posizione casuale, sovrascrivendo quello eventualmente presente, serve a evitare una qualunque periodicità.

Naturalmente è sempre presente la possibilità di ricevere un messaggio con un marker nella lista anche se originale. Ma poiché la trasmissione è bidirezionale, il server avverte della mancata attivazione e si può semplicemente ripetere il comando.

Listato 1

LORA LR; //Istanza della classe (per gli altri parametri globali utilizzati vedere il codice completo)

void setup() {
  pinMode(pinon, OUTPUT); // attiva il MOS per mantenere l’alimentazione 
  digitalWrite(pinon, 1);
  digitalWrite(pinf, 1); // predispone il cicalino 
  digitalWrite(psound, 1);

  if (!LR.begin(KEY)) {
    sketchend(1);
    return;
  } // inizializza il modulo radio e la chiave crittografica

  LR.defDevRange(RANGECODE); // inizializza i parametri di rete e di trasmissione
  LR.defNetAddress(NETADD);
  LR.setFrequency(FREQ);
  LR.setPower(PWR);
  LR.setConfig(SF, BW, CR);

  int seed = analogRead(0) * analogRead(1); // inizializza il generatore random con il rumore elettr.
  randomSeed(seed);

  sendCommand(); // spedisce il comando
  if (!getCommandReply()) {
    sketchend(2);
    return;
  } // se la risposta è OK avvisa con un segnale di beep
  // altrimenti avvisa con un diverso segnale di beep
  sketchend(0); // si auto spegne
}

void loop() // non utilizzata
{}

La rete LoraWAN

Da un paio di anni esiste un consorzio di nome LoRa Alliance, che riunisce gli operatori (tra cui IBM) che producono o usano la tecnologia LoRa per IoT brevettata da Semtech.

Lo scopo del consorzio è definire e aggiornare un protocollo di rete per gli scopi dell’IoT. Inoltre ha il compito di certificare i prodotti che usano questo protocollo, che si chiama LoRaWAN.

Da un punto di vista elettrico (strato fisico di un modello teorico ISO/OSI), la trasmissione avviene sulla banda degli 868MHz (in Europa), potendo contare su 10 canali, con spread factor SF da 7 a 12, con band width BW di 125 o 250 kHz e con potenze di 14 dBm.

La struttura della rete è stellare, il che evita i processi periodici di sincronizzazione delle strutture a griglia. La LoRaWAN si compone delle parti seguenti.
1. Uno o più Concentratori/Gateway che comunicano con gli End-device ed instradano su protocollo TCP/IP il sub-protocollo LoRaWAN. Un Server LoRaWAN sulla rete Internet raccoglierà e presenterà i dati estratti dal protocollo LoRaWAN. Per questo motivo la struttura può essere considerata come una struttura a stella di stelle.
2. Più End-device; ovvero sensori e/o attuatori sul campo. Possono essere:
A) Classe A. Classe base standard. È un apparato a bassissimo consumo che decide autonomamente quando collegarsi al Concentratore. Dopo aver spedito il messaggio si pone in ascolto per un tempo limitato (5 sec.) per due volte a distanza di un secondo, per dare al Concentratore l’opportunità di spedire una conferma o un comando.
B) Classe B. È l’evoluzione della classe A. Oltre a poter funzionare come classe A permette di ricevere messaggi dal Concentratore ma solo con finestre temporali predefinite. L’End-device di tipo B si può sincronizzare con il Concentratore rilevando un messaggio particolare (beacon) periodicamente spedito ogni 120 secondi. In sostanza, può essere inattiva eccetto quando deve spedire qualcosa o quando si deve mettere periodicamente in attesa di comunicazioni da parte del concentratore per pochi secondi. L’End-device di tipo B è l’End-device con implementazione più complessa, per questo, attualmente è poco realizzata.
C) Casse C. Classe senza particolari problemi di alimentazione. Questo tipo di End-device può ricevere sempre, eccetto ovviamente quando è in trasmissione (ricordiamo che LoRa è un sistema di trasmissione half-duplex). Non è l’evoluzione della classe B, ma semmai della classe A senza limitazioni di finestre temporali per la ricezione. I pacchetti previsti dal protocollo hanno una struttura ben definita e complessa, e sono crittografati con tecnologia AES128.

Gli elementi della rete sono schematizzati in Fig. 6. La struttura dei pacchetti è definita dalle specifiche pubblicate dalla LoRa Alliance TM. Gli End-device si possono collegare con più concentratori per aumentare l’affidabilità e la sicurezza. Lo spazio di indirizzamento in una rete LoRaWAN è il seguente:
• Identificatore di device (universalmente unico): 64 bit (standard EUI64) (definito dal costruttore)
• Indirizzo del device in rete: 32 bit (non universalmente unico)
• Identificatore di Applicazione LoRaWAN (unico): 64 bit (EUI64)
• Identificatore di gateway (unico): 64 bit (EUI64)

È chiaro che questo tipo di tecnologia è indirizzato a soggetti pubblici o privati che operano il controllo del territorio. Infatti, oltre che ai sistemi di allarme, una LPWAN (Low Power Wide Area Network) è indirizzata al controllo dei rifiuti, dell’illuminazione, della qualità dell’aria o dell’acqua, dei parcheggi, o, in campo agricolo, dei dati del terreno, dell’irrigazione ecc.

Naturalmente questi servizi hanno un costo, ma ultimamente si sono mobilitate anche forze spontanee per l’implementazione gratuita di reti cittadine, come l’organizzazione “THE THINGS Network”.

 

Uso alternativo dell’hardware del telecomando

Se in parallelo al pulsante colleghiamo un contatto pulito, come ad esempio un contatto reed di quelli per porte e finestre (quello degli antifurto, ndr), realizzeremo un efficiente sensore wireless di allarme anti-intrusione.

Per esempio collegandolo ad una porta potremo ricevere sul server, anche molto distante, la segnalazione dell’apertura che potrà essere utilizzata come allarme o come registrazione di evento. Infatti ricordiamo che lo shield LoRa può essere montato su RandA (la nostra shield per Raspberry Pi che integra il core di Arduino UNO) dove il processore Raspberry Pi può agire come un sofisticato server, eventualmente collegato in Internet.

La miniaturizzazione del telecomando e la sua auto-alimentazione lo predispongono ad essere posizionato ovunque sia necessario un sensore attivato meccanicamente. Se poi aggiungessimo un piccolo circuito che realizzi un timer a bassissimo consumo (di pochi nanoampere), potremmo azionare elettronicamente il pulsante per esempio tramite un transistor MOS che agisca come un interruttore. In questo caso potremmo periodicamente spedire al server un valore analogico letto sul pin A2 o un valore digitale sul pin D8.

Per questo utilizzo alternativo si potrebbe utilizzare un contenitore di dimensioni paragonabili a quello per telecomando come quello G1013 (con qualche adattamento), nel caso non si voglia la finestrella del pulsante.

Questi utilizzi alternativi del telecomando sono utilizzi che contano sull’attivazione momentanea del circuito che ha una alimentazione fornita da una piccola batteria non ricaricabile. Ma è già allo studio una ulteriore elaborazione del circuito del telecomando.

In questa nuova schedina, di dimensioni non troppo distanti da quella del telecomando, sarà aggiunto un carica batteria per batterie LiPo da 3,7 V. Il risultato sarà quello di avere una scheda completa di processore e modulo radio con la possibilità di essere auto-alimentata e di restare sempre accesa.

In questo modo il sistema potrà mettersi in ascolto di messaggi in arrivo o di originarne di suoi in base ad allarmi di varia natura. Infatti saranno aumentati i pin analogici e digitali disponibili sulla microscheda.

In sostanza è previsto un insieme di tre tipi di apparati (Fig. 6):
• shield per Arduino (e quindi anche per RandA) già presentato e destinato ad attività di server o di stazioni più elaborate;
• microscheda con possibilità di auto-alimentazione tramite batteria ricaricabile, comprensiva di processore Arduino (del tipo LilyPad) e modulo radio; destinata a stazioni periferiche anche a pannelli solari.
• telecomando/allarme meccanico, presentato in questo articolo.

Conclusioni

Con il trasmettitore LoRa miniaturizzato e con il prossimo auto-alimentato si completa l’offerta di sistemi programmabili che possono formare una rete proprietaria per una infinità di usi diversi.

L’utilizzo della libreria proposta in questo articolo rende queste reti molto flessibili e lontane dalla complessa rigidità della LoRaWAN. LoRaWAN nasce per standardizzare in senso industriale l’IoT. Ed è pensata per instradare su Internet questi scambi di informazioni con numerosi satelliti di sensori ed attuatori in una logica molto codificata (vedere riquadro di approfondimento).

Non volendo entrare in questa realtà più complessa, e per la quale sarebbe più opportuno un modulo operante a 868 MHz, sarebbe un peccato non utilizzare comunque le grandi potenzialità di questo splendido modulo radio.

Nota: nel pacchetto LoRa è presente un Byte chiamato Sync-Word che ha valore 0x12 come valore predefinito (registro 0x39 dello SX1278), ma che viene modificato con il valore 0x34 nel caso di trasmissioni LoRaWAN; ciò per differenziare maggiormente le trasmissioni LoRaWAN da altre trasmissioni con protocolli proprietari come il nostro.

Con questi apparati e questa libreria è possibile realizzare diverse soluzioni personalizzate. Per esempio:
• un sofisticato sistema antifurto per auto con allarme sullo stesso telecomando;
• sistema di allarme sofisticato ed esteso per abitazioni o aziende;
• una gestione di sensori ed elettrovalvole in campo agricolo;
• una automazione di appartamenti e ville su grande scala;
• una sorveglianza di valori critici ambientali.

Esistono comunque altre applicazioni del sistema, che sarebbe lungo elencare e che preferiamo lasciare alla vostra inventiva.